From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423074AbcBQNgz (ORCPT ); Wed, 17 Feb 2016 08:36:55 -0500 Received: from mail-lb0-f173.google.com ([209.85.217.173]:36103 "EHLO mail-lb0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1422802AbcBQNgw (ORCPT ); Wed, 17 Feb 2016 08:36:52 -0500 From: Felipe Balbi To: Heikki Krogerus , Oliver Neukum Cc: 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 In-Reply-To: <20160217111116.GB24649@kuha.fi.intel.com> References: <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> <20160217111116.GB24649@kuha.fi.intel.com> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/25.0.50.1 (x86_64-pc-linux-gnu) Date: Wed, 17 Feb 2016 15:36:46 +0200 Message-ID: <87bn7fihld.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, 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, >> >=20 >> > 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: >>=20 >> > >> > 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. >> > >>=20 >> > >> 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. >> >=20 >> > yeah, in fact I have been wondering if sysfs is the best interface to >>=20 >> That is the discussion we must have. >>=20 >> > 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. >>=20 >> 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 ? 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 ? IIRC mode and role negotiation goes via CC pins using the power delivery protocol. If I misunderstand anything, let me know. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWxHduAAoJEIaOsuA1yqREG/MP/0DsfbtbkLqv6bzKmbJC3nfS 0Z+r9NF6bjgnp8GXlViS9nXNdv7k+4CRzc8E/5tpE0CX7sd69LA2xvYCCIXY1jQr Fa8PKqjz0Vuw507tlPKCR7G8UbWxdAVApaMA/7C0CXWSQLuobCSaZ1E9iz00MfIO mOKocqo5glqqeXn4GNNR+nZD0wSC5WP02Lrerl+5ZDJ40urDAaLKHdTP8o9IQtOC sM3nGYhRZ9pF/bp3ZJa5SONzCo4MWFIatK0uXrlaRJGjgzfwC53ZMmt7gIpokIYT cTsQ2MmWSwGdntv135qXjjA+jbzjaaX9nEcXfdTvWwEX7XJBhGDiHF08BbU17/8i EL2+BU5ivwBX4hbUILponBMvBmExFtnt1/hbiNqCTw6jT0HuuNLES+zVj9UiuQOh 0a4lpeALpy1LbXYVd2HdW8l8GnSDUjo/mp6DZraGEdmcVd2LpOJ1ccxLbwULaKtD MwMaJC/xRrIlJ57k3K/LRJddygWjWJunh1tPFZK0QKZsbGNHoBbMR4sDROEVm2j6 /TjvyzpquUqYGA79eTyu0KRRti9UBV8W8ZcUJFVPiTkpZJq02PIEhN/XLLDOp63u U0LiiJ4YYRK1nHX5M4E8X+ezNdkxIL55frkX4DpJqABlt+ab+bKSnr6kh4cO5FbZ /9owbLEaifCZrK5J/HkF =dDaV -----END PGP SIGNATURE----- --=-=-=--