From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752725AbcLGNHD (ORCPT ); Wed, 7 Dec 2016 08:07:03 -0500 Received: from mga01.intel.com ([192.55.52.88]:64692 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751742AbcLGNHB (ORCPT ); Wed, 7 Dec 2016 08:07:01 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,310,1477983600"; d="scan'208";a="200000533" Date: Wed, 7 Dec 2016 14:52:31 +0200 From: Heikki Krogerus To: Oliver Neukum Cc: Guenter Roeck , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCHv13 2/3] usb: USB Type-C connector class Message-ID: <20161207125231.GB11966@kuha.fi.intel.com> References: <20161124122144.26259-1-heikki.krogerus@linux.intel.com> <20161124122144.26259-3-heikki.krogerus@linux.intel.com> <20161129162744.GA2255@kroah.com> <20161130091910.GD32668@kuha.fi.intel.com> <20161202180439.GA25991@roeck-us.net> <1481104008.1960.3.camel@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1481104008.1960.3.camel@suse.com> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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