[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9oJpL_y4bDaLwrZZZ54p5_C0YF9=vW7Zz1iUhpBHx2TvA@mail.gmail.com>
Date: Fri, 25 Feb 2022 18:33:42 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Alexander Graf <graf@...zon.com>,
ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Len Brown <lenb@...nel.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Greg KH <gregkh@...uxfoundation.org>,
"Woodhouse, David" <dwmw@...zon.co.uk>
Subject: Re: [PATCH] ACPI: bus: Match first 9 bytes of device IDs
On Fri, Feb 25, 2022 at 6:30 PM Ard Biesheuvel <ardb@...nel.org> wrote:
> Yeah, good point. I think this is fine, although there are a few other
> uses of ACPI_ID_LEN in the tree. So perhaps this should be something
> like
>
> #define ACPI_ID_LEN 9
> #define ACPI_CID_LEN 16
>
> /* explanation goes here */
>
> struct acpi_device_id {
> __u8 id[ACPI_CID_LEN];
>
> instead? At a quick glance, none of those ACPI_ID_LEN users seem
> related to the CID or the match metadata.
Either way is fine by me. Looking at all the current users of
ACPI_ID_LEN, none of them really mind if it's >9. I can't see where
it'd change any behavior or performance or really anything at all,
anywhere. So I'm inclined to go with my original simpler solution. But
again, either way is fine.
Alex, do you want to pick one of these and submit a v2 based on it? Or
do you see a shortcoming in that approach?
Jason
Powered by blists - more mailing lists