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: [PATCH] regmap: do not call regmap_debugfs_init() from regmap_attach_dev()
Date: Mon, 26 Jul 2021 19:48:05 +0100	[thread overview]
Message-ID: <20210726184805.GK4670@sirena.org.uk> (raw)
In-Reply-To: <45bb83c5ba33d479e1634e3a9efafcca5691fd9e.camel@ew.tq-group.com>

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

On Mon, Jul 26, 2021 at 02:18:42PM +0200, Matthias Schiffer wrote:
> On Mon, 2021-07-26 at 13:11 +0100, Mark Brown wrote:

> > That's not what your patch says it's fixing, your patch says it's
> > fixing an attempt to recreate the same directory as we had originally
> > (we should probably clean up the one with no device but that's not what
> > your commit does).  I think what you need to look at here is that we
> > store map->debugfs_name and don't overwrite it when the device is
> > supplied.

> That would be fine if regmap_debugfs_init() didn't do a lot more than
> just create the debugfs directory. I'm more concerned about the mutex

The whole point here is to move the debugfs directory so if any fix
stops that happening it's not really viable.  If we knew that devices
were definitely going to have a device bound we could just defer till
the device is bound but it's not clear to me that that will always
happen.

> and list head initialization that is happening on an already
> initialized structure. I haven't looked in detail what the mutex and
> list head are used for, but I assume bad things™ are going to happen
> when someone is already holding the mutex or using the list.

They're used to cache information on where registers are located in the
debugfs files so seeks work much faster on large register maps, they
won't be doing anything if userspace isn't up yet which should really be
the case for anything that's initializing early enough that it needed to
have a regmap prior to the driver model being up.  You're right that
there is a potential issue there though, but that can be handled
separately.

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

  reply	other threads:[~2021-07-26 18:48 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 [this message]
2021-07-27 12:24           ` (EXT) " Matthias Schiffer
2021-07-27 17:08             ` Mark Brown
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=20210726184805.GK4670@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).