RE: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

RE: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Brown, Len]

NAK, per Shaohua's comments in the bug report. 

>-----Original Message-----
>From: akpm@osdl.org [mailto:akpm@osdl.org] 
>Sent: Saturday, June 24, 2006 7:37 PM
>To: Brown, Len
>Cc: linux-acpi@vger.kernel.org; akpm@osdl.org; 
>castet.matthieu@free.fr; ambx1@neo.rr.com; 
>bjorn.helgaas@hp.com; uwe.bugla@gmx.de
>Subject: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources
>
>
>From: matthieu castet <castet.matthieu@free.fr>
>
>A patch in -mm kernel correct the parsing of "address 
>resources" of pnpacpi. 
>Before we assumed it was memory only, but it could be also IO.
>
>But this change show an hidden bug : some resources could be 
>producer type
>that are not handled by pnp layer.  So we should ignore the producer
>resources.
>
>This patch fixes bug 6292 
>(http://bugzilla.kernel.org/show_bug.cgi?id=6292).
>Some devices like PNP0A03 have 0xd00-0xffff and 0x0-0xcf7 as 
>IO producer 
>resources.
>
>Before correcting "address resources" parsing, it was seen as 
>memory and was
>harmless, because nobody tried to reserve this memory range as 
>it should be
>IO.
>
>With the correction it become IO resources, and make failed 
>all others device
>that want to register IO in this range and use pnp layer (like 
>a ISA sound
>card).
>
>The solution is to ignore producer resources
>
>Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
>Signed-off-by: Uwe Bugla <uwe.bugla@gmx.de>
>Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
>Cc: Adam Belay <ambx1@neo.rr.com>
>Cc: "Brown, Len" <len.brown@intel.com>
>Signed-off-by: Andrew Morton <akpm@osdl.org>
>---
>
> drivers/pnp/pnpacpi/rsparser.c |    8 ++++++++
> 1 file changed, 8 insertions(+)
>
>diff -puN 
>drivers/pnp/pnpacpi/rsparser.c~pnpacpi-reject-acpi_producer-res
>ources drivers/pnp/pnpacpi/rsparser.c
>--- 
>a/drivers/pnp/pnpacpi/rsparser.c~pnpacpi-reject-acpi_producer-resources
>+++ a/drivers/pnp/pnpacpi/rsparser.c
>@@ -170,6 +170,9 @@ pnpacpi_parse_allocated_address_space(st
> 		return;
> 	}
> 
>+	if (p->producer_consumer == ACPI_PRODUCER)
>+		return;
>+
> 	if (p->resource_type == ACPI_MEMORY_RANGE)
> 		pnpacpi_parse_allocated_memresource(res_table,
> 				p->minimum, p->address_length);
>@@ -248,9 +251,14 @@ static acpi_status pnpacpi_allocated_res
> 		break;
> 
> 	case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
>+		if (res->data.ext_address64.producer_consumer 
>== ACPI_PRODUCER)
>+			return AE_OK;
> 		break;
> 
> 	case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
>+		if (res->data.extended_irq.producer_consumer == 
>ACPI_PRODUCER)
>+			return AE_OK;
>+
> 		for (i = 0; i < 
>res->data.extended_irq.interrupt_count; i++) {
> 			pnpacpi_parse_allocated_irqresource(res_table,
> 				res->data.extended_irq.interrupts[i],
>_
>

Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Andrew Morton]

On Tue, 27 Jun 2006 02:30:13 -0400
"Brown, Len" <len.brown@intel.com> wrote:

> NAK, per Shaohua's comments in the bug report. 
> 
> ...
>
> >
> >This patch fixes bug 6292 
> >(http://bugzilla.kernel.org/show_bug.cgi?id=6292).

Sigh.  Uwe is available to test patches, should any happen to get written.

Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Adam Belay]

On Tue, Jun 27, 2006 at 12:03:24AM -0700, Andrew Morton wrote:
> On Tue, 27 Jun 2006 02:30:13 -0400
> "Brown, Len" <len.brown@intel.com> wrote:
> 
> > NAK, per Shaohua's comments in the bug report. 
> > 
> > ...
> >
> > >
> > >This patch fixes bug 6292 
> > >(http://bugzilla.kernel.org/show_bug.cgi?id=6292).
> 
> Sigh.  Uwe is available to test patches, should any happen to get written.

I think we want something like this one...

http://bugzilla.kernel.org/attachment.cgi?id=7931&action=view

Regarding the bug report: Shaohua, if I understand correctly, we used to
blacklist PCI root buses in the old implementation but it was changed here:

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c4bb6f5ad968540d7f9619565bacd18d7419b85f

Thanks,
Adam

Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Shaohua Li]

On Tue, 2006-06-27 at 15:37 +0800, Adam Belay wrote:
> On Tue, Jun 27, 2006 at 12:03:24AM -0700, Andrew Morton wrote: 
> > On Tue, 27 Jun 2006 02:30:13 -0400 
> > "Brown, Len" <len.brown@intel.com> wrote: 
> >  
> > > NAK, per Shaohua's comments in the bug report.  
> > >  
> > > ... 
> > > 
> > > > 
> > > >This patch fixes bug 6292  
> > > >(http://bugzilla.kernel.org/show_bug.cgi?id=6292). 
> >  
> > Sigh.  Uwe is available to test patches, should any happen to get
> written.
> 
> I think we want something like this one...
> 
> http://bugzilla.kernel.org/attachment.cgi?id=7931&action=view
Exactly.

> Regarding the bug report: Shaohua, if I understand correctly, we used
> to 
> blacklist PCI root buses in the old implementation but it was changed
> here:
> 
> 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.

Thanks,
Shaohua

Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[castet.matthieu]

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".

To be honest I am bored about this acpi stuff : there are no reply when you ask
questions or propose things, it takes months to have a patch, there are lot's
of broken ACPI bios, ...

For example http://bugzilla.kernel.org/show_bug.cgi?id=3358 I submited 1,5 years
ago is still present in the kernel...


Matthieu CASTET

--------

"The fact that ACPI was designed by a group of monkeys high on LSD, and is some
of the worst designs in the industry obviously makes running it at _any_ point
pretty damn ugly. " (July 31, 2005) Linus Torvalds

Re: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Tue, 27 Jun 2006 14:02:26 +0200
Von: castet.matthieu@free.fr
An: Shaohua Li <shaohua.li@intel.com>
Betreff: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

> 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".
> 
> To be honest I am bored about this acpi stuff : there are no reply when
> you ask
> questions or propose things, it takes months to have a patch, there are
> lot's
> of broken ACPI bios, ...
> 
> For example http://bugzilla.kernel.org/show_bug.cgi?id=3358 I submited 1,5
> years
> ago is still present in the kernel...
> 
> 
> Matthieu CASTET
> 
> --------
> 
> "The fact that ACPI was designed by a group of monkeys high on LSD, and is
> some
> of the worst designs in the industry obviously makes running it at _any_
> point
> pretty damn ugly. " (July 31, 2005) Linus Torvalds

Salut Matthieu, hi everybody else wanting to listen,
A thousand Thanks for:
a. your excellent work in doing this patch. I did not test mm3 right now, but I swear I will do that as soosn as possible.
b. this very good citation from Linus hitting it to the point very exactly (Is the Microsoft team meant by those acid trip monkeys??? I simply do not know who the fuck invented this rubbish!).
"To be honest I am bored about this acpi stuff : there are no reply when
you ask questions or propose things, it takes months to have a patch, there are lot's of broken ACPI bios, ..."
But you do not mean me personally, do you? I spent couples of days on this sucking shit NOT to "fight down" anything or anybody (like Bjorn stated), but to help finding a solution in this very sucking issue.
As a cross-platform solution is appreciated I understand your exhaust and frustration very well. Blacklisting is NO good solution at all, is it?

Furthermore I really dislike those abbreviations like "NAK", "IMHO" etc.
And I´d like to repeat my proposal:
This stuff should NOT be in the mm-branch, but in a RC-candidate of the main vanilla: There would be much more traffic on this issue and a significant higher motivation for resolving that so that everyone is satisfied. But Andrew will never agree on this, will he ever?

Cheers everybody, just smile now

Uwe

-- 


"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
-
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

Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Bjorn Helgaas]

On Tuesday 27 June 2006 06:02, 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.

If there's a specific broken BIOS, I'd prefer a quirk-type
mechanism to work around it.

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

I agree.  I don't think blacklisting PNP0A03 is the correct solution.
Any ACPI device can have a producer resource.  The next time we
find a non-PNP0A03 bridge device with a producer resource, we'll
just trip over the same problem again.

Adam, Len, or Shaohua, can you explain the reason for preferring
a blacklist entry?

Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Shaohua Li]

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

Re: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Uwe Bugla]

