[PATCH 2/4] gpiolib: Add code to support "active low" GPIOs
Sascha Hauer
s.hauer at pengutronix.de
Tue May 23 01:33:21 PDT 2017
On Tue, May 23, 2017 at 09:30:27AM +0300, Nikita Yushchenko wrote:
> > So far this particular aspect of various DT-bindings has been handled
> > on a per-driver basis. With this change, hopefully, we'll have a
> > single place to handle necessary logic inversions and eventually
> > would be able to migrate existing users as well as avoiding adding
> > redundant code to new drivers.
>
> Do we have at least single case when same pin of the same chip is active
> high in one use and active low in other use?
>
> I'd say that "logic values" of gpiolib is a major source of confusion,
> at least in it's current form. The fact that
> gpio_set_value(..., 1)
> does not set gpio value to 1 but instead sets gpio value to what is
> configured as active, is non-intuitive at least. Maybe with different
> API names (e.g. gpio_activate() / gpio_deactivate()) it could be better.
Plain gpio_set_value() in Linux does not honour any ACTIVE_LOW flags,
only gpiod_set_value() does. But anyway, you are right, it *is*
confusing. I agree that we should have a different set of functions
which honour the ACTIVE_LOW flag. Besides of being more consistent
in the end I think it's the only way to not break any existing gpio
setups in barebox. With a different API set we can review each driver
change for unwanted side effects.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the barebox
mailing list