Message-ID: <7369694284fcea1a8d7c142f47ab361f@pados.hu>
Date:   Wed, 20 Jun 2018 19:41:14 +0000
From:   "Karoly Pados" <pados@...os.hu>
To:     "Martyn Welch" <martyn.welch@...labora.co.uk>,
        "Johan Hovold" <johan@...nel.org>
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

Hi Martyn,

> 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.

You didn't miss anything. It is the same for many (maybe all) SiLabs
devices, in particular also for the cp2102n, which spawned this conversation.
I sent in patches for its GPIO support, but in contrast to the cp2105,
I try to emulate input mode by making sure that a pin is never pulled low
when it is set as an input, and that you cannot set push-pull pins as inputs.
The reason why you were invited is because we are trying to figure out which
approach should be taken.

> 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.

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.

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.

Karoly

Powered by blists - more mailing lists