-------- 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

Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Bjorn Helgaas]

On Tuesday 27 June 2006 19:02, Shaohua Li wrote:
> On Tue, 2006-06-27 at 14:02 +0200, castet.matthieu@free.fr wrote:
> > 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.

I know PNP as currently implemented doesn't support resource producers.
But I don't think of that as a restriction of PNP itself.  I think of
it as an area where a new back end (PNPACPI) added functionality, and
PNP should be enhanced to comprehend it.

I think the current scheme where some devices are claimed using
PNPACPI and pnp_register_driver(), and others are claimed using
acpi_bus_register_driver() directly, is confusing at best.

I'd rather have ALL devices handled by PNPACPI, and either extend
the PNP infrastructure to comprehend the new functionality of ACPI
(e.g., new resource types like PCI bus numbers, ACPI events), or
maybe just provide a "to_acpi_dev()" that takes a PNP device and
returns the corresponding ACPI device.

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

One reason I don't like the blacklist is because it just papers over
the problem without leaving a clue about how to really solve it.
For example, if PNP is enhanced later to comprehend resource producers,
we won't know to go back and remove things from the blacklist.

Bjorn

Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Shaohua Li]

On Wed, 2006-06-28 at 10:55 -0600, Bjorn Helgaas wrote:
> On Tuesday 27 June 2006 19:02, Shaohua Li wrote:
> > On Tue, 2006-06-27 at 14:02 +0200, castet.matthieu@free.fr wrote:
> > > 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.
> 
> I know PNP as currently implemented doesn't support resource producers.
> But I don't think of that as a restriction of PNP itself.  I think of
> it as an area where a new back end (PNPACPI) added functionality, and
> PNP should be enhanced to comprehend it.
Ok, it's fine ACPI PNP handles resource producers.

> I think the current scheme where some devices are claimed using
> PNPACPI and pnp_register_driver(), and others are claimed using
> acpi_bus_register_driver() directly, is confusing at best.
> 
> I'd rather have ALL devices handled by PNPACPI, and either extend
> the PNP infrastructure to comprehend the new functionality of ACPI
> (e.g., new resource types like PCI bus numbers, ACPI events), or
> maybe just provide a "to_acpi_dev()" that takes a PNP device and
> returns the corresponding ACPI device.
That's a big deal. We had a lot of discussions about this like
introducing ACPI bus, but frankly there isn't a solid direction which
bus ACPI devices should belong to.

> > 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.
> 
> One reason I don't like the blacklist is because it just papers over
> the problem without leaving a clue about how to really solve it.
> For example, if PNP is enhanced later to comprehend resource producers,
> we won't know to go back and remove things from the blacklist.
So lets have a note there. It (no blacklist) is meaningful to have all
ACPI devices handled by PNP layer, but currently not. We don't expect a
PNP driver for root bridge. And we will take risk of buggy BIOS.

Thanks,
Shaohua

Re: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Thu, 29 Jun 2006 09:13:36 +0800
Von: Shaohua Li <shaohua.li@intel.com>
An: Bjorn Helgaas <bjorn.helgaas@hp.com>
Betreff: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

