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]

Date:   Tue, 06 Dec 2022 09:41:10 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "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>,
        "Philipp Zabel" <p.zabel@...gutronix.de>
Subject: Re: [RFC PATCH 2/2] mfd: syscon: allow reset control for syscon devices

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()?

     Arnd