[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080818204210.GA21678@comet.dominikbrodowski.net>
Date: Mon, 18 Aug 2008 22:42:10 +0200
From: Dominik Brodowski <linux@...inikbrodowski.net>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Andreas Mohr <andi@...as.de>, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, johnstul@...ibm.com,
hirofumi@...l.parknet.co.jp, alan@...rguk.ukuu.org.uk,
arjan@...radead.org
Subject: Re: [PATCH 2/2] acpi_pm.c: check for monotonicity
Hi,
On Mon, Aug 18, 2008 at 01:28:58PM -0700, Andrew Morton wrote:
> > On Mon, Aug 18, 2008 at 10:11:15PM +0200, Dominik Brodowski wrote:
> > > + if (good != 10) {
> > > + printk(KERN_INFO "PM-Timer had no reasonable result:"
> > > + " 0x%#llx - aborting.\n", value1);
> > > + return -ENODEV;
> > > }
> > > - printk(KERN_INFO "PM-Timer had no reasonable result:"
> > > - " 0x%#llx - aborting.\n", value1);
> > > - return -ENODEV;
> >
> > Technically spoken this log message could now be considered partially
> > outdated... (we're doing 10 evaluations after all, not one with a
> > precise end result).
> >
> >
> > Seeing a define for those several open-coded 10 loops values would be nice.
> >
>
> Also it's a bit dodgy printing a cycle_t with %llx. We don't _know_
> that cycle_t was implemented with `long long' - if this was always
> true, we wouldn't (or shouldn't) have a cycle_t at all.
>
> But it seems that it happens to work for all architectures which
> implement acpi.
Well, adding a format modifier just for this isn't necessary IMO, especially
as all acpi-implementing architectures seem to be fine. Regarding the other
issues: well, I don't care all that much about a define for something used
twice and this comment; but if you want to squash it into the other patch
I'm fine with it.
Signed-off-by: Dominik Brodowski <linux@...inikbrodowski.net>
diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
index f05c4fb..09d4650 100644
--- a/drivers/clocksource/acpi_pm.c
+++ b/drivers/clocksource/acpi_pm.c
@@ -175,6 +175,9 @@ static int verify_pmtmr_rate(void)
#define verify_pmtmr_rate() (0)
#endif
+/* Number of monotonicity checks to perform during initialization */
+#define ACPI_PM_MONOTONICITY_CHECKS 10
+
static int __init init_acpi_pm_clocksource(void)
{
cycle_t value1, value2;
@@ -187,7 +190,7 @@ static int __init init_acpi_pm_clocksource(void)
clocksource_acpi_pm.shift);
/* "verify" this timing source: */
- for (j = 0; j < 10; j++) {
+ for (j = 0; j < ACPI_PM_MONOTONICITY_CHECKS; j++) {
value1 = clocksource_acpi_pm.read();
for (i = 0; i < 10000; i++) {
value2 = clocksource_acpi_pm.read();
@@ -207,9 +210,9 @@ static int __init init_acpi_pm_clocksource(void)
udelay(300 * i);
}
- if (good != 10) {
- printk(KERN_INFO "PM-Timer had no reasonable result:"
- " 0x%#llx - aborting.\n", value1);
+ if (good != ACPI_PM_MONOTONICITY_CHECKS) {
+ printk(KERN_INFO "PM-Timer failed consistency check "
+ " (0x%#llx) - aborting.\n", value1);
return -ENODEV;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists