linux-kernel - Re: [PATCH 1/2] dt-bindings: reset: Add generic GPIO reset binding

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: <9a9693a6-922d-dac8-a340-1268b96826a8@seco.com>
Date:   Thu, 28 Oct 2021 11:26:57 -0400
From:   Sean Anderson <sean.anderson@...o.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Philipp Zabel <p.zabel@...gutronix.de>,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: reset: Add generic GPIO reset binding

(I forgot to finish my thought)

On 10/28/21 11:19 AM, Sean Anderson wrote:
> Hi Rob,
>
> On 10/26/21 10:27 PM, Rob Herring wrote:
>> On Mon, Oct 18, 2021 at 07:49:21PM -0400, Sean Anderson wrote:
>>> This adds a binding for a generic GPIO reset driver. This driver is
>>> designed to easily add a GPIO-based reset to a driver which expected a
>>> reset controller. It offers greater flexibility than a reset-gpios
>>> property, and allows for one code path to be shared for GPIO resets and
>>> MMIO-based resets.
>>
>> I would like to do this last part, but not requiring a binding change.
>> IOW, be able to register any 'reset-gpios' property as a reset provider
>> directly without this added level of indirection.
>
> That would be nice, but it seems like someone would have to go through
> every driver with a reset-gpios property and convert them. Since the
> reset GPIOs are
...effectively ad-hoc, I think it would be difficult to do a conversion
in a generic manner (especially since some devices will fail to probe if
they don't get control of the GPIOs). Maybe this could be done with a
single reset driver which has reset GPIOs added to it dynamically? E.g.
when a driver requests a reset named "some-name" and there is a
reset-gpios property, request the GPIOs and assign them to the reset
driver, then hand that reset back to the calling driver.

On the other hand, having a separate driver like this makes it easy to
incrementally convert existing drivers. Although it does require a
change in bindings.

--Sean