Re: [PATCH net-next 07/15] mfd: core: add ability for cells to probe on a custom parent OF node

Lee Jones
2025-12-15T15:50:33Z

Sorry for the delay.

Just getting around to some task items en-route back from Plumbers.

> On Fri, Nov 21, 2025 at 12:06:46PM +0000, Lee Jones wrote:
> > MFD is Linuxisum, simply used to split devices up such that each
> > component can be located it their own applicable subsystem and be
> > reviewed and maintained by the subject matter experts of those domains.
>
> Perfect, so the SJA1110 fits the MFD bill perfectly.
>
> I'm getting the impression that the more I write to explain, the fewer
> chances I have for you to read. I'll try to keep things as concise as I
> can, but please remember that:
> - We've had the exact same discussions with Colin Foster's VSC7512
> work, which you ended up accepting
> - This email sent to you in 2022 and again in the other reply on patch 8:
> https://lore.kernel.org/lkml/20221222134844.lbzyx5hz7z5n763n@skbuf/
> already explains what is the kind of hardware I'm dealing with
>
> > TL;DR: if your device only deals with Networking, that's where it should
> > live. And from there, it should handle its own device registration and
> > instantiation without reaching into other, non-related subsystems.
>
> Ok, you make a vague reference which I think I understand the point of.
>
> I need to merge the discussion with the one from patch 8:
> https://lore.kernel.org/netdev/20251121120037.GA1117685@google.com/
> where you say:
>
> | Another more recent avenue you may explore is the Auxiliary Bus.
>
> Excerpt from documentation here:
> https://docs.kernel.org/driver-api/auxiliary_bus.html
>
> When Should the Auxiliary Bus Be Used
>
> (...)
> The emphasis here is on a common generic interface that keeps subsystem
> customization out of the bus infrastructure.
> (...)
> A key requirement for utilizing the auxiliary bus is that there is no
> dependency on a physical bus, device, register accesses or regmap
> support. These individual devices split from the core cannot live on the
> platform bus as they are not physical devices that are controlled by
> DT/ACPI. The same argument applies for not using MFD in this scenario as
> MFD relies on individual function devices being physical devices.
>
> The thesis I need to defend is that the SJA1110 usage is 100% fit for
> MFD and 0% auxiliary bus. In order to explain it I have to give a bit of
> history on DSA.
>
> DSA is a Linuxism for managing Ethernet switches. Key thing is they are
> a hardware IP with registers to configure them. There are many ways
> to integrate an Ethernet switch hardware IP in a chip that you sell.
> You can (a) sell the IP itself for SoC vendors to put in their address
> space and access using MMIO, or you can (b) sell them an entire chip
> with the switch IP in it, that they access over a bus like PCIe, SPI,
> I2C, MDIO, whatever, and integrate with their existing Linux SoC.
>
> DSA has started from a place where it didn't really understand that its
> core domain of expertise was the Ethernet switching IP itself. The first
> devices it supported were all of the (b) kind, discrete chips on buses.
> Thus, many drivers were written where DSA takes charge of the struct
> spi_device, mdio_device, i2c_client etc.
>
> These early drivers are simplistic, they configure the switch to pass
> traffic, and the PHYs through the internal MDIO bus to establish a link,
> and voila! They pass traffic, they're good to go.
>
> Then you start to want to develop these further. You want to avoid
> polling PHYs for link status every second.. well, you find there's an
> interrupt controller in that chip too, that you should be using with
> irqchip. You want to read the chip's temperature to prevent it from
> overheating - you find temperature sensors too, for which you register
> with hwmon. You find reset blocks, clock generation blocks, power
> management blocks, GPIO controllers, what have you.
>
> See, the more you look at the datasheet, the more you start to notice
> an entire universe of hardware IPs, and then.. you notice a microcontroller!
> Those hardware IPs are all also memory-mapped in the address space of
> that microcontroller, and when you from Linux are accessing them, you're
> just going through a SPI-to-AHB bridge.
>
> Things become really shitty when the DSA chip that you want to drive
> from drivers/net/dsa has a full-blown microprocessor capable of running
> Linux instead of that microcontroller! Then you have to support driving
> the same switch from the small Linux, using MMIO, or from the big Linux,
> over SPI.
>
> Out of a lack of expressivity that we as engineers have, we call both
> the SoC at large "a switch", and the switching IP "a switch". Hell,
> we even call the rack-mounted pizza box computer with many ports "a switch",
> no wonder nobody understands anything! We just name things after the
> most important thing that's in them.
>
> So unwind 100 steps from the rabbit hole and ask: what does DSA concern
> itself with?
>
> Ideally, the answer is "the Ethernet switch IP". This is always mapped
> in somebody's address space from address X to Y.
>
> Practically, legacy makes it that DSA concerns itself with the entire
> address space of SPI devices, MDIO devices, I2C devices etc. If you
> imagine a microprocessor in these discrete chips (which is architecturally
> almost always possible), the device tree of that would only describe a
> single region with the Ethernet switching IP, and Linux would probe a
> platform device for that. The rest is.. other stuff (of various degrees
> of functional relatedness, but nonetheless, other stuff) with *other*
> platform devices.
>
> So, DSA is in a process of trying to define a conversion model that is
> coherent, compatible with the past, minimal in its description,
> applicable to other devices, and not a pain in the butt.
>
> Fact of the matter is, we will always clash with the MFD maintainer in
> this process, and it simply doesn't scale for us to keep repeating the
> same stuff over and over. It is just too much friction. We went through
> this once, with Colin Foster who added the Microchip VSC7512 as MFD
> through your tree, and that marked the first time when a DSA driver over
> a SPI device concerned itself with just the switching IP, using MFD as
> the abstraction layer.
>
> The NXP SJA1110 is just another step in that journey, but this one is
> harder because it has legacy device tree bindings to maintain. However,
> if we are to accept that Colin Foster's work was not an architectural
> mistake, then the SJA1110 is not the end of the road either, and you
> have to be prepared for more devices to come and do the same thing.
>
> So practically speaking, the fact that DSA has these particular needs
> is just a fact. Treat the above description as a "global prompt", if you
> will :)
>
> So why not the auxiliary bus? That creates auxiliary_device structures,
> which are fake things that some core device wants to keep out to make
> things leaner. But what we want is a platform_device, because that is
> the common denominator between what kind of drivers the "small Linux"
> and the "big Linux" would use for the same hardware IPs. MFD gives us
> exactly that, and regmap provides the abstraction between MMIO and SPI.
>
> ================================================================
>
> The above was the "global prompt" that you need to have in your context,
> now let's return to the patch at hand.
>
> SJA1110 is *not* capable of running Linux inside. This allows us to get
> away with partial conversions, where the DSA driver still remains in
> charge of the entire SPI device, but delegates the other stuff to MFD.
>
> The existing bindings cannot be broken. Hindsight is 20/20, but whatever
> stupid decisions I made in the past with this "mdios" container node are
> there to stay.

