On Fri, May 23, 2025 at 04:39:59PM +0200, Rafael J. Wysocki wrote: > On Thu, May 22, 2025 at 6:34 AM Armin Wolf <W_Armin@xxxxxx> 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@xxxxxx> 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@xxxxxxxxxxxx/ That unfortunately does not help with the hid-lenovo regression. Commit 84c9d2a968c8 ("HID: lenovo: Support for ThinkPad-X12-TAB-1/2 Kbd Fn keys") added a platform_profile_cycle() call and thus a dependency on platform_profile. hid-lenovo is used for USB and Bluetooth devices and not just for Lenovo laptop/tablet specific devices. Above patch just avoids the warning splat but still prevents loading hid-lenovo when ACPI is enabled in the kernel (like Distro kernels) on a non-ACPI system. This breaks devices like "Lenovo ThinkPad Compact Keyboard with TrackPoint" on such systems. I will send a patch to remove platform_profile_cycle() call as short term regression fix and tell the original author to to resubmit once the platform_profile dependency on non-ACPI systems is worked out. Janne
