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.
