From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757414AbcK2Ny5 (ORCPT ); Tue, 29 Nov 2016 08:54:57 -0500 Received: from mx2.suse.de ([195.135.220.15]:52948 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754976AbcK2Nyt (ORCPT ); Tue, 29 Nov 2016 08:54:49 -0500 Message-ID: <1480427326.22547.40.camel@suse.com> Subject: Re: [PATCHv12 2/3] usb: USB Type-C connector class From: Oliver Neukum To: Greg KH Cc: Heikki Krogerus , Badhri Jagan Sridharan , Guenter Roeck , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org Date: Tue, 29 Nov 2016 14:48:46 +0100 In-Reply-To: <20161129132049.GA1463@kroah.com> References: <20161122141147.21977-1-heikki.krogerus@linux.intel.com> <20161122141147.21977-3-heikki.krogerus@linux.intel.com> <20161124095755.GB17492@kuha.fi.intel.com> <1480328372.22547.8.camel@suse.com> <20161128142323.GA32668@kuha.fi.intel.com> <20161128201143.GB10709@roeck-us.net> <20161129125958.GC32668@kuha.fi.intel.com> <20161129132049.GA1463@kroah.com> 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 Tue, 2016-11-29 at 14:20 +0100, Greg KH wrote: > On Tue, Nov 29, 2016 at 02:59:58PM +0200, Heikki Krogerus wrote: > > Hi Guenter, > > > > On Mon, Nov 28, 2016 at 12:11:43PM -0800, Guenter Roeck wrote: > > > Personally I don't really care about a module parameter; as mentioned above, > > > I would expect the preference, if it needs to be selectable, to be configured > > > with devicetree or ACPI properties (or by a platform driver which sets a device > > > property). > > > > Unfortunately we can not assume the firmware to be always correct. > > Companies love to recycle the firmware. We are going to see products > > from a company X that should prefer source role, a desktop for > > example, but still give the OS a device property that says otherwise. > > The reason for that is most likely because the previous product from > > that company was some kind of mobile device. > > > > So IMHO we need some way for the OS to override this thing eventually. > > If not module parameters, then something else. The other option is > > board specific quirks, and I would really prefer to avoid those if we > > can. > > Whatever it is, it is NOT going to be a module parameter, sorry, that > ship has long sailed and will not be coming back. This isn't the 1990's > anymore... Do you have a sensible alternative that works at boot time? Regards Oliver