From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Shiju Jose <shiju.jose@huawei.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 v3 6/7] acpi/ghes: update comments to point to newer ACPI specs
Date: Wed, 31 Jul 2024 08:05:45 +0200 [thread overview]
Message-ID: <20240731080545.7c0dbed7@foz.lan> (raw)
In-Reply-To: <20240730073447-mutt-send-email-mst@kernel.org>
Em Tue, 30 Jul 2024 07:36:32 -0400
"Michael S. Tsirkin" <mst@redhat.com> escreveu:
> On Tue, Jul 30, 2024 at 01:24:30PM +0200, Igor Mammedov wrote:
> > On Mon, 22 Jul 2024 08:45:58 +0200
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> >
> > > There is one reference to ACPI 4.0 and several references
> > > to ACPI 6.x versions.
> > >
> > > Update them to point to ACPI 6.5 whenever possible.
> >
> > when it comes to APCI doc comments, they should point to
> > the 1st (earliest) revision that provides given feature/value/field/table.
>
> Yes. And the motivation is twofold.
> First, guests are built against
> old acpi versions. knowing in which version things appeared
> helps us know which guests support a feature.
Good point, but IMO, a comment like "since: ACPI 4.0" would
be better, as the comment may not reflect the first version
supporting such features, but, instead, when someone added
support to a particular feature set.
> Second, acpi guys keep churning out new versions.
> It makes no sense to try and update to latest one,
> it will soon get out of date again.
True, but having it updated helps people adding new code to
get things right.
Anyway, I got your point, I'll drop this patch.
> > > void acpi_build_hest(GArray *table_data, BIOSLinker *linker,
> > > const char *oem_id, const char *oem_table_id)
> > > {
> > > - AcpiTable table = { .sig = "HEST", .rev = 1,
> > > + AcpiTable table = { .sig = "HEST",
> > > + .rev = 1, /* ACPI 4.0 to 6.4 */
> > > .oem_id = oem_id, .oem_table_id = oem_table_id };
> > >
> > > acpi_table_begin(&table, table_data);
This hunk might still make sense, though. When double-checking the links
against ACPI 6.5, I noticed that HEST now requires .rev = 2.
There are some future incompatibilities, but the current
implementation of acpi/ghes satisfies both rev 1 and ref 2 of HEST.
Also, this is not relevant on Linux, as the revision is not checked
there.
So, currently this is not a problem.
Thanks,
Mauro
next prev parent reply other threads:[~2024-07-31 6:06 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-22 6:45 [PATCH v3 0/7] Add ACPI CPER firmware first error injection for Arm Processor Mauro Carvalho Chehab
2024-07-22 6:45 ` [PATCH v3 1/7] arm/virt: place power button pin number on a define Mauro Carvalho Chehab
2024-07-30 7:25 ` Igor Mammedov
2024-07-30 8:29 ` Peter Maydell
2024-07-30 11:26 ` Igor Mammedov
2024-08-01 13:15 ` Mauro Carvalho Chehab
2024-08-05 14:04 ` Igor Mammedov
2024-08-05 15:22 ` Mauro Carvalho Chehab
2024-07-22 6:45 ` [PATCH v3 2/7] arm/virt: Wire up GPIO error source for ACPI / GHES Mauro Carvalho Chehab
2024-07-26 12:30 ` Jonathan Cameron
2024-07-26 12:30 ` Jonathan Cameron via
2024-07-30 8:36 ` Igor Mammedov
2024-07-31 5:17 ` Mauro Carvalho Chehab
2024-07-22 6:45 ` [PATCH v3 3/7] acpi/ghes: Support GPIO error source Mauro Carvalho Chehab
2024-07-30 8:40 ` Igor Mammedov
2024-08-01 12:56 ` Mauro Carvalho Chehab
2024-08-01 14:32 ` Jonathan Cameron
2024-08-01 14:32 ` Jonathan Cameron via
2024-07-22 6:45 ` [PATCH v3 4/7] acpi/ghes: Add a logic to handle block addresses and FW first ARM processor error injection Mauro Carvalho Chehab
2024-07-25 9:48 ` Markus Armbruster
2024-07-26 12:46 ` Jonathan Cameron
2024-07-26 12:46 ` Jonathan Cameron via
2024-07-29 12:49 ` Mauro Carvalho Chehab
2024-07-29 12:21 ` Mauro Carvalho Chehab
2024-07-29 14:32 ` Markus Armbruster
2024-08-01 14:34 ` Mauro Carvalho Chehab
2024-07-26 12:44 ` Jonathan Cameron via
2024-07-26 12:44 ` Jonathan Cameron
2024-07-26 12:44 ` Jonathan Cameron via
2024-07-29 11:40 ` Mauro Carvalho Chehab
2024-07-30 11:17 ` Igor Mammedov
2024-07-31 7:11 ` Mauro Carvalho Chehab
2024-07-31 8:57 ` Jonathan Cameron
2024-07-31 8:57 ` Jonathan Cameron via
2024-07-31 10:30 ` Mauro Carvalho Chehab
2024-08-01 8:36 ` Igor Mammedov
2024-08-01 14:26 ` Mauro Carvalho Chehab
2024-07-22 6:45 ` [PATCH v3 5/7] target/arm: preserve mpidr value Mauro Carvalho Chehab
2024-07-26 12:50 ` Jonathan Cameron
2024-07-26 12:50 ` Jonathan Cameron via
2024-07-22 6:45 ` [PATCH v3 6/7] acpi/ghes: update comments to point to newer ACPI specs Mauro Carvalho Chehab
2024-07-30 11:24 ` Igor Mammedov
2024-07-30 11:36 ` Michael S. Tsirkin
2024-07-31 6:05 ` Mauro Carvalho Chehab [this message]
2024-07-22 6:45 ` [PATCH v3 7/7] acpi/ghes: extend arm error injection logic Mauro Carvalho Chehab
2024-07-25 10:03 ` Markus Armbruster
2024-07-29 11:18 ` Mauro Carvalho Chehab
2024-07-26 13:22 ` Jonathan Cameron
2024-07-26 13:22 ` Jonathan Cameron via
2024-07-29 11:10 ` Mauro Carvalho Chehab
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=20240731080545.7c0dbed7@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.