On Thu, 2022-07-14 at 18:08 +0300, Andy Shevchenko wrote: > On Thu, Jul 14, 2022 at 03:02:08PM +0200, Nuno Sá wrote: > > On Thu, 2022-07-14 at 20:00 +0800, Kent Gibson wrote: > > > On Thu, Jul 14, 2022 at 10:47:27AM +0200, Nuno Sá wrote: > > ... > > > > If that solves your immediate problem then you need to decide > > > what > > > problem your patch is trying to address. > > > > So my patch is trying to solve exactly this case because (IMO), it > > does > > not make sense for consumers drivers to have to do the above code. > > Moreover, they would need some custom firmware property (eg: > > devicetree) for the cases where we want to disable BIAS since we > > cannot > > just assume we want to do it. > > Why? This is the main question. Why do you need that _in kernel_ API. > > > Well, maybe we can just assume FLAG_BIAS_DISABLE in gpiolib (when > > trying to get the gpiod) if no PULL is specified. However, I do > > have > > some concerns with it (see my conversation with Andy in the cover). > > It's AS IS if you trust firmware. > In my use case, there's no firmware controlling the pin... The input driver (which exposes the gpichip) directly controls the pins and I want to have a way to tell it (from firmware) to disable the BIAS if users want to do so (by default it's pull-up)... - Nuno Sá
