From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932113AbcEWOnc (ORCPT ); Mon, 23 May 2016 10:43:32 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:51931 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754122AbcEWOn3 (ORCPT ); Mon, 23 May 2016 10:43:29 -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> <5743053D.5060307@roeck-us.net> <1464011884.12181.59.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: <57431704.3030703@roeck-us.net> Date: Mon, 23 May 2016 07:43:16 -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: <1464011884.12181.59.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/23/2016 06:58 AM, Oliver Neukum wrote: > On Mon, 2016-05-23 at 06:27 -0700, Guenter Roeck wrote: >>>> 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 > > Now I am confused. Are you saying that the choice of Alternate Mode does > not belong into user space? > No; sorry for the confusion. The above was meant to apply to my use of "preferred mode", not yours. I was trying to say that the choice of preferred roles (which determines if Try.SRC or Try.SNK is enabled) should belong primarily into the kernel, to be determined by the platform (presumably via ACPI, devicetree data, or platform data). If it should be possible to override it by user space is a different question. That might be useful, at least for testing. If so, does such an override belong into the class or into the PD driver ? Good question. I am fine either way. I don't really have a strong opinion about alternate mode selection. I would think that there should be a kernel (platform) default, possibly determined by the alternate mode itself, but I also think that it should be selectable by user space. Question is if that should be done through the alternate mode driver or through the class (example: alternate modes used for firmware upgrades and other device specific functionality). I don't really have an answer for that at this point. I'll probably have a better idea after I implemented the alternate mode driver for Google devices. Again, sorry for creating confusion between preferred role and preferred (alternate) mode selection. Thanks, Guenter