From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1946079AbcBRKmo (ORCPT <rfc822;w@1wt.eu>);
	Thu, 18 Feb 2016 05:42:44 -0500
Received: from mx2.suse.de ([195.135.220.15]:60545 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1945981AbcBRKmk (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 18 Feb 2016 05:42:40 -0500
Message-ID: <1455792003.1384.33.camel@suse.com>
Subject: Re: [PATCH 2/3] usb: type-c: USB Type-C Connector System Software
 Interface
From: Oliver Neukum <oneukum@suse.com>
To: Felipe Balbi <balbif@gmail.com>
Cc: Felipe Balbi <balbi@kernel.org>,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Mathias Nyman <mathias.nyman@linux.intel.com>,
        Greg KH <gregkh@linuxfoundation.org>, linux-kernel@vger.kernel.org,
        linux-usb@vger.kernel.org
Date: Thu, 18 Feb 2016 11:40:03 +0100
In-Reply-To: <87twl6qpim.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>
	 <1455790706.1384.29.camel@suse.com> <87twl6qpim.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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 2016-02-18 at 12:30 +0200, Felipe Balbi wrote:
> Hi,
> 
> Oliver Neukum <oneukum@suse.com> writes:
> >> > 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?
> 
> 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.

That will happen. The alternative, however is a "typectool" or
"usbpdtool" which would need to be updated for new features.

> >> 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
> 
> that assumes kernel always knows all possible alternate modes. What do
> we about bogus requests (request alternate mode X when X is not
> supported) ?

Do as the spec says: NACK it.

The questions which modes we offer, if we are a slave, still remains.
And I think the API is deficient in that regard. But again that question
is orthogonal of both issue, handling of bogus requests and how the
CC pins are exported.

	Regards
		Oliver