On Tue, Jul 27, 2021 at 02:24:17PM +0200, Matthias Schiffer wrote:
> On Mon, 2021-07-26 at 19:48 +0100, Mark Brown wrote:

> > The whole point here is to move the debugfs directory so if any fix
> > stops that happening it's not really viable.

> Looking at the history, I assume this already broke with cffa4b2122f5
> ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev").
> This is why the kernel is trying to recreate the "dummy" debugfs
> directory on my system when regmap_attach_dev() is called by imx-
> pinctrl.

Right, before that we'd just overwrite the existing name.

> I'm not convinced that the behaviour before that commit was strictly
> better - when regmap_debugfs_init() was called for the second time, the
> new debugfs paths would be created, but the old ones were never
> removed, they just leaked.

There's definitely a memory leak, although unless you're instantiating a
lot of these devices it's going to be hard to notice.

> The thing on which I need clarification is whether it is okay to bind a
> device to these shared regmaps at all:

> There is nothing preventing two different drivers from calling
> regmap_attach_dev() on the same regmap (AFAICT, this is actually
> happening when both imx_rproc and reset-imx7 are enabled, as both use
> the same syscon "SRC").

It's OK for one device to do it, but it should probably be the core
syscon code not some random driver that happens to talk to the syscon.
All the current users look at least somewhat suspicious unless they
somehow coordinate with each other in ways that I can't determine.

> What I'm trying to find out here is if there are any legitimate users
> of regmap_attach_dev(). If there aren't any, we can remove the API and
> don't need to fix it.

There's a definite use case for it.  What's probably more interesting
is if we have any users that create regmaps without a device, currently
I can't seem to find any though it's possible my greps weren't good
enough to spot them.