From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753969AbcEWQwg (ORCPT ); Mon, 23 May 2016 12:52:36 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:46931 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751233AbcEWQwd (ORCPT ); Mon, 23 May 2016 12:52:33 -0400 Date: Mon, 23 May 2016 09:52:12 -0700 From: Guenter Roeck To: Oliver Neukum Cc: Andy Shevchenko , Rajaram R , Felipe Balbi , Heikki Krogerus , Mathias Nyman , Greg KH , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Subject: Re: [RFC PATCHv2] usb: USB Type-C Connector Class Message-ID: <20160523165212.GA5964@roeck-us.net> References: <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> <1464018904.12181.62.camel@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1464018904.12181.62.camel@suse.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Authenticated_sender: guenter@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: guenter@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: guenter@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 Mon, May 23, 2016 at 05:55:04PM +0200, Oliver Neukum wrote: > 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. > The question is not that much if it is policy (it is), but if the policy should be driven by the platform or by user space. I think there needs to be at least a default driven by the platform. As already mentioned, I am ok with a means to override this platform default from user space. But if user space doesn't say, there still needs to be a default. Thanks, Guenter > > 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 > >