On Thu, Apr 1, 2021 at 11:00 AM David Laight David.Laight@aculab.com wrote:
From: Bjorn Helgaas
Sent: 31 March 2021 18:22
On Wed, Mar 31, 2021 at 11:55:08PM +0800, Zhang Rui wrote:
...
From e18c942855e2f51e814d057fff4dd951cd0d0907 Mon Sep 17 00:00:00 2001 From: Zhang Rui rui.zhang@intel.com Date: Wed, 31 Mar 2021 20:34:13 +0800 Subject: [PATCH] ACPI: tables: FPDT: Fix 64bit alignment issue
Some of the 64bit items in FPDT table may be 32bit aligned. Using __attribute__((packed)) is not needed in this case, fixing it by allowing 32bit alignment for these 64bit items.
Can you please add a spec reference for this? I think it's ACPI v6.3, sec 5.2.23.5, or something close to that.
The exact layout in memory is prescribed by the spec. I think that's basically what "packed" accomplishes. I don't understand why using "aligned" would be preferable. Using "aligned" means things can be at different offsets depending on the starting address of the structure. We always want the identical layout, no matter what the starting address is.
Both 'packed' and 'aligned(4)' remove any structure alignment padding before 64bit items that aren't on an 8 byte boundary. (Because everything else in the structures is naturally aligned.)
The difference is significant on cpu that don't support misaligned addresses. Assuming that the structure is always on a 4n byte boundary (which the ACPI spec probably requires) accesses to the 32-bit fields are always ok. It is only 64-bit fields that must be accessed as two 32-bit memory cycles, not all the fields using multiple single byte cycles.
So what exactly is wrong with using "packed"? It is way easier to understand for a casual reader of the code.