| Message ID | 94dec32ef07d95940ee63445f151899ae7b430b3.1727236561.git.mchehab+huawei@kernel.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Prepare GHES driver to support error injection | expand |
On Wed, 25 Sep 2024 06:04:19 +0200 Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote: > The hardware error firmware is where HEST error structures are > stored. Those can be GHESv2, but they can also be other types. > > Better name the location of the hardware error. > > No functional changes. > > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> This feels a little theoretical as for now they are always GHESv2 I think? I guess it does no harm and may make sense after follow up series. Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Em Thu, 26 Sep 2024 13:12:25 +0100 Jonathan Cameron <Jonathan.Cameron@Huawei.com> escreveu: > On Wed, 25 Sep 2024 06:04:19 +0200 > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote: > > > The hardware error firmware is where HEST error structures are > > stored. Those can be GHESv2, but they can also be other types. > > > > Better name the location of the hardware error. > > > > No functional changes. > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> > This feels a little theoretical as for now they are always GHESv2 I think? It is, but the new code that will be added on the next patch series will allow future addition of other types as well, as it seeks for the source ID inside the error block structures. Yet, if we end adding other types, it will probably make sense to rename ghes.c to hest.c. > I guess it does no harm and may make sense after follow up series. > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Thanks, Mauro
diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c index 15b4c3ebbf24..d4dbfb45e181 100644 --- a/hw/acpi/generic_event_device.c +++ b/hw/acpi/generic_event_device.c @@ -346,7 +346,7 @@ static const VMStateDescription vmstate_ghes = { .version_id = 1, .minimum_version_id = 1, .fields = (const VMStateField[]) { - VMSTATE_UINT64(ghes_addr_le, AcpiGhesState), + VMSTATE_UINT64(hw_error_le, AcpiGhesState), VMSTATE_END_OF_LIST() }, }; @@ -354,7 +354,7 @@ static const VMStateDescription vmstate_ghes = { static bool ghes_needed(void *opaque) { AcpiGedState *s = opaque; - return s->ghes_state.ghes_addr_le; + return s->ghes_state.hw_error_le; } static const VMStateDescription vmstate_ghes_state = { diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c index 3d03506fdaf8..8b3292be07e7 100644 --- a/hw/acpi/ghes.c +++ b/hw/acpi/ghes.c @@ -379,7 +379,7 @@ void acpi_ghes_add_fw_cfg(AcpiGhesState *ags, FWCfgState *s, /* Create a read-write fw_cfg file for Address */ fw_cfg_add_file_callback(s, ACPI_HW_ERROR_ADDR_FW_CFG_FILE, NULL, NULL, - NULL, &(ags->ghes_addr_le), sizeof(ags->ghes_addr_le), false); + NULL, &(ags->hw_error_le), sizeof(ags->hw_error_le), false); ags->present = true; } @@ -430,7 +430,7 @@ void ghes_record_cper_errors(const void *cper, size_t len, } ags = &acpi_ged_state->ghes_state; - get_ghes_offsets(le64_to_cpu(ags->ghes_addr_le), + get_ghes_offsets(le64_to_cpu(ags->hw_error_le), &cper_addr, &read_ack_register_addr); if (!cper_addr) { diff --git a/include/hw/acpi/ghes.h b/include/hw/acpi/ghes.h index 051a9322141f..e47ffacbb5c9 100644 --- a/include/hw/acpi/ghes.h +++ b/include/hw/acpi/ghes.h @@ -58,7 +58,7 @@ enum AcpiGhesNotifyType { }; typedef struct AcpiGhesState { - uint64_t ghes_addr_le; + uint64_t hw_error_le; bool present; /* True if GHES is present at all on this board */ } AcpiGhesState;
The hardware error firmware is where HEST error structures are stored. Those can be GHESv2, but they can also be other types. Better name the location of the hardware error. No functional changes. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> --- hw/acpi/generic_event_device.c | 4 ++-- hw/acpi/ghes.c | 4 ++-- include/hw/acpi/ghes.h | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)