linux-kernel - Re: [PATCH 1/2] ACPI: platform_profile: Add support for non-ACPI platforms

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: <CAJZ5v0icRdTSToaKbdf=MdRin4NyB2MstUVaQo8VR6-n7DkVMQ@mail.gmail.com>
Date: Fri, 23 May 2025 16:39:59 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Armin Wolf <W_Armin@....de>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, lenb@...nel.org, j@...nau.net, 
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 1/2] ACPI: platform_profile: Add support for non-ACPI platforms

On Thu, May 22, 2025 at 6:34 AM Armin Wolf <W_Armin@....de> wrote:
>
> Am 21.05.25 um 22:17 schrieb Rafael J. Wysocki:
>
> > On Sun, May 18, 2025 at 8:51 PM Armin Wolf <W_Armin@....de> wrote:
> >> Currently the platform profile subsystem assumes that all supported
> >> (i.e. ACPI-capable) platforms always run with ACPI being enabled.
> >> However some ARM64 notebooks do not support ACPI and are instead
> >> using devicetree for booting.
> >>
> >> Do not register the legacy sysfs interface on such devices as it
> >> depends on the acpi_kobj (/sys/firmware/acpi/) being present. Users
> >> are encouraged to use the new platform-profile class interface
> >> instead.
> > So how does it work in this case?
> >
> The platform profile subsystem also exposes a more modern class-based sysfs interface,
> see Documentation/ABI/testing/sysfs-class-platform-profile for details.
>
> This interface does not depend on /sys/firmware/acpi being present, so userspace
> programs can still control the platform profiles using the class-based interface.
>
> This will become very important once we have platform profile drivers not depending on
> some sort of ACPI interface. I suspect that sooner or later some drivers for the embedded
> controllers on ARM64 notebooks (devicetree!) will register with the platform profile subsystem.
>
> Apart from that this allows input drivers using platform_profile_cycle() to work on non-ACPI
> platforms (like ARm64 devices using devicetree).

This driver though is located in drivers/acpi/ and depends on
CONFIG_ACPI.  Moreover, the platform profile provider drivers need to
select ACPI_PLATFORM_PROFILE so it gets built.  This means that there
are no non-ACPI platform profile providers currently in the tree.

While the observation that the code in the driver, other than the
legacy sysfs interface, doesn't really depend on ACPI is valid, if you
want it to be used on systems without ACPI, it needs to be properly
converted to a generic driver.

For now, it is better to simply make it fail to initialize without
ACPI, so I'm going to apply this patch:

https://patchwork.kernel.org/project/linux-acpi/patch/20250522141410.31315-1-alexghiti@rivosinc.com/

Thanks!