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

Date:   Fri, 1 Dec 2017 11:39:29 -0800
From:   Darren Hart <dvhart@...radead.org>
To:     Michel Dänzer <michel@...nzer.net>
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 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.

> 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.

However, that means I need to pay closer attention when Greg's
auto-merge-bot-email lands in my Inbox asking if I object.

I'll send this one to stable myself, thanks for calling our attention to it.

-- 
Darren Hart
VMware Open Source Technology Center