From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
Shiju Jose <shiju.jose@huawei.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Ani Sinha <anisinha@redhat.com>,
Dongjiu Geng <gengdongjiu1@gmail.com>,
<linux-kernel@vger.kernel.org>, <qemu-arm@nongnu.org>,
<qemu-devel@nongnu.org>
Subject: Re: [PATCH 14/15] better name the offset of the hardware error firmware
Date: Tue, 1 Oct 2024 08:02:40 +0200 [thread overview]
Message-ID: <20241001080240.56a927d2@foz.lan> (raw)
In-Reply-To: <20240926131225.0000337c@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
next prev parent reply other threads:[~2024-10-01 14:58 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 4:04 [PATCH 00/15] Prepare GHES driver to support error injection Mauro Carvalho Chehab
2024-09-25 4:04 ` [PATCH 01/15] acpi/ghes: get rid of ACPI_HEST_SRC_ID_RESERVED Mauro Carvalho Chehab
2024-09-25 14:02 ` Jonathan Cameron via
2024-09-25 4:04 ` [PATCH 02/15] acpi/ghes: simplify acpi_ghes_record_errors() code Mauro Carvalho Chehab
2024-09-25 14:09 ` Jonathan Cameron via
2024-09-25 4:04 ` [PATCH 03/15] acpi/ghes: simplify the per-arch caller to build HEST table Mauro Carvalho Chehab
2024-09-25 14:11 ` Jonathan Cameron via
2024-09-25 4:04 ` [PATCH 04/15] acpi/ghes: better handle source_id and notification Mauro Carvalho Chehab
2024-09-25 14:13 ` Jonathan Cameron via
2024-09-25 4:04 ` [PATCH 05/15] acpi/ghes: Fix acpi_ghes_record_errors() argument Mauro Carvalho Chehab
2024-09-25 14:15 ` Jonathan Cameron via
2024-09-25 4:04 ` [PATCH 06/15] acpi/ghes: Remove a duplicated out of bounds check Mauro Carvalho Chehab
2024-09-25 14:15 ` Jonathan Cameron via
2024-09-25 4:04 ` [PATCH 07/15] acpi/ghes: Change the type for source_id Mauro Carvalho Chehab
2024-09-25 14:16 ` Jonathan Cameron via
2024-09-25 4:04 ` [PATCH 08/15] acpi/ghes: Prepare to support multiple sources on ghes Mauro Carvalho Chehab
2024-09-25 14:23 ` Jonathan Cameron via
2024-10-01 5:29 ` Mauro Carvalho Chehab
2024-09-25 4:04 ` [PATCH 09/15] acpi/ghes: make the GHES record generation more generic Mauro Carvalho Chehab
2024-09-26 12:00 ` Jonathan Cameron via
2024-09-26 14:19 ` Mauro Carvalho Chehab
2024-09-25 4:04 ` [PATCH 10/15] acpi/ghes: move offset calculus to a separate function Mauro Carvalho Chehab
2024-09-26 12:03 ` Jonathan Cameron via
2024-10-01 5:38 ` Mauro Carvalho Chehab
2024-09-25 4:04 ` [PATCH 11/15] acpi/ghes: better name GHES memory error function Mauro Carvalho Chehab
2024-09-26 12:07 ` Jonathan Cameron via
2024-09-25 4:04 ` [PATCH 12/15] acpi/ghes: don't crash QEMU if ghes GED is not found Mauro Carvalho Chehab
2024-09-26 12:09 ` Jonathan Cameron via
2024-09-26 14:24 ` Mauro Carvalho Chehab
2024-09-25 4:04 ` [PATCH 13/15] acpi/ghes: rename etc/hardware_error file macros Mauro Carvalho Chehab
2024-09-26 12:11 ` Jonathan Cameron via
2024-09-25 4:04 ` [PATCH 14/15] better name the offset of the hardware error firmware Mauro Carvalho Chehab
2024-09-26 12:12 ` Jonathan Cameron via
2024-10-01 6:02 ` Mauro Carvalho Chehab [this message]
2024-09-25 4:04 ` [PATCH 15/15] docs: acpi_hest_ghes: fix documentation for CPER size Mauro Carvalho Chehab
2024-09-26 12:13 ` Jonathan Cameron via
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241001080240.56a927d2@foz.lan \
--to=mchehab+huawei@kernel.org \
--cc=Jonathan.Cameron@Huawei.com \
--cc=anisinha@redhat.com \
--cc=gengdongjiu1@gmail.com \
--cc=imammedo@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=shiju.jose@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).