On Mon, Jun 15, 2015 at 04:45:58PM +0100, Peter Maydell wrote:
> On 10 June 2015 at 10:52, Andrew Jones <drjo...@redhat.com> wrote:
> > Signed-off-by: Andrew Jones <drjo...@redhat.com>
> > Tested-by: Shannon Zhao <shannon.z...@linaro.org>
> > ---
> > hw/arm/virt-acpi-build.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 42 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> > index a9373ccaca6cb..d5a8b9c0178ea 100644
> > --- a/hw/arm/virt-acpi-build.c
> > +++ b/hw/arm/virt-acpi-build.c
> > @@ -84,6 +84,12 @@ static void acpi_dsdt_add_uart(Aml *scope, const
> > MemMapEntry *uart_memmap,
> > aml_interrupt(AML_CONSUMER, AML_LEVEL, AML_ACTIVE_HIGH,
> > AML_EXCLUSIVE, uart_irq));
> > aml_append(dev, aml_name_decl("_CRS", crs));
> > +
> > + /* The _ADR entry is used to link this device to the UART described
> > + * in the SPCR table, i.e. SPCR.base_address.address == _ADR.
> > + */
> > + aml_append(dev, aml_name_decl("_ADR", aml_int(uart_memmap->base)));
> > +
> > aml_append(scope, dev);
> > }
> >
> > @@ -334,6 +340,38 @@ build_rsdp(GArray *rsdp_table, GArray *linker,
> > unsigned rsdt)
> > }
> >
> > static void
> > +build_spcr(GArray *table_data, GArray *linker, VirtGuestInfo *guest_info)
> > +{
> > + AcpiSerialPortConsoleRedirection *spcr;
> > + const MemMapEntry *uart_memmap = &guest_info->memmap[VIRT_UART];
> > + int irq = guest_info->irqmap[VIRT_UART] + ARM_SPI_BASE;
> > +
> > + spcr = acpi_data_push(table_data, sizeof(*spcr));
> > +
> > + spcr->interface_type = 0x3; /* ARM PL011 UART */
> > +
> > + spcr->base_address.space_id = AML_SYSTEM_MEMORY;
> > + spcr->base_address.bit_width = 8;
> > + spcr->base_address.bit_offset = 0;
> > + spcr->base_address.access_width = 1;
> > + spcr->base_address.address = cpu_to_le64(uart_memmap->base);
> > +
> > + spcr->interrupt_types = (1 << 3); /* Bit[3] ARMH GIC interrupt */
> > + spcr->gsi = cpu_to_le32(irq); /* Global System Interrupt */
>
> I'm still confused about when fields in these ACPI structs
> need to be converted to little-endian, and when they don't.
> Is there a rule-of-thumb I can use when I'm looking at patches?
>
> thanks
> -- PMM
Normally it's all LE unless it's a single byte value.
Did not check this specific table.
We really need to add sparse support to check
endian-ness matches, or re-write it
all using byte_add so there's no duplication of info.
--
MST
