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]

Date:   Mon, 1 Mar 2021 18:14:37 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     Benjamin Tissoires <benjamin.tissoires@...hat.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, Mar 01, 2021 at 04:34:41PM +0100, Jiri Kosina wrote:
> On Mon, 1 Mar 2021, Benjamin Tissoires wrote:
> > 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.

For the record, I'm not in hurry with this, up to you how to proceed.
Thanks!

-- 
With Best Regards,
Andy Shevchenko