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

[James Hilliard]

On Tue, Aug 11, 2026 at 2:47 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Tue, Aug 11, 2026, at 10:27, James Hilliard wrote:
> > of_syscon_register_regmap() publishes an externally owned regmap in the
> > global syscon list, but provides no way for a removable driver to
> > withdraw it. Registering a devm-managed regmap from such a driver would
> > therefore leave a stale pointer after unbind.
> >
> > Factor external registration through an internal helper and add
> > devm_of_syscon_register_regmap(). The managed action removes the entry
> > under the syscon list lock before later devres actions release the
> > regmap. Hold a device-node reference for the lifetime of every
> > externally registered entry so its lookup key also remains valid.
> >
> > Consumers of a removable provider remain responsible for ordering
> > teardown, for example with a managed device link.
> >
> > Signed-off-by: James Hilliard <james.hilliard1@xxxxxxxxx>
>
> Hi James,
>
> 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@xxxxxxx/

> 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.

Here's how I was doing it previously:
https://lore.kernel.org/all/20260806-submit-acx00-of-dynamic-v1-v4-2-9bf2f7441632@xxxxxxxxx/

>
>      Arnd