> On Wed, 2006-06-28 at 10:55 -0600, Bjorn Helgaas wrote:
> > On Tuesday 27 June 2006 19:02, Shaohua Li wrote:
> > > On Tue, 2006-06-27 at 14:02 +0200, castet.matthieu@free.fr wrote:
> > > > 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.
> > 
> > I know PNP as currently implemented doesn't support resource producers.
> > But I don't think of that as a restriction of PNP itself.  I think of
> > it as an area where a new back end (PNPACPI) added functionality, and
> > PNP should be enhanced to comprehend it.
> Ok, it's fine ACPI PNP handles resource producers.
> 
> > I think the current scheme where some devices are claimed using
> > PNPACPI and pnp_register_driver(), and others are claimed using
> > acpi_bus_register_driver() directly, is confusing at best.
> > 
> > I'd rather have ALL devices handled by PNPACPI, and either extend
> > the PNP infrastructure to comprehend the new functionality of ACPI
> > (e.g., new resource types like PCI bus numbers, ACPI events), or
> > maybe just provide a "to_acpi_dev()" that takes a PNP device and
> > returns the corresponding ACPI device.
Hi Shaohua,
> That's a big deal. We had a lot of discussions about this like
> introducing ACPI bus, but frankly there isn't a solid direction which
> bus ACPI devices should belong to.
Where is the deeper sense of this discussion as long as the AS-IS-STATE conforms to a multiplicity of busses like ISA, PCI, AGP, please?
And why please didn´t you mix yourself in at an earlier point of time?
And why don´t you offer more profound material and information on the conflicts you saw on your IA64 architecture?
I simply have big problems understanding the attitude behind your behaviour.
> 
> > > 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.
> > 
> > One reason I don't like the blacklist is because it just papers over
> > the problem without leaving a clue about how to really solve it.
> > For example, if PNP is enhanced later to comprehend resource producers,
> > we won't know to go back and remove things from the blacklist.
> So lets have a note there. It (no blacklist) is meaningful to have all
> ACPI devices handled by PNP layer, but currently not.
In how far "currently not", please? At what point of time will this make sense according to your opinion?
> We don't expect a PNP driver for root bridge.
> And we will take risk of buggy BIOS.
What please has a buggy BIOS to do with a more cryptic or more sophisticated ACPI PNP concept?
> 
> Thanks,
> Shaohua
> 
Regards
Uwe


-- 


"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
-
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

Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Bjorn Helgaas]

On Wednesday 28 June 2006 19:13, Shaohua Li wrote:
> On Wed, 2006-06-28 at 10:55 -0600, Bjorn Helgaas wrote:
> > On Tuesday 27 June 2006 19:02, Shaohua Li wrote:
> > > 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.
> > 
> > One reason I don't like the blacklist is because it just papers over
> > the problem without leaving a clue about how to really solve it.
> > For example, if PNP is enhanced later to comprehend resource producers,
> > we won't know to go back and remove things from the blacklist.
> So lets have a note there. It (no blacklist) is meaningful to have all
> ACPI devices handled by PNP layer, but currently not. We don't expect a
> PNP driver for root bridge. And we will take risk of buggy BIOS.

Assuming we apply the first patch, a blacklist entry is neither
necessary (because the PNPACPI producer check covers it) nor
sufficient (because non-PNP0A03 devices may also have producer
resources).

It's true that blacklisting PNP0A03 will prevent problems if a BIOS
has buggy _CRS data for such a device.  But it will also hide Linux
problems like the one I fixed here:
    http://marc.theaimsgroup.com/?l=linux-acpi&m=113890268621542&w=2

So I think we should not blacklist PNP0A03 until we discover a specific
problem that requires that.

Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Shaohua Li]

On Thu, 2006-06-29 at 12:38 -0600, Bjorn Helgaas wrote:
> On Wednesday 28 June 2006 19:13, Shaohua Li wrote:
> > On Wed, 2006-06-28 at 10:55 -0600, Bjorn Helgaas wrote:
> > > On Tuesday 27 June 2006 19:02, Shaohua Li wrote:
> > > > 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.
> > > 
> > > One reason I don't like the blacklist is because it just papers over
> > > the problem without leaving a clue about how to really solve it.
> > > For example, if PNP is enhanced later to comprehend resource producers,
> > > we won't know to go back and remove things from the blacklist.
> > So lets have a note there. It (no blacklist) is meaningful to have all
> > ACPI devices handled by PNP layer, but currently not. We don't expect a
> > PNP driver for root bridge. And we will take risk of buggy BIOS.
> 
> Assuming we apply the first patch, a blacklist entry is neither
> necessary (because the PNPACPI producer check covers it) nor
> sufficient (because non-PNP0A03 devices may also have producer
> resources).
> 
> It's true that blacklisting PNP0A03 will prevent problems if a BIOS
> has buggy _CRS data for such a device.  But it will also hide Linux
> problems like the one I fixed here:
>     http://marc.theaimsgroup.com/?l=linux-acpi&m=113890268621542&w=2
> 
> So I think we should not blacklist PNP0A03 until we discover a specific
> problem that requires that.
Looks you just want it to find bug :). If you insist, I'm fine with your
proposal.

