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

James Hilliard <[email protected]>
Newsgroups dev.linux.lists.mfd,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <CADvTj4qUEA-ccFj0cSQgHb8+0jB4m6tcpsZZwveZhC_RE8w9vA@mail.gmail.com>
On Tue, Aug 11, 2026 at 2:47 AM Arnd Bergmann <[email protected]> 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 <[email protected]>
>
> 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/[email protected]/

> 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/[email protected]/

>
>      Arnd
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.