RE: [ACPI] Suggested change to processor.c

[Grover, A. <and...@in...>]

> From: Sebastian Ude [mailto:ud...@ha...] 
> While trying to debug some strange ACPI behaviour, I found 
> out that the
> following macro defined in processor.c causes integer overflows on my
> system:
> 
> #define US_TO_PM_TIMER_TICKS(t) ((t * PM_TIMER_FREQUENCY) / 1000000)
> 
> Note that PM_TIMER_FREQUENCY is defined to be 3579545 in
> acpi/include/achware.h. So, invoking the macro for, say, 1000 uS would
> expand to:
> 
> ((1000 * 3579545) / 1000000)
> 
> That seems to be more than the temporary integer variables 
> can handle (this
> is an ix386 machine) - thus, my gcc version throws a warning 
> and even more
> important, the expression does not produce the expected result.

Grrr. I *fixed* this more than two years ago. Look at 2.4.18 -- The code
before the last Great Rewrite had it.

The solution was to do this:

#define US_TO_PM_TIMER_TICKS(t) ((t * (PM_TIMER_FREQUENCY/1000)) / 1000)

Now, it rolls over at t == 600,000 (if my calculations are correct), which
is more than enough for the situations where we use this macro. Losing 3
significant figures is no big deal, especially considering I'd bet it varies
by at least that 1 KHz on systems anyways.

Regards -- Andy