From: Mark Brown <broonie@kernel.org>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Lee Jones <lee.jones@linaro.org>, Arnd Bergmann <arnd@arndb.de>,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <maz@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: "BUG: Invalid wait context" in ls_extirq_set_type
Date: Wed, 25 Aug 2021 16:54:27 +0100 [thread overview]
Message-ID: <20210825155427.GK5186@sirena.org.uk> (raw)
In-Reply-To: <20210825135438.ubcuxm5vctt6ne2q@skbuf>
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
On Wed, Aug 25, 2021 at 04:54:38PM +0300, Vladimir Oltean wrote:
> - Use a hwspinlock. Never used one, don't know what it's about?!
hwspinlocks are for locking around things that are shared with other
processors not running Linux where the other processors might also take
the lock, they're very specialist.
> Either way, there seems to be no option to use a raw spinlock. "Disable
> locking" sounds like the best bet, but regmap offers regmap_bulk_read()
> and regmap_bulk_write() and those would be broken without locking taken
> at the syscon driver level, I think?
If you disable locks at the regmap level something needs to ensure that
there's no concurrency issues which for a MFD if any of the registers
are shared sounds off.
> I did google for fixes for this kind of issues that were sent in the
> past, but in my limited search I did not find any other driver which
> uses regmap while under a raw spinlock.
No problem with adding raw spinlocks to regmap, I think it's just nobody
needed them before. I've not looked at the problem in sufficient detail
to figure out if that's actually the best solution here but from an initial
pass through it looks reasonableit looks reasonable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-08-25 15:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-25 13:54 "BUG: Invalid wait context" in ls_extirq_set_type Vladimir Oltean
2021-08-25 15:54 ` Mark Brown [this message]
2021-08-25 16:03 ` Vladimir Oltean
2021-08-25 16:35 ` Mark Brown
2021-08-26 9:01 ` Rasmus Villemoes
2021-08-26 13:33 ` Vladimir Oltean
2021-08-26 13:56 ` Rasmus Villemoes
2021-08-26 13:40 ` 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=20210825155427.GK5186@sirena.org.uk \
--to=broonie@kernel.org \
--cc=arnd@arndb.de \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=maz@kernel.org \
--cc=olteanv@gmail.com \
--cc=tglx@linutronix.de \
/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).