From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: "Nuno Sá" <nuno.sa@analog.com>
Cc: 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 0/4] add support for bias pull-disable
Date: Thu, 14 Jul 2022 17:58:36 +0300 [thread overview]
Message-ID: <YtAvHMmGay/3HACZ@smile.fi.intel.com> (raw)
In-Reply-To: <20220713131421.1527179-1-nuno.sa@analog.com>
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@analog.com/
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
next prev parent reply other threads:[~2022-07-14 14:58 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
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 [this message]
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=YtAvHMmGay/3HACZ@smile.fi.intel.com \
--to=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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox