[U-Boot] [PATCH v2] reset: Add generic GPIO reset driver

[Simon Glass]

Hi Mario,


On 4 May 2018 at 01:01, Mario Six <mario.six at gdsys.cc> wrote:
> Hi Neil,
>
> On Fri, Apr 27, 2018 at 3:01 PM, Neil Armstrong <narmstrong at baylibre.com>
wrote:
>> Hi,
>>
>> On 27/04/2018 14:53, Mario Six wrote:
>>> Some reset lines are implemented by toggling the line via a GPIO.
>>>
>>> Add a driver to properly drive such reset lines.
>>
>> You are defining a "gpio-reset" binding which has always been rejected
>> under Linux, so I'm not sure it's a good idea to add it in U-Boot only...
>>
>
> I see what you mean. I do think that the reasoning from the Linux debates
(e.g.
> [1]) applies only partially to U-Boot, mostly because in U-Boot there is
no
> good way to "have a separate device in the Linux driver model to abstract
> this". If it's not described in the DT, you have to manually create
devices,
> which is probably not what we want here.
>
> This driver was inspired by the also generic reset driver in [2] (which
was
> never applied, it seems?) which is equally as "abstract" as this one.
>
> At the end of the day, I'm fine with having a gpio-reset property in the
device
> in question and then manually reset them, but I think we can do without
the
> code duplication everywhere (plus, lots of boards already have U-Boot
specific
> device tree include files, so adding the reset device is not a big deal).
>
> Is "u-boot,gpio-reset" good as an alternative compat string?

I suppose so, but we should think about the implications. Presumably the
controlling device would reference a particular reset line, and would
control enabling/disabling reset, and thus the length of the reset pulse?

How much code do we actually save by doing this? Would another option be to
have some helper functions in the reset uclass?

>
> [1] http://comments.gmane.org/gmane.linux.drivers.devicetree/41596
> [2] https://lists.denx.de/pipermail/u-boot/2017-November/313135.html
>
>> Neil

Regards,
Simon