(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
