[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5f073751-a725-09a2-79be-49709bcd2cf9@roeck-us.net>
Date: Mon, 29 Aug 2016 06:04:52 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Vincent Palatin <vpalatin@...omium.org>
Cc: Greg KH <gregkh@...uxfoundation.org>,
Oliver Neukum <oneukum@...e.com>,
Felipe Balbi <felipe.balbi@...ux.intel.com>,
Bin Gao <bin.gao@...ux.intel.com>,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCHv6 1/3] usb: USB Type-C connector class
Heikki,
On 08/26/2016 07:07 AM, Heikki Krogerus wrote:
>
>>>>> +What: /sys/class/typec/<port>-partner/type
>>>>> +Date: June 2016
>>>>> +Contact: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
>>>>> +Description:
>>>>> + Shows the type of the partner. Can be one of the following:
>>>>> + - USB - When the partner is normal USB host/peripheral.
>>>>> + - Charger - When the partner has been identified as dedicated
>>>>> + charger.
>>>>> + - Alternate Mode - When the partner supports Alternate Modes.
>>>>> + - Accessory - When the partner is one of the accessories with
>>>>> + specific Accessory Mode defined in USB Type-C
>>>>> + specification.
>>>>
>>>>
>>>> where a dock would be classified ?
>>>
>>> A dock is just USB PD capable device with a bunch of alternate modes
>>> that is attached to the port. There is no specific identifier for a
>>> "dock".
>>
>> My remark was a bit too stern,
>> I meant a dock might be 'USB' 'Charger' 'Alternate Mode' , all at the
>> same time or alternately depending what you plug in.
>> I don't really see those types as mutually exclusive.
>
> So USB type means the partner does not have alternate modes (I'll
> clear that in the documentation), Charger is a dedicated charger and
> therefore can not be anything else (no USB, no alternate modes).
>
This is probably the most difficult attribute to support.
Many PD capable chargers support alternate modes (for firmware upgrades).
As I mentioned earlier, it is difficult to match reported Type-C partner
types (or really anything reported in the SVDM Identity command)
to the above types.
Does it really make sense to deviate that much from the Type-C specification ?
I can understand why you hesitate to use DFP / UFP, as those terms are
really hard to understand for the non-initiated. However, here it is really
difficult to even determine which value to set. The best I can come up with is
- Not PD capable. Report USB (obviously includes non-PD capable chargers)
- PD capable, supports alternate modes. Report as Alternate Mode (including
PD chargers supporting alternate modes)
- PD capable, does not support alternate modes. Report as Accessory if
connected as accessory, as charger if we the port is connected as sink,
USB otherwise
Overall this is quite vague and, especially for chargers, most of the time
misses the point.
I would really prefer if we could stay closer to the specification in this
case, and not try to merge multiple orthogonal attributes into one.
Thanks,
Guenter
Powered by blists - more mailing lists