From: Martyn Welch <martyn.welch@collabora.co.uk>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Johan Hovold <johan@kernel.org>,
Alexandre Courbot <gnurou@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Karl Palsson <karlp@tweak.net.au>,
Konstantin Shkolnyy <Konstantin.Shkolnyy@silabs.com>,
Peter Senna Tschudin <peter.senna@collabora.com>
Subject: Re: [PATCH v6 1/1] USB: serial: cp210x: Adding GPIO support for CP2105
Date: Fri, 7 Oct 2016 16:31:26 +0100 [thread overview]
Message-ID: <20161007153126.GA355@hermes.home> (raw)
In-Reply-To: <CACRpkdbQzigYvx61S__+=qW1+NWxDyxUyg-Tm0=8Sj42xy6EWg@mail.gmail.com>
On Tue, Oct 04, 2016 at 02:13:26PM +0200, Linus Walleij wrote:
> On Sat, Sep 24, 2016 at 12:50 AM, Martyn Welch
> <martyn.welch@collabora.co.uk> wrote:
>
> > This patch adds support for the GPIO found on the CP2105.
>
>
> > This device supports either push-pull or open-drain modes, it doesn't
> > provide an explicit input mode, though the state of the GPIO can be read
> > when used in open-drain mode. Like with pin use, the mode is configured in
> > the one-time programable PROM and can't be changed at runtime.
>
> I see.
>
> So implement .direction_input() and .direction_output()
> anyways.
>
> Return failure on .direction_input() if it is in push-pull mode.
>
> Return success on all .direction_output() calls.
>
> Then implement .set_single_ended() and return success for open drain
> if the is in open drain, success for push-pull if the line is in push-pull
> mode, and failure in all other cases. Simple, but correct.
>
This is proving to be problematic, because we are trying to be clever in
gpiolib and the driver.
I have the driver setup as above, if I have a pin that is configured as
open-drain (and can't be changed) and I try to drive it as an open-source
output with a low output value, it succeeds.
This is because, in gpiolib, if the device can't actually be set as o-s,
we configure it as input to emulate o-s (_gpiod_direction_output_raw):
else if (test_bit(FLAG_OPEN_SOURCE, &desc->flags)) {
if (gc->set_single_ended) {
ret = gc->set_single_ended(gc, gpio_chip_hwgpio(desc),
LINE_MODE_OPEN_SOURCE);
if (!ret)
goto set_output_value;
}
/* Emulate open source by not actively driving the line low */
if (!value)
return gpiod_direction_input(desc);
In the driver we can't change it to input, but we are trying to be clever,
so we allow pins which are o-d to be treated as though they are inputs. However, for the o-d to behave like an input at all, the pin must be driven with a "1" (i.e. pulled up, rather than driven low), so:
/*
* Return failure if pin is configured in push-pull mode, can only
* emulate input when pin is configured as open-drain
*/
if (priv->gpio_mode & BIT(gpio))
return -ENOTSUPP;
/*
* Ensure we are outputting a high state so that we can use the
* open-drain output as an input
*/
cp210x_gpio_set(gc, gpio, 1);
So now we have a pin that is supposed to be pulling to ground that is
actually pulling to VCC.
Also, if an output can only be open-drain, attempting to set the pin as
push-pull succeeds because gpiolib (currently) assumes that a pin can
always be p-p and doesn't even check the return value of it's call to
.set_single_ended:
/* Make sure to disable open drain/source hardware, if any */
if (gc->set_single_ended)
gc->set_single_ended(gc,
gpio_chip_hwgpio(desc),
LINE_MODE_PUSH_PULL);
This is clearly a separate issue.
WRT this driver, I think I need to keep set_single_ended, but change .direction_input to always return a failure and have .direction_output always return success to avoid pins being driven in unexpected ways. Does that sould acceptable?
Martyn
next prev parent reply other threads:[~2016-10-07 15:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-23 22:50 [PATCH v6 1/1] USB: serial: cp210x: Adding GPIO support for CP2105 Martyn Welch
2016-10-04 12:13 ` Linus Walleij
2016-10-07 15:31 ` Martyn Welch [this message]
2016-10-07 17:02 ` Martyn Welch
2016-10-10 9:24 ` Linus Walleij
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=20161007153126.GA355@hermes.home \
--to=martyn.welch@collabora.co.uk \
--cc=Konstantin.Shkolnyy@silabs.com \
--cc=gnurou@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=johan@kernel.org \
--cc=karlp@tweak.net.au \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=peter.senna@collabora.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).