From: Shaohua Li <shaohua.li@intel.com>
To: castet.matthieu@free.fr
Cc: Adam Belay <ambx1@neo.rr.com>, Andrew Morton <akpm@osdl.org>,
"Brown, Len" <len.brown@intel.com>,
linux-acpi@vger.kernel.org, bjorn.helgaas@hp.com,
uwe.bugla@gmx.de
Subject: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources
Date: Wed, 28 Jun 2006 09:02:48 +0800 [thread overview]
Message-ID: <1151456568.21189.84.camel@sli10-desk.sh.intel.com> (raw)
In-Reply-To: <1151409746.44a11e52e7002@imp8-g19.free.fr>
On Tue, 2006-06-27 at 14:02 +0200, castet.matthieu@free.fr wrote:
> Selon Shaohua Li <shaohua.li@intel.com>:
>
> >
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c4bb6f5ad968540d7f9619565bacd18d7419b85f
> > Thanks and sorry I didn't find the issue before. We'd better blacklist
> > root bridge. I saw at lest one BIOS (IA64 box) didn't assign correct
> > producer/consumer flag to root bridge resources. Blacklist it is much
> > safer.
>
> Is only PNP0A03 is producer type in __all__ ACPI possible devices ?
> If not we will have the same problem with others devices...
>
> I don't think blacklist is the solution : pnpacpi should be able to handle all
> ressources types : we should complete the implementation instead of blacklist
> devices our implementation doesn't support.
>
> If there are broken ACPI bios, there should be firmware update, a patched dsdt
> or a quirk, but no "quirk and no generic solution".
>From my understanding, if the device is really a PNP device its resource
should not be producer.
Or could we take this way, merge both patches (both patches are good to
me), which should be safer. Anyway, it doesn't make sense to export root
bridge to pnp layer to me.
Thanks,
Shaohua
next prev parent reply other threads:[~2006-06-28 1:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-27 6:30 [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources Brown, Len
2006-06-27 7:03 ` Andrew Morton
2006-06-27 7:37 ` Adam Belay
2006-06-27 7:29 ` Shaohua Li
2006-06-27 12:02 ` castet.matthieu
2006-06-27 14:19 ` Uwe Bugla
2006-06-27 16:03 ` Bjorn Helgaas
2006-06-28 1:02 ` Shaohua Li [this message]
2006-06-28 8:57 ` Uwe Bugla
2006-06-28 16:55 ` Bjorn Helgaas
2006-06-29 1:13 ` Shaohua Li
2006-06-29 12:24 ` Uwe Bugla
2006-06-29 18:38 ` Bjorn Helgaas
2006-06-30 1:30 ` Shaohua Li
-- strict thread matches above, loose matches on Subject: below --
2006-06-29 12:41 Li, Shaohua
2006-06-30 9:04 ` Uwe Bugla
2006-06-30 16:03 ` Bjorn Helgaas
2006-06-24 23:36 akpm
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=1151456568.21189.84.camel@sli10-desk.sh.intel.com \
--to=shaohua.li@intel.com \
--cc=akpm@osdl.org \
--cc=ambx1@neo.rr.com \
--cc=bjorn.helgaas@hp.com \
--cc=castet.matthieu@free.fr \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=uwe.bugla@gmx.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