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
