linux-kernel - Re: [RFC PATCH net-next 2/9] dt-bindings: net: Expand pcs-handle to an array

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 12 Jul 2022 16:59:53 +0100
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Sean Anderson <sean.anderson@...o.com>,
        Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>,
        Madalin Bucur <madalin.bucur@....com>,
        "David S . Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        linux-kernel@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
        Andrew Lunn <andrew@...n.ch>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org
Subject: Re: [RFC PATCH net-next 2/9] dt-bindings: net: Expand pcs-handle to
 an array

On Tue, Jul 12, 2022 at 05:18:05PM +0200, Krzysztof Kozlowski wrote:
> On 12/07/2022 17:06, Sean Anderson wrote:
> > Hi Krzysztof,
> > 
> > On 7/12/22 4:51 AM, Krzysztof Kozlowski wrote:
> >> On 11/07/2022 18:05, Sean Anderson wrote:
> >>> This allows multiple phandles to be specified for pcs-handle, such as
> >>> when multiple PCSs are present for a single MAC. To differentiate
> >>> between them, also add a pcs-names property.
> >>>
> >>> Signed-off-by: Sean Anderson <sean.anderson@...o.com>
> >>> ---
> >>>
> >>>  .../devicetree/bindings/net/ethernet-controller.yaml       | 7 ++++++-
> >>>  1 file changed, 6 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> >>> index 4f15463611f8..c033e536f869 100644
> >>> --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> >>> +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> >>> @@ -107,11 +107,16 @@ properties:
> >>>      $ref: "#/properties/phy-connection-type"
> >>>  
> >>>    pcs-handle:
> >>> -    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> >>>      description:
> >>>        Specifies a reference to a node representing a PCS PHY device on a MDIO
> >>>        bus to link with an external PHY (phy-handle) if exists.
> >>
> >> You need to update all existing bindings and add maxItems:1.
> >>
> >>>  
> >>> +  pcs-names:
> >>
> >> To be consistent with other properties this should be "pcs-handle-names"
> >> and the other "pcs-handles"... and then actually drop the "handle".
> > 
> > Sorry, I'm not sure what you're recommending in the second half here.
> 
> I would be happy to see consistent naming with other xxxs/xxx-names
> properties, therefore I recommend to:
> 1. deprecate pcs-handle because anyway the naming is encoding DT spec
> into the name ("handle"),
> 2. add new property 'pcs' or 'pcss' (the 's' at the end like clocks but
> maybe that's too much) with pcs-names.
> 
> However before implementing this, please wait for more feedback. Maybe
> Rob or net folks will have different opinions.

We decided on "pcs-handle" for PCS for several drivers, to be consistent
with the situation for network PHYs (which are "phy-handle", settled on
after we also had "phy" and "phy-device" and decided to deprecate these
two.

Surely we should have consistency within the net code - so either "phy"
and "pcs" or "phy-handle" and "pcs-handle" but not a mixture of both?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!