All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Bugla" <uwe.bugla@gmx.de>
To: Shaohua Li <shaohua.li@intel.com>, castet.matthieu@free.fr
Cc: bjorn.helgaas@hp.com, linux-acpi@vger.kernel.org,
	len.brown@intel.com, akpm@osdl.org, ambx1@neo.rr.com
Subject: Re: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources
Date: Wed, 28 Jun 2006 10:57:44 +0200	[thread overview]
Message-ID: <20060628085744.74730@gmx.net> (raw)
In-Reply-To: <1151456568.21189.84.camel@sli10-desk.sh.intel.com>


-------- Original-Nachricht --------
Datum: Wed, 28 Jun 2006 09:02:48 +0800
Von: Shaohua Li <shaohua.li@intel.com>
An: castet.matthieu@free.fr
Betreff: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

> 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

I tested the patch without blacklisting the PNP resource at the same time under 2.6.17-rc6-mm*, and did not find any regression.
And I am sure there is a solution also for IA64 architectures without going  the blacklist path which sounds a bit strange after having done such a big effort of real good work.
Unfortunately I do not own an IA64 architecture, so I neither cannot test nor understand Shaohua´s criticism on that.
Under latest mm-patches (mm1, mm2, mm3 for official release of 2.6.17) it is at least impossible for me to give any positive feedback, as all three mm-versions are simply unusable. I will feature this in another mail to Andrew.

Cheers

Uwe

-- 


Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2006-06-28  8:57 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
2006-06-28  8:57           ` Uwe Bugla [this message]
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-07-03  8:19     ` Uwe Bugla

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=20060628085744.74730@gmx.net \
    --to=uwe.bugla@gmx.de \
    --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=shaohua.li@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.