All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.