Re: [patch 51/57] ACPI: Ingore the RESET_REG_SUP bit when usingACPI reset mechanism

[Zhao Yakui]

On Wed, 2008-11-05 at 07:33 +0800, Greg KH wrote:
> 2.6.27-stable review patch.  If anyone has any objections, please let us know.
Please don't apply this patch.And this causes the reboot regression on
AMD chipset. (Bug11942)
    Now the default reboot type is changed from BOOT_KBD to BOOT_ACPI.
      
On the AMD box there exists the definition of RESET_REG &RESET_VALUE,
which is identical to the definition in Intel Chipset. After the
RESET_REG_SUP is ignored, the AMD box can't be rebooted by writing the
RESET_VALUE to RESET_REG I/O port.

Thanks.
   Yakui
    
> 
> ------------------
> From: Zhao Yakui <yakui.zhao@xxxxxxxxx>
> 
> Subject: [patch 51/57] ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism
> 
> commit 8fd145917fb62368a9b80db59562c20576238f5a upstream
> 
> ACPI: Ingore the RESET_REG_SUP bit when using ACPI reset mechanism
> 
> According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
> whether the ACPI reboot mechanism is supported.
> 
> However, some boxes have this bit clear, have a valid
> ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only
> mechanism that works for them after S3.
> 
> This suggests that other operating systems may not be checking
> the RESET_REG_SUP bit, and are using other means to decide
> whether to use the ACPI reboot mechanism or not.
> 
> Here we stop checking RESET_REG_SUP.
> Instead, When acpi reboot is requested,
> only the reset_register is checked. If the following
> conditions are met, it indicates that the reset register is supported.
> 	a. reset_register is not zero
> 	b. the access width is eight
> 	c. the bit_offset is zero
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=7299
> http://bugzilla.kernel.org/show_bug.cgi?id=1148
> 
> Signed-off-by: Zhao Yakui <yakui.zhao@xxxxxxxxx>
> Signed-off-by: Len Brown <len.brown@xxxxxxxxx>
> Cc: Chuck Ebbert <cebbert@xxxxxxxxxx>
> Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
> 
> ---
>  drivers/acpi/reboot.c |   25 ++++++++++++++++++++++---
>  1 file changed, 22 insertions(+), 3 deletions(-)
> 
> --- a/drivers/acpi/reboot.c
> +++ b/drivers/acpi/reboot.c
> @@ -15,9 +15,28 @@ void acpi_reboot(void)
>  
>  	rr = &acpi_gbl_FADT.reset_register;
>  
> -	/* Is the reset register supported? */
> -	if (!(acpi_gbl_FADT.flags & ACPI_FADT_RESET_REGISTER) ||
> -	    rr->bit_width != 8 || rr->bit_offset != 0)
> +	/*
> +	 * Is the ACPI reset register supported?
> +	 *
> +	 * According to ACPI 3.0, FADT.flags.RESET_REG_SUP indicates
> +	 * whether the ACPI reset mechanism is supported.
> +	 *
> +	 * However, some boxes have this bit clear, yet a valid
> +	 * ACPI_RESET_REG & RESET_VALUE, and ACPI reboot is the only
> +	 * mechanism that works for them after S3.
> +	 *
> +	 * This suggests that other operating systems may not be checking
> +	 * the RESET_REG_SUP bit, and are using other means to decide
> +	 * whether to use the ACPI reboot mechanism or not.
> +	 *
> +	 * So when acpi reboot is requested,
> +	 * only the reset_register is checked. If the following
> +	 * conditions are met, it indicates that the reset register is supported.
> +	 * 	a. reset_register is not zero
> +	 * 	b. the access width is eight
> +	 * 	c. the bit_offset is zero
> +	 */
> +	if (!(rr->address) || rr->bit_width != 8 || rr->bit_offset != 0)
>  		return;
>  
>  	reset_value = acpi_gbl_FADT.reset_value;
> 

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