[edk2-devel] [PATCH V3 1/3] MdeModulePkg: Extend the support keyboard type of Terminal console

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2186 A common terminal console software Putty support various types of keyboard type, such as normal mode, Linux mode, Xterm R6, Vt400, VT100+ and SCO. Refer to the link:

[edk2-devel] [PATCH V3 3/3] MdeModulePkg/BM_UI: Add the new terminal types to related menu

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2186 Add the new introduced terminal types to related setup menu to change the terminal type from setup. Most platforms would have its own configure setup menu and they need to change it to support these. The new introduced terminal types are

[edk2-devel] [PATCH V3 2/3] MdeModulePkg/TerminalDxe: Extend the terminal console support types

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2186 Extend the support types of terminal console driver. New added types are Linux, XtermR6, VT400 and SCO. Refer to https://www.ssh.com/ssh/putty/putty-manuals/0.68/Chapter4.html#config-funkeys Add the missing VT100+ function keys map. Add

[edk2-devel] [PATCH V3 0/3] MdeModulePkg/TerminalConsole: Extend the support terminal types

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2186 Putty is a very popular terminal tool in windows. So add the whole support terminal keyboard type for it. The new introduced type is Linux, XtermR6, VT400 and SCO. And enhance the support for VT100+. This patch set only add the support of

Re: [edk2-devel] [patch v2 3/5] MdeModulePkg/UefiBootManager: Unload image on EFI_SECURITY_VIOLATION

Reviewed-by: Zhichao Gao Thanks, Zhichao > -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > Dandan Bi > Sent: Wednesday, September 18, 2019 11:06 AM > To: devel@edk2.groups.io > Cc: Wang, Jian J ; Wu, Hao A ; > Ni, Ray ; Gao, Zhichao ; Gao, >

