linux-kernel - Re: [PATCH] ACPI / scan: Allow ACPI drivers to bind to PNP device objects

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Aug 2014 18:36:26 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Zhang Rui <rui.zhang@...el.com>
Cc:	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Gabriele Mazzotta <gabriele.mzt@...il.com>,
	Dirk Griesbach <spamthis@...enet.de>,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: [PATCH] ACPI / scan: Allow ACPI drivers to bind to PNP device objects

On Thursday, August 21, 2014 08:08:54 PM Zhang Rui wrote:
> Hi, Rafael,
> 
> On Thu, 2014-08-21 at 06:04 +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > 
> > We generally don't allow ACPI drivers to bind to ACPI device objects
> > that companion "physical" device objects are created for to avoid
> > situations in which two different drivers may attempt to handle one
> > device at the same time.
> 
> Yes, and I think we should not break this rule.

No, we broke the way the code worked previously.  We need to restore it first
and *then* try to fix it up, not the other way around.

> >   Recent ACPI device enumeration rework
> > extended that approach to ACPI PNP devices by starting to use a scan
> > handler for enumerating them.  However, we previously allowed ACPI
> > drivers to bind to ACPI device objects with existing PNP device
> > companions and changing that led to functional regressions on some
> > systems.
> > 
> Question: except the PNP0C01/PNP0C02 case, if we have an device have two
> ids that matches two different drivers, should we allow both drivers
> probe successfully?

No, we shouldn't, but in the cases in question we have only one driver (an
ACPI one).

> I think the answer is no.
> In the PNP0C01/PNP0C02 case, I think we can fix the issue by the
> following patch instead.

The right answer to me is to get rid of ACPI drviers entirely.

The thing below adds complexity to the resources management which I'm not
sure is necessary.

In any case, please let's do that on top of the $subject patch not
instead of it, because there are more cases we need to cover.  And we
need a fix for -stable.

Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/