Re: [PATCH] usb: typec: Defer checking of valid power role swap to low level drivers

From: Guenter Roeck
Date: Wed May 17 2017 - 09:02:57 EST


On 05/17/2017 05:38 AM, Heikki Krogerus wrote:
Hi guys,

On Wed, May 17, 2017 at 02:36:44AM -0700, Guenter Roeck wrote:
On 05/17/2017 12:34 AM, Oliver Neukum wrote:
Am Mittwoch, den 17.05.2017, 00:32 -0700 schrieb Badhri Jagan
Sridharan:

Hi,

"Two independent set of mechanisms are defined to allow a USB Type-C
DRP to functionally swap power and data roles. When USB PD is
supported, power and data role swapping is performed as a subsequent
step following the initial connection process. For non-PD implementations,
power/data role swapping can optionally be dealt with as part of the initial
connection process."

Well, as I read it, without PD once a connection is established, you
are stuck with your role. So it seems to me that blocking a later
attempt to change it makes sense.


That seems to be a harsh and not very user friendly reading of the specification.

I would argue that the user doesn't care if the partner supports PD or not
when selecting a role, and I would prefer to provide an implementation which is
as user friendly as possible.

I agree. But I have to point out that at least with UCSI, the role
swapping is usually not possible without USB PD connection.

So what I'm trying to say is that we can't really promise that role
swapping will ever be possible in all cases without PD, which may mean
different behavior depending on the platform. I don't know if that is
a huge problem.

How predictable do we want this interface to function with role
swapping?


We can only do as good as we can, but we should not preclude it either.
PR_SWAP and other swap operations fail a lot in practice with many dongles,
just because the PD protocol implementation isn't always stable. So even that
won't be predictable for some time to come.

As Badhri pointed out earlier, at least some low cost devices won't support PD.
Since we are talking about high volume products, we _have_ to make it as
user friendly as we can, if for nothing else to reduce the number of customer
service calls, repeated bug filings, and, last but not least, to avoid bad press.

Thanks,
Guenter