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:   Sun, 8 Jul 2018 20:53:36 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Cc:     Mario Limonciello <Mario.Limonciello@...l.com>,
        Darren Hart <dvhart@...radead.org>,
        Alex Hung <alex.hung@...onical.com>,
        Andy Shevchenko <andy@...radead.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH v2] platform/x86: intel-hid: Add support for Device
 Specific Methods

On Sun, Jul 8, 2018 at 2:37 AM, Srinivas Pandruvada
<srinivas.pandruvada@...ux.intel.com> wrote:
> On Sat, 2018-07-07 at 19:24 +0300, Andy Shevchenko wrote:
>> On Sat, Jul 7, 2018 at 6:48 AM,  <Mario.Limonciello@...l.com> wrote:
>> > > 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.
>>
>> I am all for the better user experience and bugs especially in FW
>> should be fixed, but I think to support all kind of behaviour the new
>> FW release should always provide a knob by which we can check if some
>> feature is supported or not.
>>
>> Above sounds to me as mistake in design of the fix.
> The fix here takes care of all the combination. If the new _DSM is
> available, it checks what functionality the _DSM interface can provide
> (Fn 0). For those functionality it gets using _DSM matching new FW
> interface. If there is no _DSM or _DSM doesn't provide the
> functionality or _DSM provided method fails, it still revert to old FW
> interface style using standalone method. Eventually because of
> configurable 5-button array, all platforms will be using new FW
> interface with consideration of backward compatibility.

Srinivas, thanks for elaboration.

-- 
With Best Regards,
Andy Shevchenko