Message-ID: <1529513516.2395.23.camel@collabora.co.uk>
Date:   Wed, 20 Jun 2018 17:51:56 +0100
From:   Martyn Welch <martyn.welch@...labora.co.uk>
To:     Johan Hovold <johan@...nel.org>, Karoly Pados <pados@...os.hu>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] USB: serial: cp210x: Implement GPIO support for CP2102N

On Wed, 2018-06-20 at 12:52 +0200, Johan Hovold wrote:
> > > [ Adding Martyn who implemented the cp2105 gpio support. ]
> > > So for cp2105 we decided against implementing an input mode. We
> > > at least
> > > need to be consistent here, so I suggest starting with dropping
> > > those
> > > 
> > 
> > Again, you're the boss, but I do find this odd. These are different
> > devices and thankfully now there'd be better support for the
> > cp2102n,
> > and you're asking me to remove input support for consistency
> > reasons.
> > To remove a feature for one device just because it wasn't correctly
> > implemented in another and wanting to stay consistent with the
> > missing
> > support is very odd for me tbh.
> > I know I'm in no position, but please let me ask you once to please
> > reconsider this.
> 
> We're not removing anything from the kernel since nothing has yet
> been
> merged. I'm asking you to separate it into a follow up patch, which
> if
> we find it useful and correct would allow the same functionality for
> cp2105 as well.
> 
> The gpio pins on cp2102n and cp2105 share the same electrical
> characteristics and there's no good reason why we should treat them
> differently.
> 
> > The way it was done for the cp2105 where we make everything and
> > everyone on the system think that a pin is "out" but in reality is
> > an
> > input is quirky to say the least, while at the same time it also
> > does
> > not make sure that an input pin (which is of course not marked as
> > such) is really an input.  Why amputate the cp2102n like this if it
> > has been already implemented correctly?  If we wanted to stay
> > consistent with half-developed and incomplete drivers then there'd
> > be
> > no improvements to Linux.
> 

The rationale for the pins being permanently configured as output pins
is that these pins (at least on the cp2105) do not appear to provide a
true input mode. They offer a "push-pull" mode (where the voltage is
pulled directly to ground or supply rail) and an "open-drain" mode
(where the pin is weakly pulled high by an internal resistor and can be
pulled to ground). Unless I missed something, there is no tristate/high
impedance mode typically associated with a pin being used as input.

Sure, you can use the open-drain mode as input as long as you
understand that the permanent pull up in the cp2015 might have an
impact on what you are reading. For example, if you have a signal that
is externally weakly pulled down, it's going to depend on the relative
resistances of the internal and external resistors as to what voltage
the line rests at and therefore what state the line is considered to be
in. This could stop things working if you naively think the cp2105 is
acting as a typical high-impedance input.

So, with that in mind, we came to the decision that as you *can* read
the state of the output when in open-drain mode, doing it that way may
avoid such potential issues. I didn't do an exhaustive search of other
GPIO devices at the time, so if it can be shown that the majority of
other GPIO drivers with such limitations can be placed into an input
state, I'd be happy for it to be changed so as to remain consistent.


Martyn

Powered by blists - more mailing lists