On typical x86 laptops, PRP0001 devices are extremely rare. Disabling it changes nothing except perhaps for a niche embedded controller. The parameter primarily affects ARM64 servers and x86 IoT platforms (Bay Trail, Apollo Lake) where ACPI and DT drivers coexist.
The 0 is just the instance number.
If you had multiple devices using PRP0001, you'd see PRP0001:0, PRP0001:1, etc.
So acpi prp0001 0 means:
“ACPI device with HID
PRP0001and instance 0.” acpi prp0001 0
You might see acpi prp0001 0 on:
If you’re running a standard desktop PC (Dell XPS, Lenovo ThinkPad, custom AMD Ryzen), you likely will not see this message because the firmware uses well-known _HID values for all devices.
In ACPI, every device in the namespace (\_SB_, \_SB_.PCI0, etc.) has a Hardware ID (HID) – a string like PNP0C09 (embedded controller) or ACPI000C (PPTT table). The HID allows the OS to load the correct driver. On typical x86 laptops, PRP0001 devices are extremely rare
PRP0001 is a special, Microsoft-defined Compatible ID (CID). Its definition:
"Device is compatible with a Device Tree node having a given 'compatible' property."
When an ACPI device node includes:
Name (_HID, "PRP0001")
Name (_DSD, Package()
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package()
Package() "compatible", "my-vendor,my-device",
)
…the Linux kernel interprets this as: "Ignore the PRP0001 HID; instead, match this device against a Device Tree driver that expects my-vendor,my-device in its .compatible table."
acpi PRP0001:00: No compatible string found in _DSD
The ACPI node is missing the compatible property, so the kernel doesn't know which driver to load. The device is ignored.
cat /sys/bus/acpi/devices/PRP0001:00/path
cat /sys/bus/acpi/devices/PRP0001:00/status
You might see this in:
Device Tree overlay applied via ACPI: