This series upgrades the ACPI SPCR table for AArch64 virt to revision 4,
adding the UART clock frequency, which was not previously available via ACPI.

Regarding the NamespaceString: following the example of the SPCR table
for RISC-V, I've set it to "." (indicating that there is no device
corresponding to the UART in the ACPI namespace). However, looking
at build_dsdt(), the UART is actually added to the DSDT, as
"\_SB.COM0" (same as RISC-V). Should the NamespaceString be that instead?

Thanks,
Vadim

Signed-off-by: Vadim Chichikalyuk <chichikalyuk@gmail.com>

Vadim Chichikalyuk (3):
  tests: acpi: whitelist expected blobs
  hw: arm: acpi: upgrade SPCR table to revision 4
  tests: acpi: update expected blobs

 hw/arm/virt-acpi-build.c          |  14 ++++++++------
 tests/data/acpi/aarch64/virt/SPCR | Bin 80 -> 90 bytes
 2 files changed, 8 insertions(+), 6 deletions(-)

-- 
2.39.5 (Apple Git-154)

On Sat, 9 Aug 2025 at 22:11, Vadim Chichikalyuk <chichikalyuk@gmail.com> wrote:
>
> This series upgrades the ACPI SPCR table for AArch64 virt to revision 4,
> adding the UART clock frequency, which was not previously available via ACPI.

So, what's the rationale here? QEMU's UART doesn't care about
clocks at all. We provide a clock in the DTB because the kernel
refuses to boot if you don't, but if the ACPI spec didn't even
have a way to pass the clock frequency until rev 4 this obviously
isn't a problem on that side.

thanks
-- PMM

> On 18 Aug 2025, at 18:26, Peter Maydell <peter.maydell@linaro.org> wrote:
> 
> So, what's the rationale here? QEMU's UART doesn't care about
> clocks at all. We provide a clock in the DTB because the kernel
> refuses to boot if you don't, but if the ACPI spec didn't even
> have a way to pass the clock frequency until rev 4 this obviously
> isn't a problem on that side.

The rationale is the same – just as the (Linux?) kernel expects 
a clock frequency if a UART is present in the DTB, guests using 
ACPI may expect a valid value for the clock frequency in the
SPCR record when one is present.

Since we already have to have a notional value in the DTB, it
makes sense to expose the same value via ACPI, too, for 
consistency. The RISC-V virt machine, for example, has it both
in its DTB and ACPI DSDT.

I’ll fix the other patches per your comments if you think this
is worth adding.

Thanks,
Vadim

On Mon, 25 Aug 2025 at 00:00, Vadim Chichikalyuk <chichikalyuk@gmail.com> wrote:
>
>
> > On 18 Aug 2025, at 18:26, Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> > So, what's the rationale here? QEMU's UART doesn't care about
> > clocks at all. We provide a clock in the DTB because the kernel
> > refuses to boot if you don't, but if the ACPI spec didn't even
> > have a way to pass the clock frequency until rev 4 this obviously
> > isn't a problem on that side.
>
> The rationale is the same – just as the (Linux?) kernel expects
> a clock frequency if a UART is present in the DTB, guests using
> ACPI may expect a valid value for the clock frequency in the
> SPCR record when one is present.

But the ACPI spec prior to rev 4 doesn't even provide a
way to specify the clock frequency, so why would a guest
expect it, and how could it do so?

thanks
-- PMM