Re: [PATCH 1/2] x86 smpboot: fix cpu_init_udelay=10000

[shrybman]

> From: Len Brown <len.brown@xxxxxxxxx>
> 
> For legacy machines cpu_init_udelay defaults to 10,000.
> For modern machines it is set to 0.
> 
> The user should be able to set cpu_init_udelay to
> any value on the cmdline, including 10,000.
> Before this patch, that was seen as "unchanged from default"
> and thus on a modern machine, the user request was ignored
> and the delay was set to 0.
> 
> Signed-off-by: Len Brown <len.brown@xxxxxxxxx>
> ---
>  arch/x86/kernel/smpboot.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index e0c198e..32267cc 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -509,7 +509,7 @@ void __inquire_remote_apic(int apicid)
>  Â*/
>  #define UDELAY_10MS_DEFAULT 10000
>  
> -static unsigned int init_udelay = UDELAY_10MS_DEFAULT;
> +static unsigned int init_udelay = INT_MAX;
>  
>  static int __init cpu_init_udelay(char *str)
>  {
> @@ -522,13 +522,16 @@ early_param("cpu_init_udelay", cpu_init_udelay);
>  static void __init smp_quirk_init_udelay(void)
>  {
>  ÂÂÂÂÂ/* if cmdline changed it from default, leave it alone */
> -ÂÂÂÂÂif (init_udelay != UDELAY_10MS_DEFAULT)
> +ÂÂÂÂÂif (init_udelay != INT_MAX)
>  ÂÂÂÂÂÂÂÂÂÂreturn;
>  
>  ÂÂÂÂÂ/* if modern processor, use no delay */
>  ÂÂÂÂÂif (((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) && (boot_cpu_data.x86 == 6)) ||
>  ÂÂÂÂÂ Â Â((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && (boot_cpu_data.x86 >= 0xF)))
>  ÂÂÂÂÂÂÂÂÂÂinit_udelay = 0;
> +
> +ÂÂÂÂÂ/* else, use legacy delay */
> +ÂÂÂÂÂinit_udelay = UDELAY_10MS_DEFAULT;


Hi Len,


Is this really what you intended? The else is commented out so if init_udelay is quirked
to be 0 it will always be reset toÂUDELAY_10MS_DEFAULT. Also init_udelay is unsigned, so
would UINT_MAX be a better choice?


Shane

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/