Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 26 Aug 2021 01:00:23 +0300
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Arnd Bergmann <arnd@arndb.de>
Cc:     Vladimir Oltean <vladimir.oltean@nxp.com>,
        Mark Brown <broonie@kernel.org>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Lee Jones <lee.jones@linaro.org>,
        Thomas Gleixner <tglx@linutronix.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 Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] mfd: syscon: request a regmap with raw spinlocks for
 some devices
Message-ID: <20210825220023.rqskspy2usvleoqr@skbuf>
References: <20210825205041.927788-1-vladimir.oltean@nxp.com>
 <20210825205041.927788-3-vladimir.oltean@nxp.com>
 <CAK8P3a1oDeU-S5dLqKTT3YFvGREvNt_a=PTkVoDhUJYquJGePQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK8P3a1oDeU-S5dLqKTT3YFvGREvNt_a=PTkVoDhUJYquJGePQ@mail.gmail.com>
Precedence: bulk

On Wed, Aug 25, 2021 at 11:24:52PM +0200, Arnd Bergmann wrote:
> On Wed, Aug 25, 2021 at 10:50 PM Vladimir Oltean
> <vladimir.oltean@nxp.com> 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 <broonie@kernel.org>
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> 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.