On Thu, 20 Nov 2025, Vladimir Oltean wrote:

On Thu, Nov 20, 2025 at 02:41:36PM +0000, Lee Jones wrote:

quoted

On Tue, 18 Nov 2025, Vladimir Oltean wrote:

quoted

I would like the "nxp,sja1110a" driver, in the configuration below, to
be able to probe the drivers for "nxp,sja1110-base-t1-mdio" and for
"nxp,sja1110-base-tx-mdio" via mfd_add_devices():

	ethernet-switch@0 {
		compatible = "nxp,sja1110a";

		mdios {
			mdio@0 {
				compatible = "nxp,sja1110-base-t1-mdio";
			};

			mdio@1 {
				compatible = "nxp,sja1110-base-tx-mdio";
			};
		};
	};

This device is not an MFD.

Please find a different way to instantiate these network drivers.

Ok.. but what is an MFD? I'm seriously interested in a definition.

One data point: the VSC7512 (driver in drivers/mfd/ocelot-spi.c,
bindings in Documentation/devicetree/bindings/mfd/mscc,ocelot.yaml) is
almost the same class of hardware (except the embedded Cortex-M7 in
SJA1110 can't run Linux, and the CPU in VSC7512 can). It instantiates
MDIO bus children, like this patch proposes too, except it works with a
different device tree hierarchy which I need to adapt to, without breaking.

The devices should be different types i.e. be located in different
subsystems.  If you're simply instantiating Watchdog timers, the code
should live solely in drivers/watchdog.  If the devices all pertain to
Networking, the code should live in the Networking subsystem, etc.

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.

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.

-- 
Lee Jones [李琼斯]