All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>,
	davem@davemloft.net, shawnguo@kernel.org,
	linux-arm-kernel@lists.infradead.org, qiangqing.zhang@nxp.com,
	robh+dt@kernel.org, netdev@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH net-next] ARM: dts: imx6qdl: Remove unnecessary mdio #address-cells/#size-cells
Date: Sat, 24 Jul 2021 12:14:09 -0700	[thread overview]
Message-ID: <6e280dae-2c94-efb9-8d34-a12cce89b6f4@gmail.com> (raw)
In-Reply-To: <20210724170310.ylouwttmutkpin42@skbuf>



On 7/24/2021 10:03 AM, Vladimir Oltean wrote:
> On Sat, Jul 24, 2021 at 09:37:35AM -0700, Florian Fainelli wrote:
>> On 7/23/2021 6:08 AM, Vladimir Oltean wrote:
>>> Hi Fabio,
>>>
>>> On Fri, Jul 23, 2021 at 08:28:35AM -0300, Fabio Estevam wrote:
>>>> 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?

Oh yes, it is fraught with peril in most cases, however for some simple 
cases like dedicated MDIO bus and single Ethernet PHY on the bus this 
works quite nicely. We have a bunch of reference boards that allow us to 
connect either a MTSIF or RGMII daughter card and we scan the MDIO bus 
in the boot loader if the networking stack is initialized (in which case 
the DT gets patched accordingly), else, we leave it to Linux to probe 
for the PHY.

> 
> 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.

Yes, the "reg" property is technically optional, however #address-cells 
and #size-cells are not, or rather they only are useful if "reg" is 
provided so it can be checked accordingly, humm.
-- 
Florian

WARNING: multiple messages have this Message-ID (diff)
From: Florian Fainelli <f.fainelli@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>,
	davem@davemloft.net, shawnguo@kernel.org,
	linux-arm-kernel@lists.infradead.org, qiangqing.zhang@nxp.com,
	robh+dt@kernel.org, netdev@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH net-next] ARM: dts: imx6qdl: Remove unnecessary mdio #address-cells/#size-cells
Date: Sat, 24 Jul 2021 12:14:09 -0700	[thread overview]
Message-ID: <6e280dae-2c94-efb9-8d34-a12cce89b6f4@gmail.com> (raw)
In-Reply-To: <20210724170310.ylouwttmutkpin42@skbuf>



On 7/24/2021 10:03 AM, Vladimir Oltean wrote:
> On Sat, Jul 24, 2021 at 09:37:35AM -0700, Florian Fainelli wrote:
>> On 7/23/2021 6:08 AM, Vladimir Oltean wrote:
>>> Hi Fabio,
>>>
>>> On Fri, Jul 23, 2021 at 08:28:35AM -0300, Fabio Estevam wrote:
>>>> 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?

Oh yes, it is fraught with peril in most cases, however for some simple 
cases like dedicated MDIO bus and single Ethernet PHY on the bus this 
works quite nicely. We have a bunch of reference boards that allow us to 
connect either a MTSIF or RGMII daughter card and we scan the MDIO bus 
in the boot loader if the networking stack is initialized (in which case 
the DT gets patched accordingly), else, we leave it to Linux to probe 
for the PHY.

> 
> 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.

Yes, the "reg" property is technically optional, however #address-cells 
and #size-cells are not, or rather they only are useful if "reg" is 
provided so it can be checked accordingly, humm.
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-24 19:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23 11:28 [PATCH net-next] ARM: dts: imx6qdl: Remove unnecessary mdio #address-cells/#size-cells Fabio Estevam
2021-07-23 11:28 ` Fabio Estevam
2021-07-23 13:08 ` Vladimir Oltean
2021-07-23 13:08   ` Vladimir Oltean
2021-07-23 13:15   ` Fabio Estevam
2021-07-23 13:15     ` Fabio Estevam
2021-07-23 13:35     ` Vladimir Oltean
2021-07-23 13:35       ` Vladimir Oltean
2021-07-24  5:21     ` Joakim Zhang
2021-07-24  5:21       ` Joakim Zhang
2021-07-24 12:48       ` Fabio Estevam
2021-07-24 12:48         ` Fabio Estevam
2021-07-24 16:37   ` Florian Fainelli
2021-07-24 16:37     ` Florian Fainelli
2021-07-24 17:03     ` Vladimir Oltean
2021-07-24 17:03       ` Vladimir Oltean
2021-07-24 19:14       ` Florian Fainelli [this message]
2021-07-24 19:14         ` Florian Fainelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6e280dae-2c94-efb9-8d34-a12cce89b6f4@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=qiangqing.zhang@nxp.com \
    --cc=robh+dt@kernel.org \
    --cc=shawnguo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.