From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1425144AbcBRHI3 (ORCPT ); Thu, 18 Feb 2016 02:08:29 -0500 Received: from mail-pf0-f173.google.com ([209.85.192.173]:33666 "EHLO mail-pf0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1424633AbcBRHI2 (ORCPT ); Thu, 18 Feb 2016 02:08:28 -0500 From: Felipe Balbi X-Google-Original-From: Felipe Balbi To: Oliver Neukum , Felipe Balbi Cc: balbif@gmail.com, Heikki Krogerus , 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 In-Reply-To: <1455717104.7626.20.camel@suse.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> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/25.0.50.2 (x86_64-pc-linux-gnu) Date: Thu, 18 Feb 2016 09:08:16 +0200 Message-ID: <8737sqsdgf.fsf@ti.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Oliver Neukum writes: >> Oliver Neukum writes: >> >> > The API to user space. That is the point. We cannot break user spac= e. >> >> > Once this sysfs API is upstream we are stuck with it. >> >>=20 >> >> 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. >>=20 >> I'm entirely sure about this. I think it's not too far-fetched to think > > What exactly are you sure about about? heh, missed a NOT there :-) >> 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. 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. 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 =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWxW3gAAoJEIaOsuA1yqREoRgP/ih8XhToq5/aRrClBroEpZfm AxsJ9TR5ubUO0wKuctOnEhRoSHUZ+athsraKax0QB7SjCcfVKVvi4j53BKAn3Vvt w1UIqS1wXz3jUATXtbgRI5qIQ1h67h98sVYjTrpeC7lLG1VTO3gdIyfH2U6iWTB3 7it1Lb+84CTZXQ7iMkMpAsH2I8MtSgnNA1neHDFj3zjCZKZZlyvmyMbtpvcBZn0w j6a4s4SK9DHdG7DUcEPPiAio3oJNDjLG+Cqn6d/N7ymcW/GqturdWB0PrDlB9nzG d6rM+ICBHttBQVZaUCJPPoazPoDn7d/vLxLMZ3c73tIMt596Z4F4oKqhrYbjbStD zZ0UKETnZw9+c7OQq8q97sCDlNajAmgZYipaCo3u4rWGjoxyTiDCwOwPjmzSYfep O9Lb6V96594n1QHRhdX1zquExNtcpi5UbXEEwgd4AK53F73e8IGy9ctYuI3XBa+e ag6G+AWmzcTG/6zmDIOm07li5hhctscCyXswmeELmePWElkhWybvbkXm9b08O6Iu BxTbK8reSPPDzcY3cV+UwCVbGoTSlX3s8rIn6Vn3/p9GHoEwuhe8yr4YYOaSIuQQ EyGqvEVJqqo5Bl/md0sCvHSCqOc2Rg/JJo6XRa2vNUzMf/NUG/+H6gZfyzIgthiz t4/GJ62M6K5ZWV3XPUgp =Jbop -----END PGP SIGNATURE----- --=-=-=--