From: Igor Mammedov <imammedo@redhat.com>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: "Michael S . Tsirkin" <mst@redhat.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Shiju Jose <shiju.jose@huawei.com>,
qemu-arm@nongnu.org, qemu-devel@nongnu.org,
Ani Sinha <anisinha@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 02/13] tests/acpi: virt: allow acpi table changes for a new table: HEST
Date: Thu, 30 Jan 2025 15:38:30 +0100 [thread overview]
Message-ID: <20250130153830.2e4e081d@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <20250130140324.06cdd4bf@foz.lan>
On Thu, 30 Jan 2025 14:03:24 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> Em Wed, 29 Jan 2025 16:03:28 +0100
> Igor Mammedov <imammedo@redhat.com> escreveu:
>
> > On Wed, 29 Jan 2025 09:04:08 +0100
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> >
> > > The DSDT table will also be affected by such change.
> > >
> > > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> >
> > move it right before the patch that would actually make changes to tables (10/13)
>
> Table changes happens on two patches:
>
> - patch 03/13: acpi/ghes: add a firmware file with HEST address
this one shouldn't affect bios tables test as it only checks ACPI and SMBIOS tables,
and hest addr file is not either.
Do you really see test failing on this patch?
> HEST table was added here
>
> - patch 10/13: arm/virt: Wire up a GED error device for ACPI / GHES
>
> DSDT changes happen here.
>
> If the idea is to avoid make check to fail between those two patches,
> we need either to split them on 4 patches (one before/one after each
> change) or do like I did on this series: whitelist before patch 3,
> update after patch 10.
It would be better to group patches that should change ACPI tables
close together so that a pair of whitelist/update could cover it.
However it depends on how many changes are there, i.e. acpi diff
should be digestible for a reader. So there is no hard border here,
just use common sense.
However when the whitelist is covers all series where only few patches
actually result in tables change, that miss-leads the reader since
whitelist patch basically tells 'watch out for changes since this moment'
and 'update' patch declares no more changes should happen.
The same applies to bisection, where closer the gap between
whitelist/update the better if the test case is the trigger.
No need to be fanatical and do it around each patch,
just make it observable (i.e. some small range of commits).
>
> Regards,
> Mauro
>
> >
> >
> > > ---
> > > tests/data/acpi/aarch64/virt/HEST | 0
> > > tests/qtest/bios-tables-test-allowed-diff.h | 2 ++
> > > 2 files changed, 2 insertions(+)
> > > create mode 100644 tests/data/acpi/aarch64/virt/HEST
> > >
> > > diff --git a/tests/data/acpi/aarch64/virt/HEST b/tests/data/acpi/aarch64/virt/HEST
> > > new file mode 100644
> > > index 000000000000..e69de29bb2d1
> > > diff --git a/tests/qtest/bios-tables-test-allowed-diff.h b/tests/qtest/bios-tables-test-allowed-diff.h
> > > index dfb8523c8bf4..46298e38e7b8 100644
> > > --- a/tests/qtest/bios-tables-test-allowed-diff.h
> > > +++ b/tests/qtest/bios-tables-test-allowed-diff.h
> > > @@ -1 +1,3 @@
> > > /* List of comma-separated changed AML files to ignore */
> > > +"tests/data/acpi/aarch64/virt/HEST",
> > > +"tests/data/acpi/aarch64/virt/DSDT",
> >
> > the list in not complete so 'make check-qtest' still fails
> > [12/13] has complete list of changed files
> >
>
>
>
> Thanks,
> Mauro
>
next prev parent reply other threads:[~2025-01-30 14:39 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-29 8:04 [PATCH v2 00/13] Change ghes to use HEST-based offsets and add support for error inject Mauro Carvalho Chehab
2025-01-29 8:04 ` [PATCH v2 01/13] acpi/ghes: Prepare to support multiple sources on ghes Mauro Carvalho Chehab
2025-01-29 13:15 ` Igor Mammedov
2025-01-29 8:04 ` [PATCH v2 02/13] tests/acpi: virt: allow acpi table changes for a new table: HEST Mauro Carvalho Chehab
2025-01-29 15:03 ` Igor Mammedov
2025-01-30 13:03 ` Mauro Carvalho Chehab
2025-01-30 14:38 ` Igor Mammedov [this message]
2025-01-31 16:18 ` Mauro Carvalho Chehab
2025-01-29 8:04 ` [PATCH v2 03/13] acpi/ghes: add a firmware file with HEST address Mauro Carvalho Chehab
2025-01-29 15:23 ` Igor Mammedov
2025-01-31 16:13 ` Mauro Carvalho Chehab
2025-01-29 8:04 ` [PATCH v2 04/13] acpi/ghes: Use HEST table offsets when preparing GHES records Mauro Carvalho Chehab
2025-01-29 14:14 ` Igor Mammedov
2025-01-29 8:04 ` [PATCH v2 05/13] acpi/generic_event_device: Update GHES migration to cover hest addr Mauro Carvalho Chehab
2025-01-29 14:17 ` Igor Mammedov
2025-01-29 8:04 ` [PATCH v2 06/13] acpi/generic_event_device: add logic to detect if HEST addr is available Mauro Carvalho Chehab
2025-01-29 14:46 ` Igor Mammedov
2025-01-29 8:04 ` [PATCH v2 07/13] acpi/ghes: add a notifier to notify when error data is ready Mauro Carvalho Chehab
2025-01-29 8:04 ` [PATCH v2 08/13] acpi/ghes: Cleanup the code which gets ghes ged state Mauro Carvalho Chehab
2025-01-29 14:55 ` Igor Mammedov
2025-01-30 13:44 ` Mauro Carvalho Chehab
2025-01-30 14:48 ` Igor Mammedov
2025-01-29 8:04 ` [PATCH v2 09/13] acpi/generic_event_device: add an APEI error device Mauro Carvalho Chehab
2025-01-29 14:58 ` Igor Mammedov
2025-01-29 8:04 ` [PATCH v2 10/13] arm/virt: Wire up a GED error device for ACPI / GHES Mauro Carvalho Chehab
2025-01-29 8:04 ` [PATCH v2 11/13] qapi/acpi-hest: add an interface to do generic CPER error injection Mauro Carvalho Chehab
2025-01-29 8:04 ` [PATCH v2 12/13] tests/acpi: virt: add a HEST table to aarch64 virt and update DSDT Mauro Carvalho Chehab
2025-01-29 15:29 ` Igor Mammedov
2025-01-31 15:49 ` Mauro Carvalho Chehab
2025-01-31 16:32 ` Igor Mammedov
2025-01-29 8:04 ` [PATCH v2 13/13] scripts/ghes_inject: add a script to generate GHES error inject Mauro Carvalho Chehab
2025-01-29 15:11 ` 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=20250130153830.2e4e081d@imammedo.users.ipa.redhat.com \
--to=imammedo@redhat.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=anisinha@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 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).