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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 19 Nov 2020 03:11:22 -0800
From:   Prashant Malani <pmalani@...omium.org>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:     Benson Leung <bleung@...omium.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [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@...ux.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