Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753411AbdCBPcD (ORCPT ); Thu, 2 Mar 2017 10:32:03 -0500 Received: from mail-lf0-f67.google.com ([209.85.215.67]:35696 "EHLO mail-lf0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753100AbdCBP3z (ORCPT ); Thu, 2 Mar 2017 10:29:55 -0500 Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class To: Heikki Krogerus References: <20170221142405.76299-1-heikki.krogerus@linux.intel.com> <20170221142405.76299-3-heikki.krogerus@linux.intel.com> Cc: Greg KH , Guenter Roeck , Felipe Balbi , Oliver Neukum , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org From: Mats Karrman Message-ID: Date: Thu, 2 Mar 2017 16:22:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <20170221142405.76299-3-heikki.krogerus@linux.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2136 Lines: 48 Hi Heikki, Good to see things are happening with Type-C! On 2017-02-21 15:24, Heikki Krogerus wrote: > ... > +When connected, the partner will be presented also as its own device under > +/sys/class/typec/. The parent of the partner device will always be the port it > +is attached to. The partner attached to port "port0" will be named > +"port0-partner". Full path to the device would be > +/sys/class/typec/port0/port0-partner/. A "/port0" too much? > + > +The cable and the two plugs on it may also be optionally presented as their own > +devices under /sys/class/typec/. The cable attached to the port "port0" port > +will be named port0-cable and the plug on the SOP Prime end (see USB Power > +Delivery Specification ch. 2.4) will be named "port0-plug0" and on the SOP > +Double Prime end "port0-plug1". The parent of a cable will always be the port, > +and the parent of the cable plugs will always be the cable. > + > +If the port, partner or cable plug support Alternate Modes, every supported > +Alternate Mode SVID will have their own device describing them. The Alternate > +Modes will not be attached to the typec class. The parent of an alternate mode > +will be the device that supports it, so for example an alternate mode of > +port0-partner will bees presented under /sys/class/typec/port0-partner/. Every bees? > +mode that is supported will have its own group under the Alternate Mode device > +named "mode", for example /sys/class/typec/port0//mode1/. > +The requests for entering/exiting a mode can be done with "active" attribute > +file in that group. > + > ... I'm hoping to find time to upgrade the kernel and try these patches in my system. Looking forward, one thing I have run into is how to connect the typec driver with a driver for an alternate mode. E.g. the DisplayPort Alternate Mode specification includes the HPD (hot plug) and HPD-INT (hot plug interrupt) signals as bits in the Attention message. These signals are needed by the DisplayPort driver to know when to start negotiation etc. Have you got any thoughts on how to standardize such interfaces? BR // Mats