Re: ACPIPNP and too large IO resources

[Bjorn Helgaas <bjorn.helgaas@hp.com>]

On Wednesday 05 July 2006 16:18, Andrew Morton wrote:
> Bjorn Helgaas <bjorn.helgaas@hp.com> 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?

> pnpacpi-reject-acpi_producer-resources.patch:
> 
> 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>
> 
> 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@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
> @@ -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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>