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

Powered by Openwall GNU/*/Linux Powered by OpenVZ