[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