Message-ID: <20251121170308.tntvl2mcp2qwx6qz@skbuf>
Date: Fri, 21 Nov 2025 19:03:08 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Lee Jones <lee@...nel.org>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Russell King <linux@...linux.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 07/15] mfd: core: add ability for cells to probe
 on a custom parent OF node

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.

Powered by blists - more mailing lists