linux-kernel - Re: [PATCH net-next 03/12] dt-bindings: net: pcs: add bindings for Renesas RZ/N1 MII converter

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, 19 Apr 2022 17:00:44 +0200
From:   Clément Léger <clement.leger@...tlin.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Magnus Damm <magnus.damm@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Herve Codina <herve.codina@...tlin.com>,
        Miquèl Raynal <miquel.raynal@...tlin.com>,
        Milan Stevanovic <milan.stevanovic@...com>,
        Jimmy Lalande <jimmy.lalande@...com>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        linux-renesas-soc@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 03/12] dt-bindings: net: pcs: add bindings for
 Renesas RZ/N1 MII converter

Le Tue, 19 Apr 2022 08:43:47 -0500,
Rob Herring <robh@...nel.org> a écrit :

> > +  clocks:
> > +    items:
> > +      - description: MII reference clock
> > +      - description: RGMII reference clock
> > +      - description: RMII reference clock
> > +      - description: AHB clock used for the MII converter register interface
> > +
> > +  renesas,miic-cfg-mode:
> > +    description: MII mux configuration mode. This value should use one of the
> > +                 value defined in dt-bindings/net/pcs-rzn1-miic.h.  
> 
> Describe possible values here as constraints. At present, I don't see 
> the point of this property if there is only 1 possible value and it is 
> required.

The ethernet subsystem contains a number of internal muxes that allows
to configure ethernet routing. This configuration option allows to set
the register that configure these muxes.

After talking with Andrew, I considered moving to something like this:

eth-miic@...30000 {
  compatible = "renesas,rzn1-miic";

  mii_conv1: mii-conv-1 {
    renesas,miic-input = <MIIC_GMAC1_PORT>;
    port = <1>;
  };
  mii_conv2: mii-conv-2 {
    renesas,miic-input = <MIIC_SWITCHD_PORT>;
    port = <2>;
  };
   ...
};

Which would allow embedding the configuration inside the port
sub-nodes. Moreover, it allows a better validation of the values using
the schema validation directly since only a limited number of values
are allowed for each port.

> 
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +  
> > +patternProperties:
> > +  "^mii-conv@[0-4]$":
> > +    type: object  
> 
>        additionalProperties: false
> 
> > +    description: MII converter port
> > +
> > +    properties:
> > +      reg:
> > +        maxItems: 1  
> 
> Why do you need sub-nodes? They don't have any properties. A simple mask 
> property could tell you which ports are present/active/enabled if that's 
> what you are tracking. Or the SoC specific compatibles you need to add 
> can imply the ports if they are SoC specific.

The MACs are using phandles to these sub-nodes to query a specific MII
converter port PCS:

switch@...50000 {
    compatible = "renesas,rzn1-a5psw";

    ports {
        port@0 {
            reg = <0>;
            label = "lan0";
            phy-handle = <&switch0phy3>;
            pcs-handle = <&mii_conv4>;
        };
    };
};

According to Andrew, this is not a good idea to represent the PCS as a
bus since it is indeed not a bus. I could also switch to something like
pcs-handle = <&eth_mii 4> but i'm not sure what you'd prefer. We could
also remove this from the device-tree and consider each driver to
request the MII ouput to be configured using something like this for
instance:

 miic_request_pcs(pcs_np, miic_port_nr, MIIC_SWITCHD_PORT);

But I'm not really fan of this because it requires the drivers to
assume some specificities of the MII converter (port number are not in
the same order of the switch for instance) and thus I would prefer this
to be in the device-tree.

Let me know if you can think of something that would suit you
better but  keep in mind that I need to correctly match a switch/MAC
port with a PCS port and that I also need to configure MII internal
muxes. 

For more information, you can look at section 8 of the manual at [1].

Thanks,

[1]
https://www.renesas.com/us/en/document/mah/rzn1d-group-rzn1s-group-rzn1l-group-users-manual-system-introduction-multiplexing-electrical-and
-- 
Clément Léger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com