From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423456AbcBQO2W (ORCPT ); Wed, 17 Feb 2016 09:28:22 -0500 Received: from mga03.intel.com ([134.134.136.65]:20943 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423215AbcBQO2U (ORCPT ); Wed, 17 Feb 2016 09:28:20 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,460,1449561600"; d="scan'208";a="917191567" Date: Wed, 17 Feb 2016 16:28:16 +0200 From: Heikki Krogerus To: Felipe Balbi Cc: Oliver Neukum , Felipe Balbi , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface Message-ID: <20160217142816.GC24649@kuha.fi.intel.com> References: <20160211135011.GA32213@kuha.fi.intel.com> <1455550218.22176.11.camel@suse.com> <20160216092238.GA18565@kuha.fi.intel.com> <1455629987.4532.25.camel@suse.com> <20160217075841.GA24649@kuha.fi.intel.com> <1455699834.7626.4.camel@suse.com> <87fuwrsk7w.fsf@ti.com> <1455705412.7626.18.camel@suse.com> <20160217111116.GB24649@kuha.fi.intel.com> <87bn7fihld.fsf@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87bn7fihld.fsf@ti.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 17, 2016 at 03:36:46PM +0200, Felipe Balbi wrote: > > Hi, > > Heikki Krogerus writes: > > On Wed, Feb 17, 2016 at 11:36:52AM +0100, Oliver Neukum wrote: > >> On Wed, 2016-02-17 at 12:29 +0200, Felipe Balbi wrote: > >> > Hi, > >> > > >> > Oliver Neukum writes: > >> > > On Wed, 2016-02-17 at 09:58 +0200, Heikki Krogerus wrote: > >> > >> On Tue, Feb 16, 2016 at 02:39:47PM +0100, Oliver Neukum wrote: > >> > >> > >> > Yes, but we need an API. We can't keep adding to it. So if that > >> > >> > is to be supported, it needs to be defined now. > >> > >> > >> > >> When you say API, do you mean the API the class provides to the > >> > >> drivers? Or did you mean ABI which would be the sysfs in this case? > >> > > > >> > > The API to user space. That is the point. We cannot break user space. > >> > > Once this sysfs API is upstream we are stuck with it. > >> > > >> > yeah, in fact I have been wondering if sysfs is the best interface to > >> > >> That is the discussion we must have. > >> > >> > userspace. I talked with Heikki a few days back about this; I was > >> > wondering if something like what the NFC folks did with netlink would be > >> > better here. > >> > >> I doubt that, because the main user is likely to be udev scripts. > >> They can easily deal with sysfs attributes. > > > > IMHO for high level interface like this, sysfs is ideal because of the > > simple fact that you only need a shell to access the files. netlink > > would make us depend on custom software, no? > > > > I'm not against using netlink, but what would be the benefit from it > > in this case? > > With HW we see nowadays, CC stack is hidden on some microcontroller, but > is it too far-fetched to consider a system where this is not the case ? There already are several USB PD stacks out there, like also Greg pointed out. > Specially when we consider things like power delivery which, I know, you > wanted to keep it out of this interface, however we would have two > 'stacks' competing for access to the same pins, right ? No. This class would be the top layer for the coming stack, where ever it ends up coming. The class is only the interface to the user space and nothing else. By saying we need to keep USB Type-C separate from USB PD I meant that the userspace access can not be mixed somewhere in layers of the USB PD/CC stack like it has been in the USB PD stacks I've seen so far. They assume that we always use the software USB PD stack with USB Type-C, which as we can see is not true when the stack is implemented in EC or firmware or some complex USB PD controller or what ever. However, the operations the userspace needs to do are exactly the same in both cases. - data role swapping - power role swapping (depends on USB PD) - Alternate Modes (depends on USB PD) And we really should not forget that we actually also have USB Type-C PHYs that can't do any USB PD communication over the CC pin, so USB PD is simply not always going to be available. But the data role swapping and also accessories are still available with them, as the do not need USB PD. This was the whole point with the class. It allows the different ways of dealing with Type-C ports to be exposed to userspace in the same way. > IIRC mode and role negotiation goes via CC pins using the power delivery > protocol. If I misunderstand anything, let me know. The data role swap with USB Type-C connectors is in no way tied to USB Power Delivery. The USB Type-C spec defines that when USB PD is available, DR_Swap USB PD function is used to swap the role, otherwise emulated disconnect will do the trick. Data role swapping is a must thing to have with USB Type-C connectors because of the fact that the role is selected randomly. Regardless was USB PD supported or not. Thanks, -- heikki