[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YxBOVH+irgYSbEIz@rric.localdomain>
Date: Thu, 1 Sep 2022 08:16:52 +0200
From: Robert Richter <rrichter@....com>
To: Jonathan Cameron <Jonathan.Cameron@...wei.com>
CC: Alison Schofield <alison.schofield@...el.com>,
Vishal Verma <vishal.l.verma@...el.com>,
Ira Weiny <ira.weiny@...el.com>,
Ben Widawsky <bwidawsk@...nel.org>,
Dan Williams <dan.j.williams@...el.com>,
<linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Len Brown <lenb@...nel.org>
Subject: Re: [PATCH 07/15] cxl/acpi: Check RCH's PCIe Host Bridge ACPI ID
On 31.08.22 11:20:28, Jonathan Cameron wrote:
> Robert Richter <rrichter@....com> wrote:
> > +static const struct acpi_device_id cxl_host_ids[] = {
> > + { "ACPI0016", 0 },
> > + { "PNP0A08", 0 },
> > + { },
>
> Trivial but no comma after a null terminator. Always good to make
> it harder for people to add things where they really shouldn't!
Can do this.
> pci_root.c avoids using an acpi_device_id table for similar matching.
> I think the point being to separate probe type use of this table
> from cases where we aren't using a normal device probe.
> So to remain consistent with that, I would just grab the hid
> and match it directly in this code.
Grabbing the hid only is actually a violation of the acpi spec as a
cid could be used interchangeable. It must also work then.
It is also not possible to use something like probe or a handler
matching the ids because the hosts must be enabled with the already
existing drivers and handlers. Suppose there are multiple handlers for
the same ids, the first handler wins and all other never get called.
To me it looks sane and simple to use acpi_match_device_ids() here.
-Robert
>
> I don't feel that strongly about this if the ACPI maintainers are
> fine with reusing this infrastructure as you have it here.
Powered by blists - more mailing lists