mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Zhang Rui <rui.zhang@intel.com>
Cc: ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Gabriele Mazzotta <gabriele.mzt@gmail.com>,
	Dirk Griesbach <spamthis@freenet.de>,
	Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: [PATCH] ACPI / scan: Allow ACPI drivers to bind to PNP device objects
Date: Thu, 21 Aug 2014 18:36:26 +0200	[thread overview]
Message-ID: <2344364.bO1d4HtJcY@vostro.rjw.lan> (raw)
In-Reply-To: <1408622934.3315.8.camel@rzhang1-toshiba>

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@intel.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


  reply	other threads:[~2014-08-21 16:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-21  4:04 Rafael J. Wysocki
2014-08-21 12:08 ` Zhang Rui
2014-08-21 16:36   ` Rafael J. Wysocki [this message]
2014-08-21 17:10   ` Rafael J. Wysocki
2014-08-22  2:00     ` Zhang Rui
2014-08-22 17:53       ` Rafael J. Wysocki
2014-08-23 15:21         ` Zhang Rui
2014-09-08 22:14           ` Rafael J. Wysocki
2014-09-08 22:32             ` Darren Hart
2014-08-24  7:06 ` Zhang Rui
2014-08-25 22:25   ` 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=2344364.bO1d4HtJcY@vostro.rjw.lan \
    --to=rjw@rjwysocki.net \
    --cc=gabriele.mzt@gmail.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=rui.zhang@intel.com \
    --cc=spamthis@freenet.de \
    /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

all inboxes | Powered by JetHome®