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
| ||
|
Message-ID: <20220415163853.683c0b6d@fixe.home> 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
Powered by blists - more mailing lists