LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Vladimir Oltean <firstname.lastname@example.org> To: Arnd Bergmann <email@example.com> Cc: Vladimir Oltean <firstname.lastname@example.org>, Mark Brown <email@example.com>, Rasmus Villemoes <firstname.lastname@example.org>, Lee Jones <email@example.com>, Thomas Gleixner <firstname.lastname@example.org>, Marc Zyngier <email@example.com>, Hou Zhiqiang <Zhiqiang.Hou@nxp.com>, Biwen Li <firstname.lastname@example.org>, Greg Kroah-Hartman <email@example.com>, "Rafael J. Wysocki" <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com> 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: <CAK8P3a1oDeU-S5dLqKTT3YFvGREvNt_a=PTkVoDhUJYquJGePQ@mail.gmail.com> On Wed, Aug 25, 2021 at 11:24:52PM +0200, Arnd Bergmann wrote: > On Wed, Aug 25, 2021 at 10:50 PM Vladimir Oltean > <firstname.lastname@example.org> 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 <email@example.com> > > Signed-off-by: Vladimir Oltean <firstname.lastname@example.org> > > 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 falling. 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 ETSEC MAC1 ICID SATA ICID 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.
next prev parent 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: 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=20210825220023.rqskspy2usvleoqr@skbuf \ --email@example.com \ --cc=Zhiqiang.Hou@nxp.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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: linkBe 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).