On Tue, May 23, 2017 at 1:33 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> 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. Thanks, Andrey Smirnov _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
