Re: [RFC v8 net-next 00/16] add support for VSC7512 control over SPI

[Colin Foster <colin.foster@in-advantage.com>]

Hi Vladimir,

On Thu, May 19, 2022 at 02:44:41PM +0000, Vladimir Oltean wrote:
> Hi Colin,
> 
> On Sat, May 14, 2022 at 03:00:10PM -0700, Colin Foster wrote:
> > On Mon, May 09, 2022 at 05:13:05PM +0000, Vladimir Oltean wrote:
> > > Hi Colin,
> > > 
> > > On Sun, May 08, 2022 at 11:52:57AM -0700, Colin Foster wrote:
> > > > 
> > > > 		mdio0: mdio0@0 {
> > > 
> > > This is going to be interesting. Some drivers with multiple MDIO buses
> > > create an "mdios" container with #address-cells = <1> and put the MDIO
> > > bus nodes under that. Others create an "mdio" node and an "mdio0" node
> > > (and no address for either of them).
> > > 
> > > The problem with the latter approach is that
> > > Documentation/devicetree/bindings/net/mdio.yaml does not accept the
> > > "mdio0"/"mdio1" node name for an MDIO bus.
> > 
> > I'm starting this implementation. Yep - it is interesting.
> > 
> > A quick grep for "mdios" only shows one hit:
> > arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts
> > 
> > While that has an mdios field (two, actually), each only has one mdio
> > bus, and they all seem to get parsed / registered through
> > sja1105_mdiobus_.*_register.
> > 
> > 
> > Is this change correct (I have a feeling it isn't):
> > 
> > ocelot-chip@0 {
> >     #address-cells = <1>;
> >     #size-cells = <0>;
> > 
> >     ...
> > 
> >     mdio0: mdio@0 {
> >         reg=<0>;
> >         ...
> >     };
> > 
> >     mdio1: mdio@1 {
> >         reg = <1>;
> >         ...
> >     };
> >     ...
> > };
> > 
> > When I run this with MFD's (use,)of_reg, things work as I'd expect. But
> > I don't directly have the option to use an "mdios" container here
> > because MFD runs "for_each_child_of_node" doesn't dig into
> > mdios->mdio0...
> 
> Sorry for the delayed response. I think you can avoid creating an
> "mdios" container node, but you need to provide some "reg" values based
> on which the MDIO controllers can be distinguished. What is your convention
> for "reg" values of MFD cells? Maybe pass the base address/size of this
> device's regmap as the "reg", even if the driver itself won't use it?

No worries. Everyone is busy.

Right now it looks like this:

}, {
    .name = "ocelot-miim0",
    .of_compatible = "mscc,ocelot-miim",
    .of_reg = 0,
    .use_of_reg = true,
    .num_resources = ARRAY_SIZE(vsc7512_miim0_resources),
    .resources = vsc7512_miim0_resources,
}, {
    .name = "ocelot-miim1",
    .of_compatible = "mscc,ocelot-miim",
    .num_resources = ARRAY_SIZE(vsc7512_miim1_resources),
    .of_reg = 1,
    .use_of_reg = true,
    .resources = vsc7512_miim1_resources,
}, {

"0" and "1" being somewhat arbitrary... although they are named as such
in the datasheet.


So you're thinking it might look more like:

.of_reg = vsc7512_miim0_resources[0].start,

and the device tree would be:

mdio0: mdio@0x7107009c {
    reg = <0x7107009c>;
};


I could see that making sense. The main thing I don't like is applying
the address-cells to every peripheral in the switch. It seems incorrect
to have:

switch {
    address-cells = <1>;
    mdio0: mdio@7107009c {
        reg = <0x7107009c>;
    };
    gpio: pinctrl {
        /* No reg parameter */
    };
};

That's what I currently have. To my surprise it actually doesn't throw
any warnings, which I would've expected.


I could see either 0/1 or the actual base addresses making sense.
Whichever you'd suggest.

I've got another day or two to button things up, so it looks like I
missed the boat for this release. This should be ready to go on day 1
after the window.