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