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