I assure you that this is frequently used.I see. However - isn't this pure theoretic? Does such case exist?Reset GPIO is active low.The reset gpio comes from platform hence it should be handled by DTS.
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.
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).
GPIO comes from SoC then "circuit path" and finally chip reset input.
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.