Message-ID: <fa7965d2ab94b8dd256450e27e36ebe368750f3f.camel@ew.tq-group.com>
Date:   Wed, 28 Jul 2021 11:13:25 +0200
From:   Matthias Schiffer <matthias.schiffer@...tq-group.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        David Lechner <david@...hnology.com>,
        linux-kernel@...r.kernel.org, Lee Jones <lee.jones@...aro.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH] regmap: do not call regmap_debugfs_init() from
 regmap_attach_dev()

[adding syscon maintainers to CC again]

On Tue, 2021-07-27 at 18:08 +0100, Mark Brown wrote:
> * PGP Signed by an unknown key
> 
> 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.

The core syscon driver doesn't create a device anymore for regmaps
obtained using syscon_node_to_regmap() etc. since bdb0066df96e ("mfd:
syscon: Decouple syscon interface from platform devices") - so there is
no device the regmap could be bound to here.

(in fact, the platform_driver part of the syscon driver could have been
removed a while ago as suggested in that commit's description, as
nothing is using it anymore sice ~2018 - I'll send a patch to do that
later)

With no device available to own the regmap, leaving it unset seems
better to me than allowing an arbitrary consumer of the syscon regmap
to claim ownership.

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

`git grep 'regmap_init[^(]*(NULL'` gives me 5 places, one of them being
in the mentioned syscon driver (which in turn is used by 200~300 of
other drivers). There might be others where NULL isn't passed directly.

Powered by blists - more mailing lists