From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754265AbcEWRJ0 (ORCPT ); Mon, 23 May 2016 13:09:26 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:38554 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753010AbcEWRJZ (ORCPT ); Mon, 23 May 2016 13:09:25 -0400 Date: Mon, 23 May 2016 10:09:19 -0700 From: Guenter Roeck To: Oliver Neukum Cc: Heikki Krogerus , Andy Shevchenko , Rajaram R , Felipe Balbi , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class Message-ID: <20160523170919.GB5964@roeck-us.net> References: <1463661894-22820-1-git-send-email-heikki.krogerus@linux.intel.com> <1463753999.14070.7.camel@suse.com> <20160523095733.GB16900@kuha.fi.intel.com> <1464002719.12181.42.camel@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1464002719.12181.42.camel@suse.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Authenticated_sender: guenter@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: guenter@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: guenter@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 23, 2016 at 01:25:19PM +0200, Oliver Neukum wrote: > On Mon, 2016-05-23 at 12:57 +0300, Heikki Krogerus wrote: > > Hi Oliver, > > > > On Fri, May 20, 2016 at 04:19:59PM +0200, Oliver Neukum wrote: > > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > > > > Like I've told some of you guys, I'm trying to implement a bus for > > > > the Alternate Modes, but I'm still nowhere near finished with that > > > > one, so let's just get the class ready now. The altmode bus should in > > > > any case not affect the userspace interface proposed in this patch. > > > > > > Is this strictly divorced from USB PD? > > > > The bus can not be tied to the USB PD stack we will have in the > > kernel completely, or there is no change of using it with things like > > UCSI. It's going to be difficult to achieve that in any case as we > > simply won't be able to send and rescieve the VDMs with things like > > UCSI, but let's see. > > > > > How do you trigger a cable reset or a USB PD reset? > > > > There needs to be an API, but I'm sure that's not going to be a > > problem. The bus and the altmode specific drivers will reside inside > > kernel. > > Absolutely. But at some point we need to settle on an API. > If I am to tell you whether your proposed API leaves out > something that needs to be covered, I need to know what > is to go into the other APIs. > > A reset is a generic function, so it does not belong to specific > drivers. > A would expect the driver to execute the reset. Maybe the question should be phrased differently: Even USCI (which doesn't provide for everything) has commands to reset the policy manager and to reset the connector. The class should provide a means to execute those commands. > > But I'm getting the sense that you are thinking about having some > > responsibility of USB PD in userspace. Please correct me if I'm wrong. > > Gods help us all if we are ready to do that. > It would fail. > Yet I think the idea that PD and Alternate Modes can be cleanly > divorced is wrong. The selection of Alternate Modes is done by > USB PD messages. We can encapsulate that, but we cannot leave it out, > especially in the area of resets. > > > I don't think it will be possible. I think the role of userspace can > > only be the source for high level requests via this interface, like > > enter/exit mode and swap role, and receiving the status and details of > > the ports, but any knowledge about the requirements regarding those > > steps belongs to the kernel. This includes also the knowledge about > > Yes. > > > stuff like mode dependencies, for example if cable plug has to be in a > > certain mode in order for the partner to be able to enter some > > specific mode, etc. > > Yes. > > So for Alternate Modes we need on a high level the following features > > 1. discovery of available Alternate Modes > 2. selection of an Alternate Mode > 3. notification about entering an Alternate Mode > 4. triggering a reset > 5. notification about resets > > 6. discovery about the current role > 7. switching roles > 8. setting preferred roles (Try.SRC and Try.SNK) > Isn't reset and role handling orthogonal to alternate mode functionality ? Both will still be needed even if alternate mode support is not implemented at all. > You covered 1. and 2. > 3. can be covered by specific drivers > 4. and 5. are not covered (and it makes no sense to tie it > to specific drivers) > > 6. and 7. is covered > 8. is not > > And 8. needs to be covered. It affects who selects the Alternate Mode. Doesn't the actual role determine that ? A device which prefers to be a DFP might still end up as UFP. > You cannot tie it to USB and it doesn't fit with pure PD stuff. > > I like your API as it is now. But it is incomplete. > Same here. Thanks, Guenter