| Message ID | 87shhrknes.fsf@e105922-lin.cambridge.arm.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Thu, Jul 20, 2017 at 06:50:51PM +0100, Punit Agrawal wrote: > "Firmware does not support APEI firmware first mode" > > Thoughts? I guess the simplest would be to add a third state to that hest_disable to denote "HEST table not found" and then exit ghes_init() early, based on checking it. Otherwise ghes_init() inits a bunch of things which you probably don't want on a platform which doesn't support APEI.
Hi Boris, Apologies for the delayed response. I somehow managed to lose updates on this thread. Borislav Petkov <bp@suse.de> writes: > On Thu, Jul 20, 2017 at 06:50:51PM +0100, Punit Agrawal wrote: >> "Firmware does not support APEI firmware first mode" >> >> Thoughts? > > I guess the simplest would be to add a third state to that hest_disable > to denote "HEST table not found" and then exit ghes_init() early, based on > checking it. Although simple, won't it make the already convoluted code flow more so. Instead in addition to not setting hest_disable when the table is not found ... > > Otherwise ghes_init() inits a bunch of things which you probably don't > want on a platform which doesn't support APEI. ... would you be open to a patch re-working the ghes driver initialisation to only do the platform driver registration. The the rest of the initialisation (including the apei_osc_setup and related messages) can be performed when the first ghes device gets probed. Does that sound like a better alternative? > > -- > Regards/Gruss, > Boris. > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- 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 Thu, Jul 27, 2017 at 10:35:45AM +0100, Punit Agrawal wrote: > ... would you be open to a patch re-working the ghes driver > initialisation to only do the platform driver registration. The the rest > of the initialisation (including the apei_osc_setup and related > messages) can be performed when the first ghes device gets probed. > > Does that sound like a better alternative? If you split it by doing one logical change per patch so that it is obvious what's going on and you don't break existing usage, I don't see why not.
Borislav Petkov <bp@suse.de> writes: > On Thu, Jul 27, 2017 at 10:35:45AM +0100, Punit Agrawal wrote: >> ... would you be open to a patch re-working the ghes driver >> initialisation to only do the platform driver registration. The the rest >> of the initialisation (including the apei_osc_setup and related >> messages) can be performed when the first ghes device gets probed. >> >> Does that sound like a better alternative? > > If you split it by doing one logical change per patch so that it is > obvious what's going on and you don't break existing usage, I don't see > why not. Good! I'll try and get the patches out in the next few days. Thanks. > > -- > Regards/Gruss, > Boris. > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- 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
diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c index 456b488eb1df..f7784d9514e1 100644 --- a/drivers/acpi/apei/hest.c +++ b/drivers/acpi/apei/hest.c @@ -233,8 +233,9 @@ void __init acpi_hest_init(void) status = acpi_get_table(ACPI_SIG_HEST, 0, (struct acpi_table_header **)&hest_tab); if (status == AE_NOT_FOUND) - goto err; - else if (ACPI_FAILURE(status)) { + return; + + if (ACPI_FAILURE(status)) { const char *msg = acpi_format_exception(status); pr_err(HEST_PFX "Failed to get table, %s\n", msg); rc = -EINVAL;