From: Hans de Goede <hdegoede@redhat.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Linus Walleij <linus.walleij@linaro.org>,
Daniel Scally <dan.scally@ideasonboard.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Kate Hsuan <hpa@redhat.com>,
linux-gpio@vger.kernel.org
Subject: Re: [PATCH v2 resend 1/2] gpio: tps68470: Fix tps68470_gpio_get() reading from the wrong register
Date: Wed, 25 Jan 2023 12:32:10 +0100 [thread overview]
Message-ID: <07a830ec-4cb9-8a02-dfc0-a3b52cc79290@redhat.com> (raw)
In-Reply-To: <CAHp75Vd22k70oiQ4ygmYrGiC_cdb6NrqtHzV+q2j=Yu3VXj00g@mail.gmail.com>
Hi,
On 1/25/23 12:23, Andy Shevchenko wrote:
> On Wed, Jan 25, 2023 at 1:05 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> For the regular GPIO pins the value should be read from TPS68470_REG_GPDI,
>> so that the actual value of the pin is read, rather than the value the pin
>> would output when put in output mode.
>
> It really depends. I think it's a wrong perception and brings nothing
> to software. If we output, we know what we program, so reading back
> returns us what we _assume_ should be on the pin under normal
> circumstances. The difference is OD/OS/OE/OC cases where we output
> only one possible value.
>
>> Fixes: 275b13a65547 ("gpio: Add support for TPS68470 GPIOs")
>
> Is it really fixing anything? Can we have more?
>
> P.S. Before doing this, I would have a clarification in the
> documentation. Sorry that I have had no time to respond to my series
> regarding that. But it seems we have a strong disagreement in the
> area.
I know disagree on some of the semantics of gpiod_get_value() but 99.9%
of the consumers of gpiod_get_value() are going to deal with pins
which are either in input mode, or in some non push-pull (e.g.
open-collector for i2c) mode. And in those cases reading GPDI
os the right thing to do.
Calling gpiod_get_value() when the pin is in push-pull mode really
does not make much sense, so there will be very little if any users
of that. And this patch fixes the 99.9% other (potential) users
while not breaking the push-pull case since even then reading GPDI
should still return the right value.
Regards,
Hans
next prev parent reply other threads:[~2023-01-25 11:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-25 11:05 [PATCH v2 resend 0/2] gpio: tps68470: 2 bugfixes Hans de Goede
2023-01-25 11:05 ` [PATCH v2 resend 1/2] gpio: tps68470: Fix tps68470_gpio_get() reading from the wrong register Hans de Goede
2023-01-25 11:23 ` Andy Shevchenko
2023-01-25 11:32 ` Andy Shevchenko
2023-01-25 11:32 ` Hans de Goede [this message]
2023-01-25 11:34 ` Andy Shevchenko
2023-01-25 11:40 ` Hans de Goede
2023-01-25 14:55 ` Andy Shevchenko
2023-01-25 17:22 ` Hans de Goede
2023-01-25 11:05 ` [PATCH v2 resend 2/2] gpio: tps68470: Make tps68470_gpio_output() always set the initial value Hans de Goede
2023-01-25 11:24 ` Andy Shevchenko
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=07a830ec-4cb9-8a02-dfc0-a3b52cc79290@redhat.com \
--to=hdegoede@redhat.com \
--cc=andy.shevchenko@gmail.com \
--cc=bgolaszewski@baylibre.com \
--cc=dan.scally@ideasonboard.com \
--cc=hpa@redhat.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
/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;
as well as URLs for NNTP newsgroup(s).