On Tue, 2022-07-19 at 11:14 +0200, Bartosz Golaszewski wrote: > On Tue, Jul 19, 2022 at 10:51 AM Nuno Sá <noname.nuno@xxxxxxxxx> > wrote: > > > > On Tue, 2022-07-19 at 10:25 +0200, Bartosz Golaszewski wrote: > > > On Wed, Jul 13, 2022 at 3:13 PM Nuno Sá <nuno.sa@xxxxxxxxxx> > > > 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... > > > > > > > > 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/ > > > > > > > > Nuno Sá (4): > > > > gpiolib: add support for bias pull disable > > > > gpiolib: of: support bias pull disable > > > > gpiolib: acpi: support bias pull disable > > > > dt-bindings: gpio: add pull-disable flag > > > > > > > > drivers/gpio/gpiolib-acpi.c | 3 +++ > > > > drivers/gpio/gpiolib-of.c | 7 +++++++ > > > > drivers/gpio/gpiolib.c | 8 ++++++-- > > > > include/dt-bindings/gpio/gpio.h | 3 +++ > > > > include/linux/gpio/machine.h | 1 + > > > > include/linux/of_gpio.h | 1 + > > > > 6 files changed, 21 insertions(+), 2 deletions(-) > > > > > > > > -- > > > > 2.37.0 > > > > > > > > > > Series applied, thanks! > > > > Hi Bart, > > > > I was actually planning to spin a v2 with your suggestion for the > > naming of the new define... Did you changed it while applying or > > should > > I still send it? Or (last option), we just leave it like this :)? > > > > - Nuno Sá > > Yeah, I'm alright with it how it is after a second though: uAPI uses > the BIAS_PULL_UP/DOWN/DISABLE notation while the in-kernel API uses > the same scheme but without the BIAS prefix. Unless you want to > change > something else - let's keep it as you first submitted it. > Alright, works for me... - Nuno Sá
