From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::242; helo=mail-it0-x242.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 688F32222C246 for ; Tue, 30 Jan 2018 03:47:08 -0800 (PST) Received: by mail-it0-x242.google.com with SMTP id p139so293127itb.1 for ; Tue, 30 Jan 2018 03:52:43 -0800 (PST) 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=OsHP/tKKYIstyGITz0cD2EZOVyXDD65ySttMDdnQ+oQ=; b=EK/2bnHJBWrPWqDcWAbTMVzk0bOk2T2JeHfgZYkwnBmh4GozRdVNEk3shqfl/3H/Eg EFwF72/wDSQZTlEYC1K8UN9zLx8HamNKq2JoX2+DlHu6oStMxVk3wr0juDT6mAKkKeia xb8Va62dAPBR6x5+3eIZ6Zd/1hZttPCiOQukw= 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=OsHP/tKKYIstyGITz0cD2EZOVyXDD65ySttMDdnQ+oQ=; b=cSFyPCMSjmnZTW2LhozMigYcjPwGeheOPBiqMrLYgJLh3xt3+lWk0onsZRGVuLgBnR FSHFCbTEnRJTDWkv4eVWXuPIpyxMUloj3LxmiEv27+pnd+8Gbv1B+eaTlMu/AmGSwpvX xQJss8qjyBLHTsB0w84hukSLnt7np/p2A4rJTiGKiJOfzlhbx246piysgTVGezWafHkF bp751SJc3Qqgm5BumAx6SGpJOmx1iRzAX1+qxTbe59sGguV6P046qHeG2fZojBE1abZ2 PU96G9SVOT+b88348n7jeDRzyNJh4XdcET9SWTx+vjaDLiwnq3gG3f0yABEeIFeO3K2b H3qg== X-Gm-Message-State: AKwxytfxwaSfg5O+Q7HFIXpu9noRdQ199UFF2dHd5A5VigvnbmviTFzi lQH8md47TkfvzFZOAO05auFT6JBUJJ2cnRiMx3/WjA6Uml8= X-Google-Smtp-Source: AH8x225x7FutCdRAGNK1EkPnfc2i9ucZi7gfsReZawE25+iMfPcsnTYSj6mM6ODpYsjK0Hdyc07TiRaQaBBiZ2dYWOc= X-Received: by 10.36.139.134 with SMTP id g128mr1200319ite.59.1517313162341; Tue, 30 Jan 2018 03:52:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.112.13 with HTTP; Tue, 30 Jan 2018 03:52:41 -0800 (PST) In-Reply-To: <20180130114738.7m6e46bx2ug7fa63@bivouac.eciton.net> References: <20180130103240.4669-1-ard.biesheuvel@linaro.org> <20180130110044.ftayhc37kfh6pw27@bivouac.eciton.net> <20180130114738.7m6e46bx2ug7fa63@bivouac.eciton.net> From: Ard Biesheuvel Date: Tue, 30 Jan 2018 11:52:41 +0000 Message-ID: To: Leif Lindholm Cc: "edk2-devel@lists.01.org" Subject: Re: [PATCH edk2-platforms] Silicon/Socionext/SynQuacer: add configurable eMMC support X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 11:47:08 -0000 Content-Type: text/plain; charset="UTF-8" On 30 January 2018 at 11:47, Leif Lindholm wrote: > On Tue, Jan 30, 2018 at 11:14:31AM +0000, Ard Biesheuvel wrote: >> On 30 January 2018 at 11:00, Leif Lindholm wrote: >> > On Tue, Jan 30, 2018 at 10:32:40AM +0000, Ard Biesheuvel wrote: >> >> Implement support for the SynQuacer eMMC controller. This involves an >> >> implementation of the SD/MMC override protocol to handle a couple of >> >> quirks that would otherwise prevent this IP from being driven by the >> >> generic SDHCI driver. >> >> >> >> Also, add a HII page to the PlatformDxe driver that allows eMMC support >> >> to be enabled, and wire it up for both DeveloperBox and EVB. >> >> >> >> Contributed-under: TianoCore Contribution Agreement 1.1 >> >> Signed-off-by: Ard Biesheuvel >> >> --- >> >> Now that the core support for the SD/MMC override protocol is finally >> >> merged, resubmit this again. I dropped Leif's R-b given that I have >> >> now added DeveloperBox, as well as a HII option to enable eMMC. >> > >> > Couple of minor comments/suggestions below and a question. >> > >> >> Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 8 + >> >> Platform/Socionext/DeveloperBox/DeveloperBox.fdf | 7 + >> >> Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.dsc | 8 + >> >> Platform/Socionext/SynQuacerEvalBoard/SynQuacerEvalBoard.fdf | 7 + >> >> Silicon/Socionext/SynQuacer/DeviceTree/SynQuacer.dtsi | 1 - >> >> Silicon/Socionext/SynQuacer/DeviceTree/SynQuacerEvalBoard.dts | 4 - >> >> Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/Emmc.c | 203 ++++++++++++++++++++ >> >> Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.c | 5 + >> >> Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.h | 9 + >> >> Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxe.inf | 4 + >> >> Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni | 6 + >> >> Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.vfr | 8 + >> >> Silicon/Socionext/SynQuacer/Include/Platform/VarStore.h | 6 +- >> >> Silicon/Socionext/SynQuacer/Library/SynQuacerDtbLoaderLib/SynQuacerDtbLoaderLib.c | 23 ++- >> >> Silicon/Socionext/SynQuacer/Library/SynQuacerDtbLoaderLib/SynQuacerDtbLoaderLib.inf | 1 + >> >> 15 files changed, 287 insertions(+), 13 deletions(-) >> >> >> > >> >> +/** >> >> + >> >> + Override function for SDHCI capability bits >> >> + >> >> + @param[in] PassThru A pointer to the >> >> + EFI_SD_MMC_PASS_THRU_PROTOCOL instance. >> >> + @param[in] ControllerHandle The EFI_HANDLE of the controller. >> >> + @param[in] Slot The 0 based slot index. >> >> + @param[in,out] SdMmcHcSlotCapability The SDHCI capability structure. >> >> + >> >> + @retval EFI_SUCCESS The override function completed successfully. >> >> + @retval EFI_NOT_FOUND The specified controller or slot does not exist. >> >> + @retval EFI_INVALID_PARAMETER SdMmcHcSlotCapability is NULL >> >> + >> >> +**/ >> >> +STATIC >> >> +EFI_STATUS >> >> +EFIAPI >> >> +SynQuacerSdMmcCapability ( >> >> + IN EFI_HANDLE ControllerHandle, >> >> + IN UINT8 Slot, >> >> + IN OUT VOID *SdMmcHcSlotCapability >> >> + ) >> >> +{ >> >> + UINT64 Capability; >> >> + >> >> + if (ControllerHandle != mSdMmcControllerHandle || Slot != 0) { >> > >> > This test pattern repeats below, does it suggest a macro? >> > >> >> I don't see how that would clear things up tbh, and the pattern occurs >> only twice >> >> #define IS_OUR_QUIRKY_SDMMC_CONTROLLER(Handle, Slot) \ >> ((Handle) == mSdMmcControllerHandle && (Slot) == 0) >> >> if (!IS_OUR_QUIRKY_SDMMC_CONTROLLER(ControllerHandle, Slot) { >> return EFI_SUCCESS; >> } >> >> I can change it if you want, or add a comment if the condition is not >> self-explanatory enough. > > It's just an awful lot of logical operations on a single line. > 'ControllerHandle != mSdMmcControllerHandle' is reasonably easy to > figure out, but '|| Slot != 0' looks a bit random there. > > A comment would be sufficient. > > Another option would be to reduce the number of logical operations by > two by doing > if (ControllerHandle == mSdMmcControllerHandle && Slot == 0) { > and doing the body inside the if-statement. > > That's a bit uglier in the next function, but I would expect it > follows the paradigm of "handle most likely case first"? > Actually, come to think of it, the slot number is completely redundant. The non-discoverable SDHCI controller we expose only implements a single slot, so something is terribly wrong if ControllerHandle == mSdMmcControllerHandle && Slot != 0. So I will reduce the sequence to if (ControllerHandle != mSdMmcControllerHandle) { return EFI_SUCCESS; } ASSERT (Slot == 0); instead. Ok? >> >> diff --git a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni >> >> index b274d12ed2c6..2eca8bbba8c3 100644 >> >> --- a/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni >> >> +++ b/Silicon/Socionext/SynQuacer/Drivers/PlatformDxe/PlatformDxeHii.uni >> >> @@ -27,3 +27,9 @@ >> >> >> >> #string STR_PCIE_MAX_SPEED_UNLIMITED #language en-US "Unlimited" >> >> #string STR_PCIE_MAX_SPEED_GEN1 #language en-US "Gen1 (2.5 GT/s)" >> >> + >> >> +#string STR_EMMC_ENABLE_PROMPT #language en-US "Enable on-board eMMC" >> >> +#string STR_EMMC_ENABLE_HELP #language en-US "Enable the on-board eMMC for booting and for use by the OS." >> >> + >> >> +#string STR_EMMC_DISABLED #language en-US "Disabled" >> >> +#string STR_EMMC_ENABLED #language en-US "Enabled" >> > >> > Perhaps a random question, but ... >> > Why am I seeing this in cleartext in the patch? Is it really a unicode file? >> >> Given that we support UTF-8 in .uni files these days, and the fact >> that all characters used are in the 7-bit ASCII range, it doesn't >> really make a difference, I guess. > > Fair enough. > > / > Leif