Fix faulty HPET clocksource usage (fix for bug #7062)

Apparently some systems export valid HPET addresses, but hpet_enable() fails. Then when the HPET clocksource starts up, it only checks for a valid HPET address, and the result is a system where time does not advance.

See http://bugme.osdl.org/show_bug.cgi?id=7062 for details.

This patch just makes sure we better check that the HPET is functional before registering the HPET clocksource.

Signed-off-by John Stultz <[email protected]>

arch/i386/kernel/hpet.c +0 -0

index c6737c3..17647a5 100644

Quoted 20 lines · On Mon, 28 Aug 2006 14:32:39 -0700 john stultz <[email protected]> wrote:

Apparently some systems export valid HPET addresses, but hpet_enable() fails. Then when the HPET clocksource starts up, it only checks for a valid HPET address, and the result is a system where time does not advance.

See http://bugme.osdl.org/show_bug.cgi?id=7062 for details.

This patch just makes sure we better check that the HPET is functional before registering the HPET clocksource.

Signed-off-by John Stultz <[email protected]>

arch/i386/kernel/hpet.c +0 -0

index c6737c3..17647a5 100644
@@ -35,7 +35,7 @@ static int __init init_hpet_clocksource(
 	void __iomem* hpet_base;
 	u64 tmp;
 

arch/i386/kernel/hpet.c static int __init init_hpet_clocksource( · line 41

Quoted 5 lines

arch/i386/kernel/hpet.c +1 -1

-	if (!hpet_address)
+	if (!is_hpet_enabled())
 		return -ENODEV;
 
 	/* calculate the hpet address: */

Thanks. This would be a 2.6.18 thing, wouldn't it?