linux-kernel - Re: [PATCHv14 2/3] usb: USB Type-C connector class

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] [day] [month] [year] [list]

Date:   Wed, 11 Jan 2017 13:05:32 +0200
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        Oliver Neukum <oneukum@...e.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCHv14 2/3] usb: USB Type-C connector class

Hi Guenter,

On Tue, Jan 10, 2017 at 09:35:42AM -0800, Guenter Roeck wrote:
> > I guess we might as well then split the VDO into header, cert stat and
> > product parts. What do you think?
> > 
> > If it's OK, then should we change that file to "identity" and dump the
> > whole response from Discover Identity command in hex (minus VDM
> > Header), separate the parts in the output, or simply provide separate
> > attribute files for each part?
> > 
> Makes me wonder what you expect in the vdo attribute today. Right now
> I copy the value from the identity header into it.
> 
> Personally I would prefer separate attributes. identity, cert_stat,
> product, maybe ?

OK.

I'm sorry for bringing this up so late, but I'm still a bit concerned
about having those attributes because we can't provide a value for
them in every system even when USB power delivery is supported. This
will be the case with at least with UCSI systems.

So what I'll do is, I'll group them into separate directory that will
not be visible unless those values can actually be made available. We
will have "supports_usb_power_delivery" attribute out side that
directory.

We can name that directory "identity" or we can call it for example
"usb_power_delivery" and have something else usb pd specific in it as
well if you like, like attribute for capability. Let me know what you
think.

I proposed putting the usb pd details into separate directory already
at one point, but not everybody liked the idea if I remember
correctly. I don't think there were any real arguments against it, so
this time I'll add the group unless you disagree.

Thanks,

-- 
heikki