lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 05 Aug 2011 03:32:37 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	dsaxena@...xity.net
Cc:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	patches@...aro.org
Subject: Re: [PATCH] Remove CLOCK_TICK_RATE from acpi_pm clocksource driver

On Wed, 2011-08-03 at 17:08 -0700, Deepak Saxena wrote:
> The acpi_pm clocksource driver uses CLOCK_TICK_RATE which is
> defined as PIT_TICK_RATE on x86. This patch cleans it up to
> just use the later so that CLOCK_TICK_RATE can be depecrated.
> 
> Signed-off-by: Deepak Saxena <dsaxena@...aro.org>
> ---
>  drivers/clocksource/acpi_pm.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/clocksource/acpi_pm.c b/drivers/clocksource/acpi_pm.c
> index effe797..6b5cf02 100644
> --- a/drivers/clocksource/acpi_pm.c
> +++ b/drivers/clocksource/acpi_pm.c
> @@ -143,7 +143,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_SERVERWORKS, PCI_DEVICE_ID_SERVERWORKS_LE,
>  #ifndef CONFIG_X86_64
>  #include <asm/mach_timer.h>
>  #define PMTMR_EXPECTED_RATE \
> -  ((CALIBRATE_LATCH * (PMTMR_TICKS_PER_SEC >> 10)) / (CLOCK_TICK_RATE>>10))
> +  ((CALIBRATE_LATCH * (PMTMR_TICKS_PER_SEC >> 10)) / (PIT_TICK_RATE>>10))
>  /*
>   * Some boards have the PMTMR running way too fast. We check
>   * the PMTMR rate against PIT channel 2 to catch these cases.

I suspect the PMTMR_EXPECTED_RATE is not so sensitive that it actually
needs to use CLOCK_TICK_RATE or PIT_TICK_RATE here. 

Instead we probably should rework mach_countup() to return how long it
ran for (in nsecs), since the acpi_pm code really shouldn't need to know
PIT_TICK_RATE details at all.

That said, mach_countup is pretty old and crusty code that is important
to TSC and loop-per-jiffy calibration. So I'm not sure if there's much
gain to digging in and mucking with things there. 

So for now, the PIT_TICK_RATE change seems like a fair change.

Acked-by: John Stultz <john.stultz@...aro.org>

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