>> Reset GPIO is active low. >> >> Currently driver uses gpiod_set_value(1) to clean reset, which depends >> on device tree to contain GPIO_ACTIVE_HIGH - that does not match reality. >> >> This fixes driver to use _raw version of gpiod_set_value() to enforce >> active-low semantics despite of what's written in device tree. Allowing >> device tree to override that only opens possibility for errors and does >> not add any value. >> >> Additionally, use _cansleep version to make things work with i2c-gpio >> and other sleeping gpio drivers. > > The reset gpio comes from platform hence it should be handled by DTS. > > In driver the gpio should not be raw. > > Even the hi8435 is active low but platform may invert signal (f.e. by > adding trigger on the circuit path). I see. However - isn't this pure theoretic? Does such case exist? In vast majority of cases, GPIO polarity is chip-specific, not chip-use-specific. Thus this knowlege belongs to driver and not to device tree describing particular chip usage. Having this always defined at usage side is IMO major source of errors. In this particular case, we already have device trees in the wild with polarity set to active_high. If we now change that to require active_low, we break existing setups. Not sure this is acceptable. I'm unsure what is good way forward here. I believe it is at gpiolib level, which perhaps should change how "logical value" is defined, such that knowledge of chip-specific information is not forced to chip usage scope. Nikita -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
