linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	David Lechner <david@lechnology.com>,
	linux-kernel@vger.kernel.org
Subject: Re: (EXT) Re: [PATCH] regmap: do not call regmap_debugfs_init() from regmap_attach_dev()
Date: Tue, 27 Jul 2021 18:08:56 +0100	[thread overview]
Message-ID: <20210727170856.GA4670@sirena.org.uk> (raw)
In-Reply-To: <b42ce068884cf6bcf471425a30bc4e17711037b3.camel@ew.tq-group.com>

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

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.  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-07-27 17:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-26  7:36 [PATCH] regmap: do not call regmap_debugfs_init() from regmap_attach_dev() Matthias Schiffer
2021-07-26 11:47 ` Mark Brown
2021-07-26 12:01   ` Matthias Schiffer
2021-07-26 12:11     ` Mark Brown
2021-07-26 12:18       ` Matthias Schiffer
2021-07-26 18:48         ` Mark Brown
2021-07-27 12:24           ` (EXT) " Matthias Schiffer
2021-07-27 17:08             ` Mark Brown [this message]
2021-07-28  9:13               ` Matthias Schiffer
2021-07-26 12:00 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210727170856.GA4670@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=david@lechnology.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthias.schiffer@ew.tq-group.com \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).