Re: [edk2-devel] [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast

Reviewed-by: Liming Gao >-Original Message- >From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of >Laszlo Ersek >Sent: Wednesday, September 18, 2019 3:49 AM >To: edk2-devel-groups-io >Cc: Gao, Liming ; Kinney, Michael D > >Subject: [edk2-devel] [PATCH 17/35]

Re: [edk2-devel] [patch v2 4/5] MdeModulePkg/PlatformDriOverride: Unload image on EFI_SECURITY_VIOLATION

> -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > Dandan Bi > Sent: Wednesday, September 18, 2019 11:06 AM > To: devel@edk2.groups.io > Cc: Wang, Jian J; Wu, Hao A; Gao, Liming; Laszlo Ersek > Subject: [edk2-devel] [patch v2 4/5]

Re: [edk2-devel] [patch v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: Unload image on EFI_SECURITY_VIOLATION

> -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > Dandan Bi > Sent: Wednesday, September 18, 2019 11:06 AM > To: devel@edk2.groups.io > Cc: Wang, Jian J; Wu, Hao A; Gao, Liming; Laszlo Ersek > Subject: [edk2-devel] [patch v2 2/5]

[edk2-devel] [PATCH v2 0/1] BaseTools: Add more parameter checking for CopyFileOnChange()

This patch is to add directory input parameter type checking and error message output for method CopyFileOnChange. V2: Remove the redundant os.path.exists checking for better performance V1: Initial patch Steven Shi (1): BaseTools: Add more parameter checking for CopyFileOnChange()

[edk2-devel] [PATCH v2 1/1] BaseTools: Add more parameter checking for CopyFileOnChange()

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2193 The current CopyFileOnChange() method in Misc.py does not accept the input SrcFile parameter as a dir, but the method does not check the SrcFile is dir or not. This patch is to add more input parameter type checking and error message output

[edk2-devel] [patch v2 5/5] ShellPkg: Unload image on EFI_SECURITY_VIOLATION

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval, the Image was loaded and an ImageHandle was created with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now. This follows UEFI Spec. But if the caller of LoadImage() doesn't have the option to defer

[edk2-devel] [patch v2 3/5] MdeModulePkg/UefiBootManager: Unload image on EFI_SECURITY_VIOLATION

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval, the Image was loaded and an ImageHandle was created with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now. This follows UEFI Spec. But if the caller of LoadImage() doesn't have the option to defer

[edk2-devel] [patch v2 2/5] MdeModulePkg/DxeCapsuleLibFmp: Unload image on EFI_SECURITY_VIOLATION

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval, the Image was loaded and an ImageHandle was created with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now. This follows UEFI Spec. But if the caller of LoadImage() doesn't have the option to defer

[edk2-devel] [patch v2 0/5] Unload image on EFI_SECURITY_VIOLATION

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992 v2: (1) Just separate the patch in MdeModulePkg into module level, the changes in EmbeddedPkg and ShellPkg are the same with V1. (2) Drop the update in PciBusDxe module in MdeModulePkg since with EFI_SECURITY_VIOLATION returned, the image

[edk2-devel] [patch v2 4/5] MdeModulePkg/PlatformDriOverride: Unload image on EFI_SECURITY_VIOLATION

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval, the Image was loaded and an ImageHandle was created with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now. This follows UEFI Spec. But if the caller of LoadImage() doesn't have the option to defer

[edk2-devel] [patch v2 1/5] EmbeddedPkg: Unload image on EFI_SECURITY_VIOLATION

For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval, the Image was loaded and an ImageHandle was created with a valid EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now. This follows UEFI Spec. But if the caller of LoadImage() doesn't have the option to defer

Re: [edk2-devel] [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning consistent

Reviewed-by: Eric Dong > -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Wednesday, September 18, 2019 3:49 AM > To: edk2-devel-groups-io > Cc: Dong, Eric ; Wu, Hao A ; > Wang, Jian J ; Ni, Ray > Subject: [PATCH 15/35] MdeModulePkg/PiSmmCore: make type

[edk2-devel] [PATCH v3] MinPlatformPkg/TestPointCheckLib: Add check for pointers

In DxeCheckBootVariable.c, add check for BootOrder and Variable that return EFI_NOT_FOUND when they are NULL. In DxeCheckGcd.c, add check for GcdIoMap to ensure it not NULL when allocating memory to what it points to. Cc: Michael Kubacki Cc: Chasel Chiu Cc: Nate DeSimone Cc: Liming Gao

Re: [edk2-devel] [PATCH v2 0/2] *** Add VS2019 Support ***

Hi Liming, The VS2017 is still working fine with this changes, I have verified it with VS2019, VS2017 and VS2015 build, Thanks, Allen > -Original Message- > From: Gao, Liming > Sent: Tuesday, September 17, 2019 10:57 PM > To: devel@edk2.groups.io; Cheng, Ching JenX > > Subject: RE:

Re: [edk2-devel] [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other NSIDs for Admin commands

Hello Tyler, I agree that the UEFI spec can be refined to explicitly mention the below 2 fields: * Input parameter 'NamespaceId' for the PassThru() service * The 'Nsid' field of the EFI_NVM_EXPRESS_COMMAND should match for the ‘PassThru’ service. Best Regards, Hao Wu From: Tyler J Erickson

[edk2-devel] [Patch V3] UefiCpuPkg/CpuExceptionHandlerLib: Fix split lock

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2150 V3 changes: change to mov instruction (non locking instuction) instead of xchg to simplify design. V2 changes: Add xchg 16 bit instructions to handle sgdt and sidt base 63:48 bits and 47:32 bits. Add comment to explain why xchg 64bit isnt

[edk2-devel] Updated Event: TianoCore Design Meeting - APAC/NAMO #cal-invite

BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Groups.io Inc//Groups.io Calendar//EN METHOD:PUBLISH CALSCALE:GREGORIAN BEGIN:VEVENT UID:calendar.14...@groups.io DTSTAMP:20190917T214934Z ORGANIZER;CN=Stephano Cetola:mailto:stephano.cet...@intel.com DTSTART;TZID=America/Los_Angeles:20190404T183000

Re: [edk2-devel] [PATCH v2] MinPlatformPkg/TestPointCheckLib: Add return value when OutTable is NULL

Hi Shenglei, Your explanation makes sense. Reviewed-by: Nate DeSimone Thanks, Nate -Original Message- From: Zhang, Shenglei Sent: Monday, September 16, 2019 7:48 PM To: Desimone, Nathaniel L ; devel@edk2.groups.io Cc: Kubacki, Michael A ; Chiu, Chasel ; Gao, Liming Subject: RE:

[edk2-devel] Updated Event: TianoCore Bug Triage - APAC / NAMO #cal-invite

BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Groups.io Inc//Groups.io Calendar//EN METHOD:PUBLISH CALSCALE:GREGORIAN BEGIN:VEVENT UID:calendar.14...@groups.io DTSTAMP:20190917T214615Z ORGANIZER;CN=Stephano Cetola:mailto:stephano.cet...@intel.com DTSTART;TZID=America/Los_Angeles:20190404T17

[edk2-devel] Cancelled Event: TianoCore Design / Bug Triage - EMEA - Wednesday, 18 September 2019 #cal-cancelled

BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Groups.io Inc//Groups.io Calendar//EN METHOD:CANCEL CALSCALE:GREGORIAN BEGIN:VEVENT STATUS:CANCELLED UID:calendar.15...@groups.io DTSTAMP:20190917T214523Z ORGANIZER;CN=Stephano Cetola:mailto:stephano.cet...@linux.intel.com

Re: [edk2-devel] [PATCH] MinPlatformPkg/TestPointCheckLib: Add check for pointers

Hi Shenglei, You are right, *GcdIoMap will always be NULL but GcdIoMap may not be as the function does not exit early in the case of GcdIoMap being == NULL, sorry I misread. Please make sure you put a space between your closing parenthesis and your opening curly: if (GcdIoMap != NULL) {

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

Andrew, Perhaps we want strict type checking as default, and platforms Or packages that can not build with strict type checking set the define for the relaxed type checking in their DSC files. Mike > -Original Message- > From: devel@edk2.groups.io On > Behalf Of Andrew Fish via

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

> On Sep 17, 2019, at 1:28 PM, Ni, Ray wrote: > > Andrew, > I agree. Your solution is like "use strict;" in Perl language. > (https://perldoc.perl.org/strict.html) > Maybe "STRICT_UEFI_TYPES" without "ER". I don't see any strict in today's > code.  > Ray, I'm flexible on the name, I was

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

Andrew, I agree. Your solution is like "use strict;" in Perl language. (https://perldoc.perl.org/strict.html) Maybe "STRICT_UEFI_TYPES" without "ER". I don't see any strict in today's code.  Thanks, Ray > -Original Message- > From: devel@edk2.groups.io On Behalf Of Andrew Fish > via

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

> On Sep 17, 2019, at 1:06 PM, Ni, Ray wrote: > > Laszlo, > Thank you very much for this work. > They are quite helpful to detect potential issues. > > But without this specific patch being checked in, future break will still > happen. > I don't want it to be checked in ASAP because I know

Re: [edk2-devel] [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration

Reviewed-by: Ray Ni > -Original Message- > From: Laszlo Ersek > Sent: Tuesday, September 17, 2019 12:49 PM > To: edk2-devel-groups-io > Cc: Wu, Hao A ; Wang, Jian J ; > Gao, Liming ; Ni, Ray > ; Gao, Zhichao > Subject: [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol

Re: [edk2-devel] [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration

Reviewed-by: Ray Ni > -Original Message- > From: devel@edk2.groups.io On Behalf Of Laszlo Ersek > Sent: Tuesday, September 17, 2019 12:49 PM > To: edk2-devel-groups-io > Cc: Bi, Dandan ; Dong, Eric ; Wu, > Hao A ; Wang, Jian J > ; Ni, Ray ; Gao, Zhichao > > Subject: [edk2-devel]

Re: [edk2-devel] [PATCH 14/35] MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls

Reviewed-by: Ray Ni > -Original Message- > From: Laszlo Ersek > Sent: Tuesday, September 17, 2019 12:49 PM > To: edk2-devel-groups-io > Cc: Wu, Hao A ; Wang, Jian J ; Ni, > Ray > Subject: [PATCH 14/35] MdeModulePkg: fix > UninstallMultipleProtocolInterfaces() calls > > Unlike the

Re: [edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

Laszlo, Thank you very much for this work. They are quite helpful to detect potential issues. But without this specific patch being checked in, future break will still happen. I don't want it to be checked in ASAP because I know that there are quite a lot of close source code that may get build

Re: [edk2-devel] [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast

Reviewed-by: Ray Ni > -Original Message- > From: Laszlo Ersek > Sent: Tuesday, September 17, 2019 12:49 PM > To: edk2-devel-groups-io > Cc: Andrew Fish ; Justen, Jordan L > ; Ni, Ray > Subject: [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast > > "gTimerEvent" has type

Re: [edk2-devel] [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration

Reviewed-by: Ray Ni > -Original Message- > From: Laszlo Ersek > Sent: Tuesday, September 17, 2019 12:49 PM > To: edk2-devel-groups-io > Cc: Andrew Fish ; Justen, Jordan L > ; Ni, Ray > Subject: [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke > notify registration >

[edk2-devel] [PATCH 34/35] UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT

(This patch is unrelated to the rest of this series; its purpose is to enable building the UefiPayloadPkg DSC files with GCC.) When building "UefiPayloadPkg/UefiPayloadPkgIa32.dsc" with GCC48 for the DEBUG target, the compiler reports that "Entry32" may be used uninitialized in ParseAcpiInfo(),

[edk2-devel] [PATCH 32/35] ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug

The EDK 1 Shell (available at ) has a bug in its EFI_SHELL_ENVIRONMENT2.Execute() implementation that edk2's UefiShellLib has no choice but to work around. Improve the explanation in the code. Also, document the implicit EFI_HANDLE -> (EFI_HANDLE*)

[edk2-devel] [PATCH 17/35] MdePkg/DxeServicesLib: remove bogus cast

The HandleProtocol() boot service takes an EFI_HANDLE, not an (EFI_HANDLE*). Remove the bogus cast in the InternalImageHandleToFvHandle() function. This is a semantic cleanup; there is no change in behavior. Cc: Liming Gao Cc: Michael D Kinney Signed-off-by: Laszlo Ersek --- Notes:

[edk2-devel] [PATCH 21/35] NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list

The SockFreeFoo() callback function for NetbufFromExt() has to match the NET_VECTOR_EXT_FREE prototype, which takes a (VOID*) as callback argument (Arg). EFI_EVENT has nothing to do with NET_VECTOR_EXT_FREE. Fix the SockFreeFoo() parameter list. This change is a no-op in practice. Cc: Jiaxin Wu

[edk2-devel] [PATCH 35/35] UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls

The last parameter of ReserveResourceInGcd() is "ImageHandle", forwarded in turn to gDS->AllocateMemorySpace() or gDS->AllocateIoSpace() as "owner" image handle. But BlDxeEntryPoint() passes "SystemTable" as "ImageHandle". Compilers have not flagged it because EFI_HANDLE (the type of

[edk2-devel] [PATCH 29/35] ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE

The UefiShell*CommandsLib instances have constructor functions that do something like: gHiiHandle = HiiAddPackages (...); ... ShellCommandRegisterCommandName (..., gHiiHandle, ...); and destructor functions that implement the following pattern: HiiRemovePackages (gHiiHandle); The --

[edk2-devel] [PATCH 27/35] SecurityPkg: stop abusing EFI_EVENT for protocol notify registration

EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration", similarly to gBS->RegisterProtocolNotify(). We should pass the address of an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT just happens to be specified as (VOID*), and has nothing to do with the

[edk2-devel] [PATCH 31/35] ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call

In the FileBufferSave() function, we invoke ShellCloseFile() if "Directory Can Not Be Saved". The ShellCloseFile() function takes a (SHELL_FILE_HANDLE*) parameter called "FileHandle", and correctly passes the de-referenced (*FileHandle) to EFI_SHELL_CLOSE_FILE, which takes a SHELL_FILE_HANDLE.

[edk2-devel] [PATCH 25/35] OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call

According to the UEFI spec -- and to the edk2 header "MdePkg/Include/Protocol/EdidOverride.h" too --, EFI_EDID_OVERRIDE_PROTOCOL_GET_EDID takes an (EFI_HANDLE*), and not an EFI_HANDLE, as second parameter ("ChildHandle"). This is probably [*] a bug in the UEFI spec. Given that this CSM module

[edk2-devel] [PATCH 33/35] StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking

The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure that every firmware volume is processed only once (every driver in every firmware volume should be discovered only once). For this, the functions use a linked list. In MdeModulePkg's DXE Core and SMM Core, the key used for

[edk2-devel] [PATCH 19/35] NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces calls

Both the "ControllerHandle" parameter of CloseProtocol() and the "Handle" parameter of UninstallMultipleProtocolInterfaces() have type EFI_HANDLE, not (EFI_HANDLE*). This patch fixes actual bugs. The issues have been dormant likely because they are on error paths. (Or, in case of

[edk2-devel] [PATCH 23/35] OvmfPkg/VirtioNetDxe: fix SignalEvent() call

The SignalEvent() boot service takes an EFI_EVENT, not an (EFI_EVENT*). Fix the call in the notification function of "EFI_SIMPLE_NETWORK_PROTOCOL.WaitForPacket". This is an actual bug. The reason it's never been triggered is likely that the "SNP.WaitForPacket" event is rarely waited for by

[edk2-devel] [PATCH 28/35] ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo

The ShellCommandRunConnect() function passes EFI_HANDLE -- (VOID*) -- objects to ConvertAndConnectControllers(), and ConvertAndConnectControllers() passes those to gBS->OpenProtocol(). Accordingly, ConvertAndConnectControllers() should specify EFI_HANDLE parameter types, not (EFI_HANDLE*) --

[edk2-devel] [PATCH 26/35] SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls

Unlike the InstallMultipleProtocolInterfaces() boot service, which takes an (EFI_HANDLE*) as first parameter, the UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as first parameter. These are actual bugs. They must have remained hidden until now because they are all in

[edk2-devel] [PATCH 30/35] ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE

The TouchFileByHandle() and IsDirectoryEmpty() functions are passed SHELL_FILE_HANDLE parameters, and they use those parameters correctly. However, their parameter lists say EFI_HANDLE. Spell out the right type in the parameter lists. In practice, this change is a no-op (because, quite

[edk2-devel] [PATCH 20/35] NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call

Both NetLibDestroyServiceChild() and EFI_SERVICE_BINDING_DESTROY_CHILD take an EFI_HANDLE for the "ChildHandle" parameter, not an (EFI_HANDLE*). This patch fixes a real bug. Cc: Jiaxin Wu Cc: Siyuan Fu Signed-off-by: Laszlo Ersek --- Notes: possibly only build-tested

[edk2-devel] [PATCH 24/35] OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functions

In the following call tree: PlatformInit () mInstalledPackages = HiiAddPackages () GopInstalled () PopulateForm (PackageList = mInstalledPackages) CreateResolutionOptions (PackageList) HiiSetString (PackageList HiiUpdateForm (PackageList) PlatformDxe passes around an

[edk2-devel] [PATCH 18/35] NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()

NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*). NetLibGetMacAddress() only uses the return value ("SnpHandle") for a NULL-check. Fix the type of "SnpHandle". This patch is a no-op. Cc: Jiaxin Wu Cc: Siyuan Fu Signed-off-by: Laszlo Ersek --- Notes: lightly tested: MAC

[edk2-devel] [PATCH 22/35] OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call

Unlike the InstallMultipleProtocolInterfaces() boot service, which takes an (EFI_HANDLE*) as first parameter, the UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as first parameter. This is an actual bug. It must have remained hidden until now because it's on an error path.

[edk2-devel] [PATCH 12/35] MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify registration

EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require the notification handle to have type (VOID*). The notification handle has nothing to do with the EFI_HANDLE type. This change is a semantic fix; functionally, it's a no-op. Cc: Dandan Bi Cc: Eric Dong Cc: Hao A Wu Cc:

[edk2-devel] [PATCH 13/35] MdeModulePkg: PEI Core: clean up "AprioriFile" handling in FindFileEx()

Clean up two issues around FindFileEx(): - The "AprioriFile" parameter's type differs between the function declaration and the function definition. The correct type is (EFI_PEI_FILE_HANDLE*). - "FfsFileHeader" has type (EFI_FFS_FILE_HEADER*); for clarity, we should cast it explicitly to

[edk2-devel] [PATCH 15/35] MdeModulePkg/PiSmmCore: make type punning consistent

The SmiHandlerRegister() function explicitly casts "SmiHandler" (of type (SMI_HANDLER*)) to EFI_HANDLE, when outputting "DispatchHandle". Apply the same cast in the counterpart function SmiHandlerUnRegister(), which compares multiple "SmiHandler"s against the input "DispatchHandle". This is a

[edk2-devel] [PATCH 08/35] MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of EFI_HII_HANDLE

HiiGetHiiHandles() returns an array of EFI_HII_HANDLEs, not EFI_HANDLEs. HiiGetString() takes an EFI_HII_HANDLE, not an EFI_HANDLE. This change is a no-op in practice; it's a semantic improvement. Cc: Dandan Bi Cc: Eric Dong Cc: Hao A Wu Cc: Jian J Wang Signed-off-by: Laszlo Ersek ---

[edk2-devel] [PATCH 14/35] MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls

Unlike the InstallMultipleProtocolInterfaces() boot service, which takes an (EFI_HANDLE*) as first parameter, the UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as first parameter. These are actual bugs. They must have remained hidden until now because they are on error

[edk2-devel] [PATCH 06/35] EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration

EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require the notification handle to have type (VOID*). The notification handle has nothing to do with the EFI_HANDLE type. This change is a semantic fix; functionally, it's a no-op. Cc: Andrew Fish Cc: Jordan Justen Cc: Ray Ni

[edk2-devel] [PATCH 10/35] MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call

The HiiConstructConfigHdr() function takes the "DriverHandle" parameter in order to fetch the device path from it, and then turn the device path into PATH routing information. The HiiConstructConfigHdr() function is called from VariableCleanupHiiExtractConfig(), which is only installed when

[edk2-devel] [PATCH 16/35] MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly

The BootScriptInsert() and BootScriptLabel() functions take the in/out parameter "Position" as (EFI_S3_BOOT_SCRIPT_POSITION*), and pass it to S3BootScriptMoveLastOpcode() and S3BootScriptLabel(), respectively. The callees take the in/out parameter "Position" as (VOID**). Add explicit casts for

[edk2-devel] [PATCH 04/35] EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in BindingStop()

The 3rd and 4th parameters of the CloseProtocol() call are wrong. Given that we're not dissociating a child controller from a parent controller (= closing a BY_CHILD_CONTROLLER open), but closing a BY_DRIVER open, the 4th parameter (ControllerHandle) should equal the 1st parameter (Handle). It's

[edk2-devel] [PATCH 11/35] MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec bug

The PI spec (v1.7) correctly specifies "EFI_RUNTIME_EVENT_ENTRY.Event" in natural language, but the field type in the structure definition itself is wrong -- it should be EFI_EVENT, not (EFI_EVENT*). This spec bug is likely unfixable for compatibility reasons, and so edk2 works it around already.

[edk2-devel] [PATCH 05/35] EmulatorPkg/DxeTimerLib: drop superfluous cast

"gTimerEvent" has type EFI_EVENT already, drop the superfluous cast. Cc: Andrew Fish Cc: Jordan Justen Cc: Ray Ni Signed-off-by: Laszlo Ersek --- Notes: build-tested only EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[edk2-devel] [PATCH 07/35] MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls

GetModuleInfoFromHandle() takes an EFI_HANDLE -- (VOID*) -- as first parameter, but InsertFpdtRecord() passes (EFI_HANDLE*) -- (VOID**). (VOID**) converts silently to (VOID*), which is why the wrong cast is masked. Note that the *value* that is passed is alright -- therefore this patch does not

[edk2-devel] [PATCH 09/35] MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration

EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration", similarly to gBS->RegisterProtocolNotify(). We should pass the address of an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT just happens to be specified as (VOID*), and has nothing to do with the

[edk2-devel] [PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call

- The 2nd parameter of EFI_SERVICE_BINDING_CREATE_CHILD is: IN OUT EFI_HANDLE *ChildHandle - The 2nd parameter of EFI_SERVICE_BINDING_DESTROY_CHILD is: IN EFI_HANDLE ChildHandle Fix the DestroyChild() call in TcpFastbootTransportStop(). This is an actual bugfix; I don't know why the

[edk2-devel] [PATCH 01/35] DO NOT APPLY: edk2: turn standard handle types into pointers to non-VOID

Unfortunately, the UEFI / PI / Shell specs define a number of handle types as pointers to VOID. This is a design mistake; those types should have been pointers to incomplete union or structure types. Any pointer-to-object type converts implicitly to, and from, pointer-to-void, which prevents

[edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs

Repository: https://github.com/lersek/edk2.git Branch: voidptr The UEFI / PI / Shell specifications define a number of standard types as pointers to VOID. This is arguably a design mistake; those types should have been pointers to distinct incomplete union or structure types. Here's why:

[edk2-devel] [PATCH 02/35] EmbeddedPkg: add missing EFIAPI calling convention specifiers

This patch is unrelated to the rest of the series; it just makes sure that "EmbeddedPkg/EmbeddedPkg.dsc" builds for all platforms advertised in SUPPORTED_ARCHITECTURES (in particular, X64). No functional changes. Cc: Ard Biesheuvel Cc: Leif Lindholm Signed-off-by: Laszlo Ersek --- Notes:

Re: [edk2-devel] [PATCH 0/2] q35: mch: allow to lock down 128K RAM at default SMBASE address

Patchew URL: https://patchew.org/QEMU/20190917130708.10281-1-imamm...@redhat.com/ Hi, This series failed the asan build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN === #!/bin/bash

Re: [edk2-devel] [PATCH 0/2] q35: mch: allow to lock down 128K RAM at default SMBASE address

Patchew URL: https://patchew.org/QEMU/20190917130708.10281-1-imamm...@redhat.com/ Hi, This series failed the docker-mingw@fedora build test. Please find the testing commands and their output below. If you have Docker installed, you can probably reproduce it locally. === TEST SCRIPT BEGIN

Re: [edk2-devel] [PATCH edk2-CCSS 0/3] Coding Standards: add rule for documenting spurious variable assignments

Series Reviewed-by: Michael D Kinney I also agree that the macros would be cleaner, easy to review, and and fewer lines of code without the comment block. If I objected previously, then I have also changed my mind. I agree we can go ahead and push the series in its current form and continue

Re: [edk2-devel] [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other NSIDs for Admin commands

Hi Hao, Sorry for the late reply. I tested and can confirm that if the NSID of the command and the provided NamespaceID as an input match, the commands do go through on the EDK2 driver. This is not the case with a driver built into a motherboard that I have here, as it only accepts values for the

Re: [edk2-devel] [External] Re: [PATCH v1 1/1] Drivers/DisplayLink/DisplayLinkPkg DisplayLinkGop

That's right, the only (current) request was index 0 - that is why it didn't show up. It was a refactoring error. It was picked up when we ported some of the changes back into our "closed source" version of the driver and the unit tests failed. Thanks for pushing this. From: Leif Lindholm

Re: [edk2-devel] [PATCH v1 1/1] Drivers/DisplayLink/DisplayLinkPkg DisplayLinkGop

On Wed, Sep 11, 2019 at 07:42:03AM +, Andy Hayes wrote: > Corrected initialisation of one of data structures used to transmit USB > control messages. Mistake had no practical effects but fixing to be on safe > side. So, was the only request used index 0? Or why didn't this cause an issue?

[edk2-devel] Upcoming Event: TianoCore Design / Bug Triage - EMEA - Wed, 09/18/2019 8:00am-9:00am #cal-reminder

*Reminder:* TianoCore Design / Bug Triage - EMEA *When:* Wednesday, 18 September 2019, 8:00am to 9:00am, (GMT-07:00) America/Los Angeles *Where:* https://zoom.us/j/695893389 View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=503242 ) *Organizer:* Stephano Cetola

Re: [edk2-devel] [PATCH v2 0/2] *** Add VS2019 Support ***

Ching: The change is good. With this change, have you verified VS2017 tool chain? I want to make sure there is no impact on VS2017. Thanks Liming > -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Cheng, > Ching JenX > Sent: Tuesday,

Re: [edk2-devel] [PATCH] MdePkg:Include: Update SmBios header file

Abner: I add my comments. > -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Leif > Lindholm > Sent: Tuesday, September 17, 2019 9:34 PM > To: Abner Chang > Cc: devel@edk2.groups.io; Kinney, Michael D ; > Gao, Liming ; Gilbert Chen > >

[edk2-devel] [staging/branch]: CdePkg - C Development Environment Package

Hi UEFI community, I’d like to introduce the CdePkg to edk2-staging. The package is not yet completed but ready to demonstrate it’s power, probably also for modernFW. A couple of years ago, after an UEFI BIOS project on AMD platform I decided to write my own ANSI C Library for UEFI Shell and

Re: [edk2-devel] [PATCH V2 0/3] MdeModulePkg/TerminalConsole: Extend the support terminal types

Leif: > -Original Message- > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > Sent: Tuesday, September 17, 2019 5:15 PM > To: devel@edk2.groups.io; Zhang, Shenglei > Cc: ard.biesheu...@linaro.org; Wang, Jian J ; Wu, Hao > A ; Ni, Ray ; > Laszlo Ersek ; Gao, Liming ; Gao, >

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 11/22]: BaseTools: BaseTools changes for RISC-V platform.

On Tue, Sep 17, 2019 at 02:08:53PM +0100, Leif Lindholm wrote: > > > Please add the requisite support to the GCC5 profile instead. (Which > > > is not actually for gcc 5, but is effectively GCC5+ - we are still > > > successfully using it with gcc 9.) > > > > I can try to use GCC5 profile but the

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 13/22]: MdePkg/Include: Update SmBios header file.

On Mon, Sep 16, 2019 at 07:01:50AM +, Chang, Abner (HPS SW/FW Technologist) wrote: > > -Original Message- > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > > Sent: Friday, September 6, 2019 12:17 AM > > To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist) > > > >

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 07/22]: MdePkg/BaseIoLibIntrinsic: RISC-V I/O intrinsic functions.

On Mon, Sep 16, 2019 at 05:37:51AM +, Chang, Abner (HPS SW/FW Technologist) wrote: > > -Original Message- > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > > Sent: Thursday, September 5, 2019 10:28 PM > > To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist) > > >

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 04/22]: MdePkg/Include: RISC-V definitions.

On Mon, Sep 16, 2019 at 05:31:40AM +, Chang, Abner (HPS SW/FW Technologist) wrote: > > -Original Message- > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > > Sent: Thursday, September 5, 2019 4:40 AM > > To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist) > > >

Re: [edk2-devel] [PATCH] MdePkg:Include: Update SmBios header file

On Tue, Sep 17, 2019 at 02:24:30PM +0800, Abner Chang wrote: > Update SmBios header file to conform with SMBIOS v3.3.0. Ah, I note SMBIOS 3.3 has not yet been released - so this can not be merged in edk2 master at this point. I did not realise this when I requested you send the patch. However,

[edk2-devel] [PATCH 2/2] tests: q35: MCH: add default SMBASE SMRAM lock test

test lockable SMRAM at default SMBASE feature introduced by commit "q35: implement 128K SMRAM at default SMBASE address" Signed-off-by: Igor Mammedov --- tests/q35-test.c | 105 +++ 1 file changed, 105 insertions(+) diff --git a/tests/q35-test.c

[edk2-devel] [PATCH 0/2] q35: mch: allow to lock down 128K RAM at default SMBASE address

Try #2 using PCI config space of MCH to negotiate/lock SMRAM at 0x3. CC: yingwen.c...@intel.com CC: devel@edk2.groups.io CC: phillip.go...@oracle.com CC: alex.william...@redhat.com CC: jiewen@intel.com CC: jun.nakaj...@intel.com CC: michael.d.kin...@intel.com CC: pbonz...@redhat.com CC:

[edk2-devel] [PATCH 1/2] q35: implement 128K SMRAM at default SMBASE address

Use commit (2f295167e0 q35/mch: implement extended TSEG sizes) for inspiration and (ab)use reserved register in config space at 0x9c offset [*] to extend q35 pci-host with ability to use 128K at 0x3 as SMRAM and hide it (like TSEG) from non-SMM context. Usage: 1: write 0xff in the register

Re: [edk2-devel] [edk2] DxeIpl : create page table, occupied too much memory range

On 09/17/19 13:08, Tiger Liu(BJ-RD) wrote: > Hi, Expert: > I have a question about creating page table. > If a CPU support 48bit physical address line, then creating page tables(Page > size=2MB) will occupy too much memory region. > > Now, developer could only use PcdUse1GPageTable to avoid

[edk2-devel] [edk2] DxeIpl : create page table, occupied too much memory range

Hi, Expert: I have a question about creating page table. If a CPU support 48bit physical address line, then creating page tables(Page size=2MB) will occupy too much memory region. Now, developer could only use PcdUse1GPageTable to avoid occupy too much memory region? Thanks Best wishes,

Re: [edk2-devel] [PATCH V2 1/3] MdeModulePkg: Extend the support keyboard type of Terminal console

On 09/17/19 08:19, Zhichao Gao wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2186 > > A common terminal console software Putty support various types of > keyboard type, such as normal mode, Linux mode, Xterm R6, Vt400, > VT100+ and SCO. Refer to the link: >

Re: [edk2-devel] [PATCH V2 0/3] MdeModulePkg/TerminalConsole: Extend the support terminal types

On Tue, Sep 17, 2019 at 07:17:27AM +, Zhang, Shenglei wrote: > That's my mistake to push the broken > patch(0d85e67714e31e0dbe4241ab2ebb7c423aba174d). > This patch only updates the file guid, which I thought has no risk. So I > didn’t check the build result. > I should double check the new

Re: [edk2-devel] [PATCH] StandaloneMmPkg: make package .DSC file build again

On Mon, 16 Sep 2019 at 19:26, Laszlo Ersek wrote: > > On 09/16/19 17:06, Yao, Jiewen wrote: > > That is correct. > > > > Current trunk only supports ARM system. > > > > I have branch to support x86 - > > https://github.com/jyao1/edk2/tree/StandaloneSmmX86Poc > > But that is not merged into trunk

Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 04/22]: MdePkg/Include: RISC-V definitions.

> -Original Message- > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > Sent: Thursday, September 5, 2019 4:40 AM > To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist) > > Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 04/22]: > MdePkg/Include: RISC-V

Re: [edk2-devel] [PATCH V2 0/3] MdeModulePkg/TerminalConsole: Extend the support terminal types

On Tue, 17 Sep 2019 at 08:17, Zhang, Shenglei wrote: > > Hi Ard, > > That's my mistake to push the broken > patch(0d85e67714e31e0dbe4241ab2ebb7c423aba174d). > This patch only updates the file guid, which I thought has no risk. So I > didn’t check the build result. > I should double check the

Re: [edk2-devel] [PATCH V2 2/3] MdeModulePkg/TerminalDxe: Extend the terminal console support types

> -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > Gao, Zhichao > Sent: Tuesday, September 17, 2019 2:19 PM > To: devel@edk2.groups.io > Cc: Wang, Jian J ; Wu, Hao A ; > Ni, Ray ; Gao, Liming > Subject: [edk2-devel] [PATCH V2 2/3]

Re: [edk2-devel] [Patch] MdeModulePkg SerialDxe.inf: Fix wrong FILE_GUID format

Push @9790f62be1aa5ee9460d4c4ec8c720919523bb62 >-Original Message- >From: Wu, Hao A >Sent: Tuesday, September 17, 2019 2:49 PM >To: Gao, Liming ; devel@edk2.groups.io >Cc: Ni, Ray >Subject: RE: [Patch] MdeModulePkg SerialDxe.inf: Fix wrong FILE_GUID >format > >> -Original

  1   2   >