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 S933480AbcH2NnK (ORCPT <rfc822;w@1wt.eu>);
        Mon, 29 Aug 2016 09:43:10 -0400
Received: from mga05.intel.com ([192.55.52.43]:16226 "EHLO mga05.intel.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932908AbcH2NnJ (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 29 Aug 2016 09:43:09 -0400
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.28,596,1464678000"; 
   d="scan'208";a="872188752"
Date: Mon, 29 Aug 2016 16:43:03 +0300
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Vincent Palatin <vpalatin@chromium.org>,
        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
Subject: Re: [PATCHv6 1/3] usb: USB Type-C connector class
Message-ID: <20160829134303.GB16924@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>
 <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>
 <5f073751-a725-09a2-79be-49709bcd2cf9@roeck-us.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5f073751-a725-09a2-79be-49709bcd2cf9@roeck-us.net>
User-Agent: Mutt/1.7.0 (2016-08-17)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, Aug 29, 2016 at 06:04:52AM -0700, Guenter Roeck wrote:
> 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.

OK. So what would you propose?


Thanks,

-- 
heikki