linux-kernel - Re: [PATCH v1 0/4] gpiolib: acpi: Split quirks to its own file

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: <CACRpkdbhnoffwtwVTMRaUAGVEpLfAESQNOb1PvYOer=V+og97Q@mail.gmail.com>
Date: Thu, 15 May 2025 09:21:10 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, linux-kernel@...r.kernel.org, 
	linux-gpio@...r.kernel.org, linux-acpi@...r.kernel.org, 
	Bartosz Golaszewski <brgl@...ev.pl>, Mika Westerberg <westeri@...nel.org>, Hans de Goede <hdegoede@...hat.com>
Subject: Re: [PATCH v1 0/4] gpiolib: acpi: Split quirks to its own file

On Wed, May 14, 2025 at 6:00 PM Mika Westerberg
<mika.westerberg@...ux.intel.com> wrote:

> >  drivers/gpio/Makefile                         |   1 +
> >  .../{gpiolib-acpi.c => gpiolib-acpi-core.c}   | 344 +----------------
> >  drivers/gpio/gpiolib-acpi-quirks.c            | 363 ++++++++++++++++++
> >  drivers/gpio/gpiolib-acpi.h                   |  15 +
>
> All this -foo-core things look redundant to me. Why not just split it out
> and call it gpiolib-quirks.c and put there all the quirks not just ACPI? I
> Don't think we want to have gpiolib-of-quirks.c and gpiolog-swnode-quirks.c
> and so on.

For OF/device tree the quirks are in gpiolib-of.c and we probably do
not want to put these into a shared file with ACPI (and swnode?)
quirks as systems with OF compile objects (Makefile entries)
and ACPI compile objects are not always included in the same build,
so having them per-hw-config-principle cuts down compiletime
overhead. Also it's pretty clear separation of concerns I think.

Yours,
Linus Walleij