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 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
