On Fri, May 23, 2025 at 6:29 PM Janne Grunau <j@xxxxxxxxxx> wrote: > > 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. And so on ACPI because platform_profile depends on it. > 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. Sure, thanks!
