Re: Re: [PATCH] PNPACPI: fix types when decoding ACPI resources [resend]

[matthieu castet <castet.matthieu-GANU6spQydw@public.gmane.org>]

Bjorn Helgaas wrote:
> On Thursday 04 August 2005 6:38 am, matthieu castet wrote:
> 
>>Bjorn Helgaas wrote:
>>
>>>On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:
>>>
>>>>Bjorn Helgaas wrote:
>>>>
>>>>>	drivers/char/hpet.c
>>>>>		This probably should be converted to PNP.  I'll
>>>>>		look into doing this.
>>>>
>>>>IIRC, I am not sure that the pnp layer was able to pass the 64 bits 
>>>>memory adress for hpet correctly. But it would be nice if it works.
>>>
>>>You're right, this was broken.  But I've been pushing a PNPACPI
>>>patch to fix this.
>>>
>>
>>Yes but is ACPI_RSTYPE_ADDRESS64 possible on 32 bit machine ?
> 
> 
> I can't think of a case where that would make sense, but I don't
> actually know the answer.
> 
> 
>>In this case your patch won't work as res->mem_resource[i].start and 
>>res->mem_resource[i].end are unsigned long, and 64 bit value won't fit.
> 
> 
> True.  But fixing that would be pretty far-reaching (changing struct
> resource), so I'm not worried until it is shown to be a problem.
> 
Ok, may be you could add a BUG_ON(sizeof(long)==4) for 
ACPI_RSTYPE_ADDRESS64.

Matthieu



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf