It's hard to get an ACPI ID
Historically and due to lack of knowledge about process the ACPI IDs for some devices are abusing the specification. As of today the v6.4 of it [1] says in the chapter 6.1.5 "_HID (Hardware ID)":
A valid ACPI ID must be of the form “NNNN####” where N is an uppercase letter or a digit (‘0’-‘9’) and # is a hex digit. This specification reserves the string “ACPI” for use only with devices defined herein. It further reserves all strings representing 4 HEX digits for exclusive use with PCI-assigned Vendor IDs.
Note that the first part of the ACPI ID is a Vendor ID which has to be in the official registry.
However, we have a lot of IDs, including some of them issued by Intel, that do not follow that.
Recently, while I cleaned up kernel from fake IDs [2] that hardware vendors never ever allocated for their devices (many of them simply don't care), it appears that Siemens on behalf of Seiko Epson was trying to establish yet another fake ID for their RTC discrete component in the Coreboot [3] and Linux kernel [4].
Luckily they have listened to me and actually followed the process, i.e. they have asked Seiko Epson to register themselves in ACPI registry [5], which happens couple of month ago under the 'SECC' vendor (while it’s even better, I dunno why they haven't simply reused their PNP Vendor ID which is in the registry for ages). And they have allocated the proper ID, SECC6110, for their RX6110SA component.
Now the patches for Coreboot (see [6]) and Linux kernel, as commit 8d69f62fddf6 ("rtc: rx6110: add ACPI bindings to I2C"), are accepted.
I really wish that all hardware vendors will follow this, including Intel (for the record, we improved a lot the ACPI ID allocation process and there shouldn’t be new cases).
Funny thing that newly introduced ID for Alibaba abusing the specification due to potential collisions with real PCI IDs ('BABA' can be represented as 0xbaba).
This entry was originally posted at https://andy-shev.dreamwidth.org/151340.html. Please comment there using OpenID.
A valid ACPI ID must be of the form “NNNN####” where N is an uppercase letter or a digit (‘0’-‘9’) and # is a hex digit. This specification reserves the string “ACPI” for use only with devices defined herein. It further reserves all strings representing 4 HEX digits for exclusive use with PCI-assigned Vendor IDs.
Note that the first part of the ACPI ID is a Vendor ID which has to be in the official registry.
However, we have a lot of IDs, including some of them issued by Intel, that do not follow that.
Recently, while I cleaned up kernel from fake IDs [2] that hardware vendors never ever allocated for their devices (many of them simply don't care), it appears that Siemens on behalf of Seiko Epson was trying to establish yet another fake ID for their RTC discrete component in the Coreboot [3] and Linux kernel [4].
Luckily they have listened to me and actually followed the process, i.e. they have asked Seiko Epson to register themselves in ACPI registry [5], which happens couple of month ago under the 'SECC' vendor (while it’s even better, I dunno why they haven't simply reused their PNP Vendor ID which is in the registry for ages). And they have allocated the proper ID, SECC6110, for their RX6110SA component.
Now the patches for Coreboot (see [6]) and Linux kernel, as commit 8d69f62fddf6 ("rtc: rx6110: add ACPI bindings to I2C"), are accepted.
I really wish that all hardware vendors will follow this, including Intel (for the record, we improved a lot the ACPI ID allocation process and there shouldn’t be new cases).
Funny thing that newly introduced ID for Alibaba abusing the specification due to potential collisions with real PCI IDs ('BABA' can be represented as 0xbaba).
This entry was originally posted at https://andy-shev.dreamwidth.org/151340.html. Please comment there using OpenID.