Bjorn Helgaas wrote:

On Thursday 04 August 2005 6:38 am, matthieu castet wrote:

quoted

Bjorn Helgaas wrote:

quoted

On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:

quoted

Bjorn Helgaas wrote:

quoted

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.

quoted

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