On Tue, Nov 12, 2024 at 5:09 PM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Tue, Nov 05, 2024 at 04:39:38PM +0200, Andy Shevchenko wrote:
On Tue, Nov 05, 2024 at 12:45:23PM +0530, Sai Kumar Cholleti wrote:
Setting GPIO direction = high, sometimes results in GPIO value = 0.
If a GPIO is pulled high, the following construction results in the value being 0 when the desired value is 1:
$ echo "high" > /sys/class/gpio/gpio336/direction $ cat /sys/class/gpio/gpio336/value 0
Before the GPIO direction is changed from an input to an output, exar_set_value() is called with value = 1, but since the GPIO is an input when exar_set_value() is called, _regmap_update_bits() reads a 1 due to an external pull-up. regmap_set_bits() sets force_write = false, so the value (1) is not written. When the direction is then changed, the GPIO becomes an output with the value of 0 (the hardware default).
regmap_write_bits() sets force_write = true, so the value is always written by exar_set_value() and an external pull-up doesn't affect the outcome of setting direction = high.
The same can happen when a GPIO is pulled low, but the scenario is a little more complicated.
$ echo high > /sys/class/gpio/gpio351/direction $ cat /sys/class/gpio/gpio351/value 1
$ echo in > /sys/class/gpio/gpio351/direction $ cat /sys/class/gpio/gpio351/value 0
$ echo low > /sys/class/gpio/gpio351/direction $ cat /sys/class/gpio/gpio351/value 1
Reviewed-by: Andy Shevchenko andriy.shevchenko@linux.intel.com
Does this need to be applied, Bart? Seems it is missed in your branches...
Maybe if the author used get_maintainers.pl as they should, I would have noticed this earlier?
I have some other fixes to pick up so I'll send this later in the merge window.
Bart