Re: [PATCH net-next] ARM: dts: imx6qdl: Remove unnecessary mdio #address-cells/#size-cells

On Sat, Jul 24, 2021 at 09:37:35AM -0700, Florian Fainelli wrote:

On 7/23/2021 6:08 AM, Vladimir Oltean wrote:

quoted

Hi Fabio,

On Fri, Jul 23, 2021 at 08:28:35AM -0300, Fabio Estevam wrote:

quoted

Since commit dabb5db17c06 ("ARM: dts: imx6qdl: move phy properties into
phy device node") the following W=1 dtc warnings are seen:

arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi:323.7-334.4: Warning (avoid_unnecessary_addr_size): /soc/bus@2100000/ethernet@2188000/mdio: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property

Remove the unnecessary mdio #address-cells/#size-cells to fix it.

Fixes: dabb5db17c06 ("ARM: dts: imx6qdl: move phy properties into phy device node")
Signed-off-by: Fabio Estevam <festevam@gmail.com>
---

Are you actually sure this is the correct fix? If I look at mdio.yaml, I
think it is pretty clear that the "ethernet-phy" subnode of the MDIO
controller must have an "@[0-9a-f]+$" pattern, and a "reg" property. If

It is valid to omit the "reg" property of an Ethernet PHY which the kernel
will then dynamically scan for. If you know the Ethernet PHY address it's
obviously better to set it so you avoid scanning and the time spent in doing
that. The boot loader could (should?) also provide that information to the
kernel for the same reasons.

Interesting, but brittle I suppose (it only works reliably with a single
PHY on a shared MDIO bus). NXP has "QDS" boards for internal development
and these have multi-port riser cards with various PHYs for various
SERDES protocols, and we have a really hard time describing the hardware
in DT (we currently use overlays applied by U-Boot), so we would like
some sort of auto-detection of PHYs if that was possible, but I think
that for anything except the simplest of cases it isn't. For example
what happens if you unbind and rebind two net devices in a different
order - they will connect to a PHY at a different address, won't they?

Anyway, I was wrong, ok, but I think the point still stands that
according to mdio.yaml this DT description is not valid. So after your
explanation, it is the DT schema that we should update.