From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752918AbcHZOPq (ORCPT ); Fri, 26 Aug 2016 10:15:46 -0400 Received: from mga09.intel.com ([134.134.136.24]:45918 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751388AbcHZOPp (ORCPT ); Fri, 26 Aug 2016 10:15:45 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,581,1464678000"; d="scan'208";a="753818532" Date: Fri, 26 Aug 2016 17:07:10 +0300 From: Heikki Krogerus To: Vincent Palatin Cc: Greg KH , Guenter Roeck , Oliver Neukum , Felipe Balbi , Bin Gao , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCHv6 1/3] usb: USB Type-C connector class Message-ID: <20160826140710.GG12117@kuha.fi.intel.com> References: <1471867560-93494-1-git-send-email-heikki.krogerus@linux.intel.com> <1471867560-93494-2-git-send-email-heikki.krogerus@linux.intel.com> <20160825115958.GE12117@kuha.fi.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vincent, On Fri, Aug 26, 2016 at 03:16:16PM +0200, Vincent Palatin wrote: > >> > +What: /sys/class/typec//current_vconn_role > >> > +Date: June 2016 > >> > +Contact: Heikki Krogerus > >> > +Description: > >> > + Shows the current VCONN role of the port. This attribute can be > >> > + used to request VCONN role swap on the port when the port > >> > + supports USB Power Delivery. > >> > + > >> > + Valid values are: > >> > + - source > >> > + - sink > >> > >> > >> either we are currently sourcing vconn or not, but even if you are > >> not, you are probably not a vconn sink either (ie only vconn-powered > >> accessory are, your usual linux-powered laptop/phone is probably not) > > > > It's not relevant to know whether the vconn is being actually used or > > not here. I'm not sure what's your point? > > > My point was: saying we are a VCONN "sink" just because we are not > currently sourcing vconn is usually not true. OK, I understand your point now. You are correct. I think we need to change this attribute and call it "vconn_source" that reports "1" or "0". I'll change that and send one more version of these on Monday (hopefully the last one) unless somebody disagrees. > >> > +What: /sys/class/typec/-partner/type > >> > +Date: June 2016 > >> > +Contact: Heikki Krogerus > >> > +Description: > >> > + Shows the type of the partner. Can be one of the following: > >> > + - USB - When the partner is normal USB host/peripheral. > >> > + - Charger - When the partner has been identified as dedicated > >> > + charger. > >> > + - Alternate Mode - When the partner supports Alternate Modes. > >> > + - Accessory - When the partner is one of the accessories with > >> > + specific Accessory Mode defined in USB Type-C > >> > + specification. > >> > >> > >> where a dock would be classified ? > > > > A dock is just USB PD capable device with a bunch of alternate modes > > that is attached to the port. There is no specific identifier for a > > "dock". > > My remark was a bit too stern, > I meant a dock might be 'USB' 'Charger' 'Alternate Mode' , all at the > same time or alternately depending what you plug in. > I don't really see those types as mutually exclusive. So USB type means the partner does not have alternate modes (I'll clear that in the documentation), Charger is a dedicated charger and therefore can not be anything else (no USB, no alternate modes). To answer your original question, a dock would be reported as Alternate Mode. Thanks, -- heikki