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@xxxxxxx> 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