Thanks for drafting all of this. It's not an ideal level of verboseness
for a busy maintainer with 50+ of reviews to do, but I appreciate your
depth of knowledge and the eloquence of the writing.

There does appear to be at least some level of misunderstanding between
us. I'm not for one moment suggesting that a switch can't be an MFD. If
it contains probe-able components that need to be split-up across
multiple different subsystems, then by all means, move the core driver
into drivers/mfd/ and register child devices 'till your heart's content.

What I am saying, however, is that from what I can see in front of me,
there doesn't appear to be any evidence that this device belongs there.

Unless there's something I'm missing, it looks awfully like you're
simply trying to register a couple of platform deices devices and you've
chosen to use the MFD API as a convenient way to do so. That is not
what MFD is for.

Side note: The implementation is also janky.

> Fact of the matter is, we will always clash with the MFD maintainer in
> this process, and it simply doesn't scale for us to keep repeating the
> same stuff over and over. It is just too much friction. We went through
> this once, with Colin Foster who added the Microchip VSC7512 as MFD
> through your tree, and that marked the first time when a DSA driver over
> a SPI device concerned itself with just the switching IP, using MFD as
> the abstraction layer.

I don't recall those discussions from 3 years ago, but the Ocelot
platform, whatever it may be, seems to have quite a lot more
cross-subsystem device support requirements going on than I see here:

drivers/i2c/busses/i2c-designware-platdrv.c
drivers/irqchip/irq-mscc-ocelot.c
drivers/mfd/ocelot-*
drivers/net/dsa/ocelot/*
drivers/net/ethernet/mscc/ocelot*
drivers/net/mdio/mdio-mscc-miim.c
drivers/phy/mscc/phy-ocelot-serdes.c
drivers/pinctrl/pinctrl-microchip-sgpio.c
drivers/pinctrl/pinctrl-ocelot.c
drivers/power/reset/ocelot-reset.c
drivers/spi/spi-dw-mmio.c
net/dsa/tag_ocelot_8021q.c

> - We've had the exact same discussions with Colin Foster's VSC7512
> work, which you ended up accepting

Quick update: After doing a little searching for Colin's original
patch-set, I've managed to find as far back as v5 (v16 was merged),
which I believe was the first version that proposed using MFD. There
were lots of review comments and an insistence to add more than one
device (rather than adding them subsequently) to make it a true MFD,
however, I don't see any suggestion that MFD wasn't the right place for
it.

> Then you start to want to develop these further. You want to avoid
> polling PHYs for link status every second.. well, you find there's an
> interrupt controller in that chip too, that you should be using with
> irqchip. You want to read the chip's temperature to prevent it from
> overheating - you find temperature sensors too, for which you register
> with hwmon. You find reset blocks, clock generation blocks, power
> management blocks, GPIO controllers, what have you.

Absolutely! MFD would be perfect for that.

My point is, you don't seem to have have any of that here.

--
Lee Jones [李琼斯]