All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Igor Mammedov <imammedo@redhat.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Shiju Jose <shiju.jose@huawei.com>, <qemu-arm@nongnu.org>,
	<qemu-devel@nongnu.org>, Ani Sinha <anisinha@redhat.com>,
	Dongjiu Geng <gengdongjiu1@gmail.com>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 02/11] acpi/ghes: add a firmware file with HEST address
Date: Tue, 28 Jan 2025 11:12:57 +0100	[thread overview]
Message-ID: <20250128111257.74766c82@foz.lan> (raw)
In-Reply-To: <20250123180135.4f86483f@imammedo.users.ipa.redhat.com>

Em Thu, 23 Jan 2025 18:01:35 +0100
Igor Mammedov <imammedo@redhat.com> escreveu:

> On Thu, 23 Jan 2025 10:02:17 +0000
> Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote:
> 
> > On Wed, 22 Jan 2025 16:46:19 +0100
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> >   
> > > Store HEST table address at GPA, placing its content at
> > > hest_addr_le variable.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > >     
> > A few trivial things inline.
> > 
> > Jonathan
> >   
> > > ---
> > > 
> > > Change from v8:
> > > - hest_addr_lr is now pointing to the error source size and data.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>    
> > Bonus.  I guess you really like this patch :)  
> > > ---
> > >  hw/acpi/ghes.c         | 17 ++++++++++++++++-
> > >  include/hw/acpi/ghes.h |  1 +
> > >  2 files changed, 17 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c
> > > index 3f519ccab90d..34e3364d3fd8 100644
> > > --- a/hw/acpi/ghes.c
> > > +++ b/hw/acpi/ghes.c
> > > @@ -30,6 +30,7 @@
> > >  
> > >  #define ACPI_HW_ERROR_FW_CFG_FILE           "etc/hardware_errors"
> > >  #define ACPI_HW_ERROR_ADDR_FW_CFG_FILE      "etc/hardware_errors_addr"
> > > +#define ACPI_HEST_ADDR_FW_CFG_FILE          "etc/acpi_table_hest_addr"
> > >  
> > >  /* The max size in bytes for one error block */
> > >  #define ACPI_GHES_MAX_RAW_DATA_LENGTH   (1 * KiB)
> > > @@ -261,7 +262,7 @@ static void build_ghes_error_table(GArray *hardware_errors, BIOSLinker *linker,
> > >      }
> > >  
> > >      /*
> > > -     * tell firmware to write hardware_errors GPA into
> > > +     * Tell firmware to write hardware_errors GPA into    
> > 
> > Sneaky tidy up.  No problem with it in general but adding noise here, so if there
> > are others in the series maybe gather them up in a cleanup patch.  
> 
> +1

If Ok, I would prefer to keep this here, as there's no other cleanups
anymore, and writing a patch just for this seems overkill. Besides,
it replicates a comment with a similar content on this patch.

So, instead, if OK to you, I would prefer to add a comment about it at
the patch description.

> >   
> > >       * hardware_errors_addr fw_cfg, once the former has been initialized.
> > >       */
> > >      bios_linker_loader_write_pointer(linker, ACPI_HW_ERROR_ADDR_FW_CFG_FILE, 0,
> > > @@ -355,6 +356,8 @@ void acpi_build_hest(GArray *table_data, GArray *hardware_errors,
> > >  
> > >      acpi_table_begin(&table, table_data);
> > >  
> > > +    int hest_offset = table_data->len;    
> should be unsigned, and better uint32_t
> but we have a zoo wrt type here all over the place.

Changed this one to uint32_t. 

> > Local style looks to be traditional C with definitions at top.  Maybe define
> > hest_offset up a few lines and just set it here?  
> 
> yep, it applies to whole QEMU (i.e. definitions only at the start of the block)

Good to know. That's my personal style too. Yet, I guess I saw somewhere
other places declaring variables in the middle of the code. 

> > > +
> > >      /* Error Source Count */
> > >      build_append_int_noprefix(table_data, num_sources, 4);
> > >      for (i = 0; i < num_sources; i++) {
> > > @@ -362,6 +365,15 @@ void acpi_build_hest(GArray *table_data, GArray *hardware_errors,
> > >      }
> > >  
> > >      acpi_table_end(linker, &table);
> > > +
> > > +    /*
> > > +     * tell firmware to write into GPA the address of HEST via fw_cfg,    
> > 
> > Given the tidy up above, fix this one to have a capital T, or was this
> > where you meant to change it?
> >   
> > > +     * once initialized.
> > > +     */
> > > +    bios_linker_loader_write_pointer(linker,
> > > +                                     ACPI_HEST_ADDR_FW_CFG_FILE, 0,    
> > 
> > Could wrap less and stay under 80 chars as both lines above add up to 70 something
> >   
> > > +                                     sizeof(uint64_t),
> > > +                                     ACPI_BUILD_TABLE_FILE, hest_offset);
> > >  }    
> >   
> 



Thanks,
Mauro

  reply	other threads:[~2025-01-28 10:13 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-22 15:46 [PATCH 00/11] Change ghes to use HEST-based offsets and add support for error inject Mauro Carvalho Chehab
2025-01-22 15:46 ` [PATCH 01/11] acpi/ghes: Prepare to support multiple sources on ghes Mauro Carvalho Chehab
2025-01-23  9:56   ` Jonathan Cameron via
2025-01-23  9:56     ` Jonathan Cameron
2025-01-23  9:56     ` Jonathan Cameron via
2025-01-23 16:48   ` Igor Mammedov
2025-01-22 15:46 ` [PATCH 02/11] acpi/ghes: add a firmware file with HEST address Mauro Carvalho Chehab
2025-01-23 10:02   ` Jonathan Cameron
2025-01-23 10:02     ` Jonathan Cameron via
2025-01-23 11:46     ` Mauro Carvalho Chehab
2025-01-23 17:01     ` Igor Mammedov
2025-01-28 10:12       ` Mauro Carvalho Chehab [this message]
2025-01-28 10:00     ` Mauro Carvalho Chehab
2025-01-28 14:10       ` Jonathan Cameron
2025-01-28 14:10         ` Jonathan Cameron via
2025-01-29 13:33   ` Igor Mammedov
2025-01-22 15:46 ` [PATCH 03/11] acpi/ghes: Use HEST table offsets when preparing GHES records Mauro Carvalho Chehab
2025-01-23 10:29   ` Jonathan Cameron
2025-01-23 10:29     ` Jonathan Cameron via
2025-01-23 18:23     ` Mauro Carvalho Chehab
2025-01-24  9:59       ` Igor Mammedov
2025-01-22 15:46 ` [PATCH 04/11] acpi/generic_event_device: Update GHES migration to cover hest addr Mauro Carvalho Chehab
2025-01-23 10:31   ` Jonathan Cameron
2025-01-23 10:31     ` Jonathan Cameron via
2025-01-24 10:08   ` Igor Mammedov
2025-01-22 15:46 ` [PATCH 05/11] acpi/generic_event_device: add logic to detect if HEST addr is available Mauro Carvalho Chehab
2025-01-23 10:52   ` Jonathan Cameron
2025-01-23 10:52     ` Jonathan Cameron via
2025-01-24 10:23   ` Igor Mammedov
2025-01-28 11:29     ` Mauro Carvalho Chehab
2025-01-29  6:26       ` Mauro Carvalho Chehab
2025-01-22 15:46 ` [PATCH 06/11] acpi/ghes: add a notifier to notify when error data is ready Mauro Carvalho Chehab
2025-01-23 10:52   ` Jonathan Cameron
2025-01-23 10:52     ` Jonathan Cameron via
2025-01-22 15:46 ` [PATCH 07/11] acpi/ghes: Cleanup the code which gets ghes ged state Mauro Carvalho Chehab
2025-01-23 10:54   ` Jonathan Cameron
2025-01-23 10:54     ` Jonathan Cameron via
2025-01-24 12:25   ` Igor Mammedov
2025-01-22 15:46 ` [PATCH 08/11] acpi/generic_event_device: add an APEI error device Mauro Carvalho Chehab
2025-01-24 12:30   ` Igor Mammedov
2025-01-28 17:42     ` Mauro Carvalho Chehab
2025-01-28 17:45       ` Michael S. Tsirkin
2025-01-22 15:46 ` [PATCH 09/11] arm/virt: Wire up a GED error device for ACPI / GHES Mauro Carvalho Chehab
2025-01-23 10:56   ` Jonathan Cameron
2025-01-23 10:56     ` Jonathan Cameron via
2025-01-22 15:46 ` [PATCH 10/11] qapi/acpi-hest: add an interface to do generic CPER error injection Mauro Carvalho Chehab
2025-01-23 11:00   ` Jonathan Cameron
2025-01-23 11:00     ` Jonathan Cameron via
2025-01-24 12:40     ` Igor Mammedov
2025-01-24 12:38   ` Igor Mammedov
2025-01-22 15:46 ` [PATCH 11/11] scripts/ghes_inject: add a script to generate GHES error inject Mauro Carvalho Chehab
2025-01-23 12:10   ` Jonathan Cameron
2025-01-23 12:10     ` Jonathan Cameron via
2025-01-24 12:47 ` [PATCH 00/11] Change ghes to use HEST-based offsets and add support for " 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=20250128111257.74766c82@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 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.