From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755431AbcEXLEw (ORCPT ); Tue, 24 May 2016 07:04:52 -0400 Received: from mga14.intel.com ([192.55.52.115]:10472 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754656AbcEXLEu (ORCPT ); Tue, 24 May 2016 07:04:50 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,359,1459839600"; d="scan'208";a="109474725" Date: Tue, 24 May 2016 14:04:31 +0300 From: Heikki Krogerus To: Oliver Neukum Cc: Guenter Roeck , Andy Shevchenko , Rajaram R , Felipe Balbi , 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: <20160524110431.GC26874@kuha.fi.intel.com> References: <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> <20160523165212.GA5964@roeck-us.net> <20160524100822.GB26874@kuha.fi.intel.com> <1464085118.11721.11.camel@suse.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1464085118.11721.11.camel@suse.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 24, 2016 at 12:18:38PM +0200, Oliver Neukum wrote: > On Tue, 2016-05-24 at 13:08 +0300, Heikki Krogerus wrote: > > Hi Guenter, > > > > On Mon, May 23, 2016 at 09:52:12AM -0700, Guenter Roeck wrote: > > > 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. > > > > I don't completely agree with that. The platform should not, and > > actually in most cases with ACPI AFAIK, will not provide any > > "preferences" to the OS about anything. The platform should only > > provide the OS the physical capabilities and nothing else. So if for > > example the platform is capable of acting as only source with a Type-C > > port, that is what it needs to tell to the OS so possibly the PHY can > > be programmed accordingly, etc. > > May I suggest that the point is moot as long as we agree that user space > needs to be able to set a policy? The OS cannot ignore the port before > user space tells it what to do. So a default will be needed. > > The OS must act conservatively, which means it cannot deactivate > hardware. So if a port can do DRP, that must be the default. So exactly my point. > I would go so far that I would suggest that we add a module parameter > for Try.SRC and Try.SNK to avoid trouble during boot. I would be fine with that, but apparently module parameters are so 90s :( > > So IMO, just like with any decision related to what the system will > > ultimately be used for, decision about the preferred role really > > belongs to the userspace. > > Yes, but ought the APIs for role, mode and PD be separate or not. > Sorry to sound like a broken record, but you need to provide some > higher level planning here. I was kinda hoping that we could formulate the plan together in this thread. Thanks, -- heikki