From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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 10/15] acpi/ghes: move offset calculus to a separate function
Date: Thu, 26 Sep 2024 13:03:48 +0100 [thread overview]
Message-ID: <20240926130348.00005e45@Huawei.com> (raw)
In-Reply-To: <5e8c2f0267a21d05ed09c8af616a92d94638c474.1727236561.git.mchehab+huawei@kernel.org>
On Wed, 25 Sep 2024 06:04:15 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> Currently, CPER address location is calculated as an offset of
> the hardware_errors table. It is also badly named, as the
> offset actually used is the address where the CPER data starts,
> and not the beginning of the error source.
>
> Move the logic which calculates such offset to a separate
> function, in preparation for a patch that will be changing the
> logic to calculate it from the HEST table.
>
> While here, properly name the variable which stores the cper
> address.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Trivial comment inline.
Given this is a placeholder for more radical refactor I'll not comment on
the maths etc being less flexible than it will hopefully end up!
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> void ghes_record_cper_errors(const void *cper, size_t len,
> uint16_t source_id, Error **errp)
> {
> - /*
> - * As the current version supports only one source, the ack offset is
> - * just sizeof(uint64_t).
> - */
> - read_ack_register_addr = start_addr + sizeof(uint64_t);
> -
> cpu_physical_memory_read(read_ack_register_addr,
> - &read_ack_register, sizeof(read_ack_register));
> + &read_ack_register, sizeof(read_ack_register));
>
Wrong patch for this alignment tidy up?
Or are my eyes deceiving me and there is more going on here...
J
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
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 10/15] acpi/ghes: move offset calculus to a separate function
Date: Thu, 26 Sep 2024 13:03:48 +0100 [thread overview]
Message-ID: <20240926130348.00005e45@Huawei.com> (raw)
In-Reply-To: <5e8c2f0267a21d05ed09c8af616a92d94638c474.1727236561.git.mchehab+huawei@kernel.org>
On Wed, 25 Sep 2024 06:04:15 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> Currently, CPER address location is calculated as an offset of
> the hardware_errors table. It is also badly named, as the
> offset actually used is the address where the CPER data starts,
> and not the beginning of the error source.
>
> Move the logic which calculates such offset to a separate
> function, in preparation for a patch that will be changing the
> logic to calculate it from the HEST table.
>
> While here, properly name the variable which stores the cper
> address.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Trivial comment inline.
Given this is a placeholder for more radical refactor I'll not comment on
the maths etc being less flexible than it will hopefully end up!
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> void ghes_record_cper_errors(const void *cper, size_t len,
> uint16_t source_id, Error **errp)
> {
> - /*
> - * As the current version supports only one source, the ack offset is
> - * just sizeof(uint64_t).
> - */
> - read_ack_register_addr = start_addr + sizeof(uint64_t);
> -
> cpu_physical_memory_read(read_ack_register_addr,
> - &read_ack_register, sizeof(read_ack_register));
> + &read_ack_register, sizeof(read_ack_register));
>
Wrong patch for this alignment tidy up?
Or are my eyes deceiving me and there is more going on here...
J
next prev parent reply other threads:[~2024-09-26 12:04 UTC|newest]
Thread overview: 57+ 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 14:02 ` Jonathan Cameron
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 14:09 ` Jonathan Cameron
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 14:11 ` Jonathan Cameron
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 14:13 ` Jonathan Cameron
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 14:15 ` Jonathan Cameron
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 14:15 ` Jonathan Cameron
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 14:16 ` Jonathan Cameron
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-09-25 14:23 ` Jonathan Cameron
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
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 [this message]
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
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
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
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
2024-09-26 12:12 ` Jonathan Cameron via
2024-10-01 6:02 ` Mauro Carvalho Chehab
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
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=20240926130348.00005e45@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=anisinha@redhat.com \
--cc=gengdongjiu1@gmail.com \
--cc=imammedo@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab+huawei@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.