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] [day] [month] [year] [list]

Message-ID: <20161129140239.GA3605@kroah.com>
Date:   Tue, 29 Nov 2016 15:02:39 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Oliver Neukum <oneukum@...e.com>
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, Nov 29, 2016 at 02:48:46PM +0100, Oliver Neukum wrote:
> 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?

I'm for a device tree or acpi setting, as this really is a platform
thing, it is the only place that should "know" this type of problem, so
that is where it can be 'specified'.

Yes, firmware is "hard", but it gets really really tiring constantly
having to paper over firmware and hardware bugs in the kernel just
because we seem to be the ones that are willing to actually fix problems
that others cause.

thanks,

greg k-h