On Thu, Apr 1, 2021 at 11:00 AM David Laight <David.Laight@xxxxxxxxxx> 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@xxxxxxxxx> > > > 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. > > > > 1) 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. > > > > 2) 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.
