All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Mark Brown <broonie@kernel.org>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Lee Jones <lee.jones@linaro.org>, Arnd Bergmann <arnd@arndb.de>,
	Marc Zyngier <maz@kernel.org>,
	Hou Zhiqiang <Zhiqiang.Hou@nxp.com>, Biwen Li <biwen.li@nxp.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] regmap: teach regmap to use raw spinlocks if requested in the config
Date: Thu, 02 Sep 2021 10:35:01 +0200	[thread overview]
Message-ID: <874kb3cr4a.ffs@tglx> (raw)
In-Reply-To: <20210901160555.GG5976@sirena.org.uk>

On Wed, Sep 01 2021 at 17:05, Mark Brown wrote:
> On Mon, Aug 30, 2021 at 04:16:04PM +0200, Thomas Gleixner wrote:
>> On Mon, Aug 30 2021 at 13:19, Mark Brown wrote:
>
>> > That probably does make sense, I think we're just using regular
>> > spinlocks for spinlocks mainly because they're the default rather
>> > than because anyone put huge amounts of thought into it.  IIRC
>> > the first users were using spinlocks for their locking when they
>> > were converted.
>
>> So if the actual spinlock protected operations are not doing any other
>> business than accessing preallocated cache memory and a few MMIO
>> operations then converting them to raw spinlocks should have no real
>> impact on RT.
>
> I think Vladimir's point that something might try to use one of the APIs
> that can do multiple register writes atomically to generate a very long
> register write sequence is valid here.  It's far from the common case
> but it'd be hard to audit, it's going to be a lot easier to handle going
> to raw spinlocks in the cases where it's specifically needed than to
> keep on top of ensuring that none of the users are causing issues or
> start causing issues in the future.  This does make me feel it's a bit
> safer to leave the default the way it is since if you get it wrong then
> lockdep will tend to notice very quickly while it's less likely that
> we'd get tooling spotting issues the other way around.

Fair enough.

>> One way to do that is obviously starting with the patch from Vladimir
>> and then convert them one by one, so the assumption that they are not
>> doing anything nasty (in the RT sense) can be validated.
>
> Vladimir's patch is in Linus' tree now so users that can safely do so
> can start using raw spinlocks.

ok

  reply	other threads:[~2021-09-02  8:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-25 20:50 [PATCH 0/2] Use raw spinlocks in the ls-extirq driver Vladimir Oltean
2021-08-25 20:50 ` [PATCH 1/2] regmap: teach regmap to use raw spinlocks if requested in the config Vladimir Oltean
2021-08-26 23:01   ` Thomas Gleixner
2021-08-27 16:12     ` Vladimir Oltean
2021-08-27 19:59       ` Thomas Gleixner
2021-08-30 10:49         ` Vladimir Oltean
2021-08-30 11:02     ` Rasmus Villemoes
2021-08-30 12:42       ` Mark Brown
2021-08-30 12:19     ` Mark Brown
2021-08-30 14:16       ` Thomas Gleixner
2021-09-01 16:05         ` Mark Brown
2021-09-02  8:35           ` Thomas Gleixner [this message]
2021-08-25 20:50 ` [PATCH 2/2] mfd: syscon: request a regmap with raw spinlocks for some devices Vladimir Oltean
2021-08-25 21:24   ` Arnd Bergmann
2021-08-25 22:00     ` Vladimir Oltean
2021-08-26  9:24       ` Arnd Bergmann
2021-08-26 13:57         ` Vladimir Oltean
2021-08-26 14:48           ` Arnd Bergmann
2021-09-06  9:18   ` Lee Jones
2021-08-26 12:51 ` (subset) [PATCH 0/2] Use raw spinlocks in the ls-extirq driver 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=874kb3cr4a.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=Zhiqiang.Hou@nxp.com \
    --cc=arnd@arndb.de \
    --cc=biwen.li@nxp.com \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=maz@kernel.org \
    --cc=rafael@kernel.org \
    --cc=vladimir.oltean@nxp.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.