linux-kernel - Re: [PATCH] USB: serial: cp210x: Implement GPIO support for CP2102N

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180705130931.GA9802@localhost>
Date:   Thu, 5 Jul 2018 15:09:31 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Martyn Welch <martyn.welch@...labora.co.uk>
Cc:     Karoly Pados <pados@...os.hu>, Johan Hovold <johan@...nel.org>,
        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 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