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: <aCWi-oUsCrbS0AiI@smile.fi.intel.com>
Date: Thu, 15 May 2025 11:16:58 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Mika Westerberg <mika.westerberg@...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 Thu, May 15, 2025 at 09:21:10AM +0200, Linus Walleij wrote:
> 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.

Yes, gpiolib-quirks.c would make sense for the shared code, but I don't
expect we will have any reasonable amount of those that are shared between
ACPI, DT, swnode cases.

But main problem here is the module parameters that are already exist,
there is no clean way in Linux kernel to provide an aliases table when
renaming files (AFAIK, otherwise tell me how to achieve that).

-- 
With Best Regards,
Andy Shevchenko