linux-kernel - Re: [PATCH v2 1/3] thinkpad_acpi: Move tablet detection into separate function

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]

Message-ID: <20161105193022.GH100528@f23x64.localdomain>
Date:   Sat, 5 Nov 2016 12:30:22 -0700
From:   Darren Hart <dvhart@...radead.org>
To:     Lyude <lyude@...hat.com>
Cc:     ibm-acpi-devel@...ts.freedesktop.org,
        Daniel Martin <consume.noise@...il.com>,
        Henrique de Moraes Holschuh <ibm-acpi@....eng.br>,
        ibm-acpi-devel@...ts.sourceforge.net,
        platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/3] thinkpad_acpi: Move tablet detection into
 separate function

On Mon, Oct 31, 2016 at 07:56:40PM -0400, Lyude wrote:
> Suggested by Daniel Martin <consume.noise@...il.com>
> 
> Lenovo's having a bit of fun randomly changing what hotkey events and
> acpi handles they use for reporting tablet mode, so unfortunately this
> means we're definitely going to need to probe for multiple types of
> tablet mode support. Since the hotkey_init() is already a lot larger
> then it should be, let's split up this detection into it's own function
> to make things a little easier to read.
> 
> As well, since we're going to have multiple types of tablet modes, make
> hotkey_tablet into an enum so we can also use it to indicate the type of
> tablet mode reporting the machine supports.
> 
> Changes since v1:
> - Don't use bool for in_tablet_mode (fixes complaints from kbuild test
>   robot)
> 

This series doesn't apply cleanly now (simple fuzz).

Once we hear back from Henrique on his enum preference and thoughts on the
refactoring (which looks reasonable to me), please resubmit this series and
review Documentation/SubmittingPatches for the changelog (below ---) and please
be consistent in your placement of "v2" in the subject [PATCH vX N/M] prefix.

Most all of my feedback here is minor, but there were enough little things that
added up and I'd like to see this resubmitted as a series with those addressed
that applies cleanly - largely to make sure I haven't missed context and somehow
merged the wrong bits.

Thanks Lyude,

-- 
Darren Hart
Intel Open Source Technology Center