On Tue, May 23, 2017 at 09:02:27AM +0300, Nikita Yushchenko wrote: > >> However, hi8435 driver historically was coded using inverted values > >> passed to gpiolib calls. And there are setups in the wild with device > >> trees containing GPIO_ACTIVE_HIGH that I'd prefer not breaking. > >> > >> To solve, I submitted a patch on hi8435 driver that changes to _raw() > >> gpio calls (thus making it independent of what is written in device > >> tree), and want [future] device trees not to contain explicitly written > >> gpio polarity. > > > > So maybe add another #define, GPIO_ACTIVE_IGNORED, to make it clear > > that it does not matter what value you put there, it is ignored. > > "Crap origin" here is that in vast majority of cases, polarity is > per-chip, not per-chip-use, knowledge. And proper location for per-chip > knowledge is chip's driver. Moving this knowledge to per-chip-use > location in device trees only provides a source for errors, with little > gain. > > Vladimir Barinov mentions possibility that signal can be inverted by > board between gpio provider and chip's pin ... but do we have at least > one practical case of this? And if we even do, it's quite uncommon, and > something special should be required in device tree for these special > cases and not for "normal" cases. I disagree. Not for hi8435, but I have seen quite some board designs invert GPIOs before getting them into board level components. That's why we should define those xxx-gpios properties on board level DTS, where polarity can be chosen per board design. Shawn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
