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

[Nikita Yushchenko <nikita.yoush@cogentembedded.com>]

> 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.

I understand that we have these logic values in linux and may want
similarity between linux and barebox. But far not sure at which side it
should be fixed.

Right now I'm trying to handle a situation (in linux) where chip has
signal active low, but driver author just used gpiolib calls with
physical values, inverted.  So device trees are plain wrong (stating
gpio is active high which is not true) but changing that is about to
break existing working setups.

I don't know how many similar cases exist, but I guess that quite a few.
 And all this is caused by enforcement of logical gpio values concept
everywhere - while it is useful only in rare case of setup-dependent
signal polarity.  In vast majority of cases signal polarity is
chip-dependent, not setup-dependent.

Nikita

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox