From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161307AbcBQLLW (ORCPT ); Wed, 17 Feb 2016 06:11:22 -0500 Received: from mga14.intel.com ([192.55.52.115]:16955 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161067AbcBQLLU (ORCPT ); Wed, 17 Feb 2016 06:11:20 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,460,1449561600"; d="scan'208";a="916753149" Date: Wed, 17 Feb 2016 13:11:16 +0200 From: Heikki Krogerus To: Oliver Neukum Cc: Felipe Balbi , 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: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1455705412.7626.18.camel@suse.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 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? Thanks, -- heikki