From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B870C001BB for ; Thu, 1 Apr 2021 18:06:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5B20161130 for ; Thu, 1 Apr 2021 18:06:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237970AbhDASFK (ORCPT ); Thu, 1 Apr 2021 14:05:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236050AbhDARtT (ORCPT ); Thu, 1 Apr 2021 13:49:19 -0400 Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 45371C08EC72; Thu, 1 Apr 2021 06:50:06 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id v25so1834842oic.5; Thu, 01 Apr 2021 06:50:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=obPyz+e6xbd7We+KsT9T0ixM5UyYHDGjsKl1W8VAD1Q=; b=Y9k5poOP2aOMcOVYyJPVznKH3uA/mv6KRYy9/7o9IOuHXs/S70YSMRN8YaCVA18RgO M8jAKe/MCXxMqG9exZ6lEGmPiiV6euSGm8shFEeCVjLJCw2p+RmoUlb5nmGhcBy0bV9B QtGJSCcv9Q/xtcwLTDXBIipVHZ5KE+5KThBbu5Ybs+9KZzY/kl+OMd1j2wLqOlt35ZNz 1JJ3UZhlIOXxHO6PoNW9cd6DB2CfCl147jhLLvxJ4/PG79CkzZo7Yj9uOp5w9Tn7CP+F K1zmyRN1tUN93lXq4VWA+hTTRMr/WHKHTuRpN18nYEeh651fSyTbBcWlbBZQzakHrwxv 8uMw== X-Gm-Message-State: AOAM533OzpDdy1cg3P5X66oDfyLfpFs7zIBMLBRwFMML7w7WREVy5F6d VEf2FF5QtymYQ9pCgzoBzeoz4+SrESrcvoeEX1M= X-Google-Smtp-Source: ABdhPJwyQVp4oAnnyAvoO1xmI2F+tkbmp4RWiyGqaSVTQUrfQWAgb31mo8zgnybKLFuYB5swwjP5Geu1Q8ZqMJofj5k= X-Received: by 2002:aca:5fc3:: with SMTP id t186mr5819440oib.69.1617285005595; Thu, 01 Apr 2021 06:50:05 -0700 (PDT) MIME-Version: 1.0 References: <20210331172210.GA1397554@bjorn-Precision-5520> <100f5a45dae14c77b341b7f1c5ea1db0@AcuMS.aculab.com> In-Reply-To: <100f5a45dae14c77b341b7f1c5ea1db0@AcuMS.aculab.com> From: "Rafael J. Wysocki" Date: Thu, 1 Apr 2021 15:49:52 +0200 Message-ID: Subject: Re: [PATCH v2 04/15] ACPI: table: replace __attribute__((packed)) by __packed To: David Laight Cc: Bjorn Helgaas , Zhang Rui , Xiaofei Tan , "rjw@rjwysocki.net" , "lenb@kernel.org" , "bhelgaas@google.com" , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linuxarm@openeuler.org" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 1, 2021 at 11:00 AM David Laight 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 > > > 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.