Re: [PATCH v1 1/1] i2c: acpi: Replace custom code with device_match_acpi_handle()

[Rafael J. Wysocki]

On Tue, Jun 24, 2025 at 9:38 AM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> 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.