linux-kernel - Re: [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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAK8P3a3hrYU1mRFy0H0==Wh4T2-WtZqe9bF=MuoibsH8zP9d0Q@mail.gmail.com>
Date:   Thu, 26 Aug 2021 16:48:56 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     Arnd Bergmann <arnd@...db.de>, Vladimir Oltean <olteanv@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Lee Jones <lee.jones@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        "Z.Q. Hou" <zhiqiang.hou@....com>, Biwen Li <biwen.li@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] mfd: syscon: request a regmap with raw spinlocks for
 some devices

On Thu, Aug 26, 2021 at 3:57 PM Vladimir Oltean <vladimir.oltean@....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