public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: "Mario Limonciello (AMD)" <superm1@kernel.org>,
	Pratap Nirujogi <pnirujog@amd.com>
Cc: mario.limonciello@amd.com, W_Armin@gmx.de,
	rafael.j.wysocki@intel.com, linux-acpi@vger.kernel.org
Subject: Re: [PATCH] ACPI: video: Don't allow MFD devices to probe
Date: Fri, 06 Mar 2026 13:37:16 +0100	[thread overview]
Message-ID: <5975968.DvuYhMxLoT@rafael.j.wysocki> (raw)
In-Reply-To: <CAJZ5v0ihj+DARV3P52LMOn9U+bqwVW=2fQ_QtDsjeVZkR9hFmQ@mail.gmail.com>

On Friday, March 6, 2026 1:17:19 PM CET Rafael J. Wysocki wrote:
> On Fri, Mar 6, 2026 at 11:50 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Fri, Mar 6, 2026 at 3:51 AM Mario Limonciello (AMD)
> > <superm1@kernel.org> wrote:
> > >
> > > After ACPI video was converted into a platform device in
> > > commit 02c057ddefef5 ("ACPI: video: Convert the driver to a platform one")
> > > other devices that are MFD children of LNXVIDEO are being probed.
> > > This isn't intended.
> > >
> > > During probe detect MFD cells and reject them.
> > >
> > > Fixes: 02c057ddefef5 ("ACPI: video: Convert the driver to a platform one")
> > > Reported-by: Pratap Nirujogi <pnirujog@amd.com>
> > > Closes: https://lore.kernel.org/regressions/007e3390-6b2b-457e-83c7-c794c5952018@amd.com/
> >
> > The link is broken, so I can't see what is really happening, but my
> > guess is that MFD devices are created under the video bus device and
> > they get the same device ID (confusingly enough).
> >
> > > Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
> > > ---
> > >  drivers/acpi/acpi_video.c | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
> > > index 3fa28f1abca38..2cb526775ac47 100644
> > > --- a/drivers/acpi/acpi_video.c
> > > +++ b/drivers/acpi/acpi_video.c
> > > @@ -14,6 +14,7 @@
> > >  #include <linux/init.h>
> > >  #include <linux/types.h>
> > >  #include <linux/list.h>
> > > +#include <linux/mfd/core.h>
> > >  #include <linux/mutex.h>
> > >  #include <linux/input.h>
> > >  #include <linux/backlight.h>
> > > @@ -1988,6 +1989,9 @@ static int acpi_video_bus_probe(struct platform_device *pdev)
> > >         int error;
> > >         acpi_status status;
> > >
> > > +       if (mfd_get_cell(pdev))
> > > +               return -ENODEV;
> >
> > If the above is the case, I'd prefer this check
> >
> >         if (!device->pnp.type.backlight)
> >
> > which should also work, but is more general.
> 
> Well, this will not work if the ACPI companion is shared between
> multiple devices.
> 
> However, adding an MFD check here is a "works for me" change rather.
> 
> I think what needs to be done is to extend the duplication check (see
> my patch from yesterday at
> https://lore.kernel.org/linux-acpi/5663583.Sb9uPGUboI@rafael.j.wysocki/)
> to detect the cases when another platform device (not necessarily a
> child of the same parent) sharing the same ACPI companion is probed.

So, Pratap, can you please test the appended patch (untested so far)?

---
 drivers/acpi/acpi_video.c |   22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -1978,16 +1978,38 @@ static int acpi_video_bus_put_devices(st
 	return 0;
 }
 
+static bool acpi_video_bus_bound(struct acpi_device *adev)
+{
+	struct acpi_video_bus *video;
+
+	guard(mutex)(&video_list_lock);
+
+	list_for_each_entry(video, &video_bus_head, entry) {
+		if (video->device == adev)
+			return true;
+	}
+
+	return false;
+}
+
 static int instance;
 
 static int acpi_video_bus_probe(struct platform_device *pdev)
 {
 	struct acpi_device *device = ACPI_COMPANION(&pdev->dev);
+	static DEFINE_MUTEX(probe_lock);
 	struct acpi_video_bus *video;
 	bool auto_detect;
 	int error;
 	acpi_status status;
 
+	/* Probe one video bus device at a time in case there are duplicates. */
+	guard(mutex)(&probe_lock);
+
+	/* Bind only one platform device for the given ACPI companion. */
+	if (acpi_video_bus_bound(device))
+		return -EALREADY;
+
 	status = acpi_walk_namespace(ACPI_TYPE_DEVICE,
 				acpi_dev_parent(device)->handle, 1,
 				acpi_video_bus_match, NULL,





  reply	other threads:[~2026-03-06 12:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-06  2:51 [PATCH] ACPI: video: Don't allow MFD devices to probe Mario Limonciello (AMD)
2026-03-06  3:05 ` Nirujogi, Pratap
2026-03-06 10:50 ` Rafael J. Wysocki
2026-03-06 12:17   ` Rafael J. Wysocki
2026-03-06 12:37     ` Rafael J. Wysocki [this message]
2026-03-09  4:24       ` Nirujogi, Pratap
2026-03-06 12:42     ` Mario Limonciello
2026-03-06 12:46       ` Rafael J. Wysocki

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=5975968.DvuYhMxLoT@rafael.j.wysocki \
    --to=rafael@kernel.org \
    --cc=W_Armin@gmx.de \
    --cc=linux-acpi@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=pnirujog@amd.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=superm1@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