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]
Message-ID: <2344364.bO1d4HtJcY@vostro.rjw.lan>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