From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946029AbcBRKa6 (ORCPT ); Thu, 18 Feb 2016 05:30:58 -0500 Received: from mail-pa0-f47.google.com ([209.85.220.47]:32936 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1426054AbcBRKay (ORCPT ); Thu, 18 Feb 2016 05:30:54 -0500 From: Felipe Balbi X-Google-Original-From: Felipe Balbi To: Oliver Neukum , Felipe Balbi Cc: Felipe Balbi , 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: <1455790706.1384.29.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> <8737sqsdgf.fsf@ti.com> <1455790706.1384.29.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 12:30:41 +0200 Message-ID: <87twl6qpim.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: >> > What exactly are you sure about about? >>=20 >> heh, missed a NOT there :-) > > I am still confused :-) > Do you think a sysfs interface is good, bad or good > but insufficient? I'm not sure it's the best interface. My fear is that as new requirements/features come along, the amount of files will continue to grow. >> 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: >>=20 >> Change to alternate mode X message >> CC microcontroller interrupts CPU >> read status to get X >> change multiplexer >>=20 > > 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 that assumes kernel always knows all possible alternate modes. What do we about bogus requests (request alternate mode X when X is not supported) ? > 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. fair enough. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWxZ1RAAoJEIaOsuA1yqREBFkQAJPkDW1hV7W59b1VFPc3upLJ QltCCNNVHywWLJ6TfYqXaAaArKx2xKAXsgB4/0iYzOirDOYDYDQTFHu5/HHM5oCj wYSXqUY3EEWRkxZajhVNMFzL9M9rTKkznr8jDpRBXN6S5Gi8Rcb+fH8QvRrPT7/m Drlczua5nYi6UhWRV3hN8qA53mXK/X30P+FHqZYLLd0rJ21pxHB/h9eYj1fRyFCQ xYXHfFAwPo77RkRFCQd1lYooAUtcjmSQCCHsiMdO2WHXOb3MUXi2K9AxqJuKeCGJ X98hwyYlP6BC22oh/yFVKi11Wf/uLlvRmFhVam2FmiWZVLH17SppvbNt9FFssqa6 9JUS8FUgHKdkI35FLViAleq2S2IqkuXw2oEDwEY8v4gpd8Pie87JazuHKeJ8pkwE aDwQvxNIWZcfIIN2wZn5SugNulYYcWZlxmp92TZVZ9xL/2c6FFPuuvVF9OpgbyqH EZ+SaeEFRqroxB1qWLB/B5p5gn9YwrTrZTgvXa/8Dn6V/T1LduiLlePjiTiZTBsE 7AdZnQIn0h4IrRFg1o/zGZeLCi6dXJ0UgVmJHxZkSkm1dCHAJJ/beiiEAGiyf8PZ t/6IrFaaqbSNOPb6KjR/QsTNNDUT/Cmr+Uprx/mt6vqBCnaTuLLIZ09aoT81mF5x rA0DLqwQ8kqyGvuqqi3R =h84T -----END PGP SIGNATURE----- --=-=-=--