Re: [PATCH net-next v3 2/8] dt-bindings: net: Add SoC-e SWIP MDIO controller

[Vasilij Strassheim <v.strassheim@linutronix.de>]

On Wed, 2026-09-30 at 20:24 +0200, Andrew Lunn wrote:
> On Wed, Sep 30, 2026 at 07:13:35PM +0200, Vasilij Strassheim wrote:
> > On Wed, 2026-09-30 at 17:14 +0200, Andrew Lunn wrote:
> > > On Wed, Sep 30, 2026 at 04:00:56PM +0200, Vasilij Strassheim wrote:
> > > > On Sat, 2026-09-26 at 00:55 +0200, Andrew Lunn wrote:
> > > > > > The controller exposes separate register regions for transaction data
> > > > > > and for the shared transaction control and external bus selector
> > > > > > register.
> > > > > 
> > > > > > +examples:
> > > > > > +  - |
> > > > > > +    mdio@204 {
> > > > > > +        compatible = "soce,swip-mdio-23-02";
> > > > > > +        reg = <0x204 0xc>, <0x200 0x4>;
> > > > > 
> > > > > At least in the example, they are not separate?
> > > > 
> > > > Not separate regions but registers...
> > > > I'm obviously bad at documenting things.
> > > > 
> > > > The current information in the commit message is misleading and
> > > > irrelevant. Looking at the bot's feedback, it's at the same time not
> > > > clear enough yet that the mdio controller part is mapped within the
> > > > switch memory and can't be used separately from it.
> > > > 
> > > > I will update the commit message to something like this:
> > > > Add a binding for the MDIO controller integrated into SoC-e SWIP
> > > > Ethernet switch IP cores.
> > > > The controller shares the memory of the synthesized switch IP core and
> > > > cannot be used independently.
> > > 
> > > I think part of the issue is the compatible. That suggests it is a
> > > separate device, with its own driver. But it is actually driven by the
> > > switch driver.
> > 
> > I can't avoid the compatible right now. Somehow it is still a separate
> > functionality. I hope the following example doesn't cause unnecessary
> > confusion, but rather helps to understand the system better:
> > 
> > The relationship between the MDIO controller and the switch core is more
> > like that of tools in a Swiss Army knife.
> > There are a few standalone tools, such as the knife and the screwdriver.
> > These can also be described on their own. But they only make sense when
> > they are attached to the knife as a whole. As soon as one takes it
> > apart, the individual tools can no longer be used effectively. At the
> > same time, no one needs to worry about the screwdriver if they only need
> > the knife.
> 
> Maybe consider an MFD.
> 
> You then do get independent devices.
> 
> Also, with the current structure, i'm not sure how the mdio-mux is
> getting instantiated. You list it inside the switch node, so i don't
> think i will get turned into a platform device and probed. An MFD
> might helper, maybe.
> 
> There are other switches which are described as MFD, so it is not
> unknown.

I was initially thinking that an MFD would be too much for a switch, but
after looking at it more closely, it seems to be the right model here.
I will update this again with a bigger change.

I would also update the Kconfig structure. The Ethernet switch child
will be the only user-visible entry point. Selecting it will select the
"SWIP IP Core" MFD parent as well as the required MDIO controller and
mux drivers. The MFD and MDIO controller symbols will have only empty
tristate options.

> 
>       Andrew
Thanks,
Vasilij