lkml.org 
[lkml]   [2020]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 2/3] usb: typec: Add product_type sysfs attribute file for partners and cables
Hi Heikki,

On Thu, Nov 19, 2020 at 01:05:06PM +0200, Heikki Krogerus wrote:
> On Wed, Nov 18, 2020 at 10:53:50AM -0800, Prashant Malani wrote:
> > > +What: /sys/class/typec/<port>-cable/product_type
> > > +Date: December 2020
> > > +Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
> > > +Description: USB Power Delivery Specification defines a set of product types
> > > + for the cables. This file will show the product type of the
> > > + cable if it is known. If the product type of the cable is not
> > > + visible to the device driver, this file will not exist.
> > > +
> > > + When the cable product type is detected, uvevent is also raised
> > > + with PRODUCT_TYPE showing the product type of the cable.
> > > +
> > > + Valid values:
> > > +
> > > + ======================== ==========================
> > > + undefined -
> > > + active Active Cable
> > > + passive Passive Cable
> > > + ======================== ==========================
> >
> > There exists a /sys/class/typec/<port>-cable/type attribute (connected
> > to the "active" field in struct typec_cable [1]), which is supposed
> > to be populated by the Type C port driver. Won't the newly introduced
> > attribute duplicate the same information as "type"?
>
> True. So we don't need add this for the cable separately. I'll just
> modify the code so that it considers also the response to Discover
> Identity command if we have access to it.
>
> Would it be OK if we name the file "type" instead of "product_type"
> also with the partners?

That makes the naming consistent. Sounds good to me :)

Best regards,

-Prashant

\
 
 \ /
  Last update: 2020-11-19 12:13    [W:0.222 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site