linux-kernel - [PATCH 2/2] mfd: syscon: request a regmap with raw spinlocks for some devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 25 Aug 2021 23:50:41 +0300
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Rasmus Villemoes <linux@...musvillemoes.dk>,
        Lee Jones <lee.jones@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Hou Zhiqiang <Zhiqiang.Hou@....com>,
        Biwen Li <biwen.li@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: [PATCH 2/2] mfd: syscon: request a regmap with raw spinlocks for some devices

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 <broonie@...nel.org>
Signed-off-by: Vladimir Oltean <vladimir.oltean@....com>
---
 drivers/mfd/syscon.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
index 765c0210cb52..70da4e87b072 100644
--- a/drivers/mfd/syscon.c
+++ b/drivers/mfd/syscon.c
@@ -83,6 +83,22 @@ static struct syscon *of_syscon_register(struct device_node *np, bool check_clk)
 	if (ret)
 		reg_io_width = 4;

+	/*
+	 * We might be providing a regmap to e.g. an irqchip driver, and in
+	 * that case, normal spinlocks won't do: the IRQ core holds raw
+	 * spinlocks, so it needs to be raw spinlocks all the way down.
+	 * Detect those drivers here (currently "ls-extirq") and request raw
+	 * spinlocks in the regmap config for them.
+	 */
+	if (of_device_is_compatible(np, "fsl,lx2160a-isc") ||
+	    of_device_is_compatible(np, "fsl,ls2080a-isc") ||
+	    of_device_is_compatible(np, "fsl,ls2080a-isc") ||
+	    of_device_is_compatible(np, "fsl,ls1088a-isc") ||
+	    of_device_is_compatible(np, "fsl,ls1043a-scfg") ||
+	    of_device_is_compatible(np, "fsl,ls1046a-scfg") ||
+	    of_device_is_compatible(np, "fsl,ls1021a-scfg"))
+		syscon_config.use_raw_spinlock = true;
+
 	ret = of_hwspin_lock_get_id(np, 0);
 	if (ret > 0 || (IS_ENABLED(CONFIG_HWSPINLOCK) && ret == 0)) {
 		syscon_config.use_hwlock = true;
-- 
2.25.1