Re: [PATCH 1/6] ASoC: wcd938x: switch to using gpiod API

Mark Brown
2023-04-20T13:01:45Z

[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]

On Thu, Apr 20, 2023 at 02:30:17PM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2023 13:58, Mark Brown wrote:
> > On Thu, Apr 20, 2023 at 12:16:12PM +0200, Krzysztof Kozlowski wrote:

> >> - gpio_direction_output(wcd938x->reset_gpio, 0);
> >> - /* 20us sleep required after pulling the reset gpio to LOW */
> >> + gpiod_set_value_cansleep(wcd938x->reset_gpio, 1);
> >> + /* 20us sleep required after asserting the reset gpio */

> > This is inverting the sense of the GPIO in the API from active low to
> > active high which will mean we're introducing a new reliance on having
> > the signal described as active low in DT. That's an ABI concern.

> It's bringing it to the correct level. Old code was not respecting the
> DTS thus if such DTS came with inverted design, the driver would not work.

Sure, but OTOH if the user didn't bother specifying as active low it
would work. I suspect it's more likely that someone missed a flag that
had no practical impact in DT than that someone would add an inverter to
their design.

> We were already fixing the upstream DTS users and I thought all of them
> are fixed since long time (half a year) or even correct from the
> beginning. Now I found one more case with incorrect level, which I will fix.

That's just upstream, what about any downstream users?

> > I remain deeply unconvinced that remapping active low outputs like this
> > in the GPIO API is helping.

> The code is mapping them to correct state. The previous state was
> incorrect and did not allow to handle active high (which can happen).
> This is the effort to make code correct - driver and DTS.

We could handle inversions through an explicit property if that were
needed, that would be a less problematic transition and clearer in the
consumer code.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]