Re: [PATCH 0/4] add support for bias pull-disable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 13, 2022 at 03:14:17PM +0200, Nuno Sá wrote:
> The gpio core looks at 'FLAG_BIAS_DISABLE' in preparation of calling the
> gpiochip 'set_config()' hook. However, AFAICT, there's no way that this
> flag is set because there's no support for it in firwmare code. Moreover,
> in 'gpiod_configure_flags()', only pull-ups and pull-downs are being
> handled.
> 
> On top of this, there are some users that are looking at
> 'PIN_CONFIG_BIAS_DISABLE' in the 'set_config()' hook. So, unless I'm
> missing something, it looks like this was never working for these chips.
> 
> Note that the ACPI case is only compiled tested. At first glance, it seems
> the current patch is enough but i'm not really sure...

So, I looked closer to the issue you are trying to describe here.

As far as I understand we have 4 state of BIAS in the hardware:
1/ AS IS (defined by firnware)
2/ Disabled (neither PU, not PD)
3/ PU
4/ PD

The case when the default of bias is not disabled (for example specific, and I
think very special, hardware may reset it to PD or PU), it's a hardware driver
responsibility to inform the framework about the real state of the lines and
synchronize it.

Another case is when the firmware sets the line in non-disabled state and
by some reason you need to disable it. The question is, why?

> As a side note, this came to my attention during this patchset [1]
> (and, ofr OF,  was tested with it).
> 
> [1]: https://lore.kernel.org/linux-input/20220708093448.42617-5-nuno.sa@xxxxxxxxxx/

Since this provides a GPIO chip, correct?, it's responsibility of the driver to
synchronize it, no? Basically if you really don't trust firmware, you may
go via all GPIO lines and switch them to the known (in software) state. This
approach on the other hand is error prone, because firmware should know better
which pin is used for which purpose, no? If you don't trust firwmare (in some
cases), then it's a matter of buggy platform that has to be quirked out.

-- 
With Best Regards,
Andy Shevchenko





[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux