linux-kernel - Re: [PATCH v1 1/1] i2c: acpi: Replace custom code with device_match_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: <CAJZ5v0hB1dJ-wb1_Wn0yrf0JVfpqR9cZ7xBmjKM2kB1Q=FF=yQ@mail.gmail.com>
Date: Tue, 24 Jun 2025 12:18:22 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Mika Westerberg <mika.westerberg@...ux.intel.com>, Randolph Ha <rha051117@...il.com>, 
	linux-i2c@...r.kernel.org, linux-acpi@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Wolfram Sang <wsa+renesas@...g-engineering.com>, 
	Mika Westerberg <westeri@...nel.org>
Subject: Re: [PATCH v1 1/1] i2c: acpi: Replace custom code with device_match_acpi_handle()

On Tue, Jun 24, 2025 at 9:38 AM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Tue, Jun 24, 2025 at 10:25:59AM +0300, Mika Westerberg wrote:
> > On Tue, Jun 24, 2025 at 10:19:02AM +0300, Andy Shevchenko wrote:
> > > On Tue, Jun 24, 2025 at 08:45:08AM +0300, Mika Westerberg wrote:
> > > > On Mon, Jun 23, 2025 at 04:45:21PM +0300, Andy Shevchenko wrote:
> > > > > Since driver core provides a generic device_match_acpi_handle()
> > > > > we may replace the custom code with it.
> > > >
> > > > Well okay but now you replace a simple comparison with a function call. I'm
> > > > fine with the patch but I also don't think this is an improvement ;-)
> > >
> > > The improvement is in using standard API for such cases.
> >
> > Well ACPI_HANDLE() and comparing handles is also a "standard API".
>
> In some [rare] cases this might lead to removing acpi.h which is a monsteur
> that slows down a build and provokes developer to avoid IWYU principle from
> enforcement.
>
> > > You may argue on many things that may be open coded in
> > > the kernel while we have helpers (in some cases exported)
> > > functions that are one-liners or so. Note, the helper also
> > > performs an additional check and having an open coded copy
> > > may miss such a change. To me it's an improvement.
> >
> > Which is unnecessary check in this case.
>
> In this perhaps, but my point is that any of such amendments will be applied in
> one place for all, while open coding prevents this.
>
> > But like I said, no objections. I just don't think this improves anything.
>
> I think there is an improvement.

For example, this helps (I think) when someone uses something like LXR
to look for places where a device is matched against a given ACPI
handle, but only as long as device_match_acpi_handle() is used in all
of those places consistently.