From: Alexander Graf <graf@amazon.com>
To: <linux-acpi@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>, Len Brown <lenb@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"Jason A . Donenfeld" <Jason@zx2c4.com>,
"Greg KH" <gregkh@linuxfoundation.org>, <ardb@kernel.org>,
<dwmw@amazon.co.uk>
Subject: [PATCH] ACPI: bus: Match first 9 bytes of device IDs
Date: Fri, 25 Feb 2022 16:55:52 +0100 [thread overview]
Message-ID: <20220225155552.30636-1-graf@amazon.com> (raw)
We create a list of ACPI "PNP" IDs which contains _HID, _CID and CLS
entries of the respective devices. However, we squeeze them into
struct acpi_device_id which only has 9 bytes space to store the identifier
based on the ACPI spec:
"""
A _HID object evaluates to either a numeric 32-bit compressed EISA
type ID or a string. If a string, the format must be an alphanumeric
PNP or ACPI ID with no asterisk or other leading characters.
A valid PNP ID must be of the form "AAA####" where A is an uppercase
letter and # is a hex digit.
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.
"""
While most people adhere to the ACPI specs, Microsoft decided that its
VM Generation Counter device [1] should only be identifiable by _CID with
an value of "VM_Gen_Counter" - longer than 9 characters.
To still allow device drivers to match identifiers that exceed the 9 byte
limit, without wasting memory for the unlikely case that you have long
identifiers, let's match only the first 9 characters of the identifier.
This patch is a prerequisite to add support for VMGenID in Linux [2].
[1] https://download.microsoft.com/download/3/1/C/31CFC307-98CA-4CA5-914C-D9772691E214/VirtualMachineGenerationID.docx
[2] https://lore.kernel.org/lkml/20220225124848.909093-1-Jason@zx2c4.com/
Signed-off-by: Alexander Graf <graf@amazon.com>
---
Alternatives to the approach above would be:
1) Always set id[8] = '\0' in acpi_add_id()
2) Allocate the id in struct acpi_device_id dynamically
I'm happy to explore option 1 instead if people believe it's cleaner.
Option 2 on the other hand seems overkill for the issue at hand. We don't
have a lot of devices that exceed the 8 character threshold, so chance of
collision is quite small. On the other hand, the extra overhead of
maintaining the string allocation dynamically will quickly become a
headache.
---
drivers/acpi/bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 07f604832fd6..aba93171739f 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -829,7 +829,7 @@ static bool __acpi_match_device(struct acpi_device *device,
/* First, check the ACPI/PNP IDs provided by the caller. */
if (acpi_ids) {
for (id = acpi_ids; id->id[0] || id->cls; id++) {
- if (id->id[0] && !strcmp((char *)id->id, hwid->id))
+ if (id->id[0] && !strncmp((char *)id->id, hwid->id, ACPI_ID_LEN))
goto out_acpi_match;
if (id->cls && __acpi_match_device_cls(id, hwid))
goto out_acpi_match;
--
2.16.4
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
next reply other threads:[~2022-02-25 15:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 15:55 Alexander Graf [this message]
2022-02-25 16:57 ` [PATCH] ACPI: bus: Match first 9 bytes of device IDs Jason A. Donenfeld
2022-02-25 17:09 ` Alexander Graf
2022-02-25 17:16 ` Jason A. Donenfeld
2022-02-25 17:13 ` Ard Biesheuvel
2022-02-25 17:21 ` Jason A. Donenfeld
2022-02-25 17:30 ` Ard Biesheuvel
2022-02-25 17:33 ` Jason A. Donenfeld
2022-02-25 18:03 ` Jason A. Donenfeld
2022-02-25 18:39 ` Jason A. Donenfeld
2022-02-25 19:06 ` Alexander Graf
2022-02-25 21:03 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220225155552.30636-1-graf@amazon.com \
--to=graf@amazon.com \
--cc=Jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=dwmw@amazon.co.uk \
--cc=gregkh@linuxfoundation.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.