USB: serial: cp210x: Implement GPIO support for CP2102N

[Johan Hovold <johan@kernel.org>]

On Fri, Jun 22, 2018 at 04:10:21PM +0100, Martyn Welch wrote:
> On Wed, 2018-06-20 at 19:41 +0000, Karoly Pados wrote:

> > Here I argue the following multiple ways. First, I say that claiming
> > that a pin which is used as an input is actually an output is not
> > only confusing, but also much less correct than thinking of it as an
> > input pin with a weak pullup to prevent floating signals. Second,
> > the pullups - while not  explicitly listed in the datasheet - can be
> > calculated from what is there,  and for the cp2105 are typically
> > 132k, for the cp2102n even higher around  165k. These are pretty
> > weak pullups, so weak that they won't matter for the vast majority
> > of applications as people rarely use pull-ups or pull- downs higher
> > than 100k (not never, but rarely). So claiming that it can result in
> > false expectation, while not completely wrong, is favoring the 
> > needs of a few instead of the much more common practice.
> > 
> > Lastly, and maybe most importantly, I argue that calling everything
> > an  "output" pin only in name does not actually avoid any design
> > errors, as the same circuit that would case a false reading in one
> > case would also cause the same false reading in the other, and the
> > circuits are usually developed before the software. So it'll be too
> > late anyway by the time  somebody realizes such a mistake. But on
> > the contrary, it opens up more  opportunities for errors, because
> > now you are open to software bugs that ignore a pin's direction
> > because everything's an output either way even  when it really
> > isn't, and think that they can treat it as as open-drain while for
> > some reason it is in push-pull mode. Worse, even if it is in
> > open-drain mode, it will only work with a specific output values -
> > it must be high, which is not the default. With my proposal, 
> > setting a pin's direction to "input" will make sure it cannot be
> > actively  driven by the chip, avoiding such "misunderstandings" and
> > errors, and  similar measures are also in place for the push-pull
> > pins.
> 
> Yeah, I'll go with that. :-)

Sounds good to me too. Thanks to both of you for spelling this out.

> > The only problem I can see is if there isn't a way for the cp2105 to 
> > query the reset values of the pins (maybe there is, I just haven't 
> > looked into it). Then I don't know how the direction could be 
> > determined for an open-drain pin during initialization. But this is 
> > solved for the cp2102n, and then it is a device-specific issue for 
> > the cp2105, which shouldn't be forced onto other devices if we
> > otherwise decide the approach to be inferior.
> 
> I'm pretty sure there is a way to determine the pin state, though
> unfortunately I no longer have access to the HW to be able to test...

If this isn't (yet) possible, it's never wrong to continue treating the
cp2105 pins as (open-drain) outputs.

Thanks,
Johan
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html