From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751830AbcF3RLA (ORCPT ); Thu, 30 Jun 2016 13:11:00 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:54613 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751424AbcF3RKy (ORCPT ); Thu, 30 Jun 2016 13:10:54 -0400 Date: Thu, 30 Jun 2016 10:10:25 -0700 From: Guenter Roeck To: Heikki Krogerus Cc: Greg KH , Oliver Neukum , Felipe Balbi , Roger Quadros , Rajaram R , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [PATCHv4 1/2] usb: USB Type-C connector class Message-ID: <20160630171025.GA28994@roeck-us.net> References: <1467207518-55953-1-git-send-email-heikki.krogerus@linux.intel.com> <1467207518-55953-2-git-send-email-heikki.krogerus@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1467207518-55953-2-git-send-email-heikki.krogerus@linux.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, Jun 29, 2016 at 04:38:37PM +0300, Heikki Krogerus wrote: > The purpose of USB Type-C connector class is to provide > unified interface for the user space to get the status and > basic information about USB Type-C connectors on a system, > control over data role swapping, and when the port supports > USB Power Delivery, also control over power role swapping > and Alternate Modes. > > Signed-off-by: Heikki Krogerus > --- [ ... ] > + > +What: /sys/class/typec/-partner/supports_usb_power_delivery > +Date: June 2016 > +Contact: Heikki Krogerus > +Description: > + Shows if the partner supports USB Power Delivery. > + - 1 if USB Power Delivery is supported > + - 0 when it's not > + > + > +What: /sys/class/typec/-partner/id_header_vdo > +Date: June 2016 > +Contact: Heikki Krogerus > +Description: > + If the partner supports USB Power Deliver, shows the VDO > + returned from Discover Identity USB Power Delivery command. > + > + If the partner does not support USB Power Delivery, the > + attribute is hidden. > + On second thought, and after merging the code (and realizing that I don't get the raw data from the Type-C Port Manager), I am not sure if a raw attribute is that useful here. It also doesn't provide all information either. Would it make sense to split it into multiple decoded attributes ? - vendor-id [bit 0..15 of ID header VDO] - product-type (undefined, hub, peripheral, alternate mode adapter for ufp; passive/active for cable plugs) Might map into typec_partner_type, but I don't see a 1:1 match. [bit 27..29 of ID header VDO] - alternate-mode-supported [bit 26 of ID header VDO] - capabilities (ufp, dfp, drp, none (?)) [bit 30/31 of ID header VDO] - product-id [bit 16..31 of Product VDO] Does this make any sense ? Thanks, Guenter