Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201111054356.793390-1-ben.widawsky@intel.com>
 <20201111054356.793390-2-ben.widawsky@intel.com> <CAJZ5v0i7fcoBe5o-J7q5fYW_1nUYJ-QdshWOBV5fFf85rD_sDA@mail.gmail.com>
 <CAPcyv4i6MCu6RmLCyE+K-j3bbtrYeA+hJXL4+Zy_Tfhmwv2ErA@mail.gmail.com>
In-Reply-To: <CAPcyv4i6MCu6RmLCyE+K-j3bbtrYeA+hJXL4+Zy_Tfhmwv2ErA@mail.gmail.com>
From:   "Rafael J. Wysocki" <rafael@kernel.org>
Date:   Wed, 18 Nov 2020 12:14:56 +0100
Message-ID: <CAJZ5v0j_ReK3AGDdw7fLvmw_7knECCg2U_huKgJzQeLCy8smug@mail.gmail.com>
Subject: Re: [RFC PATCH 1/9] cxl/acpi: Add an acpi_cxl module for the CXL interconnect
To:     Dan Williams <dan.j.williams@intel.com>
Cc:     "Rafael J. Wysocki" <rafael@kernel.org>,
        Ben Widawsky <ben.widawsky@intel.com>,
        linux-cxl@vger.kernel.org,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux PCI <linux-pci@vger.kernel.org>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        Ira Weiny <ira.weiny@intel.com>,
        Vishal Verma <vishal.l.verma@intel.com>,
        "Kelley, Sean V" <sean.v.kelley@intel.com>,
        Bjorn Helgaas <bhelgaas@google.com>,
        "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Nov 17, 2020 at 10:45 PM Dan Williams <dan.j.williams@intel.com> wrote:
>
> On Tue, Nov 17, 2020 at 6:33 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> [..]
> > > +static struct acpi_driver acpi_cxl_driver = {
> >
> > First of all, no new acpi_driver instances, pretty please!
> >
> > acpi_default_enumeration() should create a platform device with the
> > ACPI0017 ID for you.  Can't you provide a driver for this one?
> >
>
> Ah, yes, I recall we had this discussion around the time the ACPI0012
> NFIT driver was developed. IIRC the reason ACPI0012 remaining an
> acpi_driver was due to a need to handle ACPI notifications, is that
> the deciding factor?

Sort of.  In fact, a platform device driver can still handle ACPI
notifications just fine, it just needs to install a notify handler for
that.

The cases when an acpi_driver is really needed are basically when
creating the platform device during the enumeration is not desirable,
like in the PCI or PNP cases (because they both create device objects
of a different type to represent the "physical" device).

It doesn't look like it is really needed for ACPI0012, but since it is
there already, well ...

> ACPI0017 does not have any notifications so it seems like platform driver is the way to go.

Indeed.