linux-kernel - Re: [PATCHv13 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161207125231.GB11966@kuha.fi.intel.com>
Date:   Wed, 7 Dec 2016 14:52:31 +0200
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Oliver Neukum <oneukum@...e.com>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Greg KH <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCHv13 2/3] usb: USB Type-C connector class

Hi Oliver,

On Wed, Dec 07, 2016 at 10:46:48AM +0100, Oliver Neukum wrote:
> On Fri, 2016-12-02 at 10:04 -0800, Guenter Roeck wrote:
> 
> Hi,
> 
> > At least for my part I very much concentrated on making sure that
> > the user space ABI as well as the port driver API are sane and usable.
> 
> Rightly so, as this part cannot be changed once included in a kernel
> release.
> So, can we agree that that part at least is ready to go?

I at least have no plans on doing any changes to the ABI. The API will
change.

> > The driver interface is not my area of expertise. As such, my testing
> > and understanding of that part was limited to "it appears to work,
> > it must be ok". I very much relied on you to get this part right.
> > 
> > That makes me feel really bad. It isn't fun to have my "Reviewed-by"
> > on a patch that gets (and apparently deserves) a WTF from a senior
> > kernel maintainer. This hurts both your and my reputation, and obviously
> > will make me quite hesitant to add a "Reviewed-by:" to the next version
> > of the series.
> 
> The driver model is arcane. It is the reason we have people who really
> understand it review code.
> 
> But I think it is a reason we need to question assumptions.
> Is it really true that the lifetimes of both ends of a plug
> are tightly locked? What happens if you unplug a cable
> whose ends have different power supplies?

This is just a sidenote. Since both plugs will be registered and
unregistered separately with the new API I'm going to propose,
removing only one of the plugs will then be possible. I can't say if
the specifications actually allow that, but the API will not block
it. Both plugs are in any case represented as their own devices with
the cable as the parent as before.


Thanks,

-- 
heikki