Hi Sebastian, Am Dienstag, den 13.08.2013, 12:40 +0200 schrieb Sebastian Hesselbarth: > On 08/13/13 12:03, Thierry Reding wrote: > > On Tue, Aug 13, 2013 at 10:30:30AM +0200, Thomas Petazzoni wrote: > >> Dear Thierry Reding, > >> > >> On Tue, 13 Aug 2013 10:09:56 +0200, Thierry Reding wrote: > >> > >>>> +- reset-gpios: optional gpio to PERST# > >>>> +- reset-delay-ms: delay in ms to wait after reset de-assertion > >>> > >>> I remember some recent discussion about this, and we now have this reset > >>> framework, so perhaps it makes more sense to use the reset binding for > >>> this? Cc'ing Stephen (as part of the device tree bindings maintainers > >>> team) who was involved in that recent reset bindings discussion. > >> > >> I also thought about this, but the reset framework seems to be designed > >> for "reset controller" IPs, i.e special IPs that are controlling reset > >> signals. Looking at Documentation/devicetree/bindings/reset/reset.txt, > >> I'm not sure to see how this would apply to GPIO-controlled reset > >> signals. > > > > See: > > > > http://www.mail-archive.com/devicetree-discuss@xxxxxxxxxxxxxxxx/msg36900.html > > > > which seems to have carried over to this at some point: > > > > http://www.spinics.net/lists/devicetree/msg00521.html > > > > Some of the messages in between I can't find in any archive, sorry. > > Thierry, Sascha, > > thanks for the input. Flipping through the above discussion, I guess > using "reset-gpios" and "reset-delay-us" should be fine? > > I can also remove the delay property for now, as I cannot find a final > conclusion about the configurable delay. Yes, I'm in favor of using 'reset-gpios'. If we can agree on this binding, I'll add support to the reset framework core. > In the driver, I will stick to bare gpiolib and wait for gpio-reset > driver to become available. Currently, we don't have sophisticated > reset handling in pci-mvebu anyway. Sounds good to me. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
