From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Alexander Graf <graf@amazon.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Len Brown <lenb@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Greg KH <gregkh@linuxfoundation.org>,
"Woodhouse, David" <dwmw@amazon.co.uk>
Subject: Re: [PATCH] ACPI: bus: Match first 9 bytes of device IDs
Date: Fri, 25 Feb 2022 18:33:42 +0100 [thread overview]
Message-ID: <CAHmME9oJpL_y4bDaLwrZZZ54p5_C0YF9=vW7Zz1iUhpBHx2TvA@mail.gmail.com> (raw)
In-Reply-To: <CAMj1kXEtUUod8Hp6VhS6k7iDKYkFj_t_J=qS2XF1p2X_SFdTvg@mail.gmail.com>
On Fri, Feb 25, 2022 at 6:30 PM Ard Biesheuvel <ardb@kernel.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
next prev parent reply other threads:[~2022-02-25 17:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 15:55 [PATCH] ACPI: bus: Match first 9 bytes of device IDs Alexander Graf
2022-02-25 16:57 ` 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 [this message]
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='CAHmME9oJpL_y4bDaLwrZZZ54p5_C0YF9=vW7Zz1iUhpBHx2TvA@mail.gmail.com' \
--to=jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=dwmw@amazon.co.uk \
--cc=graf@amazon.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).