From: Shannon Zhao <shannon.zhao@linaro.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Andrew Jones <drjones@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Igor Mammedov <imammedo@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 2/2] hw/arm/virt-acpi-build: Add SPCR table
Date: Wed, 17 Jun 2015 09:06:47 +0800 [thread overview]
Message-ID: <5580C827.10600@linaro.org> (raw)
In-Reply-To: <20150616161800-mutt-send-email-mst@redhat.com>
On 2015/6/16 22:19, Michael S. Tsirkin wrote:
> On Tue, Jun 16, 2015 at 09:33:19AM +0800, Shannon Zhao wrote:
>>
>>
>> On 2015/6/16 2:13, Michael S. Tsirkin wrote:
>>> On Mon, Jun 15, 2015 at 05:59:06PM +0100, Peter Maydell wrote:
>>>> On 15 June 2015 at 17:32, Andrew Jones <drjones@redhat.com> wrote:
>>>>> On Mon, Jun 15, 2015 at 06:10:25PM +0200, Michael S. Tsirkin wrote:
>>>>>> On Mon, Jun 15, 2015 at 04:45:58PM +0100, Peter Maydell wrote:
>>>>>>> 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?
>>>>
>>>>>> 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.
>>>>
>>>>> Everything used in the table is either a single byte, or I used le32,
>>>>> Well, I didn't bother for the pci_{device,vendor}_id assignments, as
>>>>> they're 0xffff anyway. I can change those two to make them more explicit,
>>>>> if that's preferred.
>>>>
>>>> Yep, I just looked over the struct definition, so since this
>>>> has been reviewed I'll apply it to target-arm.next.
>>>>
>>>> You could probably make it easier to review and write
>>>> code that has to do these endianness swaps with something
>>>> like
>>>>
>>>> #define acpi_struct_assign(FIELD, VAL) \
>>>> ((FIELD) = \
>>>> __builtin_choose_expr(sizeof(FIELD) == 1, VAL, \
>>>> __builtin_choose_expr(sizeof(FIELD) == 2, cpu_to_le16(VAL), \
>>>> __builtin_choose_expr(sizeof(FIELD) == 4, cpu_to_le32(VAL), \
>>>> __builtin_choose_expr(sizeof(FIELD) == 8, cpu_to_le64(VAL), \
>>>> abort))))
>>>>
>>>> (untested, but based on some code in linux-user/qemu.h).
>>>>
>>>> Then it's always
>>>>
>>>> acpi_struct_assign(spcr->field, value);
>>>>
>>>> whether the field is 1, 2, 4 or 8 bytes.
>>>>
>>>> Not my bit of the codebase though, so I'll leave it to the
>>>> ACPI maintainers to decide how much they like magic macros :-)
>>>>
>>>> thanks
>>>> -- PMM
>>>
>>>
>>> We don't much. One can use build_append_int_noprefix and just avoid
>>> structs altogether.
>>
>> But if we use build_append_int_noprefix, we have to bother about the
>> unused fields of the struct and have lots of
>> build_append_int_noprefix(table, 0, 1/2/4/8).
>
> With a struct you have a bunch of reserved fields - is that very
> different?
>
Not only about the reserved fields, but also the fields which ARM
doesn't use or x86 doesn't use. For example, xpm1a_event_block in struct
AcpiFadtDescriptorRev5_1 is not used for ARM now, if we use
build_append_int_noprefix, we should add lots of
build_append_int_noprefix(table, 0, 1/2/4/8). But if we use struct, we
just need to care them when we define it, rather than every time we use.
>>> We did this for some structures and I'm thinking it's a good direction
>>> generally.
>>>
>>
>> --
>> Shannon
--
Shannon
next prev parent reply other threads:[~2015-06-17 1:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 9:52 [Qemu-devel] [PATCH v3 0/2] ACPI: ARM: add SPCR table Andrew Jones
2015-06-10 9:52 ` [Qemu-devel] [PATCH v3 1/2] ACPI: Add definitions for the " Andrew Jones
2015-06-10 16:16 ` Michael S. Tsirkin
2015-06-11 7:08 ` Igor Mammedov
2015-06-10 9:52 ` [Qemu-devel] [PATCH v3 2/2] hw/arm/virt-acpi-build: Add " Andrew Jones
2015-06-10 16:16 ` Michael S. Tsirkin
2015-06-11 7:09 ` Igor Mammedov
2015-06-15 15:45 ` Peter Maydell
2015-06-15 16:10 ` Michael S. Tsirkin
2015-06-15 16:32 ` Andrew Jones
2015-06-15 16:59 ` Peter Maydell
2015-06-15 18:13 ` Michael S. Tsirkin
2015-06-16 1:33 ` Shannon Zhao
2015-06-16 14:16 ` Igor Mammedov
2015-06-16 14:19 ` Michael S. Tsirkin
2015-06-17 1:06 ` Shannon Zhao [this message]
2015-06-17 6:52 ` Michael S. Tsirkin
2015-06-17 9:42 ` Andrew Jones
2015-06-18 10:28 ` Shannon Zhao
2015-06-18 11:03 ` Andrew Jones
2015-06-18 11:49 ` Shannon Zhao
2015-06-10 16:16 ` [Qemu-devel] [PATCH v3 0/2] ACPI: ARM: add " Michael S. Tsirkin
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=5580C827.10600@linaro.org \
--to=shannon.zhao@linaro.org \
--cc=drjones@redhat.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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).