linux-kernel - Re: [PATCH] platform/x86: hp-wmi: Actually use mask parameter in hp_wmi_hw

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: <406921d4-0052-19f1-e949-c8026d9cc22d@daenzer.net>
Date:   Mon, 4 Dec 2017 09:31:20 +0100
From:   Michel Dänzer <michel@...nzer.net>
To:     Darren Hart <dvhart@...radead.org>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Andy Shevchenko <andy@...radead.org>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] platform/x86: hp-wmi: Actually use mask parameter in
 hp_wmi_hw_state

On 2017-12-01 08:39 PM, Darren Hart wrote:
> On Tue, Nov 28, 2017 at 08:41:47PM +0100, Michel Dänzer wrote:
>> On 2017-11-28 08:30 PM, Andy Shevchenko wrote:
>>> On Tue, Nov 28, 2017 at 8:06 PM, Michel Dänzer <michel@...nzer.net> wrote:
>>>> On 2017-11-28 05:57 PM, Darren Hart wrote:
>>>>> On Tue, Nov 28, 2017 at 04:17:58PM +0100, Michel Dänzer wrote:
>>>>>> We were always checking bit 0 (which represents the docked state)
>>>>>> regardless of the mask.
>>>>>>
>>>>>> Fixes the "tablet mode" state always being reported the same as the
>>>>>> docked state, which with current libinput can cause the built-in input
>>>>>> devices of laptops to be incorrectly disabled while docked.
>>>
>>>>> Merged in 4.15-rc1
>>>>
>>>> AFAIK commits without
>>>>
>>>>  Cc: stable@...r.kernel.org
>>>>
>>>> don't get automatically picked up for stable branches. Can you manually
>>>> nominate 9968e12 for stable?
>>>
>>> AFAIK Greg picks up patches based on Fixes tag as well.
>>> Feel free to ping us or just forward that one yourself if Greg will
>>> not pick up in reasonable (month?) time.
>>
>> Both 4.14.1 and 4.14.2 were released after Linus merged the fix, but
> 
> Based on Documentation/process/stable-kernel-rules.rst, this seems unlikely to
> happen automatically.

Right, because there's no Cc: stable@...r.kernel.org in the commit log,
that was my point above. :)


>> neither has it. Given that, and that a fair number of people seem to be
>> running into this, seems like a good idea to do it ASAP.
> 
> This is our responsibility to check if patches are candidates for stable, and
> the Fixes tag should be a trigger for us, the maintainers, to do that check.
> Sometimes we miss things, sometimes the dependencies are more than they are
> worth. In this case, we just missed it.
> 
> You can just send this in yourself using the original fix and following the
> process in stable-kernel-rules.rst.

I did, and Greg picked it up promptly. I forgot to Cc you guys on the
nomination e-mail, sorry about that.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer