Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753411AbdCBPcD (ORCPT <rfc822;w@1wt.eu>);
        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
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 2 Mar 2017 10:29:55 -0500
Subject: Re: [PATCH v17 2/3] usb: USB Type-C connector class
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>
References: <20170221142405.76299-1-heikki.krogerus@linux.intel.com>
 <20170221142405.76299-3-heikki.krogerus@linux.intel.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
        Guenter Roeck <linux@roeck-us.net>,
        Felipe Balbi <felipe.balbi@linux.intel.com>,
        Oliver Neukum <oneukum@suse.com>, linux-kernel@vger.kernel.org,
        linux-usb@vger.kernel.org
From: Mats Karrman <mats.dev.list@gmail.com>
Message-ID: <ae5d8f3a-859b-c3fa-1427-c25920a82abe@gmail.com>
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: <linux-kernel.vger.kernel.org>
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<index>", for example /sys/class/typec/port0/<alternate mode>/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