linux-kernel - Re: [PATCH net-next 09/12] ARM: dts: r9a06g032: describe 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:   Fri, 15 Apr 2022 16:38:53 +0200
From:   Clément Léger <clement.leger@...tlin.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     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>,
        Rob Herring <robh+dt@...nel.org>,
        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 09/12] ARM: dts: r9a06g032: describe MII
 converter

Le Fri, 15 Apr 2022 16:16:46 +0200,
Andrew Lunn <andrew@...n.ch> a écrit :

> On Fri, Apr 15, 2022 at 10:24:53AM +0200, Clément Léger wrote:
> > Le Fri, 15 Apr 2022 01:22:01 +0200,
> > Andrew Lunn <andrew@...n.ch> a écrit :
> >   
> > > On Thu, Apr 14, 2022 at 02:22:47PM +0200, Clément Léger wrote:  
> > > > Add the MII converter node which describes the MII converter that is
> > > > present on the RZ/N1 SoC.    
> > > 
> > > Do you have a board which actually uses this? I just noticed that
> > > renesas,miic-cfg-mode is missing, it is a required property, but maybe
> > > the board .dts file provides it?
> > > 
> > >     Andrew  
> > 
> > Hi Andrew, yes, I have a board that defines and use that.  
> 
> Great. Do you plan to mainline it? It is always nice to see a user.

Although we are working on a specific customer board, we will probably
try to mailine this support for the RZ/N1D-DB.

> 
> > The
> > renesas,miic-cfg-mode actually configures the muxes that are present on
> > the SoC. They allows to mux the various ethernet components (Sercos
> > Controller, HSR Controller, Ethercat, GMAC1, RTOS-GMAC).
> > All these muxes are actually controller by a single register
> > CONVCTRL_MODE. You can actually see the muxes that are present in the
> > manual [1] at Section 8 and the CONVCTRL_MODE possible values are listed
> > on page 180.
> > 
> > This seems to be something that is board dependent because the muxing
> > controls the MII converter outputs which depends on the board layout.  
> 
> Does it also mux the MDIO lines as well?

Nope, the MDIO lines are muxed using the pinctrl driver.

> 
> We might want to consider the name 'mux'. Linux already has the
> concept of a mux, e.g. an MDIO mux, and i2c mux etc. These muxes have
> one master device, which with the aid of the mux you can connect to
> multiple busses. And at runtime you flip the mux as needed to access
> the devices on the multiple slave busses. For MDIO you typically see
> this when you have multiple Ethernet switch, each has its own slave
> MDIO bus, and you use the mux to connect the single SOC MDIO bus
> master to the various slave busses as needed to perform a bus
> transaction. I2C is similar, you can have multiple SFPs, either with
> there own IC2 bus, connected via a mux to a single I2C bus controller
> on the SoC.
> 
> I've not looked at the data sheet yet, but it sounds like it operates
> in a different way, so we might want to avoid 'mux'.

Indeed, Let's not refer to it as mux in the code at all. If using your
proposal below, I guess we could avoid that.

> 
> > I'm open to any modification for this setup which does not really fit
> > any abstraction that I may have seen.
> > 
> > [1]
> > https://www.renesas.com/us/en/document/mah/rzn1d-group-rzn1s-group-rzn1l-group-users-manual-system-introduction-multiplexing-electrical-and  
> 
> O.K, looking at figure 8.1.
> 
> What the user wants to express is something like:
> 
> Connect MI_CONV5 to SECOS PORTA
> Connect MI_CONV4 to ETHCAT PORTB
> Connect MI_CONV3 to SWITCH PORTC
> Connect MI_CONV2 to SWITCH PORTD
> 
> plus maybe
> 
> Connect SWITCH PORTIN to RTOS

Yes, that is correct.

> 
> So i guess i would express the DT bindings like this, 5 values, and
> let the driver then try to figure out the value you need to put in the
> register, or return -EINVAL. For DT bindings we try to avoid magic
> values which get written into registers. We prefer a higher level
> description, and then let the driver figure out how to actually
> implement that.

Ok, looks like a more flexible way to doing it. Let's go with something
like this:

renesas,miic-port-connection = <PORTIN_GMAC2>, <MAC2>, <SWITCH_PORTC>,
<SWITCH_PORTB>, <SWITCH_PORTA>;





-- 
Clément Léger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com