linux-kernel - Re: [net-next RFC PATCH 03/14] dt-bindings: net: document ethernet PHY package nodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <655e4939.5d0a0220.d9a9e.0491@mx.google.com>
Date:   Wed, 22 Nov 2023 19:32:22 +0100
From:   Christian Marangi <ansuelsmth@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Rob Herring <robh@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Florian Fainelli <florian.fainelli@...adcom.com>,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@...adcom.com>,
        Daniel Golle <daniel@...rotopia.org>,
        Qingfang Deng <dqfext@...il.com>,
        SkyLake Huang <SkyLake.Huang@...iatek.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        David Epping <david.epping@...singlinkelectronics.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
        Harini Katakam <harini.katakam@....com>,
        Simon Horman <horms@...nel.org>,
        Robert Marko <robert.marko@...tura.hr>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-msm@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org
Subject: Re: [net-next RFC PATCH 03/14] dt-bindings: net: document ethernet
 PHY package nodes

On Tue, Nov 21, 2023 at 03:45:42PM +0100, Andrew Lunn wrote:
> > > I do think we need somewhere to put package properties. But i don't
> > > think phy-mode is such a property. At the moment, i don't have a good
> > > example of a package property.
> > 
> > What about power supplies and reset/enable lines?
> 
> Yes, good point. I can imagine some packages sharing regulators. Reset
> might also be shared, but it makes things messy to handle.
>

Sooooo.... Sorry if I insist but I would really love to have something
""stable"" to move this further. (the changes are easy enough so it's
really a matter of finding a good DT structure)

Maybe a good idea would be summarize the concern and see what solution
was proposed:

Concern list:
1. ethernet-phy-package MUST be placed in mdio node (not in ethernet,
   the example was wrong anyway) and MUST have an addr

   Current example doesn't have an addr. I would prefer this way but
   no problem in changing this.

   Solution:
     - Add reg to the ethernet-phy-package node with the base address of
       the PHY package (base address = the first PHY address of the
       package)

       We will have a PHY node with the same address of the PHY package
       node. Each PHY node in the PHY package node will have reg set to
       the REAL address in the mdio bus.

2. global-phys are redundant and can be dropped.

   They are used to facilitate and make it less obscure how the PHY
   package is described. Can totally be handled internally by the PHY
   driver. Still I would prefer to keep them as is.

   Solution:
     - Drop the thing and leave the PHY driver handle it with hardcoded
       values.
       Due to point 1, the shared struct will have the base address of
       the PHY package and will be handle to reference the global PHY at
       an offset from the base address.

3. phy-mode is problematic.

   It's an optional value to enforce a specific mode for each PHY in the
   package. For complex configuration the mode won't be defined.

   Solution:
    - Rename it to package-phy-mode to make it less confusing.

    - Add an additional function that PHY package can use to make custom
      validation on the mode for every PHY attached (in the PHY package).

      Would make it less clear but more flexible for complex
      configuration. Maybe both solution can be implemented and the
      special function is used if the mode is not defined?

4. Not finding a correct place to put PHY package info.

   I'm still convinced the mdio node is the correct place.
   - PHY package are PHY in bundle so they are actual PHY
   - We already have in the mdio node special handling (every DSA switch
     use custom compatible and PHY ID is not used to probe them
     normally)
   - Node this way won't be treated as PHY as they won't match the PHY
     node name pattern and also won't have the compatible pattern for
     PHY.

   Solution:
    - ethernet-phy-package node is OK given a reg is defined.

These are the 4 concern we have currently, hoping I didn't miss any, I
hope we can sort those so I can send a v2 and make some progress on
this.

-- 
	Ansuel