[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220901111403.00003bff@huawei.com>
Date: Thu, 1 Sep 2022 11:14:03 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Robert Richter <rrichter@....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 Thu, 1 Sep 2022 08:16:52 +0200
Robert Richter <rrichter@....com> wrote:
> 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.
Ok. One for the ACPI maintainers to comment on if they wish - I'm fine with this
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
>
> -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