Thanks,
SHaohua

RE: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Li, Shaohua]

>-----Original Message-----
>From: Uwe Bugla [mailto:uwe.bugla@gmx.de]
>Sent: Thursday, June 29, 2006 8:24 PM
>To: Li, Shaohua; bjorn.helgaas@hp.com
>Cc: linux-acpi@vger.kernel.org; Brown, Len; akpm@osdl.org; ambx1@neo.rr.com;
>castet.matthieu@free.fr
>Subject: Re: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources
>
>
>-------- Original-Nachricht --------
>Datum: Thu, 29 Jun 2006 09:13:36 +0800
>Von: Shaohua Li <shaohua.li@intel.com>
>An: Bjorn Helgaas <bjorn.helgaas@hp.com>
>Betreff: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources
>
>> On Wed, 2006-06-28 at 10:55 -0600, Bjorn Helgaas wrote:
>> > On Tuesday 27 June 2006 19:02, Shaohua Li wrote:
>> > > On Tue, 2006-06-27 at 14:02 +0200, castet.matthieu@free.fr wrote:
>> > > > 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.
>> >
>> > I know PNP as currently implemented doesn't support resource producers.
>> > But I don't think of that as a restriction of PNP itself.  I think of
>> > it as an area where a new back end (PNPACPI) added functionality, and
>> > PNP should be enhanced to comprehend it.
>> Ok, it's fine ACPI PNP handles resource producers.
>>
>> > I think the current scheme where some devices are claimed using
>> > PNPACPI and pnp_register_driver(), and others are claimed using
>> > acpi_bus_register_driver() directly, is confusing at best.
>> >
>> > I'd rather have ALL devices handled by PNPACPI, and either extend
>> > the PNP infrastructure to comprehend the new functionality of ACPI
>> > (e.g., new resource types like PCI bus numbers, ACPI events), or
>> > maybe just provide a "to_acpi_dev()" that takes a PNP device and
>> > returns the corresponding ACPI device.
>Hi Shaohua,
>> That's a big deal. We had a lot of discussions about this like
>> introducing ACPI bus, but frankly there isn't a solid direction which
>> bus ACPI devices should belong to.
>Where is the deeper sense of this discussion as long as the AS-IS-STATE
>conforms to a multiplicity of busses like ISA, PCI, AGP, please?
>And why please didn´t you mix yourself in at an earlier point of time?
>And why don´t you offer more profound material and information on the
>conflicts you saw on your IA64 architecture?
I just took one ia64 box I ever saw as an example, but it's not unique to ia64 I think.

>I simply have big problems understanding the attitude behind your behaviour.
Me too :)

>> > > 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.
>> >
>> > One reason I don't like the blacklist is because it just papers over
>> > the problem without leaving a clue about how to really solve it.
>> > For example, if PNP is enhanced later to comprehend resource producers,
>> > we won't know to go back and remove things from the blacklist.
>> So lets have a note there. It (no blacklist) is meaningful to have all
>> ACPI devices handled by PNP layer, but currently not.
>In how far "currently not", please? At what point of time will this make
>sense according to your opinion?
>> We don't expect a PNP driver for root bridge.
>> And we will take risk of buggy BIOS.
>What please has a buggy BIOS to do with a more cryptic or more
>sophisticated ACPI PNP concept?
I want to emphasize I have no objection to merge the producer patch now but still think root bridge should be black list.

Thanks,
Shaohua
-
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

Re: RE: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Uwe Bugla]

-------- Original-Nachricht --------
Datum: Thu, 29 Jun 2006 20:41:07 +0800
Von: "Li, Shaohua" <shaohua.li@intel.com>
An: Uwe Bugla <uwe.bugla@gmx.de>, bjorn.helgaas@hp.com
Betreff: RE: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

