On Tue, May 08, 2012 at 03:26:16PM -0600, Stephen Warren wrote: > On 05/07/2012 10:24 AM, Mark Brown wrote: > > It's really not idiomatic for drivers using GPIOs to allow > > configuration of their flags in the first place. Or, quite > > frankly, to use flags. Honestly I'd not expect any bindings that > > the GPIO driver provides to have any attention at all paid to them > > most of the time, looking at the code seems to support that (though > > there's surprisingly few bindings using GPIOs at all it seems). > So, are you saying we should remove the flags from the GPIO bindings, > and do something custom in each consumer? Not really, it's more internal Linux stuff with the gpio API being a bit stuck. > Right now, we can't rely on of_get_gpio_flags(), since not all GPIO > drivers actually allow flags to be represented in bindings. > However, having each client have a unique binding for things like > open-drain, inverted, ... seems bad; there are probably fewer > providers than consumers, although a single standardized It really depends what the device is doing with the GPIO, we would at least need to have a way for the user to get the flags back out in case the configuration is important for what it does. Most of this stuff is going to be nonsensical for most uses anyway, though, and obviously there's the whole middleware emulation thing as well. > representation might admittedly have been ever better. Well, that's legacy device tree stuff for you :/
Attachment:
signature.asc
Description: Digital signature
