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;
MIME-Version: 1.0
References: <20210825205041.927788-1-vladimir.oltean@nxp.com>
 <20210825205041.927788-3-vladimir.oltean@nxp.com> <CAK8P3a1oDeU-S5dLqKTT3YFvGREvNt_a=PTkVoDhUJYquJGePQ@mail.gmail.com>
 <20210825220023.rqskspy2usvleoqr@skbuf> <CAK8P3a3FnsWbGRU7BNc8uwt0nFAHa7K4c+qpoZixwdW9kihC5w@mail.gmail.com>
 <20210826135725.lrn2afoekxzzvtbf@skbuf>
In-Reply-To: <20210826135725.lrn2afoekxzzvtbf@skbuf>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Thu, 26 Aug 2021 16:48:56 +0200
Message-ID: <CAK8P3a3hrYU1mRFy0H0==Wh4T2-WtZqe9bF=MuoibsH8zP9d0Q@mail.gmail.com>
Subject: Re: [PATCH 2/2] mfd: syscon: request a regmap with raw spinlocks for
 some devices
To:     Vladimir Oltean <vladimir.oltean@nxp.com>
Cc:     Arnd Bergmann <arnd@arndb.de>, Vladimir Oltean <olteanv@gmail.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>,
        "Z.Q. Hou" <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>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Aug 26, 2021 at 3:57 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> On Thu, Aug 26, 2021 at 11:24:24AM +0200, Arnd Bergmann wrote:
>
> So basically you want me to create a platform driver under drivers/soc
> which probes on:
>         "fsl,lx2160a-isc"
>         "fsl,ls2080a-isc"
>         "fsl,ls2080a-isc"
>         "fsl,ls1088a-isc"
>         "fsl,ls1043a-scfg"
>         "fsl,ls1046a-scfg"
>         "fsl,ls1021a-scfg"
> and does the same thing as syscon, but sets "syscon_config.use_raw_spinlock = true;"
> and that is the only difference?

That would work, but it's not what I was suggesting.

> By the way, how does syscon probe its children exactly? And how would
> this driver probe its children?

syscon does not probe its children. As far as I can tell, your irqchip driver
works by accident because it uses IRQCHIP_DECLARE() rather than
builtin_platform_driver(), so it works even when no platform_device gets
created, as IRQCHIP_DECLARE() just looks for the compatible
string on its own.

My suggestion was to have the driver that binds to the isc node export a
high-level interface such as fsl_isc_set_extirq_polarity(). If the extirq
irqchip driver can work as a platform_driver(), then the new isc driver
can also be responsible for probing its children using the mfd
infrastructure, which solves the probe order problem, and lets you
have child devices that are not irqchip or clock controller.

       Arnd