LKML Archive on
help / color / mirror / Atom feed
From: Vladimir Oltean <>
To: Arnd Bergmann <>
Cc: Vladimir Oltean <>,
	Mark Brown <>,
	Rasmus Villemoes <>,
	Lee Jones <>,
	Thomas Gleixner <>,
	Marc Zyngier <>,
	Hou Zhiqiang <>, Biwen Li <>,
	Greg Kroah-Hartman <>,
	"Rafael J. Wysocki" <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH 2/2] mfd: syscon: request a regmap with raw spinlocks for some devices
Date: Thu, 26 Aug 2021 01:00:23 +0300	[thread overview]
Message-ID: <20210825220023.rqskspy2usvleoqr@skbuf> (raw)
In-Reply-To: <>

On Wed, Aug 25, 2021 at 11:24:52PM +0200, Arnd Bergmann wrote:
> On Wed, Aug 25, 2021 at 10:50 PM Vladimir Oltean
> <> wrote:
> >
> > This patch solves a ls-extirq irqchip driver bug in a perhaps
> > non-intuitive (at least non-localized) way.
> >
> > The issue is that ls-extirq uses regmap, and due to the fact that it is
> > being called by the IRQ core under raw spinlock context, it needs to use
> > raw spinlocks itself. So it needs to request raw spinlocks from the
> > regmap config.
> >
> > All is fine so far, except the ls-extirq driver does not manage its own
> > regmap, instead it uses syscon_node_to_regmap() to get it from the
> > parent syscon (this driver).
> >
> > Because the syscon regmap is initialized before any of the consumer
> > drivers (ls-extirq) probe, we need to know beforehand whether to request
> > raw spinlocks or not.
> >
> > The solution seems to be to check some compatible string. The ls-extirq
> > driver probes on quite a few NXP Layerscape SoCs, all with different
> > compatible strings. This is potentially fragile and subject to bit rot
> > (since the fix is not localized to the ls-extirq driver, adding new
> > compatible strings there but not here seems plausible). Anyway, it is
> > probably the best we can do without major rework.
> >
> > Suggested-by: Mark Brown <>
> > Signed-off-by: Vladimir Oltean <>
> This should work, but how hard would it be to change the ls-extirq
> driver instead to not use the syscon driver at all but make the extirq
> driver set up the regmap itself?
> Are there any other users of the syscon?

Not that I can see, but that doesn't make the fact that it uses a syscon a bad decision.

For context, Layerscape devices have a "Misc" / "And Others" memory region
called "Supplemental Configuration Unit" (SCFG) which "provides the
chip-specific configuration and status registers for the device. It is the
chip-defined module for extending the device configuration unit (DCFG) module."
to quote the documentation.

The ls-extirq file is a driver around _a_single_register_ of SCFG. SCFG
provides an option of reversing the interrupt polarity of the external IRQ
pins: make them active-low instead of active-high, or rising instead of

The reason for the existence of the driver is that we got some pushback during
device tree submission: while we could describe in the device tree an interrupt
as "active-high" and going straight to the GIC, in reality that interrupt is
"active-low" but inverted by the SCFG (the inverted is enabled by default).
Additionally, the GIC cannot process active-low interrupts in the first place
AFAIR, which is why an inverter exists in front of it.

Some other SCFG registers are (at least on LS1021A):

Deep Sleep Control Register
eTSEC Clock Deep Sleep Control Register (eTSEC is our Ethernet controller)
Pixel Clock Control Register
PCIe PM Write Control Register
PCIe PM Read Control Register
USB3 parameter 1 control register
QuadSPI configuration
Endianness Control Register
Snoop configuration
Interrupt Polarity <- this is the register controlled by ls-extirq
etc etc.

Also, even if you were to convince me that we shouldn't use a syscon, I feel
that the implication (change the device trees for 7 SoCs) just to solve a
kernel splat would be like hitting a nail with an atomic bomb. I'm not going to
do it.

  reply	other threads:[~2021-08-25 22:00 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
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 [this message]
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:

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

  git send-email \
    --in-reply-to=20210825220023.rqskspy2usvleoqr@skbuf \ \ \ \ \ \ \ \ \ \ \ \ \ \

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