Hi Mario,
On 4 May 2018 at 01:01, Mario Six <mario....@gdsys.cc> wrote: > Hi Neil, > > On Fri, Apr 27, 2018 at 3:01 PM, Neil Armstrong <narmstr...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
