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 5FF8A21962321 for ; Mon, 12 Jun 2017 21:43:03 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id u19so155249516qta.3 for ; Mon, 12 Jun 2017 21:44:17 -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=EkiiPt/gAgRzdEM6gCDoHpUEIDJYwfFZgenkWP3cUow=; b=EtDZ+du3a2FjmhxRd6OWBwoSCV3i6HLY56jFUMjdcDJh6DVT9hhzw8lf0vsusZ3bNs uHpEdjbnsOHa4yW5OIyWCbH+6G4nj/1IYNYovPESZdObXBdiH6K8XAhmAPn73nAWCRmT waGkp1WJQBtRUBbbIwcSSzr3VCozPWzC8+u/U= 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=EkiiPt/gAgRzdEM6gCDoHpUEIDJYwfFZgenkWP3cUow=; b=L4wHrz6+GJf/76vJn8T5+O8kfR1xlbxQ9bl6yl7cWk9iXjOSPpLwwZM0WqZrEbhpVD oDM/7r5EPLPqd0ecgB+iZH+KXduHffL4qmQ2slfoxNQT0k+UHXgrLvSoVmbqX4wj16bW YJWLqkqP1UM5qPE2rSVpWJ86ihWbTUsXjZAIsk70QcZaAWW0zkaM2ZL9EM77/EJyl6dc RrZ2AlInDrZe0A4YJDaobYo6m7mqf4jgcbu7i7776nlDZh4DAMx/twOYyhLW+LYQL5t+ KXCJkEFI80Y7WstreT73kABpjuhkX9T6+iQSd+XuE4szefGlo8CUxsCUCJKgG+Lb0nTh 2+GQ== X-Gm-Message-State: AODbwcBqoIp15uDl5x4Ak8CnGrz5IIycotiZKxgeVe+rfhVyiXvPymJ3 5MSW46quS5EDgOT1zVENzO8tZS/O51IY X-Received: by 10.200.8.13 with SMTP id u13mr65338982qth.233.1497329056743; Mon, 12 Jun 2017 21:44:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.180.135 with HTTP; Mon, 12 Jun 2017 21:44:16 -0700 (PDT) In-Reply-To: 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:44:16 +0800 Message-ID: To: Andrew Fish Cc: Ard Biesheuvel , Jason Liu , edk2-devel@lists.01.org, Leif Lindholm , Haojian Zhuang , Shawn Guo 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:43:03 -0000 Content-Type: text/plain; charset="UTF-8" 2017-06-13 12:25 GMT+08:00 Andrew Fish : > > On Jun 12, 2017, at 9:13 PM, Jun Nie wrote: > > 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? > > > Sure > > type struct { > UINT16 RCA; > UINT8 CardType; > UINT32 OCRData; > ... > > Has different alignment than: > type struct { > UINT16 RCA; > UINT32 CardType; > UINT32 OCRData; > ... > > Both are legal things for the C compiler to due given the type is an enum. > 1st example OCRData starts at offset 4 > 2nd example OCRData starts at offset 8 > > An integer type is not an int. > > Thanks, > > Andrew Fish But I do not care about OCRData. I just care the alignment of ECSDData, which is the last member and I assume it shall be impacted just by the previous member alignment. Does ECSDData alignment cannot be secured with Pad change if enum is the 2nd member? If so, is it safe if I make sure the first member in ECSDData is UINT64? typedef struct { UINT16 RCA; UINT8 CardType; OCR OCRData; CID CIDData; CSD CSDData; + UINT64 Pad; // For 8 bytes alignment of ECSDData ECSD ECSDData; // MMC V4 extended card specific } CARD_INFO; Thanks! 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 > > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > >