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 v4 08/15] acpi/ghes: make the GHES record generation more generic
Date: Wed, 4 Dec 2024 08:52:07 +0100 [thread overview]
Message-ID: <20241204085207.0ecae6ae@foz.lan> (raw)
In-Reply-To: <20241125115643.00002923@huawei.com>
Em Mon, 25 Nov 2024 11:56:43 +0000
Jonathan Cameron <Jonathan.Cameron@huawei.com> escreveu:
> On Fri, 22 Nov 2024 10:11:25 +0100
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
>
> > Split the code into separate functions to allow using the
> > common CPER filling code by different error sources.
> >
> > The generic code was moved to ghes_record_cper_errors(),
> > and ghes_gen_err_data_uncorrectable_recoverable() now contains
> > only a logic to fill the Generic Error Data part of the record,
> > as described at:
> >
> > ACPI 6.2: 18.3.2.7.1 Generic Error Data
> >
> > The remaining code to generate a memory error now belongs to
> > acpi_ghes_record_errors() function.
> >
> > A further patch will give it a better name.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>
> One trivial follow up that is enabled by the change you are discussing with Igor.
> Up to you that one.
>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > +
> > +int acpi_ghes_record_errors(uint16_t source_id, uint64_t physical_address)
> > +{
> > + /* Memory Error Section Type */
> > + const uint8_t guid[] =
> > + UUID_LE(0xA5BC1114, 0x6F64, 0x4EDE, 0xB8, 0x63, 0x3E, 0x83, \
> > + 0xED, 0x7C, 0x83, 0xB1);
> > + Error *errp = NULL;
> > + int data_length;
> > + GArray *block;
> > +
> > + if (!physical_address) {
> > + error_report("can not find Generic Error Status Block for source id %d",
> > + source_id);
> > + return -1;
> > + }
>
> With this error check gone (as per discussion with Igor) you could use
> g_autofree to deal with freeing block.
>
> That would bring the errp check right next to the call that would result
> in errp potentially being set and slightly improve readability.
>
> Mind you there are no uses of this in hw/acpi currently so maybe this
> isn't a good time to start :)
Yeah, I prefer to not do such cleanup now. As you said, this isn't used
right now at ghes, and there are still two series on the top of it.
IMO, such kind of change should happen afterwards, and checking on
other places were memory is allocated in the driver.
Thanks,
Mauro
next prev parent reply other threads:[~2024-12-04 7:53 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-22 9:11 [PATCH v4 00/15] Prepare GHES driver to support error injection Mauro Carvalho Chehab
2024-11-22 9:11 ` [PATCH v4 01/15] acpi/ghes: get rid of ACPI_HEST_SRC_ID_RESERVED Mauro Carvalho Chehab
2024-11-22 9:11 ` [PATCH v4 02/15] acpi/ghes: simplify acpi_ghes_record_errors() code Mauro Carvalho Chehab
2024-11-22 9:11 ` [PATCH v4 03/15] acpi/ghes: simplify the per-arch caller to build HEST table Mauro Carvalho Chehab
2024-11-22 9:11 ` [PATCH v4 04/15] acpi/ghes: better handle source_id and notification Mauro Carvalho Chehab
2024-11-22 16:20 ` Igor Mammedov
2024-11-22 9:11 ` [PATCH v4 05/15] acpi/ghes: Fix acpi_ghes_record_errors() argument Mauro Carvalho Chehab
2024-11-22 9:11 ` [PATCH v4 06/15] acpi/ghes: Remove a duplicated out of bounds check Mauro Carvalho Chehab
2024-11-22 9:11 ` [PATCH v4 07/15] acpi/ghes: Change the type for source_id Mauro Carvalho Chehab
2024-11-22 15:41 ` Igor Mammedov
2024-11-22 9:11 ` [PATCH v4 08/15] acpi/ghes: make the GHES record generation more generic Mauro Carvalho Chehab
2024-11-22 16:19 ` Igor Mammedov
2024-11-25 11:06 ` Mauro Carvalho Chehab
2024-11-25 11:56 ` Jonathan Cameron via
2024-12-04 7:52 ` Mauro Carvalho Chehab [this message]
2024-12-03 11:42 ` Igor Mammedov
2024-12-03 13:38 ` Mauro Carvalho Chehab
2024-11-22 9:11 ` [PATCH v4 09/15] acpi/ghes: better name GHES memory error function Mauro Carvalho Chehab
2024-11-22 9:11 ` [PATCH v4 10/15] acpi/ghes: don't crash QEMU if ghes GED is not found Mauro Carvalho Chehab
2024-11-22 16:21 ` Igor Mammedov
2024-11-22 9:11 ` [PATCH v4 11/15] acpi/ghes: rename etc/hardware_error file macros Mauro Carvalho Chehab
2024-11-22 9:11 ` [PATCH v4 12/15] acpi/ghes: better name the offset of the hardware error firmware Mauro Carvalho Chehab
2024-11-22 9:11 ` [PATCH v4 13/15] acpi/ghes: move offset calculus to a separate function Mauro Carvalho Chehab
2024-12-03 11:51 ` Igor Mammedov
2024-12-03 13:47 ` Mauro Carvalho Chehab
2024-12-04 7:54 ` Igor Mammedov
2024-12-04 8:56 ` Mauro Carvalho Chehab
2024-12-04 9:24 ` Igor Mammedov
2024-12-09 9:27 ` Mauro Carvalho Chehab
2024-11-22 9:11 ` [PATCH v4 14/15] acpi/ghes: Change ghes fill logic to work with only one source Mauro Carvalho Chehab
2024-12-03 11:52 ` Igor Mammedov
2024-11-22 9:11 ` [PATCH v4 15/15] docs: acpi_hest_ghes: fix documentation for CPER size Mauro Carvalho Chehab
2024-12-03 11:56 ` Igor Mammedov
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=20241204085207.0ecae6ae@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).