From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753106AbcEWP6l (ORCPT ); Mon, 23 May 2016 11:58:41 -0400 Received: from mx2.suse.de ([195.135.220.15]:50415 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751861AbcEWP6k (ORCPT ); Mon, 23 May 2016 11:58:40 -0400 Message-ID: <1464018904.12181.62.camel@suse.com> Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class From: Oliver Neukum To: Guenter Roeck Cc: Andy Shevchenko , Rajaram R , Felipe Balbi , Heikki Krogerus , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Date: Mon, 23 May 2016 17:55:04 +0200 In-Reply-To: <57431704.3030703@roeck-us.net> 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> <57431704.3030703@roeck-us.net> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2016-05-23 at 07:43 -0700, Guenter Roeck wrote: > On 05/23/2016 06:58 AM, Oliver Neukum wrote: > > 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 Why on earth? That is most clearly a policy decision. > 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. Well, if platform data has a default, I suppose we ought to use it. > 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 I would say that the ought to be a driver for type C which controls alternate modes and roles. Regards Oliver