summaryrefslogtreecommitdiff
path: root/MdeModulePkg/Core/Dxe/Hand
AgeCommit message (Collapse)AuthorFilesLines
2024-02-06MdeModulePkg: Optimize CoreConnectSingleControllerZhi Jin1-1/+6
CoreConnectSingleController() searches for the Driver Family Override Protocol drivers by looping and checking each Driver Binding Handles. This loop can be skipped by checking if any Driver Family Override Protocol installed in the platform first, to improve the performance. Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Zhi Jin <zhi.jin@intel.com>
2024-02-06MdeModulePkg: Remove handle validation check in CoreGetProtocolInterfaceZhi Jin1-6/+12
CoreGetProtocolInterface() is called by CoreOpenProtocol(), CoreCloseProtocol() and CoreOpenProtocolInformation(). Before CoreOpenProtocol() calls CoreGetProtocolInterface(), the input parameter UserHandle has been already checked for validation. So does CoreCloseProtocol(). Removing the handle validation check in CoreGetProtocolInterface() could improve the performance, as CoreOpenProtocol() is called very frequently. To ensure the assumption that the caller of CoreGetProtocolInterface() must pass in a valid UserHandle that is checked with CoreValidateHandle(), add the parameter check in CoreOpenProtocolInformation(), and declare CoreGetProtocolInterface() as static. Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Zhi Jin <zhi.jin@intel.com>
2023-12-01MdeModulePkg: Optimize CoreInstallMultipleProtocolInterfacesZhi Jin1-17/+72
CoreLocateDevicePath is used in CoreInstallMultipleProtocolInterfaces to check if a Device Path Protocol instance with the same device path is alreay installed. CoreLocateDevicePath is a generic API, and would introduce some unnecessary overhead for such usage. The optimization is: 1. Implement IsDevicePathInstalled to loop all the Device Path Protocols installed and check if any of them matchs the given device path. 2. Replace CoreLocateDevicePath with IsDevicePathInstalled in CoreInstallMultipleProtocolInterfaces. This optimization could save several seconds in PCI enumeration on a system with many PCI devices. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Zhi Jin <zhi.jin@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2023-08-31MdeModulePkg: Fix memory leak in LocateHandleBuffer()Nate DeSimone1-1/+5
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4543 REF: https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-boot-services-locatehandlebuffer CoreLocateHandleBuffer() can in certain cases, return an error and not free an allocated buffer. This scenario occurs if the first call to InternalCoreLocateHandle() returns success and the second call returns an error. On a successful return, LocateHandleBuffer() passes ownership of the buffer to the caller. However, the UEFI specification is not explicit about what the expected ownership of this buffer is in the case of an error. However, it is heavily implied by the code example given in section 7.3.15 of v2.10 of the UEFI specificaton that if LocateHandleBuffer() returns a non-successful status code then the ownership of the buffer does NOT transfer to the caller. This code example explicitly refrains from calling FreePool() if LocateHandleBuffer() returns an error. From a practical standpoint, it is logical to assume that a non-successful status code indicates that no buffer of handles was ever allocated. Indeed, in most error cases, LocateHandleBuffer() does not go far enough to get to the point where a buffer is allocated. Therefore, all existing users of this API must already be coded to support the case of a non-successful status code resulting in an invalid handle buffer being returned. Therefore, this change will not cause any backwards compatibility issues with existing code. In conclusion, this boils down to a fix for a memory leak that also brings the behavior of our LocateHandleBuffer() implementation into alignment with the original intentions of the UEFI specification authors. Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
2021-12-07MdeModulePkg: Apply uncrustify changesMichael Kubacki5-632/+605
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the MdeModulePkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
2021-10-14MdeModulePkg/Core/Dxe: Acquire a lock when iterating gHandleListHua Ma4-41/+64
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3680 This patch fixes the following issue: The global variable gHandleList is a linked list. This list is locked when a entry is added or removed from the list, but there is no lock when iterating this list in function CoreValidateHandle(). It can lead to "Handle.c (76): CR has Bad Signature" assertion if the iterated entry in the list is just removed by other task during iterating. Currently some caller functions of CoreValidateHandle() have CoreAcquireProtocolLock(), but some caller functions of CoreValidateHandle() do not CoreAcquireProtocolLock(). Add CoreAcquireProtocolLock() always when CoreValidateHandle() is called, Also, A lock check is added in the CoreValidateHandle(). Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Hua Ma <hua.ma@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
2021-10-08MdeModulePkg/Core/Dxe: Add lock protection in CoreLocateHandleBuffer()Hua Ma1-13/+51
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3666 Currently, CoreLocateHandleBuffer() follows three steps: 1) get the size of protocol database firstly 2) allocate the buffer based on the size 3) get the protocol database into the buffer There is no lock protection for the whole three steps. If a new protocol added in step 2) by other task, e.g. (event timer handle USB device hotplug). The size of protocol database may be increased and cannot fit into the previous buffer in step 3). The protocol database cannot be returned successfully, EFI_BUFFER_TOO_SMALL error will be returned. This patch adds the lock to protect the whole three steps. It can make sure the correct protocol database be returned. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Hua Ma <hua.ma@intel.com> Reviewed-by: Dandan Bi dandan.bi@intel.com Reviewed-by: Liming Gao gaoliming@byosoft.com.cn
2020-02-19MdeModulePkg: Make retval in UninstallMultipleProtocol follow SpecHeinrich Schuchardt1-6/+14
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1869 The UEFI spec requires that if any error occurs in UninstallMultipleProtocolInterfaces(), EFI_INVALID_PARAMETER is returned and not the return code of UninstallProtocolInterface(). Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
2019-04-09MdeModulePkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney5-35/+5
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 <michael.d.kinney@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
2018-06-28MdeModulePkg: Clean up source filesLiming Gao4-26/+26
1. Do not use tab characters 2. No trailing white space in one line 3. All files must end with CRLF Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2018-06-26MdeModulePkg: Use new added Perf macrosBi, Dandan1-4/+4
Replace old Perf macros with the new added ones. Cc: Liming Gao <liming.gao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-10-09MdeModulePkg/DxeCore: Add comments for the ASSERT to check NULL ptrHao Wu1-1/+9
Commit 8932679df5be046feba30fae80776c5815232a08 adds an ASSERT for checking NULL pointer dereference. The ASSERT added here is for addressing a false positive NULL pointer dereference issue raised from static analysis. This commit adds comments to clarify the reason for using ASSERT as the check. Cc: Star Zeng <star.zeng@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
2017-09-26MdeModulePkg/DxeCore: Add check to ensure no possible NULL ptr derefHao Wu1-0/+1
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-09-22MdeModulePkg/DxeCore: Fixed Interface returned by CoreOpenProtocolAmit Kumar1-13/+23
Change since v4: Revise the patch based on V4 sent by Amit Kumar 1) Only return the corresponding protocol interface in *Interface if the return status is EFI_SUCCESS or EFI_ALREADY_STARTED. 2) Interface is returned unmodified for all error conditions except EFI_UNSUPPORTED and EFI_ALREADY_STARTED, NULL will be returned in *Interface when EFI_UNSUPPORTED and Attributes is not EFI_OPEN_PROTOCOL_TEST_PROTOCOL, the protocol interface will be returned in *Interface when EFI_ALREADY_STARTED. Change since v3: 1) Fixed issue when Attributes = EFI_OPEN_PROTOCOL_TEST_PROTOCOL and Inteface = NULL case. [Reported by:star.zeng at intel.com] Change Since v2: 1) Modified to use EFI_ERROR to get status code Change since v1: 1) Fixed typo protocal to protocol 2) Fixed coding style Cc: Laszlo Ersek <lersek@redhat.com> Cc: Amit Kumar <amit.ak@samsung.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Gabriel Somlo <gsomlo@gmail.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Amit Kumar <amit.ak@samsung.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <gsomlo@gmail.com>
2017-07-18MdeModulePkg/DxeCore: Avoid accessing non-owned memoryRuiyu Ni1-27/+27
The patch fixes two kinds of bugs in DxeCore that accesses memory which might be freed or owned by other modules. The two bugs don't cause functionality issue. 1. CoreValidateHandle() checks whether the handle is valid by validating its signature. The proper way is to check whether the handle is in the handle database. 2. CoreDisconnectControllersUsingProtocolInterface() and CoreOpenProtocol() de-reference Link pointer which is already freed. The proper way is to not de-reference the pointer. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com>
2017-06-27Revert "MdeModulePkg/DxeCore: Fixed Interface returned by CoreOpenProtocol"Star Zeng1-14/+12
This reverts commit 45cfcd8dccf84b8abbc1d6f587fedb5d2037ec79 since it is breaking OVMF platform and also real platforms. REF: https://www.mail-archive.com/edk2-devel@lists.01.org/msg26882.html https://www.mail-archive.com/edk2-devel@lists.01.org/msg26820.html Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com>
2017-06-26MdeModulePkg/DxeCore: Fixed Interface returned by CoreOpenProtocolAmit Kumar1-12/+14
Change since v3: 1) Fixed issue when Attributes = EFI_OPEN_PROTOCOL_TEST_PROTOCOL and Inteface = NULL case. [Reported by:star.zeng at intel.com] Change Since v2: 1) Modified to use EFI_ERROR to get status code Change since v1: 1) Fixed typo protocal to protocol 2) Fixed coding style Modified source code to update Interface as per spec. 1) In case of Protocol is un-supported, interface should be returned NULL. 2) In case of any error, interface should not be modified. 3) In case of Test Protocol, interface is optional. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Amit Kumar <amit.ak@samsung.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-06-23MdeModulePkg: Enhance the debug message for InstallProtocolInterfaceStar Zeng1-6/+8
Current code is using debug message like below for InstallProtocolInterface. InstallProtocolInterface: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX XXX User could not know whether the installation is failed or not by the debug message, for example, the code below does not initialize Handle before calling InstallProtocolInterface, EFI_INVALID_PARAMETER will be returned. EFI_HANDLE Handle; Status = gBS->InstallProtocolInterface ( &Handle, &XXX, EFI_NATIVE_INTERFACE, XXX ); This patch is to add additional debug message if the installation is failed and specific debug message for the case that the input handle is invalid. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-06-21MdeModulePkg: Return invalid param in LocateProtocol for Protocol==NULLStar Zeng1-6/+2
Return EFI_INVALID_PARAMETER in LocateProtocol for Protocol==NULL to follow UEFI 2.7 spec PiSmmCore is also updated as the EFI_SMM_SYSTEM_TABLE2.SmmLocateProtocol is reusing the definition of EFI_LOCATE_PROTOCOL. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2016-10-27MdeModulePkg/Core: Fix typos in commentsGary Lin1-1/+1
- paramters -> parameters - funciton -> function - dependecy -> dependency - evauated -> evaluated - genric -> generic - retore -> restore - Protocl -> Protocol - availible -> available - elasped -> elapsed - sarted -> started - boundry -> boundary - permenent -> permanent - debuging -> debugging - availble -> available Cc: Feng Tian <feng.tian@intel.com> Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Feng Tian <feng.tian@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2016-04-25MdeModulePkg/DxeCore: Avoid assertion in CoreLocateProtocolRuiyu Ni1-2/+5
The patch uses CoreAcquireLockOrFail() instead of CoreAcquireProtocolLock() in CoreLocateProtocol() to avoid assertion when CoreLocateProtocol() is called with the protocol database locked. The issue was found when changing PcdDebugPrintErrorLevel to enable page/pool allocation debug message. Nt32 platform hangs immediately after DxeCore is loaded. Investigation shows the following calling stacks: DxeCore entry point (Install a certain protocol) 0 DxeCore::CoreInstallProtocolInterface // Protocol DB is locked 1 DxeCore::AllocatePool 2 PeiDxeDebugLibReportStatusCode::DebugPrint 3 DxeReportStatusCodeLib::ReportStatusCodeEx // <-------------------| 4 DxeReportStatusCodeLib::InternalGetReportStatusCode | 5 DxeCore::LocateProtocol(StatusCodeRuntimeProtocol) | // Assertion when locking Protocol DB 2nd time | 6 DxeCore::CoreAcquireProtocolLock | 7 PeiDxeDebugLibReportStatusCode::DebugAssert | 8 DxeReportStatusCodeLib::ReportSatusCodeEx // loop begins --------- In frame #6 the assertion is triggered due to the protocol database is already locked. #8 calls #4 and the loop begins. After changing #6 to CoreAcquireLockOrFail(), the assertion is avoided and the loop is broken. With the fix, NT32 can boot to Shell even setting PcdDebugPrintErrorLevel to 0xFFFFFFFF, with all error levels turned on. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2015-09-21MdeModulePkg: Remove event from protocol database only if registeredSamer El-Haj-Mahmoud1-2/+3
In a CloseEvent, an UnregisterProtocolNotify is done unconditionally. There is a penalty associated with searching the protocol database on every CloseEvent and impacts performance, especially during Network IO. Unregister needs to be done only if the Event is for a RegisterProtocolNotify. So extend the ExFlag in IEVENT to a UINT8 and define new flags that can be set to indicate if the Event is part of a group, or registered on a protocol notify. Then in CloseEvent, call UnregisterProtocolNotify only if the register protocol notify flag is set. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@hpe.com> Reviewed-by: Feng Tian <feng.tian@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18517 6f19259b-4bc3-4df7-8a09-765794883524
2014-07-28Update code to support VS2013 tool chain.Eric Dong2-1/+4
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15695 6f19259b-4bc3-4df7-8a09-765794883524
2014-04-01Check the parameter before use it.Eric Dong1-1/+2
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Gao, Liming <liming,gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15425 6f19259b-4bc3-4df7-8a09-765794883524
2013-08-20Add the missing status code in the returned table of ↵Shumin Qiu1-2/+6
InstallMultipleProtocolInterface(). Signed-off-by: Shumin Qiu <shumin.qiu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14571 6f19259b-4bc3-4df7-8a09-765794883524
2012-08-22Add PI1.2.1 SAP2 support and UEFI231B mantis 896lgao41-14/+60
1. Update SecurityManagementLib to support SAP2 and SAP services. 2. Update SecurityStub driver to produce SAP2 and SAP protocol both. 3. Update DxeCore and SmmCore to use SAP2 and SAP service to verify Image. 4. Update DxeCore ConnectController() to use SAP2 service to check user permission. Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Guo Dong <dong.guo@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13660 6f19259b-4bc3-4df7-8a09-765794883524
2012-07-25Fix the typo in InstallMultipleProtocolInterfaces commentsniruiyu1-3/+4
Signed-off-by: Ruiyu Ni<ruiyu.ni@intel.com> Reviewed-by: Liming Gao<liming.gao@intel.com> git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13554 6f19259b-4bc3-4df7-8a09-765794883524
2011-07-06Fix the comments to follow UEFI Spec regarding how to check an EFI_HANDLE is ↵niruiyu2-4/+3
valid/invalid. Signed-off-by: niruiyu Reviewed-by: lgao4 git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11987 6f19259b-4bc3-4df7-8a09-765794883524
2011-05-24Add the DriverFamilyOverride support in DxeCore.niruiyu1-1/+38
Signed-off-by: niruiyu Reviewed-by: lgao4 git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11698 6f19259b-4bc3-4df7-8a09-765794883524
2011-03-16Fix LocateDevicePath() to return proper error status code. It was returning ↵mdkinney1-17/+20
EFI_INVALID_PARAMETER if Device was NULL even if not handles matched the search criteria. The proper behavior is to return EFI_NOT_FOUND if not handles match the search criteria, and only return EFI_INVALID_PARAMETER if at least one match is found and Device is NULL. Also update function header comment block for LocateDevicePath() to match UEFI Specification. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11406 6f19259b-4bc3-4df7-8a09-765794883524
2010-09-16Refine code to make code run safely.ydong101-1/+2
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10880 6f19259b-4bc3-4df7-8a09-765794883524
2010-04-24Update the copyright notice formathhtian5-10/+10
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10420 6f19259b-4bc3-4df7-8a09-765794883524
2010-02-26Add more code robustness check for modules under MdeModulePkg.rsun32-3/+5
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@10108 6f19259b-4bc3-4df7-8a09-765794883524
2010-02-08Remove DEBUG_LOAD for InstallProtocolInterface() to align with PPI ↵qhuang81-5/+5
installation debug message in PeiCore. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9945 6f19259b-4bc3-4df7-8a09-765794883524
2009-09-21Remove the error checking for multi-instance device path since Dxecore has ↵qhuang81-8/+0
been enhanced to handle that. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9295 6f19259b-4bc3-4df7-8a09-765794883524
2009-09-21Enhance DxeCore LocateDevicePath() boot service to handle muli-instance ↵qhuang81-3/+15
device path. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9294 6f19259b-4bc3-4df7-8a09-765794883524
2009-05-11fix the typo in DxeCoreeric_tian1-2/+2
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@8292 6f19259b-4bc3-4df7-8a09-765794883524
2009-02-23Update DxeCore for the performance infrastructure updates: Use Raw sting to ↵qhuang81-4/+4
replace XXX_TOKEN git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@7567 6f19259b-4bc3-4df7-8a09-765794883524
2009-01-21Fix Klocwork warning. We should directly return EFI_INVALID_PARAMETER when ↵eric_tian1-1/+1
BufferSize is NULL. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@7323 6f19259b-4bc3-4df7-8a09-765794883524
2008-12-16Clean up to update the reference of the these macros:qhuang81-5/+5
EFI_SIGNATURE_16 -> SIGNATURE_16 EFI_SIGNATURE_32 -> SIGNATURE_32 EFI_SIGNATURE_64 -> SIGNATURE_64 EFI_FIELD_OFFSET -> OFFSET_OF EFI_MAX_BIT -> MAX_BIT EFI_MAX_ADDRESS -> MAX_ADDRESS These macros are not defined in UEFI spec. It makes more sense to use the equivalent macros in Base.h to avoid alias. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@7056 6f19259b-4bc3-4df7-8a09-765794883524
2008-10-30Measure time spent in Driver Binding Supported() callsmdkinney1-0/+2
Update time measurement of StartImage() calls to properly record the handle of the started Image git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@6292 6f19259b-4bc3-4df7-8a09-765794883524
2008-10-21Fix several coding style violationsqhuang81-6/+6
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@6163 6f19259b-4bc3-4df7-8a09-765794883524
2008-09-23move header files in MdeModulePkg\Core\Dxe except DxeMain.h into their ↵eric_tian5-0/+274
corresponding sub-module directories. It is used to provide good modularity. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@5949 6f19259b-4bc3-4df7-8a09-765794883524
2008-09-17Add VA_END to end the VA_START.qwang121-0/+5
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@5907 6f19259b-4bc3-4df7-8a09-765794883524
2008-09-16CoreHandleProtocol function description should be corrected.eric_tian1-4/+12
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@5903 6f19259b-4bc3-4df7-8a09-765794883524
2008-09-10Fix a bug by adding CoreReleaseProtocolLock.qwang122-2/+3
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@5866 6f19259b-4bc3-4df7-8a09-765794883524
2008-09-091) Update some comment.qwang122-14/+26
2) Add in handle for the out_of_resource cases 3) Add in Done label to clean up the code. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@5853 6f19259b-4bc3-4df7-8a09-765794883524
2008-09-08Change field Handle to type IHANDLE to remove the type casting.qwang121-2/+2
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@5846 6f19259b-4bc3-4df7-8a09-765794883524
2008-09-08Remove NULL_HANDLE. NULL_HANDLE should be replaced with NULL as consistency. ↵qwang122-14/+14
For now, only DXE core is using this macro. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@5836 6f19259b-4bc3-4df7-8a09-765794883524
2008-08-27Clean up DxeCore to remove duplicate memory allocation & device path utility ↵qhuang84-21/+21
services in Library.c.DxeCore should use MemoryAllocationLib & DevicePathLib for these API. Minor cleanup the coding style: #include <DxeMain.h> should be changed to #include "DxeMain.h" since "DxeMain.h" is not pubic header fie. git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@5742 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.1 at 2024-07-30 01:18:08 +0000