> 
> 
> >-----Original Message-----
> >From: Uwe Bugla [mailto:uwe.bugla@gmx.de]
> >Sent: Thursday, June 29, 2006 8:24 PM
> >To: Li, Shaohua; bjorn.helgaas@hp.com
> >Cc: linux-acpi@vger.kernel.org; Brown, Len; akpm@osdl.org;
> ambx1@neo.rr.com;
> >castet.matthieu@free.fr
> >Subject: Re: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources
> >
> >
> >-------- Original-Nachricht --------
> >Datum: Thu, 29 Jun 2006 09:13:36 +0800
> >Von: Shaohua Li <shaohua.li@intel.com>
> >An: Bjorn Helgaas <bjorn.helgaas@hp.com>
> >Betreff: Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources
> >
> >> On Wed, 2006-06-28 at 10:55 -0600, Bjorn Helgaas wrote:
> >> > On Tuesday 27 June 2006 19:02, Shaohua Li wrote:
> >> > > On Tue, 2006-06-27 at 14:02 +0200, castet.matthieu@free.fr wrote:
> >> > > > 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.
> >> >
> >> > I know PNP as currently implemented doesn't support resource
> producers.
> >> > But I don't think of that as a restriction of PNP itself.  I think of
> >> > it as an area where a new back end (PNPACPI) added functionality, and
> >> > PNP should be enhanced to comprehend it.
> >> Ok, it's fine ACPI PNP handles resource producers.
> >>
> >> > I think the current scheme where some devices are claimed using
> >> > PNPACPI and pnp_register_driver(), and others are claimed using
> >> > acpi_bus_register_driver() directly, is confusing at best.
> >> >
> >> > I'd rather have ALL devices handled by PNPACPI, and either extend
> >> > the PNP infrastructure to comprehend the new functionality of ACPI
> >> > (e.g., new resource types like PCI bus numbers, ACPI events), or
> >> > maybe just provide a "to_acpi_dev()" that takes a PNP device and
> >> > returns the corresponding ACPI device.
> >Hi Shaohua,
> >> That's a big deal. We had a lot of discussions about this like
> >> introducing ACPI bus, but frankly there isn't a solid direction which
> >> bus ACPI devices should belong to.
> >Where is the deeper sense of this discussion as long as the AS-IS-STATE
> >conforms to a multiplicity of busses like ISA, PCI, AGP, please?
> >And why please didn´t you mix yourself in at an earlier point of time?
> >And why don´t you offer more profound material and information on the
> >conflicts you saw on your IA64 architecture?
> I just took one ia64 box I ever saw as an example, but it's not unique to
> ia64 I think.
> 
> >I simply have big problems understanding the attitude behind your
> behaviour.
> Me too :)
> 
> >> > > 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.
> >> >
> >> > One reason I don't like the blacklist is because it just papers over
> >> > the problem without leaving a clue about how to really solve it.
> >> > For example, if PNP is enhanced later to comprehend resource
> producers,
> >> > we won't know to go back and remove things from the blacklist.
> >> So lets have a note there. It (no blacklist) is meaningful to have all
> >> ACPI devices handled by PNP layer, but currently not.
> >In how far "currently not", please? At what point of time will this make
> >sense according to your opinion?
> >> We don't expect a PNP driver for root bridge.
> >> And we will take risk of buggy BIOS.
> >What please has a buggy BIOS to do with a more cryptic or more
> >sophisticated ACPI PNP concept?
> I want to emphasize I have no objection to merge the producer patch now
> but still think root bridge should be black list.
Hi Shaohua,
if I got something wrong I´d appreciate you to correct me.
First of all, what is a root bridge please? I know what a PCI-ISA bridge is, but I stumbled across the expression "root bridge."
As a consequence I do not understand in how far this "root bridge" should be blacklisted.
As far as I have received the issue the decision of blacklisting or rejecting ACPI_PRODUCER is a EITHER-OR one, but NOT a ALSO-THIS and ALSO-THAT one.
In so far your path of argumentation is more than confusing, at least for me, and may be for others too.
And as a second consequence I do not understand the essence of proposal or decision you are expecting from Bjorn.
Would be please clear up this??
> 
> Thanks,
> Shaohua
Regards
Uwe

-- 


"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
-
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

