From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755312AbcEYPTz (ORCPT ); Wed, 25 May 2016 11:19:55 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:51539 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755207AbcEYPTx (ORCPT ); Wed, 25 May 2016 11:19:53 -0400 Date: Wed, 25 May 2016 08:19:47 -0700 From: Guenter Roeck To: Heikki Krogerus Cc: Oliver Neukum , Andy Shevchenko , Rajaram R , Felipe Balbi , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class Message-ID: <20160525151947.GB19413@roeck-us.net> References: <1463661894-22820-1-git-send-email-heikki.krogerus@linux.intel.com> <1464094300.11721.17.camel@suse.com> <20160525112846.GB27570@kuha.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160525112846.GB27570@kuha.fi.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Authenticated_sender: guenter@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: guenter@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: guenter@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 25, 2016 at 02:28:46PM +0300, Heikki Krogerus wrote: > Hi, > > On Tue, May 24, 2016 at 02:51:40PM +0200, Oliver Neukum wrote: > > On Thu, 2016-05-19 at 15:44 +0300, Heikki Krogerus wrote: > > > > Hi, > > > > as this discussion seems to go in circles, I am starting anew > > at the top. > > > > > Like I've told some of you guys, I'm trying to implement a bus for > > > the Alternate Modes, but I'm still nowhere near finished with that > > > one, so let's just get the class ready now. The altmode bus should in > > > any case not affect the userspace interface proposed in this patch. > > > > > > As you can see, the Alternate Modes are handled completely differently > > > compared to the original proposal. Every Alternate Mode will have > > > their own device instance (which will be then later bound to an > > > Alternate Mode specific driver once we have the bus), but also every > > > partner, cable and cable plug will have their own device instances > > > representing them. > > > > The API works for a DFP. I fail to see how the UFP learns about entering > > an alternate mode. > > Secondly, support to trigger a reset is missing > > I'm fine with adding an attribute for port and cable resets if it's > something that is needed. So do you want to be able to execute hard > reset on a port? > > But could you please explain the case(s) where you need to tricker a > reset. > > > > An other change is that the data role is now handled in two ways. > > > The current_data_role file will represent static mode of the port, and > > > it will use the names for the roles as they are defined in the spec: > > > DFP, UFP and DRP. This file should be used if the port needs to be > > > > Good, but support for Try.SRC and Try.SNK is missing. > > OK, but what is Try.SNK? It's not in the specs? > It is not in the USB PD specification, but in "USB Type-C Specification Release 1.2 - Cable and Connector Specification". Section 4.5.2.2.11, "Try.SNK State", says "Note: if both Try.SRC and Try.SNK mechanisms are implemented, only one shall be enabled by the port at any given time. Deciding which of these two mechanisms is enabled is product design-specific." ... which is why I suggested earlier that there should be a platform parameter to enable one or the other. Guenter