diff mbox series

[v2,4/4] HID: i2c-hid: acpi: Drop redundant ACPI_PTR()

Message ID 20210226193225.47129-4-andriy.shevchenko@linux.intel.com (mailing list archive)
State New
Delegated to: Jiri Kosina
Headers show
Series [v2,1/4] HID: i2c-hid: acpi: Get ACPI companion only once and reuse it | expand

Commit Message

Andy Shevchenko Feb. 26, 2021, 7:32 p.m. UTC
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@linux.intel.com>
---
v2: no changes
 drivers/hid/i2c-hid/i2c-hid-acpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Benjamin Tissoires March 1, 2021, 2:38 p.m. UTC | #1
Hi,

On Fri, Feb 26, 2021 at 8:34 PM Andy Shevchenko
<andriy.shevchenko@linux.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@linux.intel.com>

Thanks a lot for the series. This indeed cleans things up.

For the series:
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.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.

Cheers,
Benjamin

> ---
> v2: no changes
>  drivers/hid/i2c-hid/i2c-hid-acpi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
> index a4810f199d59..a6f0257a26de 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
> @@ -126,7 +126,7 @@ static struct i2c_driver i2c_hid_acpi_driver = {
>                 .name   = "i2c_hid_acpi",
>                 .pm     = &i2c_hid_core_pm,
>                 .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> -               .acpi_match_table = ACPI_PTR(i2c_hid_acpi_match),
> +               .acpi_match_table = i2c_hid_acpi_match,
>         },
>
>         .probe_new      = i2c_hid_acpi_probe,
> --
> 2.30.0
>
Jiri Kosina March 1, 2021, 3:34 p.m. UTC | #2
On Mon, 1 Mar 2021, Benjamin Tissoires wrote:

> Hi,
> 
> On Fri, Feb 26, 2021 at 8:34 PM Andy Shevchenko
> <andriy.shevchenko@linux.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@linux.intel.com>
> 
> Thanks a lot for the series. This indeed cleans things up.

Indeed, thanks.

> For the series:
> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.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,
Andy Shevchenko March 1, 2021, 4:14 p.m. UTC | #3
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@linux.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@linux.intel.com>
> > 
> > Thanks a lot for the series. This indeed cleans things up.
> 
> Indeed, thanks.
> 
> > For the series:
> > Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.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!
Jiri Kosina March 8, 2021, 9:45 a.m. UTC | #4
On Mon, 1 Mar 2021, Andy Shevchenko 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@linux.intel.com>
> > > 
> > > Thanks a lot for the series. This indeed cleans things up.
> > 
> > Indeed, thanks.
> > 
> > > For the series:
> > > Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.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!

Queued in for-5.13/i2c-hid. Thanks,
diff mbox series

Patch

diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index a4810f199d59..a6f0257a26de 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -126,7 +126,7 @@  static struct i2c_driver i2c_hid_acpi_driver = {
 		.name	= "i2c_hid_acpi",
 		.pm	= &i2c_hid_core_pm,
 		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
-		.acpi_match_table = ACPI_PTR(i2c_hid_acpi_match),
+		.acpi_match_table = i2c_hid_acpi_match,
 	},
 
 	.probe_new	= i2c_hid_acpi_probe,