kernel/git/next/linux-next.git/drivers/acpi/acpi_pnp.c, branch master

ACPI: PNP: Drop CMOS RTC PNP device support

2026-02-26T17:48:07+00:00

A previous change updated is_cmos_rtc_device() to effectively never allow PNP devices to be created for the CMOS RTC on x86 with ACPI and the PNP bus type is only used on x86, so the CMOS RTC device IDs can be dropped from acpi_pnp_device_ids[] and is_cmos_rtc_device() can go away completely. Update the code accordingly. Signed-off-by: Rafael J. Wysocki Link: https://patch.msgid.link/3411834.aeNJFYEL58@rafael.j.wysocki

ACPI: x86/rtc-cmos: Use platform device for driver binding

2026-02-26T17:47:52+00:00

Modify the rtc-cmos driver to bind to a platform device on systems with ACPI via acpi_match_table and advertise the CMOST RTC ACPI device IDs for driver auto-loading. Note that adding the requisite device IDs to it and exposing them via MODULE_DEVICE_TABLE() is sufficient for this purpose. Since the ACPI device IDs in question are the same as for the CMOS RTC ACPI scan handler, put them into a common header file and use the definition from there in both places. Additionally, to prevent a PNP device from being created for the CMOS RTC if a platform one is present already, make is_cmos_rtc_device() check cmos_rtc_platform_device_present introduced previously. Signed-off-by: Rafael J. Wysocki Acked-by: Alexandre Belloni Link: https://patch.msgid.link/13969123.uLZWGnKmhe@rafael.j.wysocki

ACPI: PNP: Drop acpi_nonpnp_device_ids[]

2025-12-16T20:51:04+00:00

Now that "system" devices are represented as platform devices, they are not claimed by the PNP ACPI scan handler any more and platform devices can be created for ACPI device objects listing "system" device IDs as their compatible device IDs. Accordingly, it should not be necessary any more to add device IDs to acpi_nonpnp_device_ids[], so drop it. No intentional functional impact. Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello (AMD) Link: https://patch.msgid.link/3587570.QJadu78ljV@rafael.j.wysocki

ACPI: PNP: Drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[]

2025-12-16T20:50:30+00:00

There is a long-standing problem with ACPI device enumeration that if the given device has a compatible ID which is one of the generic system resource device IDs (PNP0C01 and PNP0C02), it will be claimed by the PNP scan handler and it will not be represented as a platform device, so it cannot be handled by a platform driver. Drivers have been working around this issue by "manually" creating platform devices that they can bind to (see the Intel HID driver for one example) or adding their device IDs to acpi_nonpnp_device_ids[]. None of the above is particularly clean though and the only reason why the PNP0C01 and PNP0C02 device IDs are present in acpi_pnp_device_ids[] is to allow the legacy PNP system driver to bind to those devices and reserve their resources so they are not used going forward. Obviously, to address this problem PNP0C01 and PNP0C02 need to be dropped from acpi_pnp_device_ids[], but doing so without making any other changes would be problematic because the ACPI core would then create platform devices for the generic system resource device objects and that would not work on all systems for two reasons. First, the PNP system driver explicitly avoids reserving I/O resources below the "standard PC hardware" boundary, 0x100, to avoid conflicts in that range (one possible case when this may happen is when the CMOS RTC driver is involved), but the platform device creation code does not do that. Second, there may be resource conflicts between the "system" devices and the other devices in the system, possibly including conflicts with PCI BARs. Registering the PNP system driver via fs_initcall() helps to manage those conflicts, even though it does not make them go away. Resource conflicts during the registration of "motherboard resources" that occur after PCI has claimed BARs are harmless as a rule and do not need to be addressed in any specific way. To overcome the issues mentioned above, use the observation that it is not actually necessary to create any device objects in addition to struct acpi_device ones in order to reserve the "system" device resources because that can be done directly in the ACPI device enumeration code. Namely, modify acpi_default_enumeration() to add the given ACPI device object to a special "system devices" list if its _HID is either PNP0C01 or PNP0C02 without creating a platform device for it. Next, add a new special acpi_scan_claim_resources() function that will be run via fs_initcall() and will walk that list and reserve resources for each device in it along the lines of what the PNP system driver does. Having made the above changes, drop PNP0C01 and PNP0C02 from acpi_pnp_device_ids[] which will allow platform devices to be created for ACPI device objects whose _CID lists contain PNP0C01 or PNP0C02, but the _HID is not in acpi_pnp_device_ids[]. Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello (AMD) [ rjw: Drop a leftover comment and add a new one elsewhere ] Link: https://patch.msgid.link/9550709.CDJkKcVGEf@rafael.j.wysocki Signed-off-by: Rafael J. Wysocki

Merge tag 'acpi-6.15-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

2025-04-02T22:16:30+00:00

