From: Liu Gang <Gang.Liu@freescale.com>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linus.walleij@linaro.org, b07421@freescale.com,
r61911@freescale.com
Subject: Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
Date: Fri, 22 Nov 2013 12:47:36 +0800 [thread overview]
Message-ID: <1385095656.16677.39.camel@linux> (raw)
In-Reply-To: <1384993966.1403.466.camel@snotra.buserror.net>
On Wed, 2013-11-20 at 18:32 -0600, Scott Wood wrote:
> For userspace value setting, it looks like gpiolib blocks the write if
> the pin if FLAG_IS_OUT is set. This suggests that this is an error
> condition for other uses as well. Though, I notice that
> mpc8xxx_gpio_dir_out() calls gpio_set() before actually changing the
> direction. So it may be useful to avoid races where the wrong value is
> output briefly after the direction is changed (especially in open drain
> situations, where the signal could have a meaningful default even before
> we begin outputting). But that raises the question of how you'd do that
> from userspace, and it also renders the to-be-output value as write-only
> data (until the direction is actually changed), since a readback would
> get the input value instead.
>
> > So maybe it's better to eliminate the effects of the ->data to the
> > input pins when reading the status, regardless of the possible changes
> > of the pins and the data.
> > Do you think so?
>
> Perhaps, but that doesn't require you to modify ->data in the get()
> function.
>
> -Scott
>
I think you considered about this more comprehensive.
I'll update the code without the modification of ->data in the get()
function, and also with the comments from Anatolij.
Best Regards,
Liu Gang
WARNING: multiple messages have this Message-ID (diff)
From: Liu Gang <Gang.Liu@freescale.com>
To: Scott Wood <scottwood@freescale.com>
Cc: linux-gpio@vger.kernel.org, linus.walleij@linaro.org,
linuxppc-dev@lists.ozlabs.org, r61911@freescale.com,
b07421@freescale.com
Subject: Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
Date: Fri, 22 Nov 2013 12:47:36 +0800 [thread overview]
Message-ID: <1385095656.16677.39.camel@linux> (raw)
In-Reply-To: <1384993966.1403.466.camel@snotra.buserror.net>
On Wed, 2013-11-20 at 18:32 -0600, Scott Wood wrote:
> For userspace value setting, it looks like gpiolib blocks the write if
> the pin if FLAG_IS_OUT is set. This suggests that this is an error
> condition for other uses as well. Though, I notice that
> mpc8xxx_gpio_dir_out() calls gpio_set() before actually changing the
> direction. So it may be useful to avoid races where the wrong value is
> output briefly after the direction is changed (especially in open drain
> situations, where the signal could have a meaningful default even before
> we begin outputting). But that raises the question of how you'd do that
> from userspace, and it also renders the to-be-output value as write-only
> data (until the direction is actually changed), since a readback would
> get the input value instead.
>
> > So maybe it's better to eliminate the effects of the ->data to the
> > input pins when reading the status, regardless of the possible changes
> > of the pins and the data.
> > Do you think so?
>
> Perhaps, but that doesn't require you to modify ->data in the get()
> function.
>
> -Scott
>
I think you considered about this more comprehensive.
I'll update the code without the modification of ->data in the get()
function, and also with the comments from Anatolij.
Best Regards,
Liu Gang
next prev parent reply other threads:[~2013-11-22 4:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-15 7:16 [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536 Liu Gang
2013-11-15 7:16 ` Liu Gang
2013-11-19 9:49 ` Linus Walleij
2013-11-19 9:49 ` Linus Walleij
2013-11-19 15:32 ` Anatolij Gustschin
2013-11-19 15:32 ` Anatolij Gustschin
2013-11-20 2:07 ` Liu Gang
2013-11-19 22:51 ` Scott Wood
2013-11-19 22:51 ` Scott Wood
2013-11-20 2:54 ` Liu Gang
2013-11-20 2:54 ` Liu Gang
2013-11-21 0:32 ` Scott Wood
2013-11-21 0:32 ` Scott Wood
2013-11-22 4:47 ` Liu Gang [this message]
2013-11-22 4:47 ` Liu Gang
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=1385095656.16677.39.camel@linux \
--to=gang.liu@freescale.com \
--cc=b07421@freescale.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=r61911@freescale.com \
--cc=scottwood@freescale.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 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.