Hi Hans,
Sorry for the delay.
On 11/3/22 20:28, Hans de Goede wrote:
[...]
Ok, so I've been taking a look at how we can invert the 'x' passed
to the gpiod_direction_output(ts->gpiod_rst, x) calls and not break
things with ACPI.
The rst pin is looked up through a acpi_gpio_mapping which
contains acpi_gpio_params as one of the per pin parameters
and that does have an active_low flag.
I just read the kernel docs about GPIO and ACPI and I'm not entirely
sure this is always 100% safe to do:
https://docs.kernel.org/firmware-guide/acpi/gpio-properties.html
Specifically:
"""
The GpioIo() resource unfortunately doesn't explicitly provide an
initial state of the output pin which driver should use during its
initialization.
Linux tries to use common sense here and derives the state from the bias
and polarity settings. The table below shows the expectations:
========= ============= ==============
Pull Bias Polarity Requested...
========= ============= ==============
Implicit x AS IS (assumed firmware configured for us)
Explicit x (no _DSD) as Pull Bias (Up == High, Down == Low),
assuming non-active (Polarity = !Pull Bias)
Down Low as low, assuming active
Down High as low, assuming non-active
Up Low as high, assuming non-active
Up High as high, assuming active
========= ============= ==============
"""
But since we actually override this during our devm_gpiod_get_optional
by passing forcing the flag to be either GPIOD_IN or GPIOD_ASIS, we
should be good for this driver IIUC?
Thanks for the pointers,
Cheers,
Quentin
