From: Kent Gibson <warthog618@gmail.com>
To: "Nuno Sá" <noname.nuno@gmail.com>
Cc: "Andy Shevchenko" <andriy.shevchenko@linux.intel.com>,
"Nuno Sá" <nuno.sa@analog.com>,
linux-acpi@vger.kernel.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Bartosz Golaszewski" <brgl@bgdev.pl>,
"Frank Rowand" <frowand.list@gmail.com>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Linus Walleij" <linus.walleij@linaro.org>
Subject: Re: [PATCH 1/4] gpiolib: add support for bias pull disable
Date: Thu, 14 Jul 2022 16:27:10 +0800 [thread overview]
Message-ID: <20220714082710.GA103849@sol> (raw)
In-Reply-To: <4bf06ba5994f559499c45275cd7f44bfee1bbde1.camel@gmail.com>
On Thu, Jul 14, 2022 at 09:14:21AM +0200, Nuno Sá wrote:
> On Thu, 2022-07-14 at 12:20 +0800, Kent Gibson wrote:
> > On Wed, Jul 13, 2022 at 08:36:38PM +0300, Andy Shevchenko wrote:
> > > On Wed, Jul 13, 2022 at 03:14:18PM +0200, Nuno Sá wrote:
> > > > This change prepares the gpio core to look at firmware flags and
> > > > set
> > > > 'FLAG_BIAS_DISABLE' if necessary. It works in similar way to
> > > > 'GPIO_PULL_DOWN' and 'GPIO_PULL_UP'.
> > >
> > > ...
> > >
> > > > GPIO_PULL_UP = (1 << 4),
> > > > GPIO_PULL_DOWN = (1 << 5),
> > > > + GPIO_PULL_DISABLE = (1 << 6),
> > >
> > > To me it seems superfluous. You have already two flags:
> > > PUp
> > > PDown
> > > When none is set --> Pdisable
> > >
> >
> > Agree with Andy on this. The FLAG_BIAS_DISABLE was added, by me, to
> > allow the cdev interface to support bias. cdev requires a "don't
> > care"
> > state, distinct from an explicit BIAS_DISABLE.
> > The FLAG_BIAS_DISABLE allows gpiolib-cdev to communicate that to
> > gpiolib, without altering the interpretation of the existing PULL_UP
> > and
> > PULL_DOWN flags.
> > That is not an issue on the machine interface, where the two
> > GPIO_PULL
> > flags suffice.
> >
>
> I see, but this means we can only disable the pin BIAS through
> userspace. I might be wrong but I don't see a reason why it wouldn't be
> valid to do it from an in kernel path as we do for PULL-UPS and PULL-
> DOWNS
>
> > If you are looking for the place where FLAG_BIAS_DISABLE is set it is
> > in
> > gpio_v2_line_config_flags_to_desc_flags() in gpiolib-cdev.c.
> >
> > Referring to gpio_set_bias(), the only place in gpiolib the
> > FLAG_BIAS_DISABLE is used, if neither FLAG_PULL_UP, FLAG_PULL_DOWN,
> > nor FLAG_BIAS_DISABLE are set then the bias configuration remains
> > unchanged (the don't care case) - no change is passed to the driver.
> > Otherwise the corresponding PIN_CONFIG_BIAS flag is passed to the
> > driver.
> >
>
> Exactly, but note FLAG_BIAS_DISABLE can only be set from userspace at
> this point (IIUTC). If everyone agrees that should be case, so be it.
> But as I said, I just don't see why it's wrong to do it within the
> kernel.
>
Believe it or not gpiolib-cdev is part of the kernel, not userspace - it
just provides an interface to userspace.
Bias can be disabled by calling gpiod_direction_input() or
gpiod_direction_output() after setting the FLAG_BIAS_DISABLE, as
gpiolib-cdev does.
Does that work for you?
Cheers,
Kent.
> > If there are cases of drivers not fully or correctly supporting those
> > PIN_CONFIG_BIAS flags, then that is an issue with those drivers.
> >
>
> Look at my reply to Andy in the cover for more details
>
> - Nuno Sá
next prev parent reply other threads:[~2022-07-14 8:27 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-13 13:14 [PATCH 0/4] add support for bias pull-disable Nuno Sá
2022-07-13 13:14 ` [PATCH 1/4] gpiolib: add support for bias pull disable Nuno Sá
2022-07-13 17:36 ` Andy Shevchenko
2022-07-14 4:20 ` Kent Gibson
2022-07-14 7:14 ` Nuno Sá
2022-07-14 8:27 ` Kent Gibson [this message]
2022-07-14 8:47 ` Nuno Sá
2022-07-14 12:00 ` Kent Gibson
2022-07-14 13:02 ` Nuno Sá
2022-07-14 15:08 ` Andy Shevchenko
2022-07-14 15:47 ` Nuno Sá
2022-07-18 10:44 ` Linus Walleij
2022-07-13 13:14 ` [PATCH 2/4] gpiolib: of: support " Nuno Sá
2022-07-18 10:30 ` Linus Walleij
2022-07-13 13:14 ` [PATCH 3/4] gpiolib: acpi: " Nuno Sá
2022-07-18 10:32 ` Linus Walleij
2022-07-18 10:49 ` Nuno Sá
2022-07-18 13:49 ` Linus Walleij
2022-07-18 18:25 ` Andy Shevchenko
2022-07-13 13:14 ` [PATCH 4/4] dt-bindings: gpio: add pull-disable flag Nuno Sá
2022-07-18 10:33 ` Linus Walleij
2022-07-18 20:52 ` Rob Herring
2022-07-13 17:39 ` [PATCH 0/4] add support for bias pull-disable Andy Shevchenko
2022-07-14 7:09 ` Nuno Sá
2022-07-14 9:12 ` Andy Shevchenko
2022-07-14 9:49 ` Nuno Sá
2022-07-14 14:58 ` Andy Shevchenko
2022-07-14 15:43 ` Nuno Sá
2022-07-14 18:57 ` Andy Shevchenko
2022-07-15 10:20 ` Nuno Sá
2022-07-15 12:05 ` Andy Shevchenko
2022-07-15 12:20 ` Nuno Sá
2022-07-15 19:31 ` Bartosz Golaszewski
2022-07-18 7:51 ` Nuno Sá
2022-07-18 10:29 ` Linus Walleij
2022-07-18 10:46 ` Nuno Sá
2022-07-18 10:25 ` Linus Walleij
2022-07-19 8:25 ` Bartosz Golaszewski
2022-07-19 8:52 ` Nuno Sá
2022-07-19 9:14 ` Bartosz Golaszewski
2022-07-19 10:21 ` Nuno Sá
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220714082710.GA103849@sol \
--to=warthog618@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=brgl@bgdev.pl \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=noname.nuno@gmail.com \
--cc=nuno.sa@analog.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.