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@xxxxxxxxx> > > > > 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
