| Message ID | 1308640587-24502-5-git-send-email-ying.huang@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jun 21, 2011 at 03:16:27PM +0800, Huang Ying wrote: > + rc = apei_osc_setup(); > + if (rc) > + pr_info(GHES_PFX "Evaluate APEI _OSC failed!\n"); Hm. This is maybe a little strong. It'd be valid for a machine to return an error here but still have the GHES functionality enabled via the generic call, but this message would still show up and potentially confuse the user. Can we keep a flag to check whether the generic method gave us control, and only give the error if both fail to enable it?
On 06/21/2011 09:22 PM, Matthew Garrett wrote: > On Tue, Jun 21, 2011 at 03:16:27PM +0800, Huang Ying wrote: > >> + rc = apei_osc_setup(); >> + if (rc) >> + pr_info(GHES_PFX "Evaluate APEI _OSC failed!\n"); > > Hm. This is maybe a little strong. It'd be valid for a machine to return > an error here but still have the GHES functionality enabled via the > generic call, but this message would still show up and potentially > confuse the user. Can we keep a flag to check whether the generic method > gave us control, and only give the error if both fail to enable it? At least on some of my testing machine, generic _OSC call will not return any error even it does not support APEI bit. So I think sometimes it may be helpful to printk something here. To avoid confusion, can we change the message as follow. - generic _OSC succeeded, APEI _OSC failed: APEI firmware first mode is enabled by APEI bit. - generic _OSC failed, APEI _OSC succeeded: APEI firmware first mode is enabled by APEI _OSC. - both succeeded: APEI firmware first mode is enabled by APEI bit and APEI _OSC. - both failed: Failed to enable APEI firmware first mode! Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jun 22, 2011 at 10:21:20AM +0800, Huang Ying wrote: > At least on some of my testing machine, generic _OSC call will not > return any error even it does not support APEI bit. So I think > sometimes it may be helpful to printk something here. To avoid > confusion, can we change the message as follow. > > - generic _OSC succeeded, APEI _OSC failed: APEI firmware first mode is > enabled by APEI bit. > - generic _OSC failed, APEI _OSC succeeded: APEI firmware first mode is > enabled by APEI _OSC. "WHEA _OSC", I think. The UUID here is part of the Microsoft spec, not the APEI one. > - both succeeded: APEI firmware first mode is enabled by APEI bit and > APEI _OSC. > - both failed: Failed to enable APEI firmware first mode! Otherwise, looks good.
--- a/drivers/acpi/apei/apei-base.c +++ b/drivers/acpi/apei/apei-base.c @@ -604,3 +604,29 @@ struct dentry *apei_get_debugfs_dir(void return dapei; } EXPORT_SYMBOL_GPL(apei_get_debugfs_dir); + +int apei_osc_setup(void) +{ + static u8 apei_uuid_str[] = "ed855e0c-6c90-47bf-a62a-26de0fc5ad5c"; + acpi_handle handle; + u32 capbuf[3]; + struct acpi_osc_context context = { + .uuid_str = apei_uuid_str, + .rev = 1, + .cap.length = sizeof(capbuf), + .cap.pointer = capbuf, + }; + + capbuf[OSC_QUERY_TYPE] = OSC_QUERY_ENABLE; + capbuf[OSC_SUPPORT_TYPE] = 0; + capbuf[OSC_CONTROL_TYPE] = 0; + + if (ACPI_FAILURE(acpi_get_handle(NULL, "\\_SB", &handle)) + || ACPI_FAILURE(acpi_run_osc(handle, &context))) + return -EIO; + else { + kfree(context.ret.pointer); + return 0; + } +} +EXPORT_SYMBOL_GPL(apei_osc_setup); --- a/drivers/acpi/apei/apei-internal.h +++ b/drivers/acpi/apei/apei-internal.h @@ -124,4 +124,6 @@ void apei_estatus_print(const char *pfx, const struct acpi_hest_generic_status *estatus); int apei_estatus_check_header(const struct acpi_hest_generic_status *estatus); int apei_estatus_check(const struct acpi_hest_generic_status *estatus); + +int apei_osc_setup(void); #endif --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -678,6 +678,10 @@ static int __init ghes_init(void) if (rc) goto err_ioremap_exit; + rc = apei_osc_setup(); + if (rc) + pr_info(GHES_PFX "Evaluate APEI _OSC failed!\n"); + return 0; err_ioremap_exit: ghes_ioremap_exit();
APEI firmware first mode must be turned on explicitly on some machines, otherwise they may be no GHES hardware error record for hardware error notification. APEI bit in generic _OSC call can be used to do that, but on some machine, a special APEI _OSC call must be used. This patch adds the support to that APEI _OSC call. Signed-off-by: Huang Ying <ying.huang@intel.com> --- drivers/acpi/apei/apei-base.c | 26 ++++++++++++++++++++++++++ drivers/acpi/apei/apei-internal.h | 2 ++ drivers/acpi/apei/ghes.c | 4 ++++ 3 files changed, 32 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html