Re: [PATCH v6 2/3] mfd: syscon: Add managed registration for external regmaps

["Arnd Bergmann" <arnd@arndb.de>]

On Tue, Aug 11, 2026, at 11:17, James Hilliard wrote:
> On Tue, Aug 11, 2026 at 2:47 AM Arnd Bergmann <arnd@arndb.de> wrote:

>> I don't think this is the right way to do it. As far as I can tell,
>> the device you have here is a generic mfd that uses a regmap, which
>> is not the same thing we usually call a syscon.
>>
>> The of_syscon_register_regmap() code path was added specifically
>> for chips that have a traditional syscon but depending on the
>> firmware may have to access this by some other means. This is
>> already stretching the definition of syscon. I don't think we
>> should take this further and allow normal device drivers like
>> yours to register through the syscon framework.
>
> This was suggested to me by Andrew:
> https://lore.kernel.org/all/c78c2c35-52e7-4393-9714-06039d8a3f28@lunn.ch/

Maybe Andrew can clarify, but his reply can also be interpreted
as saying that you should copy syscon_regmap_lookup_by_phandle()
into your own driver, rather than changing the actual
syscon code.

One problem I see with your current approach is that the lifetime of
the regmap is not the lifetime of the user by the framework.
Unloading the mfd driver while the phy driver is in use will
destroy the regmap. This is a direct result of syscon being
a very special case that must work during early boot instead
of being a general-purpose abstraction for managing regmaps.

>> Since you already have a top-level mfd device here, just use
>> that to pass the regmap to the child devices like we do for
>> other mfd drivers. You can e.g. do this when populating the child
>> devices through platform_data, or get the pointer from the
>> parent drvdata.
>
> The EPHY is not an MFD-created platform child. Phylib enumerates it as a
> struct phy_device on the SoC MDIO bus, so its device parent is the
> struct mii_bus rather than the AC200 I2C device. It therefore cannot
> directly obtain the AC200 regmap through parent drvdata or MFD child
> platform data.

I see, so the fundamental problem here is that you have a single
device that is connected to two buses and both the OF devicetree
and the Linux driver model are rather bad at handling this.

I would probably do this in one of two ways:

 a) have a driver module that registers both a phy driver and
    a platform_driver and figures out the interaction between
    them internally.

 b) have the MFD driver export a private interface that lets
    the phy_driver interact with the i2c registers and
    make sure the i2c_driver sets suppress_bind_attrs=true
    to prevent it from being unbound while the phy_driver
    is loaded. The symbol dependency itself is enough to
    prevent the mfd driver from being unloaded here.

In either case, you still have the choice between a proper
abstraction that can deal with multiple instances of the
ac200 device, or slightly cheaty but common assumption that
only one of them can ever be present.

      Arnd