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: <5a57e163-c705-4308-93ac-11e0cea2804b@app.fastmail.com>
Date:   Wed, 07 Dec 2022 09:59:32 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Jeremy Kerr" <jk@...econstruct.com.au>,
        "Philipp Zabel" <p.zabel@...gutronix.de>,
        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 Wed, Dec 7, 2022, at 08:56, Jeremy Kerr wrote:
> Hi Arnd,
>
> Thanks for taking a look a this. Just a question about the early
> approach; I'm not too familiar with the internals of the syscon/regmap
> infrastructure:
>
>> > 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.
>> 
>> Ok, in that case I think we should at least leave the option of
>> doing the reset from an early syscon as well.
>
> OK, sounds good - I'll add a direct of_reset_control_get_<variant>() in
> the early of_syscon_register path, which should work in a similar way to
> the clocks properties.
>
> However: this may conflict with the later platform_device syscon; if the
> late syscon tries to of_reset_control_get_exclusive() the same reset
> controller (because it's the same syscon node), that will (of course)
> fail.
>
> Hence a question about the syscon infrastructure: how are the late- and
> early- syscon registrations supposed to interact? Should I allow for
> there to be two syscons registered (one through of_syscon_register(),
> the other through the platform device probe), or do we expect that to
> never happen?
>
> In case of the former, I can just grab a shared handle to the reset
> controller instead, but I want to make sure that's the correct thing to do.

Hmm, it's clearly not doing what I was remembering it to do ;-)

Before 2014 commit bdb0066df96e ("mfd: syscon: Decouple syscon interface
from platform devices"), it was supposed to be the same regmap in
both cases, with the linked list being maintained to ensure we
never get more than one instance for device_node.

After this commit, I see that the platform_driver no longer matches
syscon nodes from devicetree, but only those nodes that have
platform_device.dev.name="syscon" and are created from board
files. The only user of manually created syscon devices at the
time was mach-clps711x, but that has been converted to DT
a long time ago, so I don't even see anything using the
platform_device at all.

This would in turn indicate that we can completely remove the
platform_driver code, but I don't see how your RFC patch then
had any effect because it wouldn't actually perform the
reset for any devices in mainline kernels.

    Arnd