linux-kernel - Re: [RFC PATCH 2/2] mfd: syscon: allow reset control for syscon 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: <a83f62d604e70a8e58309dc7a5e2e3515227e1c4.camel@pengutronix.de>
Date:   Tue, 06 Dec 2022 10:25:28 +0100
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Arnd Bergmann <arnd@...db.de>,
        Jeremy Kerr <jk@...econstruct.com.au>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Lee Jones <lee@...nel.org>, Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>
Subject: Re: [RFC PATCH 2/2] mfd: syscon: allow reset control for syscon
 devices

On Di, 2022-12-06 at 09:41 +0100, Arnd Bergmann wrote:
> On Tue, Dec 6, 2022, at 08:39, Jeremy Kerr wrote:
> > Simple syscon devices may require deassertion of a reset signal in order
> > to access their register set. Rather than requiring a custom driver to
> > implement this, we can use the generic "resets" specifiers to link a
> > reset line to the syscon.
> > 
> > This change adds an optional reset line to the syscon device
> > description, and code to perform the deassertion/assertion on
> > probe/remove.
> > 
> > Signed-off-by: Jeremy Kerr <jk@...econstruct.com.au>
> 
> I see that this will only work after the device has been registered,
> but not for early users of the syscon framework that bypass the
> device logic and just call device_node_to_regmap() or 
> syscon_regmap_lookup*() during early boot.
> 
> It should be possible to solve this by adding the reset logic
> into the of_syscon_register() function and using the
> of_reset_control_get*() helpers instead of the devm_* ones,
> but I'm not sure if that causes other problems with probe
> order, or if that helps at all, if reset drivers already
> require the device subsystem to be running.
> 
> Philipp, what is the earliest point at which
> reset_controller_register() can be called? Is that
> possible before postcore_initcall() or driver_register()?

reset_controller_register() only initializes a few fields in the passed
rcdev structure and adds it to a static list under a static mutex, so
there's not much of a limit.

However, reset controllers that choose to register early without
creating a platform device may run into issues with devlink inhibiting
reset consumers' probe [1].

[1] a1467faa1041 ("ARM: imx: register reset controller from a platform driver")
    https://lore.kernel.org/linux-arm-kernel/20211005100618.730907-1-p.zabel@pengutronix.de/

regards
Philipp