On Thu, 2006-07-06 at 23:29 +0800, Bjorn Helgaas wrote: > On Wednesday 05 July 2006 16:18, Andrew Morton wrote: > > Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > > > You recently proposed pushing it: > > > > http://marc.theaimsgroup.com/?l=linux-acpi&m=115119275408021&w=2 > > > Len initially nacked it, but I think the outcome of the > discussion > > > is that Shaohua doesn't object to this patch. He probably would > > > still like to blacklist PNP0A03, but that's an additional step we > > > don't have to take at the same time. > > > > OK, well let's please push this up the priority list and work out > what want > > to do. If Len's now OK with merging it then I think all lights are > green? > > My opinion is that we don't need to blacklist PNP0A03 unless > we discover a problem. > > Len, Shaohua, can you ack this? Sure. Please merge the patch Bjorn pointed out. Thanks, Shaohua > > > pnpacpi-reject-acpi_producer-resources.patch: > > > > From: matthieu castet <castet.matthieu@xxxxxxx> > > > > 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@xxxxxxx> > > Signed-off-by: Uwe Bugla <uwe.bugla@xxxxxx> > > Cc: Bjorn Helgaas <bjorn.helgaas@xxxxxx> > > Cc: Adam Belay <ambx1@xxxxxxxxxx> > > Cc: "Brown, Len" <len.brown@xxxxxxxxx> > > > > akpm: previously nacked, as per comment #26. But am hanging onto it > until the > > thing gets fixed for real. > > > > Signed-off-by: Andrew Morton <akpm@xxxxxxxx> > > --- > > > > 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 > > @@ -173,6 +173,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); > > @@ -252,9 +255,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], > > _ > > > > - > > 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 > > > - 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
