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  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 <>
To:     Clément Léger <>
Cc:     Vivien Didelot <>,
        Florian Fainelli <>,
        Vladimir Oltean <>,
        "David S . Miller" <>,
        Jakub Kicinski <>,
        Paolo Abeni <>,
        Rob Herring <>,
        Krzysztof Kozlowski <>,
        Geert Uytterhoeven <>,
        Magnus Damm <>,
        Heiner Kallweit <>,
        Russell King <>,
        Thomas Petazzoni <>,
        Herve Codina <>,
        Miquèl Raynal <>,
        Milan Stevanovic <>,
        Jimmy Lalande <>,,,,
Subject: Re: [PATCH net-next 09/12] ARM: dts: r9a06g032: describe MII

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

O.K, looking at figure 8.1.

What the user wants to express is something like:


plus maybe


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.


Powered by blists - more mailing lists