From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D06472095CC40 for ; Mon, 12 Jun 2017 21:11:47 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id u19so154599447qta.3 for ; Mon, 12 Jun 2017 21:13:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xli6Y/Y3Gy+lmYWi+D5nHkStHGElHmSsQ/FKUcFZsQg=; b=WaqEO87Fia5qujGZVwBfS/txDEPtI60sMFF5/BOx2sRVczP2Tz5jdkOBwGhkpHQPkS uuRRHYSInAIs3Jw/bUjDpANXrI+Da3GtPnFJhHK6q5miG0BoqCR903C26qe9+pXY6HTy MYjuA0LQpU52ru3kq+U0dfe/8W4kNfWD/FVKg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xli6Y/Y3Gy+lmYWi+D5nHkStHGElHmSsQ/FKUcFZsQg=; b=AvoqY7Io9CnpxIYklRqpIWefBLbULhzTHD2dgho2ZEhUjfRzvkHq0ZGT8m4IDA0bMm O5seVbJMJmgmdCr55eRGvmAd+grJg0hd+VXDmVjIUf1qx0ePwE9ijJAG/xQGlrCTyyHS Zf9Jln9dVW+NZusIF8BItanPUmdwXiUVGa991M1UJSlUJBae3L2JqDpRH9S6HMymsqh+ TTeMJUcEUFcijazQ4KmpbUoOocue24xbHbnGPE8Sp8Sis5bm1hyoNo5LFQASQYZ3u5gw 3p7Kd/kZPpeG5+ImP7dIVO8UYctv12MBarDzWb8th/vWiXqRl1mVQpg0bVBJwTmFRy8c Uzaw== X-Gm-Message-State: AKS2vOxWmVn6gTSRZoOoNskCAXbKi9jHFodGW9+A5GObaBsOkpIaf5ik Qc2hijb6s5jKUeGXNKkaJA6X8qAiaBMX X-Received: by 10.237.43.134 with SMTP id e6mr54138214qtd.211.1497327181179; Mon, 12 Jun 2017 21:13:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.113.71 with HTTP; Mon, 12 Jun 2017 21:13:00 -0700 (PDT) In-Reply-To: <0C3C4FE2-0357-42D5-8DD2-28C840179A1A@apple.com> References: <1497232768-8993-1-git-send-email-jun.nie@linaro.org> <20170612155315.GK26676@bivouac.eciton.net> <0C3C4FE2-0357-42D5-8DD2-28C840179A1A@apple.com> From: Jun Nie Date: Tue, 13 Jun 2017 12:13:00 +0800 Message-ID: To: Andrew Fish Cc: Leif Lindholm , Jason Liu , edk2-devel@lists.01.org, Shawn Guo , Haojian Zhuang , Ard Biesheuvel Subject: Re: [PATCH v2] EmbeddedPkg/MmcDxe: Add alignment for ECSD data X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 04:11:48 -0000 Content-Type: text/plain; charset="UTF-8" 2017-06-13 12:01 GMT+08:00 Andrew Fish : > >> On Jun 12, 2017, at 7:14 PM, Jun Nie wrote: >> >> 2017-06-12 23:53 GMT+08:00 Leif Lindholm : >>> On Mon, Jun 12, 2017 at 09:59:28AM +0800, Jun Nie wrote: >>>> Add alignment for ECSD data for DMA access. Otherwise >>>> the data is corrupted on Sanechips platform. >>> >>> I never did see a reply to my proposed solution, and the below is not >>> it. Can you explain why you prefer this one? >>> >>> / >>> Leif >> >> Sorry, just see your email because that thread is not highlighted for >> new email in gmail for unknown reason. >> I have concern that "UINT64 VENDOR_SPECIFIC_FIELD[8]" cannot secure >> the ECSD alignment because it is not the first member. Changing the >> first member to "UINT64 RESERVED_1[2]" shall secure the alignment. But >> I preferred Pad method. It is more readable if all ECSD member are >> UINT8 type. It is also more clear to add alignment info in CARD_INFO, >> just before ECSD member. >> I do not get point of Andrew, maybe he share the same concern. >> > > Jun > > typedef enum { > UNKNOWN_CARD, > MMC_CARD, //MMC card > MMC_CARD_HIGH, //MMC Card with High capacity > EMMC_CARD, //eMMC 4.41 card > SD_CARD, //SD 1.1 card > SD_CARD_2, //SD 2.0 or above standard card > SD_CARD_2_HIGH //SD 2.0 or above high capacity card > } CARD_TYPE; > > Per C spec sizeof(CARD_TYPE) can be 1, 2, 4, or 8 (64-bit integer), and it is legal for the compiler to pick any of these. So it is not portable C code to use an enum in a data structure when layout maters. > > Thanks, > > Andrew Fish CARD_TYPE CardType is 2nd member of CARD_INFO, while ECSDData is the last member and I just want to align it to 8 bytes. I had assume pad will be added automatically by compiler if CARD_TYPE is not 8 bytes aligned and UNIT64 type appear in following member. Does enum will impact the later member alignment? Could you help elaborate more about this? Thank you! Jun >> >>> >>>> Contributed-under: TianoCore Contribution Agreement 1.0 >>>> Signed-off-by: Jun Nie >>>> --- >>>> EmbeddedPkg/Universal/MmcDxe/Mmc.h | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/EmbeddedPkg/Universal/MmcDxe/Mmc.h b/EmbeddedPkg/Universal/MmcDxe/Mmc.h >>>> index 8a7d5a3..6e3ab17 100644 >>>> --- a/EmbeddedPkg/Universal/MmcDxe/Mmc.h >>>> +++ b/EmbeddedPkg/Universal/MmcDxe/Mmc.h >>>> @@ -319,6 +319,7 @@ typedef struct { >>>> OCR OCRData; >>>> CID CIDData; >>>> CSD CSDData; >>>> + UINT64 Pad; // For 8 bytes alignment of ECSDData >>>> ECSD ECSDData; // MMC V4 extended card specific >>>> } CARD_INFO; >>>> >>>> -- >>>> 1.9.1 >>>> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >