netdev - 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:16:46 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Clément Léger <clement.leger@...tlin.com>
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

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.

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

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

> 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

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.

	  Andrew