linux-kernel - Re: [PATCH v2 4/4] HID: i2c-hid: acpi: Drop redundant ACPI

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: <nycvar.YFH.7.76.2103011633490.12405@cbobk.fhfr.pm>
Date:   Mon, 1 Mar 2021 16:34:41 +0100 (CET)
From:   Jiri Kosina <jikos@...nel.org>
To:     Benjamin Tissoires <benjamin.tissoires@...hat.com>
cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Douglas Anderson <dianders@...omium.org>,
        "open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 4/4] HID: i2c-hid: acpi: Drop redundant ACPI_PTR()

On Mon, 1 Mar 2021, Benjamin Tissoires wrote:

> Hi,
> 
> On Fri, Feb 26, 2021 at 8:34 PM Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com> wrote:
> >
> > The driver depends on ACPI, ACPI_PTR() resolution is always the same.
> > Otherwise a compiler may produce a warning.
> >
> > That said, the rule of thumb either ugly ifdeffery with ACPI_PTR or
> > none should be used in a driver.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> 
> Thanks a lot for the series. This indeed cleans things up.

Indeed, thanks.

> For the series:
> Acked-by: Benjamin Tissoires <benjamin.tissoires@...hat.com>
> 
> Jiri, I wonder where we want to land this one. This is not strictly
> bug fixes, but we could definitively sneak this one in 5.12-rc1.
> Well, I should probably run the series on an acpi laptop here before
> merging, but I'd like to know if delaying to 5.13 is OK or if we need
> this in 5.12.

I'd like to do it the standard way and have it bake in for-next to see if 
it really doesn't break anything, so unless there are convicing arguments 
for 5.12-rcX, I'd rathre queue this for 5.13.

Thanks,

-- 
Jiri Kosina
SUSE Labs