Tianocore/edk2.git/MdeModulePkg/Include/Protocol/SdMmcOverride.h, branch master

MdeModulePkg: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

Replace traditional `#ifndef`/`#define`/`#endif` include guards with `#pragma` once. `#pragma once` is a widely supported preprocessor directive that prevents header files from being included multiple times. It is supported by all toolchains used to build edk2: GCC, Clang/LLVM, and MSVC. Compared to macro-based include guards, `#pragma once`: - Eliminates the risk of macro name collisions or copy/paste errors where two headers inadvertently use the same guard macro. - Eliminate inconsistency in the way include guard macros are named (e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.). - Reduces boilerplate (three lines replaced by one). - Avoids polluting the macro namespace with guard symbols. - Can improve build times as the preprocessor can skip re-opening the file entirely, rather than re-reading it to find the matching `#endif` ("multiple-include optimization"). - Note that some compilers may already optimize traditional include guards, by recognzining the idiomatic pattern. This change is made acknowledging that overall portability of the code will technically be reduced, as `#pragma once` is not part of the C/C++ standards. However, this is considered acceptable given: 1. edk2 already defines a subset of supported compilers in BaseTools/Conf/tools_def.template, all of which have supported `#pragma once` for over two decades. 2. There have been concerns raised to the project about inconsistent include guard naming and potential macro collisions. Approximate compiler support dates: - MSVC: Supported since Visual C++ 4.2 (1996) - GCC: Supported since 3.4 (2004) (http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html) - Clang (LLVM based): Since initial release in 2007 Signed-off-by: Michael Kubacki

MdeModulePkg: Apply uncrustify changes

2021-12-07T17:24:28+00:00

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the MdeModulePkg package Cc: Andrew Fish Cc: Leif Lindholm Cc: Michael D Kinney Signed-off-by: Michael Kubacki Reviewed-by: Liming Gao

MdeModulePkg/SdMmcOverride: Add GetOperatingParam notify phase

2019-07-01T01:19:26+00:00

https://bugzilla.tianocore.org/show_bug.cgi?id=1882 The new notify phase allows platform to configure additional bus parameters in addition to parameters that can already be configured with capability override. Specifically we allow to configure bus width, clock frequency and driver strength. If platform doesn't wish to configure some of the parameters it can left it on default values and driver will assume it's standard behavior with respect to those parameters. The definition of the SD_MMC_BUS_MODE has been extended to incorporate SD card default speed and high speed. Tests on Marvell boards were also performed by Marcin Wojtas : https://edk2.groups.io/g/devel/message/42999 Board 1 (out of tree): SD - OK, MMC - OK Board 2: (Armada80x0McBin): SD - OK, MMC - OK Board 3: (Armada70x0Db): SD - problems, MMC - OK Please note that the problem on Armada70x0Db SD devices are introduced by adding new types of SD bus modes, a subsequent patch within edk2-platforms repository will be proposed to address it. (More details can be referred from the above link.) Signed-off-by: Mateusz Albecki Reviewed-by: Hao A Wu Regression-tested-by: Sumit Garg

MdeModulePkg: Replace BSD License with BSD+Patent License

2019-04-09T17:58:08+00:00

https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney Reviewed-by: Hao Wu Reviewed-by: Jian J Wang

MdeModulePkg/SdMmcPciHcDxe: Allow overriding base clock frequency

2018-11-20T05:46:57+00:00

Some SdMmc host controllers are run by clocks with different frequency than it is reflected in Capabilities Register 1. It is allowed by SDHCI specification ver. 4.2 - if BaseClkFreq field value of the Capability Register 1 is zero, the clock frequency must be obtained via another method. Because the bitfield is only 8 bits wide, a maximum value that could be obtained from hardware is 255MHz. In case the actual frequency exceeds 255MHz, the 8-bit BaseClkFreq member of SD_MMC_HC_SLOT_CAP structure occurs to be not sufficient to be used for setting the clock speed in SdMmcHcClockSupply function. This patch adds new UINT32 array ('BaseClkFreq[]') to SD_MMC_HC_PRIVATE_DATA structure for specifying the input clock speed for each slot of the host controller. All routines that are used for clock configuration are updated accordingly. This patch also adds new IN OUT BaseClockFreq field in the Capability callback of the SdMmcOverride, protocol which allows to update BaseClkFreq value. The patch reuses original commit from edk2-platforms: 20f6f144d3a8 ("Marvell/Drivers: XenonDxe: Allow overriding base clock frequency") Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas Reviewed-by: Ard Biesheuvel Reviewed-by: Hao Wu

MdeModulePkg/SdMmcPciHcDxe: Add SwitchClockFreqPost to SdMmcOverride

2018-11-20T05:46:57+00:00

Some SD Host Controlers need to do additional operations after clock frequency switch. This patch add new callback type to NotifyPhase of the SdMmcOverride protocol. It is called after SdMmcHcClockSupply. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas Reviewed-by: Ard Biesheuvel Reviewed-by: Hao Wu

MdeModulePkg/SdMmcPciHcDxe: Add UhsSignaling to SdMmcOverride protocol

2018-11-20T05:46:57+00:00

Some SD Host Controllers use different values in Host Control 2 Register to select UHS Mode. This patch adds a new UhsSignaling type routine to the NotifyPhase of the SdMmcOverride protocol. UHS signaling configuration is moved to a common, default routine (SdMmcHcUhsSignaling). After it is executed, the protocol producer can override the values if needed. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas Reviewed-by: Ard Biesheuvel Reviewed-by: Hao Wu

MdeModulePkg/SdMmcPciHcDxe: Add an optional parameter in NotifyPhase

2018-11-20T05:46:57+00:00

In order to ensure bigger flexibility in the NotifyPhase routine of the SdMmcOverride protocol, enable using an optional phase-specific data. This will allow to exchange more information between the protocol producer driver and SdMmcPciHcDxe in the newly added callbacks. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas Reviewed-by: Ard Biesheuvel Reviewed-by: Hao Wu

MdeModulePkg: introduce SD/MMC override protocol

2018-01-30T09:25:13+00:00

Many ARM based SoCs have integrated SDHCI controllers, and often, these implementations deviate in subtle ways from the pertinent specifications. On the one hand, these deviations are quite easy to work around, but on the other hand, having a collection of SoC specific workarounds in the generic driver stack is undesirable. So let's introduce an optional SD/MMC override protocol that we can invoke at the appropriate moments in the device initialization. That way, the workaround itself remains platform specific, but we can still use the generic driver stack on such platforms. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Reviewed-by: Hao Wu Reviewed-by: Star Zeng