Re: [PATCH 00/12] gpiolib: acpi: Refactor, harden, and modularize ACPI GPIO support

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Mon, May 18, 2026 at 09:53:45AM +0200, Marco Scardovi (scardracs) wrote:
> Good morning everyone,
> 
> This patch series took fairly a bit of time because, well,

It needs more work. Please, take your time to get familiar with the Linux
kernel process and patches requirements (read Submitting Patches and related
documentation).

> it ended up going a "bit"
> out of hand. It improves style, robustness, resource safety, and modularity
> of the ACPI GPIO subsystem. The massive gpiolib-acpi-core.c driver (previously
> well over 1400 lines) has been significantly refactored, reducing its footprint
> by separating concerns into distinct, dedicated modules for ACPI Operation Region
> handling and ACPI Event/Interrupt processing.

> Key changes and structure of the series:
> 1. Hardening & Correctness (Patches 1-4):
>    - Style adjustments to match Linux Kernel coding standard.
>    - Modernized parsing in quirks using standard sysfs/kstrto helpers.
>    - Added robust bounds checking for ACPI GPIO resource pin ranges.
>    - Fixed a critical memory resource leak in the OpRegion cleanup path.

Start from fixing critical issues first.

> 2. ACPI Operation Region Modularization (Patches 5-9):
>    - Declared shared data structures in the local header.
>    - Exposed private-to-core registration helpers by making them non-static.
>    - Extracted Operation Region handling logic to gpiolib-acpi-opregion.c.
>    - Diverted callback registration to the new OpRegion module.
>    - Removed the unused static emulation handlers from the core driver.
> 
> 3. ACPI Event & Interrupt Handling Modularization (Patches 10-12):
>    - Declared shared helper prototypes in the local header.
>    - Extracted Event/Interrupt logic to gpiolib-acpi-events.c.
>    - Fully decoupled static event handlers and event structures from the core.
> 
> Build correctness and functional behavior were validated on x86 virtual
> platforms using virtme-ng under KASAN and kmemleak with successful boot,
> execution, and zero resource leaks.

I didn't get the point of the whole series. It also gets +80 or so LoC.

-- 
With Best Regards,
Andy Shevchenko