Hi Benson, On Wed, Nov 18, 2020 at 09:48:21AM -0800, Benson Leung wrote: > > +What: /sys/class/typec/<port>-partner/product_type > > +Date: December 2020 > > +Contact: Heikki Krogerus <heikki.kroge...@linux.intel.com> > > +Description: USB Power Delivery Specification defines a set of > > product types > > + for the partner devices. This file will show the product type of > > + the partner if it is known. Dual-role capable partners will have > > + both UFP and DFP product types defined, but only one that > > + matches the current role will be active at the time. If the > > + product type of the partner is not visible to the device driver, > > + this file will not exist. > > + > > + When the partner product type is detected, or changed with role > > + swap, uvevent is also raised that contains PRODUCT_TYPE=<product > > + type> (for example PRODUCT_TYPE=hub). > > + > > + Valid values: > > + > > + UFP / device role > > + ======================== ========================== > > + undefined - > > + hub PDUSB Hub > > + peripheral PDUSB Peripheral > > + psd Power Bank > > + ama Alternate Mode Adapter > > + vpd VCONN Powered USB Device > > I have it on good authority that "vpd" is incorrectly categorized here, > and for future proofing, we'd better not introduce vpd as a product > type for UFP... > > A vpd is actually more closely related to a "cable" than it is a "UFP." > A closer reading of the USB Type-C and USB PD specs will reveal that > VPDs can only ever appear as SOP' and not as SOP, so having its type > appear under UFP is a mistake. > > In other words, the USB PD V3.0 R2.0 spec is wrong. A change has been > working its way through the spec committee to fix this, but it is not yet > published. > > In order to reduce the amount of churn, I would recommend not > including vpd as a possible type until a new version of the spec (or the ECN) > is published.
Thanks for the heads-up. I'll leave the vpd out then. cheers, -- heikki
