linux-kernel - Re: [PATCHv12 2/3] usb: USB Type-C connector class

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1480427326.22547.40.camel@suse.com>
Date:   Tue, 29 Nov 2016 14:48:46 +0100
From:   Oliver Neukum <oneukum@...e.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Badhri Jagan Sridharan <badhri@...gle.com>,
        Guenter Roeck <linux@...ck-us.net>,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCHv12 2/3] usb: USB Type-C connector class

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