[PATCH 2/4] gpiolib: Add code to support "active low" GPIOs

Andrey Smirnov andrew.smirnov at gmail.com
Tue May 23 17:16:42 PDT 2017

On Tue, May 23, 2017 at 1:33 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> 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.

Sounds reasonable. I'll add the API and convert the rest of the
patches to use it appropriately in v2 of the patch.

Andrey Smirnov

More information about the barebox mailing list