From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933248AbcH2NFB (ORCPT <rfc822;w@1wt.eu>);
        Mon, 29 Aug 2016 09:05:01 -0400
Received: from bh-25.webhostbox.net ([208.91.199.152]:42105 "EHLO
        bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1757423AbcH2NE7 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 29 Aug 2016 09:04:59 -0400
Subject: Re: [PATCHv6 1/3] usb: USB Type-C connector class
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Vincent Palatin <vpalatin@chromium.org>
References: <1471867560-93494-1-git-send-email-heikki.krogerus@linux.intel.com>
 <1471867560-93494-2-git-send-email-heikki.krogerus@linux.intel.com>
 <CANVmJF=nMMVNSR7P3j7n-w3v_huQjX37LB43AfHiL8+R3g8KBQ@mail.gmail.com>
 <20160825115958.GE12117@kuha.fi.intel.com>
 <CANVmJFm9m0u3ACw9HeOKSxC5TbVJt+vyAGhiCk2JH87wrfyHrg@mail.gmail.com>
 <20160826140710.GG12117@kuha.fi.intel.com>
Cc: Greg KH <gregkh@linuxfoundation.org>, Oliver Neukum <oneukum@suse.com>,
        Felipe Balbi <felipe.balbi@linux.intel.com>,
        Bin Gao <bin.gao@linux.intel.com>, linux-kernel@vger.kernel.org,
        linux-usb@vger.kernel.org
From: Guenter Roeck <linux@roeck-us.net>
Message-ID: <5f073751-a725-09a2-79be-49709bcd2cf9@roeck-us.net>
Date: Mon, 29 Aug 2016 06:04:52 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160826140710.GG12117@kuha.fi.intel.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated_sender: linux@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: linux@roeck-us.net
X-Authenticated-Sender: bh-25.webhostbox.net: linux@roeck-us.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Heikki,

On 08/26/2016 07:07 AM, Heikki Krogerus wrote:
>
>>>>> +What:          /sys/class/typec/<port>-partner/type
>>>>> +Date:          June 2016
>>>>> +Contact:       Heikki Krogerus <heikki.krogerus@linux.intel.com>
>>>>> +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).
>

This is probably the most difficult attribute to support.

Many PD capable chargers support alternate modes (for firmware upgrades).
As I mentioned earlier, it is difficult to match reported Type-C partner
types (or really anything reported in the SVDM Identity command)
to the above types.

Does it really make sense to deviate that much from the Type-C specification ?
I can understand why you hesitate to use DFP / UFP, as those terms are
really hard to understand for the non-initiated. However, here it is really
difficult to even determine which value to set. The best I can come up with is

- Not PD capable. Report USB (obviously includes non-PD capable chargers)
- PD capable, supports alternate modes. Report as Alternate Mode (including
   PD chargers supporting alternate modes)
- PD capable, does not support alternate modes. Report as Accessory if
   connected as accessory, as charger if we the port is connected as sink,
   USB otherwise

Overall this is quite vague and, especially for chargers, most of the time
misses the point.

I would really prefer if we could stay closer to the specification in this
case, and not try to merge multiple orthogonal attributes into one.

Thanks,
Guenter