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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 26 Mar 2019 22:00:24 +0100 (CET)
From:   Thomas Gleixner <>
To:     Ricardo Neri <>
cc:     Ingo Molnar <>, Borislav Petkov <>,
        Ashok Raj <>,
        Andi Kleen <>,
        Peter Zijlstra <>,
        "Ravi V. Shankar" <>,,,
        Ricardo Neri <>,
        "H. Peter Anvin" <>, Tony Luck <>,
        Philippe Ombredanne <>,
        Kate Stewart <>,
        "Rafael J. Wysocki" <>
Subject: Re: [RFC PATCH v2 02/14] x86/hpet: Expose more functions to read
 and write registers

On Wed, 27 Feb 2019, Ricardo Neri wrote:
>  struct irq_data;
> @@ -109,6 +114,11 @@ extern void hpet_unregister_irq_handler(rtc_irq_handler handler);
>  static inline int hpet_enable(void) { return 0; }
>  static inline int is_hpet_enabled(void) { return 0; }
>  #define hpet_readl(a) 0
> +#define hpet_writel(d, a)

What for?

> +#ifdef CONFIG_X86_64
> +#define hpet_readq(a) 0
> +#define hpet_writeq(d, a)
> +#endif


There are no users outside of HPET and your new HPET watchdog code for
those. And both are not compiled when CONFIG_HPET=n.

The only reason to have the hpet_readl() define, which btw. should be an
inline, is to avoid massive ifdeffery in the TSC calibration code.



Powered by blists - more mailing lists