From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755031AbcEWN1o (ORCPT ); Mon, 23 May 2016 09:27:44 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:51175 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755001AbcEWN1m (ORCPT ); Mon, 23 May 2016 09:27:42 -0400 Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class To: Oliver Neukum References: <1463661894-22820-1-git-send-email-heikki.krogerus@linux.intel.com> <1463669237.14323.8.camel@suse.com> <20160520112402.GC12663@kuha.fi.intel.com> <1463751447.14070.6.camel@suse.com> <573FF752.2080204@roeck-us.net> <1463813039.24976.9.camel@suse.com> <5741D63E.1050206@roeck-us.net> <1463981641.12181.5.camel@suse.com> Cc: Andy Shevchenko , Rajaram R , Felipe Balbi , Heikki Krogerus , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org From: Guenter Roeck Message-ID: <5743053D.5060307@roeck-us.net> Date: Mon, 23 May 2016 06:27:25 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1463981641.12181.5.camel@suse.com> Content-Type: text/plain; charset=utf-8; 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: X-Mailing-List: linux-kernel@vger.kernel.org On 05/22/2016 10:34 PM, Oliver Neukum wrote: > On Sun, 2016-05-22 at 08:54 -0700, Guenter Roeck wrote: >> Hi Oliver, >> >> On 05/20/2016 11:43 PM, Oliver Neukum wrote: >>> On Fri, 2016-05-20 at 22:51 -0700, Guenter Roeck wrote: >>>> On 05/20/2016 06:37 AM, Oliver Neukum wrote: >>>>> On Fri, 2016-05-20 at 14:24 +0300, Heikki Krogerus wrote: >>>>>> On Thu, May 19, 2016 at 04:47:17PM +0200, Oliver Neukum wrote: >>>>>>> >>>>>>> Please explain. How does that express DRP but prefered master? >>>>>> >>>>>> Sorry but I'm not sure what you mean here. If the port is capable of >>>>>> being used as dual role port (DRP in the supported_data_roles file), >>>>>> that is the only case where you can select the role with this file. So >>>>>> I would imagine that in your case you want to make the port act as >>>>>> DFP only, right? But if the port is capable of acting only as UFP, you >>>>>> are stuck with that role. >>>>> >>>>> How do I trigger that Try.SRC is to be used on a port? >>>>> >>>> >>>> This would be part of the USB PD protocol, ie probably outside the scope >>>> of the class code. In my implementation, I enable Try.SRC or Try.SNK based >>>> on the platform's preferred role. >>> >>> Hi, >>> >>> from a purely formal point of view that makes sense. >>> >>> >From a usability viewpoint I'd ideally want all controls >>> for role at one place. And possibly the controls for modes >>> at the same place. >>> >>> I think part of the problem here is that we lack a statement >>> of mission. What are these controls for? >>> Merely for controlling modes and providing information >>> about modes? And to use neutral terms only for the "master" >>> side or both sides? >>> >> >> Good question. I originally added a sysfs attribute 'preferred-mode' to >> my code, but then concluded that this is supposed to be provided >> by the platform and added it as platform data instead, with (currently) >> no means to report it to user space. > > Mode or role? I would say that the choice of alternate modes belongs to s/preferred mode/preferred role/g > user space. THere's no point in giving a preference to the kernel. > Role is different. Try.SRC is part of the standard (and Try.SNK has been > added). It needs to be in kernel space. > > Now, if you say that this API is for selecting modes only, then I say it > lacks support for cable resets and notifications thereof. Yes, that is a > PD feature, but that doesn't help us. It changes the mode. > >> Heikki's current code doesn't really match the semantics of a 'preferred' >> mode, at least not as I read it. In my understanding, 'preferred mode' >> means "this is a DRP port which prefers to be a source/sink". In Heikki's >> code, one can fix the mode to source or sink, but that doesn't support >> situations such as "this port prefers to be a source, but is currently >> a sink because the link partner happens to be a charger or refuses to act >> as sink for some other reason". > > Yes. That is why we need a mission statement. We may be talking > a rice cooker not preparing tea here. > >> Given that, my working assumption is that preferred mode handling is supposed >> to be outside the scope of the infrastructure. I am happy to be corrected, >> though. >> >> On a side note, are you working on a USB-PD implementation as well ? > > No, one of my task is to to make use of USB PD (and alternate modes) > in a distribution. > > Regards > Oliver > > >