From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1945953AbcBRKXl (ORCPT ); Thu, 18 Feb 2016 05:23:41 -0500 Received: from mx2.suse.de ([195.135.220.15]:56266 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1426137AbcBRKVD (ORCPT ); Thu, 18 Feb 2016 05:21:03 -0500 Message-ID: <1455790706.1384.29.camel@suse.com> Subject: Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software Interface From: Oliver Neukum To: Felipe Balbi Cc: Felipe Balbi , Heikki Krogerus , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Date: Thu, 18 Feb 2016 11:18:26 +0100 In-Reply-To: <8737sqsdgf.fsf@ti.com> References: <1455037283-106479-1-git-send-email-heikki.krogerus@linux.intel.com> <1455037283-106479-3-git-send-email-heikki.krogerus@linux.intel.com> <20160209182155.GC31787@kroah.com> <20160210103042.GB5270@kuha.fi.intel.com> <20160210172035.GA28335@kroah.com> <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> <87egcbihpg.fsf@ti.com> <1455717104.7626.20.camel@suse.com> <8737sqsdgf.fsf@ti.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2016-02-18 at 09:08 +0200, Felipe Balbi wrote: > Oliver Neukum writes: > >> Oliver Neukum writes: Hi, > > What exactly are you sure about about? > > heh, missed a NOT there :-) I am still confused :-) Do you think a sysfs interface is good, bad or good but insufficient? > >> that, eventually, we will need an actual stack exposed for the CC pin. > > > > The raw CC pin? What about the timing requirement? > > well, not the _raw_ CC pin, but a situation where the microcontroller > handling CC pin is "dumb", in the sense that it provides an interface > for us to request/start arbitrary transactions. That will, in turn, > shift the actual bits on the CC pin. Or something along these lines. Well, how else would we send vendor specific messages? > An example would be the alternate mode thing. CC microcontroller doesn't > have to know what are the available alternate modes, but it needs to be > able to tell processor what request is coming from the other end. Indeed. > I guess what I'm trying to say is that CC microcontroller might not be > the one controlling the multiplexer which switches USB pins to another > function. IOW: > > Change to alternate mode X message > CC microcontroller interrupts CPU > read status to get X > change multiplexer > Yes. But it seems to me that in this case we need a kernel driver without an API to user space. There are necessarily internal users of the PD controller. There are also external users. So the CC pins should be seen as a bus, which in essence they are (it reminds me of ancient ethernet actually), and if you really want full user space access, you'd need the quivalent of an sg driver. The issue is orthogonal to the question how we support UCSI, except that UCSI is a user of the CC pins and PD and frankly I don't see the firmware and a driver access this sanely simultaneously. Therefore I'd prefer we make an API here which does not depend on UCSI, but can, if necessary, work on top of a driver doing full hardware access. Regards Oliver