Re: [patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[Bjorn Helgaas]

On Friday 30 June 2006 03:04, Uwe Bugla wrote:
> First of all, what is a root bridge please? I know what a PCI-ISA
> bridge is, but I stumbled across the expression "root bridge."

A PCI root bridge is a device that sits between the processor and
a PCI bus.  On the upstream side (closer to the processor), it has
some platform-specific interface.  The downstream side is a standard
PCI bus.

Most PNP devices have some registers that control them.  For example,
a UART has a receive buffer, a transmit buffer, an interrupt enable
register, etc.  These appear at specific I/O port or MMIO addresses.
Those addresses are the resources consumed by the UART.  If you access
those resources, the UART responds by doing something.

Bridges are different.  They also consume I/O port and/or MMIO address
space.  But some of that address space is passed through to the other
side of the bridge, to the devices on the downstream bus.  In ACPI,
the resources that are passed to the downstream side are "consumed"
by the bridge and also "produced" on the downstream side.

The UART has no downstream side.  It "consumes" resources but
doesn't produce any.  (It does produce RS-232 signals on the
other side, but that's a completely different protocol and outside
the scope of ACPI.)

> As a consequence I do not understand in how far this "root bridge"
> should be blacklisted.  As far as I have received the issue the
> decision of blacklisting or rejecting ACPI_PRODUCER is a EITHER-OR
> one, but NOT a ALSO-THIS and ALSO-THAT one.

My opinion is that we must change PNPACPI to either understand or
ignore the producer resources.  Matthieu posted a patch to ignore
them.  If we don't do this, we will have the maintenance burden of
updating a blacklist whenever anybody invents a new device with
producer resources.

We could blacklist PNP0A03 in addition to changing PNPACPI.  For the
specific bug you tripped over, there's no reason to do both, but I
think Shaohua is worried about other problems.  For example, if the
BIOS reported that the PNP0A03 device consumed I/O port 0x3f8, which
is really consumed by the COM1 UART, that conflict might prevent the
serial driver from using the UART.

Or, somebody could make a PNP driver that claimed PNP0A03 PCI root
bridges, which would conflict with the existing ACPI driver that
claims PNP0A03 devices.  Blacklisting PNP0A03 in PNPACPI would prevent
a PNP driver from claiming it.

Bjorn

[patch 11/18] pnpacpi: reject ACPI_PRODUCER resources

[akpm]

From: matthieu castet <castet.matthieu@free.fr>

A patch in -mm kernel correct the parsing of "address resources" of pnpacpi. 
Before we assumed it was memory only, but it could be also IO.

But this change show an hidden bug : some resources could be producer type
that are not handled by pnp layer.  So we should ignore the producer
resources.

This patch fixes bug 6292 (http://bugzilla.kernel.org/show_bug.cgi?id=6292).
Some devices like PNP0A03 have 0xd00-0xffff and 0x0-0xcf7 as IO producer 
resources.

Before correcting "address resources" parsing, it was seen as memory and was
harmless, because nobody tried to reserve this memory range as it should be
IO.

With the correction it become IO resources, and make failed all others device
that want to register IO in this range and use pnp layer (like a ISA sound
card).

The solution is to ignore producer resources

Signed-off-by: Matthieu CASTET <castet.matthieu@free.fr>
Signed-off-by: Uwe Bugla <uwe.bugla@gmx.de>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Adam Belay <ambx1@neo.rr.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 drivers/pnp/pnpacpi/rsparser.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff -puN drivers/pnp/pnpacpi/rsparser.c~pnpacpi-reject-acpi_producer-resources drivers/pnp/pnpacpi/rsparser.c
--- a/drivers/pnp/pnpacpi/rsparser.c~pnpacpi-reject-acpi_producer-resources
+++ a/drivers/pnp/pnpacpi/rsparser.c
@@ -170,6 +170,9 @@ pnpacpi_parse_allocated_address_space(st
 		return;
 	}
 
+	if (p->producer_consumer == ACPI_PRODUCER)
+		return;
+
 	if (p->resource_type == ACPI_MEMORY_RANGE)
 		pnpacpi_parse_allocated_memresource(res_table,
 				p->minimum, p->address_length);
@@ -248,9 +251,14 @@ static acpi_status pnpacpi_allocated_res
 		break;
 
 	case ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS64:
+		if (res->data.ext_address64.producer_consumer == ACPI_PRODUCER)
+			return AE_OK;
 		break;
 
 	case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+		if (res->data.extended_irq.producer_consumer == ACPI_PRODUCER)
+			return AE_OK;
+
 		for (i = 0; i < res->data.extended_irq.interrupt_count; i++) {
 			pnpacpi_parse_allocated_irqresource(res_table,
 				res->data.extended_irq.interrupts[i],
_