Linux ACPI
 help / color / mirror / Atom feed
From: Dan Williams <dan.j.williams@intel.com>
To: Sudeep Holla <sudeep.holla@arm.com>, <linux-kernel@vger.kernel.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Borislav Petkov <bp@alien8.de>, <linux-acpi@vger.kernel.org>,
	<linux-cxl@vger.kernel.org>
Subject: Re: [PATCH 8/9] ACPI: APEI: EINJ: Transition to the faux device interface
Date: Thu, 5 Jun 2025 20:35:09 -0700	[thread overview]
Message-ID: <684261ed3c91c_2491100df@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20250317-plat2faux_dev-v1-8-5fe67c085ad5@arm.com>

[ add linux-cxl ]

Sudeep Holla wrote:
> The APEI error injection driver does not require the creation of a
> platform device. Originally, this approach was chosen for simplicity
> when the driver was first implemented.
> 
> With the introduction of the lightweight faux device interface, we now
> have a more appropriate alternative. Migrate the driver to utilize the
> faux bus, given that the platform device it previously created was not
> a real one anyway. This will simplify the code, reducing its footprint
> while maintaining functionality.
> 
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: linux-acpi@vger.kernel.org
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  drivers/acpi/apei/einj-core.c | 32 +++++++++++---------------------
>  1 file changed, 11 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c
> index 04731a5b01faaba534bad853d0acc4c8a873a53b..7ff334422899e757de918107202507dd171d61da 100644
> --- a/drivers/acpi/apei/einj-core.c
> +++ b/drivers/acpi/apei/einj-core.c
[..]
>  static int __init einj_init(void)
>  {
> -	struct platform_device_info einj_dev_info = {
> -		.name = "acpi-einj",
> -		.id = -1,
> -	};
> -	int rc;
> -
> -	einj_dev = platform_device_register_full(&einj_dev_info);
> -	if (IS_ERR(einj_dev))
> -		return PTR_ERR(einj_dev);
> +	einj_dev = faux_device_create("acpi-einj", NULL, &einj_device_ops);
> +	if (!einj_dev)
> +		return -ENODEV;
>  
> -	rc = platform_driver_probe(&einj_driver, einj_probe);
> -	einj_initialized = rc == 0;
> +	einj_initialized = true;

git bisect says this change breaks CXL subsystem initialization. This
patch seems to not understand the semantic guarantees of
platform_driver_probe().

CXL init now fails with:

    faux acpi-einj: probe did not succeed, tearing down the device

...which will fire on the majority of CXL systems because EINJ is optional.

However, failure to probe is not a module load condition failure because
the CXL subsystem still needs access to the symbols even on systems
where the EINJ facility is disabled. In other words CXL has a module
dependency on einj.ko, but all of its entry points into that module
first check einj_initialized. So part of the fix is:

diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c
index fea11a35eea3..9b041415a9d0 100644
--- a/drivers/acpi/apei/einj-core.c
+++ b/drivers/acpi/apei/einj-core.c
@@ -883,19 +883,16 @@ static int __init einj_init(void)
        }
 
        einj_dev = faux_device_create("acpi-einj", NULL, &einj_device_ops);
-       if (!einj_dev)
-               return -ENODEV;
 
-       einj_initialized = true;
+       if (einj_dev)
+               einj_initialized = true;
 
        return 0;
 }
 
 static void __exit einj_exit(void)
 {
-       if (einj_initialized)
-               faux_device_destroy(einj_dev);
-
+       faux_device_destroy(einj_dev);
 }
 
 module_init(einj_init);

However, that is not sufficient because faux_device_create() unlike
platform_driver_probe() does not suppress bind attributes which means
that einj_initialized result is not stable. I.e. somebody can unbind the
faux_driver from any faux_device at any time.

I think it is reasonable for faux_devices to only have one chance to
call ->probe() at create time:

diff --git a/drivers/base/faux.c b/drivers/base/faux.c
index 9054d346bd7f..934da77ca48b 100644
--- a/drivers/base/faux.c
+++ b/drivers/base/faux.c
@@ -86,6 +86,7 @@ static struct device_driver faux_driver = {
        .name           = "faux_driver",
        .bus            = &faux_bus_type,
        .probe_type     = PROBE_FORCE_SYNCHRONOUS,
+       .suppress_bind_attrs = true,
 };
 
 static void faux_device_release(struct device *dev)

Unless that global change is acceptable I do not think
faux_device_create() is a suitable replacement for
platform_driver_probe().

Lastly, for cases where probe failure are ok the dev_err() is too noisy,
so another change to make it behave like platform_driver_probe() would
be:

diff --git a/drivers/base/faux.c b/drivers/base/faux.c
index 9054d346bd7f..f5fbda0a9a44 100644
--- a/drivers/base/faux.c
+++ b/drivers/base/faux.c
@@ -169,7 +170,7 @@ struct faux_device *faux_device_create_with_groups(const char *name,
         * successful is almost impossible to determine by the caller.
         */
        if (!dev->driver) {
-               dev_err(dev, "probe did not succeed, tearing down the device\n");
+               dev_dbg(dev, "probe did not succeed, tearing down the device\n");
                faux_device_destroy(faux_dev);
                faux_dev = NULL;
        }

Greg, if you are ok with suppress_bind_attrs = true for faux devices I will
wrap the above into a 3 patch series to fix the regression.

  reply	other threads:[~2025-06-06  3:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-17 10:13 [PATCH 0/9] drivers: Transition to the faux device interface Sudeep Holla
2025-03-17 10:13 ` [PATCH 8/9] ACPI: APEI: EINJ: " Sudeep Holla
2025-06-06  3:35   ` Dan Williams [this message]
2025-03-17 13:01 ` [PATCH 0/9] drivers: " Greg Kroah-Hartman
2025-03-17 14:28   ` Sudeep Holla
2025-03-17 14:20 ` Mark Brown
2025-03-17 18:10 ` (subset) " Mark Brown

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=684261ed3c91c_2491100df@dwillia2-xfh.jf.intel.com.notmuch \
    --to=dan.j.williams@intel.com \
    --cc=bp@alien8.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=sudeep.holla@arm.com \
    /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