Messages in this thread | | | Date | Thu, 30 Jun 2016 10:10:25 -0700 | From | Guenter Roeck <> | Subject | Re: [PATCHv4 1/2] usb: USB Type-C connector class |
| |
On Wed, Jun 29, 2016 at 04:38:37PM +0300, Heikki Krogerus wrote: > The purpose of USB Type-C connector class is to provide > unified interface for the user space to get the status and > basic information about USB Type-C connectors on a system, > control over data role swapping, and when the port supports > USB Power Delivery, also control over power role swapping > and Alternate Modes. > > Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > --- [ ... ]
> + > +What: /sys/class/typec/<port>-partner/supports_usb_power_delivery > +Date: June 2016 > +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> > +Description: > + Shows if the partner supports USB Power Delivery. > + - 1 if USB Power Delivery is supported > + - 0 when it's not > + > + > +What: /sys/class/typec/<port>-partner/id_header_vdo > +Date: June 2016 > +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com> > +Description: > + If the partner supports USB Power Deliver, shows the VDO > + returned from Discover Identity USB Power Delivery command. > + > + If the partner does not support USB Power Delivery, the > + attribute is hidden. > + On second thought, and after merging the code (and realizing that I don't get the raw data from the Type-C Port Manager), I am not sure if a raw attribute is that useful here. It also doesn't provide all information either.
Would it make sense to split it into multiple decoded attributes ?
- vendor-id [bit 0..15 of ID header VDO] - product-type (undefined, hub, peripheral, alternate mode adapter for ufp; passive/active for cable plugs) Might map into typec_partner_type, but I don't see a 1:1 match. [bit 27..29 of ID header VDO] - alternate-mode-supported [bit 26 of ID header VDO] - capabilities (ufp, dfp, drp, none (?)) [bit 30/31 of ID header VDO] - product-id [bit 16..31 of Product VDO]
Does this make any sense ?
Thanks, Guenter
| |