linux-kernel - Re: [PATCH v2] platform/x86: intel-hid: Add support for Device Specific Methods

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]

Date:   Sat, 7 Jul 2018 03:48:54 +0000
From:   <Mario.Limonciello@...l.com>
To:     <dvhart@...radead.org>, <andy.shevchenko@...il.com>
CC:     <srinivas.pandruvada@...ux.intel.com>, <alex.hung@...onical.com>,
        <andy@...radead.org>, <platform-driver-x86@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <rjw@...ysocki.net>
Subject: Re: [PATCH v2] platform/x86: intel-hid: Add support for Device
 Specific Methods

>I strongly advocate for vendors to have more control over their drivers,
>but this scenario really frustrates me. I don't think I can justify this
>to Linus as a fix. But before we just say "no" (because hey, I want
>these fixes available as early as possible too), let's ask Rafael if he
>has an opinion or if there is precedent for this in his experience with
>ACPI drivers in general:

Full disclosure - an updated FW has since been rolled out that reverted this
behavior back to previous FW behavior due to lack of Linux support for the
new _DSM.  There is desire to use the new interface (as it did fix actual
problems with the old one) so at some point it may return.  When that happens
it would be ideal that people who are (for example) running an LTS kernel
or distro kernel that tracks stable can pick it up too.