Pull more ACPI updates from Rafael Wysocki: "These are fixes and cleanups on top of the previous ACPI material for 6.15-rc1 merged recently: - Extend the Lenovo Yoga Tab 3 ACPI quirk to skip GPIO event-handlers along with ACPI AC and battery which makes it work with Linux when started in the Windows mode (Hans de Goede) - Prevent the ACPI processor idle driver from being used on systems without _CST and with invalid C2/C3 in FADT in order to restore its previous (and expected) behavior that has been altered inadvertently by a recent code change (Giovanni Gherdovich) - Skip ACPI IRQ override on ASUS Vivobook 14 X1404VAP to make the internal keyboard work on it (Paul Menzel) - Make the ACPI backlight driver handle fetching EDID passed as ACPI_TYPE_PACKAGE which is not specification-compliant, but has been encountered in the field (Gergo Koteles) - Simplify the aggregation of choices in the ACPI platform-profile driver which has been unlocked by recent modifications of that driver (Kurt Borja) - Use str_enabled_disabled() instead of hardcoded strings in the ACPI code related to NUMA (Thorsten Blum) - Add Intel OC Watchdog device IDs to non-PNP device list to prevent PNP from claiming the devices that carry these IDs in which case non-PNP drivers cannot bind to them (Diogo Ivo)" * tag 'acpi-6.15-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: video: Handle fetching EDID as ACPI_TYPE_PACKAGE ACPI: processor: idle: Return an error if both P_LVL{2,3} idle states are invalid ACPI: platform_profile: Optimize _aggregate_choices() ACPI: x86: Extend Lenovo Yoga Tab 3 quirk with skip GPIO event-handlers ACPI: resource: Skip IRQ override on ASUS Vivobook 14 X1404VAP ACPI: PNP: Add Intel OC Watchdog IDs to non-PNP device list ACPI: NUMA: Use str_enabled_disabled() helper function

ACPI: PNP: Add Intel OC Watchdog IDs to non-PNP device list

2025-03-27T19:33:38+00:00

Intel Over-Clocking Watchdogs are described in ACPI tables by both the generic PNP0C02 _CID and their ACPI _HID. The presence of the _CID then causes the PNP scan handler to attach to the watchdog, preventing the actual watchdog driver from binding. Address this by adding the ACPI _HIDs to the list of non-PNP devices, so that the PNP scan handler is bypassed. Note that these watchdogs can be described by multiple _HIDs for what seems to be identical hardware. This commit is not a complete list of all the possible watchdog ACPI _HIDs. Signed-off-by: Diogo Ivo Link: https://patch.msgid.link/20250317-ivo-intel_oc_wdt-v3-2-32c396f4eefd@siemens.com Signed-off-by: Rafael J. Wysocki

net: remove sb1000 cable modem driver

2025-03-21T16:11:54+00:00

This one is hilariously outdated, it provided a faster downlink over TV cable for users of analog modems in the 1990s, through an ISA card. The web page for the userspace tools has been broken for 25 years, and the driver has only ever seen mechanical updates. Link: http://web.archive.org/web/20000611165545/http://home.adelphia.net:80/~siglercm/sb1000.html Signed-off-by: Arnd Bergmann Reviewed-by: Simon Horman Link: https://patch.msgid.link/20250312085236.2531870-1-arnd@kernel.org Signed-off-by: Paolo Abeni

ACPI: PNP: Introduce list of known non-PNP devices

2023-01-17T11:52:11+00:00

In some cases, PNP device IDs from acpi_pnp_device_ids[] are returned by _CID for devices for which matching platform drivers are present in the kernel and should be bound to them. However, the IDs coming from _CID cause the PNP scan handler to attach to those devices which prevents platform device objects from being created for them. Address this by introducing a list of known non-PNP device IDs into acpi_pnp.c such that if a device ID is there in that list, it cannot be attached to by the PNP scan handler and add the platform runtime update and telemetry device IDs to that list to start with. Reported-by: Chen Yu Signed-off-by: Rafael J. Wysocki Tested-by: Zhang Yang

ACPI: PNP: remove duplicated BRI0A49 and BDP3336 entries

2021-09-24T16:12:15+00:00

BRI0A49 and BDP3336 are already on the list. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Hans de Goede Signed-off-by: Rafael J. Wysocki

ACPI: PNP: compare the string length in the matching_id()

2020-12-15T18:30:49+00:00

Recently we met a touchscreen problem on some Thinkpad machines, the touchscreen driver (i2c-hid) is not loaded and the touchscreen can't work. An i2c ACPI device with the name WACF2200 is defined in the BIOS, with the current rule in matching_id(), this device will be regarded as a PNP device since there is WACFXXX in the acpi_pnp_device_ids[] and this PNP device is attached to the acpi device as the 1st physical_node, this will make the i2c bus match fail when i2c bus calls acpi_companion_match() to match the acpi_id_table in the i2c-hid driver. WACF2200 is an i2c device instead of a PNP device, after adding the string length comparing, the matching_id() will return false when matching WACF2200 and WACFXXX, and it is reasonable to compare the string length when matching two IDs. Suggested-by: Rafael J. Wysocki Signed-off-by: Hui Wang Cc: All applicable Signed-off-by: Rafael J. Wysocki