Date   
[PATCH 03/35] EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call

Laszlo Ersek
 

- 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 current code doesn't crash=
.
Perhaps the function is never reached in practice? (It could be tied to a=
n
error path.)

Cc: Ard Biesheuvel <ard.biesheuvel@...>
Cc: Leif Lindholm <leif.lindholm@...>
Signed-off-by: Laszlo Ersek <lersek@...>
---

Notes:
build-tested only

EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.=
c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootT=
ransportTcp.c b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/Fastbo=
otTransportTcp.c
index 29f23a82c75f..34f9ba74e4db 100644
--- a/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTranspor=
tTcp.c
+++ b/EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTranspor=
tTcp.c
@@ -503,7 +503,7 @@ TcpFastbootTransportStop (
Status =3D mTcpListener->Configure (mTcpListener, NULL);
ASSERT_EFI_ERROR (Status);
=20
- Status =3D mTcpServiceBinding->DestroyChild (mTcpServiceBinding, &mTcp=
Handle);
+ Status =3D mTcpServiceBinding->DestroyChild (mTcpServiceBinding, mTcpH=
andle);
=20
// Free any data the user didn't pick up
Entry =3D (FASTBOOT_TCP_PACKET_LIST *) GetFirstNode (&mPacketListHead)=
;
--=20
2.19.1.3.g30247aa5d201

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

Laszlo Ersek
 

This patch is unrelated to the rest of the series; it just makes sure tha=
t
"EmbeddedPkg/EmbeddedPkg.dsc" builds for all platforms advertised in
SUPPORTED_ARCHITECTURES (in particular, X64).

No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@...>
Cc: Leif Lindholm <leif.lindholm@...>
Signed-off-by: Laszlo Ersek <lersek@...>
---

Notes:
build-tested only

EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h | 32 +++++++++++=
++++-----
EmbeddedPkg/GdbStub/GdbStubInternal.h | 9 ++++++
EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c | 1 +
EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c | 1 +
EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c | 8 +++++
EmbeddedPkg/MetronomeDxe/Metronome.c | 1 +
6 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h b/EmbeddedP=
kg/Drivers/SataSiI3132Dxe/SataSiI3132.h
index e3db0821c38f..20636574c271 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h
@@ -205,7 +205,9 @@ SataSiI3132DriverBindingStop (
IN EFI_HANDLE *ChildHandleBuffer
);
=20
-EFI_STATUS SiI3132AtaPassThruCommand (
+EFI_STATUS
+EFIAPI
+SiI3132AtaPassThruCommand (
IN SATA_SI3132_INSTANCE *pSataSiI3132Instance,
IN SATA_SI3132_PORT *pSataPort,
IN UINT16 PortMultiplierPort,
@@ -216,7 +218,9 @@ EFI_STATUS SiI3132AtaPassThruCommand (
/**
* EFI ATA Pass Thru Protocol
*/
-EFI_STATUS SiI3132AtaPassThru (
+EFI_STATUS
+EFIAPI
+SiI3132AtaPassThru (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
IN UINT16 PortMultiplierPort,
@@ -224,37 +228,49 @@ EFI_STATUS SiI3132AtaPassThru (
IN EFI_EVENT Event OPTIONAL
);
=20
-EFI_STATUS SiI3132GetNextPort (
+EFI_STATUS
+EFIAPI
+SiI3132GetNextPort (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN OUT UINT16 *Port
);
=20
-EFI_STATUS SiI3132GetNextDevice (
+EFI_STATUS
+EFIAPI
+SiI3132GetNextDevice (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
IN OUT UINT16 *PortMultiplierPort
);
=20
-EFI_STATUS SiI3132BuildDevicePath (
+EFI_STATUS
+EFIAPI
+SiI3132BuildDevicePath (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
IN UINT16 PortMultiplierPort,
IN OUT EFI_DEVICE_PATH_PROTOCOL **DevicePath
);
=20
-EFI_STATUS SiI3132GetDevice (
+EFI_STATUS
+EFIAPI
+SiI3132GetDevice (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN EFI_DEVICE_PATH_PROTOCOL *DevicePath,
OUT UINT16 *Port,
OUT UINT16 *PortMultiplierPort
);
=20
-EFI_STATUS SiI3132ResetPort (
+EFI_STATUS
+EFIAPI
+SiI3132ResetPort (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port
);
=20
-EFI_STATUS SiI3132ResetDevice (
+EFI_STATUS
+EFIAPI
+SiI3132ResetDevice (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
IN UINT16 PortMultiplierPort
diff --git a/EmbeddedPkg/GdbStub/GdbStubInternal.h b/EmbeddedPkg/GdbStub/=
GdbStubInternal.h
index b8346d7a545f..b08159302cfa 100644
--- a/EmbeddedPkg/GdbStub/GdbStubInternal.h
+++ b/EmbeddedPkg/GdbStub/GdbStubInternal.h
@@ -323,6 +323,7 @@ SendError (
Send 'OK' when the function is done executing successfully.
**/
VOID
+EFIAPI
SendSuccess (
VOID
);
@@ -332,6 +333,7 @@ SendSuccess (
Send empty packet to specify that particular command/functionality is n=
ot supported.
**/
VOID
+EFIAPI
SendNotSupported (
VOID
);
@@ -353,6 +355,7 @@ ReadNthRegister (
@param SystemContext Register content at time of the exce=
ption
**/
VOID
+EFIAPI
ReadGeneralRegisters (
IN EFI_SYSTEM_CONTEXT SystemContext
);
@@ -364,6 +367,7 @@ ReadGeneralRegisters (
@param InBuffer This is the input buffer received from g=
db server
**/
VOID
+EFIAPI
WriteNthRegister (
IN EFI_SYSTEM_CONTEXT SystemContext,
IN CHAR8 *InBuffer
@@ -377,6 +381,7 @@ WriteNthRegister (
**/
=20
VOID
+EFIAPI
WriteGeneralRegisters (
IN EFI_SYSTEM_CONTEXT SystemContext,
IN CHAR8 *InBuffer
@@ -391,6 +396,7 @@ WriteGeneralRegisters (
@param *PacketData Pointer to Payload data for the packet
**/
VOID
+EFIAPI
ReadFromMemory (
IN CHAR8 *PacketData
);
@@ -404,6 +410,7 @@ ReadFromMemory (
@param PacketData Pointer to Payload data for the packet
**/
VOID
+EFIAPI
WriteToMemory (
IN CHAR8 *PacketData
);
@@ -418,6 +425,7 @@ WriteToMemory (
**/
=20
VOID
+EFIAPI
ContinueAtAddress (
IN EFI_SYSTEM_CONTEXT SystemContext,
IN CHAR8 *PacketData
@@ -432,6 +440,7 @@ ContinueAtAddress (
@param PacketData Pointer to Payload data for the packet
**/
VOID
+EFIAPI
SingleStep (
IN EFI_SYSTEM_CONTEXT SystemContext,
IN CHAR8 *PacketData
diff --git a/EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c b/Embedd=
edPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c
index c250844eda74..08bba1bbf111 100644
--- a/EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c
+++ b/EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c
@@ -174,6 +174,7 @@ RemoveSpcrTable (
=20
STATIC
VOID
+EFIAPI
OnReadyToBoot (
IN EFI_EVENT Event,
IN VOID *Context
diff --git a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c b/EmbeddedPkg/Dr=
ivers/Lan9118Dxe/Lan9118Dxe.c
index a0fca4d6a335..2138f7576bec 100644
--- a/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
+++ b/EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c
@@ -34,6 +34,7 @@ LAN9118_DEVICE_PATH Lan9118PathTemplate =3D {
**
*/
EFI_STATUS
+EFIAPI
Lan9118DxeEntry (
IN EFI_HANDLE Handle,
IN EFI_SYSTEM_TABLE *SystemTable
diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c b/Em=
beddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
index f6a723adfb28..0e2905c1ebb0 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
@@ -39,6 +39,7 @@ GetSataDevice (
}
=20
EFI_STATUS
+EFIAPI
SiI3132AtaPassThruCommand (
IN SATA_SI3132_INSTANCE *SataSiI3132Instance,
IN SATA_SI3132_PORT *SataPort,
@@ -310,6 +311,7 @@ SiI3132AtaPassThruCommand (
=20
**/
EFI_STATUS
+EFIAPI
SiI3132AtaPassThru (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
@@ -371,6 +373,7 @@ SiI3132AtaPassThru (
=20
**/
EFI_STATUS
+EFIAPI
SiI3132GetNextPort (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN OUT UINT16 *Port
@@ -442,6 +445,7 @@ SiI3132GetNextPort (
=20
**/
EFI_STATUS
+EFIAPI
SiI3132GetNextDevice (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
@@ -523,6 +527,7 @@ SiI3132GetNextDevice (
=20
**/
EFI_STATUS
+EFIAPI
SiI3132BuildDevicePath (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
@@ -601,6 +606,7 @@ SiI3132BuildDevicePath (
port number does not exist.
**/
EFI_STATUS
+EFIAPI
SiI3132GetDevice (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN EFI_DEVICE_PATH_PROTOCOL *DevicePath,
@@ -717,6 +723,7 @@ SiI3132HwResetPort (
=20
**/
EFI_STATUS
+EFIAPI
SiI3132ResetPort (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port
@@ -772,6 +779,7 @@ SiI3132ResetPort (
=20
**/
EFI_STATUS
+EFIAPI
SiI3132ResetDevice (
IN EFI_ATA_PASS_THRU_PROTOCOL *This,
IN UINT16 Port,
diff --git a/EmbeddedPkg/MetronomeDxe/Metronome.c b/EmbeddedPkg/Metronome=
Dxe/Metronome.c
index 579332169507..13db25168fac 100644
--- a/EmbeddedPkg/MetronomeDxe/Metronome.c
+++ b/EmbeddedPkg/MetronomeDxe/Metronome.c
@@ -110,6 +110,7 @@ EFI_HANDLE gMetronomeHandle =3D NULL;
=20
**/
EFI_STATUS
+EFIAPI
MetronomeInitialize (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
--=20
2.19.1.3.g30247aa5d201

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

Laszlo Ersek
 

Unfortunately, the UEFI / PI / Shell specs define a number of handle type=
s
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 compilers from catching at least the following two types o=
f
mistakes:

- mixing up one handle type with another (for example, EFI_HANDLE with
EFI_EVENT),

- getting the depth of indirection wrong (for example, mixing up
(EFI_HANDLE*) with EFI_HANDLE).

In order to root out such mistakes in the edk2 codebase, introduce
incomplete structure types with unique tags, such as:

struct EFI_FOOBAR_OBJECT;
typedef struct EFI_FOOBAR_OBJECT *EFI_FOOBAR_HANDLE;

replacing the spec mandated

typedef VOID *EFI_FOOBAR_HANDLE;

(For some types, such as:

- EFI_ACPI_HANDLE,
- EFI_EVENT,
- EFI_FONT_HANDLE,
- EFI_HANDLE,
- EFI_HII_HANDLE,
- EFI_S3_BOOT_SCRIPT_POSITION,
- SHELL_FILE_HANDLE,

we connect the actual complete type (the internal, implementation-specifi=
c
type) to the typedef. Some of these also demonstrate how the code could
have looked in practice if the specs had used proper opaque (=3Dincomplet=
e)
types.)

Then, unleash "build" on the package DSC files. This causes the compiler
to warn about incompatible pointer assignments, and to stop the build.

The rest of the series addresses the resultant warnings. Each patch
belongs in one of two categories:

- semantic cleanups (no functional / behavioral changes),
- actual bugfixes.

As the subject line of this patch states, this specific patch is *not*
meant to be applied. It is just a "what if" patch that temporarily
isolates the standard types from each other, the way the specs should
have, so that the compiler have more information to work with.

Cc: Achin Gupta <achin.gupta@...>
Cc: Andrew Fish <afish@...>
Cc: Anthony Perard <anthony.perard@...>
Cc: Ard Biesheuvel <ard.biesheuvel@...>
Cc: Benjamin You <benjamin.you@...>
Cc: Chao Zhang <chao.b.zhang@...>
Cc: Dandan Bi <dandan.bi@...>
Cc: David Woodhouse <dwmw2@...>
Cc: Eric Dong <eric.dong@...>
Cc: Guo Dong <guo.dong@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Jaben Carsey <jaben.carsey@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Jian Wang <jian.j.wang@...>
Cc: Jiaxin Wu <jiaxin.wu@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jordan Justen <jordan.l.justen@...>
Cc: Julien Grall <julien.grall@...>
Cc: Leif Lindholm <leif.lindholm@...>
Cc: Liming Gao <liming.gao@...>
Cc: Maurice Ma <maurice.ma@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Ray Ni <ray.ni@...>
Cc: Siyuan Fu <@sfu5>
Cc: Supreeth Venkatesh <supreeth.venkatesh@...>
Cc: Zhichao Gao <zhichao.gao@...>
Signed-off-by: Laszlo Ersek <lersek@...>
---
MdePkg/Include/Pi/PiPeiCis.h | 6 ++++--
MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h | 3 ++-
MdePkg/Include/Protocol/Bis.h | 3 ++-
MdePkg/Include/Protocol/Eap.h | 3 ++-
MdePkg/Include/Protocol/HiiFont.h | 3 +--
MdePkg/Include/Protocol/MmMp.h | 3 ++-
MdePkg/Include/Protocol/S3SaveState.h | 2 +-
MdePkg/Include/Protocol/Shell.h | 3 ++-
MdePkg/Include/Protocol/UserManager.h | 9 ++++++---
MdePkg/Include/Uefi/UefiBaseType.h | 6 ++++--
MdePkg/Include/Uefi/UefiInternalFormRepresentation.h | 3 ++-
MdeModulePkg/Core/Dxe/Event/Event.h | 2 +-
MdeModulePkg/Core/Dxe/Hand/Handle.h | 2 +-
MdeModulePkg/Core/PiSmmCore/PiSmmCore.h | 2 +-
MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h | 2 +-
MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h | 2 +-
StandaloneMmPkg/Core/StandaloneMmCore.h | 2 +-
17 files changed, 34 insertions(+), 22 deletions(-)

diff --git a/MdePkg/Include/Pi/PiPeiCis.h b/MdePkg/Include/Pi/PiPeiCis.h
index d9d4ed7d413a..3e9e82b62ae9 100644
--- a/MdePkg/Include/Pi/PiPeiCis.h
+++ b/MdePkg/Include/Pi/PiPeiCis.h
@@ -18,12 +18,14 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
///
/// The handles of EFI FV.
///
-typedef VOID *EFI_PEI_FV_HANDLE;
+struct EFI_PEI_FV_OBJECT;
+typedef struct EFI_PEI_FV_OBJECT *EFI_PEI_FV_HANDLE;
=20
///
/// The handles of EFI FFS.
///
-typedef VOID *EFI_PEI_FILE_HANDLE;
+struct EFI_PEI_FILE_OBJECT;
+typedef struct EFI_PEI_FILE_OBJECT *EFI_PEI_FILE_HANDLE;
=20
///
/// Declare the forward reference data structure for EFI_PEI_SERVICE.
diff --git a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h b/MdePk=
g/Include/Protocol/AcpiSystemDescriptionTable.h
index a8e0b24c6c8d..8a1863f3e03d 100644
--- a/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
+++ b/MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
@@ -16,7 +16,8 @@
{ 0xeb97088e, 0xcfdf, 0x49c6, { 0xbe, 0x4b, 0xd9, 0x6, 0xa5, 0xb2, 0xe=
, 0x86 }}
=20
typedef UINT32 EFI_ACPI_TABLE_VERSION;
-typedef VOID *EFI_ACPI_HANDLE;
+struct EFI_ACPI_OBJECT;
+typedef struct EFI_ACPI_OBJECT *EFI_ACPI_HANDLE;
=20
#define EFI_ACPI_TABLE_VERSION_NONE (1 << 0)
#define EFI_ACPI_TABLE_VERSION_1_0B (1 << 1)
diff --git a/MdePkg/Include/Protocol/Bis.h b/MdePkg/Include/Protocol/Bis.=
h
index 2be6718f4bc2..8eca94512d03 100644
--- a/MdePkg/Include/Protocol/Bis.h
+++ b/MdePkg/Include/Protocol/Bis.h
@@ -37,7 +37,8 @@ typedef struct _EFI_BIS_PROTOCOL EFI_BIS_PROTOCOL;
//
// Basic types
//
-typedef VOID *BIS_APPLICATION_HANDLE;
+struct BIS_APPLICATION_OBJECT;
+typedef struct BIS_APPLICATION_OBJECT *BIS_APPLICATION_HANDLE;
typedef UINT16 BIS_ALG_ID;
typedef UINT32 BIS_CERT_ID;
=20
diff --git a/MdePkg/Include/Protocol/Eap.h b/MdePkg/Include/Protocol/Eap.=
h
index 203d0f40b0dd..06584ef409d0 100644
--- a/MdePkg/Include/Protocol/Eap.h
+++ b/MdePkg/Include/Protocol/Eap.h
@@ -28,7 +28,8 @@ typedef struct _EFI_EAP_PROTOCOL EFI_EAP_PROTOCOL;
/// Type for the identification number assigned to the Port by the
/// System in which the Port resides.
///
-typedef VOID * EFI_PORT_HANDLE;
+struct EFI_PORT_OBJECT;
+typedef struct EFI_PORT_OBJECT *EFI_PORT_HANDLE;
=20
///
/// EAP Authentication Method Type (RFC 3748)
diff --git a/MdePkg/Include/Protocol/HiiFont.h b/MdePkg/Include/Protocol/=
HiiFont.h
index 1f2e321ea4e2..450cad9ada70 100644
--- a/MdePkg/Include/Protocol/HiiFont.h
+++ b/MdePkg/Include/Protocol/HiiFont.h
@@ -19,8 +19,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
{ 0xe9ca4775, 0x8657, 0x47fc, { 0x97, 0xe7, 0x7e, 0xd6, 0x5a, 0x8, 0x43,=
0x24 } }
=20
typedef struct _EFI_HII_FONT_PROTOCOL EFI_HII_FONT_PROTOCOL;
-
-typedef VOID *EFI_FONT_HANDLE;
+typedef LIST_ENTRY *EFI_FONT_HANDLE;
=20
///
/// EFI_HII_OUT_FLAGS.
diff --git a/MdePkg/Include/Protocol/MmMp.h b/MdePkg/Include/Protocol/MmM=
p.h
index beace1386cbe..cd4e0db47e08 100644
--- a/MdePkg/Include/Protocol/MmMp.h
+++ b/MdePkg/Include/Protocol/MmMp.h
@@ -36,7 +36,8 @@
//
// Completion token
//
-typedef VOID* MM_COMPLETION;
+struct MM_COMPLETION_OBJECT;
+typedef struct MM_COMPLETION_OBJECT* MM_COMPLETION;
=20
typedef struct {
MM_COMPLETION Completion;
diff --git a/MdePkg/Include/Protocol/S3SaveState.h b/MdePkg/Include/Proto=
col/S3SaveState.h
index c1b8f8b9e08d..235c36be6737 100644
--- a/MdePkg/Include/Protocol/S3SaveState.h
+++ b/MdePkg/Include/Protocol/S3SaveState.h
@@ -21,7 +21,7 @@
{ 0xe857caf6, 0xc046, 0x45dc, { 0xbe, 0x3f, 0xee, 0x7, 0x65, 0xfb, 0=
xa8, 0x87 }}
=20
=20
-typedef VOID *EFI_S3_BOOT_SCRIPT_POSITION;
+typedef UINT8 *EFI_S3_BOOT_SCRIPT_POSITION;
=20
typedef struct _EFI_S3_SAVE_STATE_PROTOCOL EFI_S3_SAVE_STATE_PROTOCOL;
=20
diff --git a/MdePkg/Include/Protocol/Shell.h b/MdePkg/Include/Protocol/Sh=
ell.h
index cfb7878228c5..bf791792b4f2 100644
--- a/MdePkg/Include/Protocol/Shell.h
+++ b/MdePkg/Include/Protocol/Shell.h
@@ -11,12 +11,13 @@
#define __EFI_SHELL_PROTOCOL_H__
=20
#include <Guid/FileInfo.h>
+#include <Protocol/SimpleFileSystem.h>
=20
#define EFI_SHELL_PROTOCOL_GUID \
{ \
0x6302d008, 0x7f9b, 0x4f30, { 0x87, 0xac, 0x60, 0xc9, 0xfe, 0xf5, 0xda=
, 0x4e } \
}
-typedef VOID *SHELL_FILE_HANDLE;
+typedef EFI_FILE_PROTOCOL *SHELL_FILE_HANDLE;
=20
typedef enum {
///
diff --git a/MdePkg/Include/Protocol/UserManager.h b/MdePkg/Include/Proto=
col/UserManager.h
index 26ac4955f1ec..9abfcffbeebf 100644
--- a/MdePkg/Include/Protocol/UserManager.h
+++ b/MdePkg/Include/Protocol/UserManager.h
@@ -24,8 +24,10 @@
0xbaf1e6de, 0x209e, 0x4adb, { 0x8d, 0x96, 0xfd, 0x8b, 0x71, 0xf3, 0x=
f6, 0x83 } \
}
=20
-typedef VOID *EFI_USER_PROFILE_HANDLE;
-typedef VOID *EFI_USER_INFO_HANDLE;
+struct EFI_USER_PROFILE_OBJECT;
+typedef struct EFI_USER_PROFILE_OBJECT *EFI_USER_PROFILE_HANDLE;
+struct EFI_USER_INFO_OBJECT;
+typedef struct EFI_USER_INFO_OBJECT *EFI_USER_INFO_HANDLE;
=20
///
/// The attributes of the user profile information.
@@ -157,7 +159,8 @@ typedef CHAR16 *EFI_USER_INFO_CREDENTIAL_PROVIDER_NAM=
E;
/// Biometric Exchange Formats Framework) specification.
///
#define EFI_USER_INFO_CBEFF_RECORD 0x0B
-typedef VOID *EFI_USER_INFO_CBEFF;
+struct EFI_USER_INFO_CBEFF_OBJECT;
+typedef struct EFI_USER_INFO_CBEFF_OBJECT *EFI_USER_INFO_CBEFF;
///
/// Indicates how close of a match the fingerprint must be in order to b=
e considered a match.
///
diff --git a/MdePkg/Include/Uefi/UefiBaseType.h b/MdePkg/Include/Uefi/Uef=
iBaseType.h
index a62f13dd064f..be5831991b52 100644
--- a/MdePkg/Include/Uefi/UefiBaseType.h
+++ b/MdePkg/Include/Uefi/UefiBaseType.h
@@ -28,11 +28,13 @@ typedef RETURN_STATUS EFI_STATUS;
///
/// A collection of related interfaces.
///
-typedef VOID *EFI_HANDLE;
+struct EFI_OBJECT;
+typedef struct EFI_OBJECT *EFI_HANDLE;
///
/// Handle to an event structure.
///
-typedef VOID *EFI_EVENT;
+struct EFI_EVENT_OBJECT;
+typedef struct EFI_EVENT_OBJECT *EFI_EVENT;
///
/// Task priority level.
///
diff --git a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h b/MdePk=
g/Include/Uefi/UefiInternalFormRepresentation.h
index 4a1346a599d0..93bf9e9e0f13 100644
--- a/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
+++ b/MdePkg/Include/Uefi/UefiInternalFormRepresentation.h
@@ -20,7 +20,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
///
/// The following types are currently defined:
///
-typedef VOID* EFI_HII_HANDLE;
+struct EFI_HII_OBJECT;
+typedef struct EFI_HII_OBJECT* EFI_HII_HANDLE;
typedef CHAR16* EFI_STRING;
typedef UINT16 EFI_IMAGE_ID;
typedef UINT16 EFI_QUESTION_ID;
diff --git a/MdeModulePkg/Core/Dxe/Event/Event.h b/MdeModulePkg/Core/Dxe/=
Event/Event.h
index 8141c5003eec..42590cb1dd09 100644
--- a/MdeModulePkg/Core/Dxe/Event/Event.h
+++ b/MdeModulePkg/Core/Dxe/Event/Event.h
@@ -37,7 +37,7 @@ typedef struct {
} TIMER_EVENT_INFO;
=20
#define EVENT_SIGNATURE SIGNATURE_32('e','v','n','t')
-typedef struct {
+typedef struct EFI_EVENT_OBJECT {
UINTN Signature;
UINT32 Type;
UINT32 SignalCount;
diff --git a/MdeModulePkg/Core/Dxe/Hand/Handle.h b/MdeModulePkg/Core/Dxe/=
Hand/Handle.h
index 83eb2b9f3afe..1f1ab3274e8a 100644
--- a/MdeModulePkg/Core/Dxe/Hand/Handle.h
+++ b/MdeModulePkg/Core/Dxe/Hand/Handle.h
@@ -15,7 +15,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
///
/// IHANDLE - contains a list of protocol handles
///
-typedef struct {
+typedef struct EFI_OBJECT {
UINTN Signature;
/// All handles list of IHANDLE
LIST_ENTRY AllHandles;
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h b/MdeModulePkg/Core/=
PiSmmCore/PiSmmCore.h
index 0908e7f4e9e7..c55da58d465e 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.h
@@ -145,7 +145,7 @@ typedef struct {
///
/// IHANDLE - contains a list of protocol handles
///
-typedef struct {
+typedef struct EFI_OBJECT {
UINTN Signature;
/// All handles list of IHANDLE
LIST_ENTRY AllHandles;
diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h b/MdeModu=
lePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
index 50d4c96edb63..bfebbb1f8182 100644
--- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
+++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h
@@ -88,7 +88,7 @@ struct _EFI_AML_NODE_LIST {
// This buffer should not be freed.
// Size is the total size of this ACPI node buffer.
//
-typedef struct {
+typedef struct EFI_ACPI_OBJECT {
UINT32 Signature;
UINT8 *Buffer;
UINTN Size;
diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h b/MdeMod=
ulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
index 4a3feab94df5..48972d0fcad6 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h
@@ -274,7 +274,7 @@ typedef struct _HII_DATABASE_PACKAGE_LIST_INSTANCE {
=20
#define HII_HANDLE_SIGNATURE SIGNATURE_32 ('h','i','h','l')
=20
-typedef struct {
+typedef struct EFI_HII_OBJECT {
UINTN Signature;
LIST_ENTRY Handle;
UINTN Key;
diff --git a/StandaloneMmPkg/Core/StandaloneMmCore.h b/StandaloneMmPkg/Co=
re/StandaloneMmCore.h
index 4d0eed273f50..dcf91bc5e916 100644
--- a/StandaloneMmPkg/Core/StandaloneMmCore.h
+++ b/StandaloneMmPkg/Core/StandaloneMmCore.h
@@ -105,7 +105,7 @@ typedef struct {
///
/// IHANDLE - contains a list of protocol handles
///
-typedef struct {
+typedef struct EFI_OBJECT {
UINTN Signature;
/// All handles list of IHANDLE
LIST_ENTRY AllHandles;
--=20
2.19.1.3.g30247aa5d201

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

Laszlo Ersek
 

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:

Roughly paraphrasing the constraints from ISO C99 "6.5.16.1 Simple
assignment" and "6.5.4 Cast operators", any pointer-to-object type
converts implicitly to, and from, pointer-to-void, provided const /
volatile qualifications are not relaxed. Such implicit conversions
prevent compilers from catching at least the following two kinds of
coding mistakes:

- mixing up one type with another (for example, EFI_HANDLE with
EFI_EVENT),

- getting the depth of indirection wrong (for example, mixing up
(EFI_HANDLE*) with EFI_HANDLE).

This series first separates these standard types from each other, in the
first patch, which is *not* being proposed for merging. This unmasks a
number of warts (semantic issues, or actual bugs) in the source code, in
the form of build breakages. The rest of the series works through those
breakages, cleaning and fixing the code.

Every DSC file in the edk2 tree was built for at least one of the NOOPT,
DEBUG, RELEASE targets (NOOPT being preferred), with the GCC48 toolchain
(for IA32 / X64) and the GCC5 toolchain (for ARM / AARCH64). Of course,
the build arches were restricted to the SUPPORTED_ARCHITECTURES stated
in the individual DSC files.

There were two exceptions to the above rule: DynamicTablesPkg was only
build-tested with AARCH64 (despite its SUPPORTED_ARCHITECTURES), given
that 32-bit ARM has no ACPI bindings. StandaloneMmPkg too was only
build-tested with AARCH64; it doesn't actually support IA32/X64 yet.

Regarding boot & runtime tests, ArmVirtQemu on AARCH64 was tested with
booting to the OS (RHEL7). Furthermore, I exercised OVMF with my usual
boot and S3 tests, covering IA32, IA32X64, and X64. Finally, some other
individual tests (noted per patch) were done with OVMF.

Cc: Achin Gupta <achin.gupta@...>
Cc: Andrew Fish <afish@...>
Cc: Anthony Perard <anthony.perard@...>
Cc: Ard Biesheuvel <ard.biesheuvel@...>
Cc: Benjamin You <benjamin.you@...>
Cc: Chao Zhang <chao.b.zhang@...>
Cc: Dandan Bi <dandan.bi@...>
Cc: David Woodhouse <dwmw2@...>
Cc: Eric Dong <eric.dong@...>
Cc: Guo Dong <guo.dong@...>
Cc: Hao A Wu <hao.a.wu@...>
Cc: Jaben Carsey <jaben.carsey@...>
Cc: Jian J Wang <jian.j.wang@...>
Cc: Jian Wang <jian.j.wang@...>
Cc: Jiaxin Wu <jiaxin.wu@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jordan Justen <jordan.l.justen@...>
Cc: Julien Grall <julien.grall@...>
Cc: Leif Lindholm <leif.lindholm@...>
Cc: Liming Gao <liming.gao@...>
Cc: Maurice Ma <maurice.ma@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Ray Ni <ray.ni@...>
Cc: Siyuan Fu <@sfu5>
Cc: Supreeth Venkatesh <supreeth.venkatesh@...>
Cc: Zhichao Gao <zhichao.gao@...>

Thanks
Laszlo

Laszlo Ersek (35):
DO NOT APPLY: edk2: turn standard handle types into pointers to
non-VOID
EmbeddedPkg: add missing EFIAPI calling convention specifiers
EmbeddedPkg/AndroidFastbootTransportTcpDxe: fix DestroyChild() call
EmbeddedPkg/Universal/MmcDxe: "fix" CloseProtocol() call in
BindingStop()
EmulatorPkg/DxeTimerLib: drop superfluous cast
EmulatorPkg: stop abusing EFI_HANDLE for keystroke notify registration
MdeModulePkg: fix cast in GetModuleInfoFromHandle() calls
MdeModulePkg/UefiHiiLib: stop using EFI_HANDLE in place of
EFI_HII_HANDLE
MdeModulePkg: stop abusing EFI_EVENT for protocol notify registration
MdeModulePkg/PlatformVarCleanupLib: fix HiiConstructConfigHdr() call
MdeModulePkg: document workaround for EFI_RUNTIME_EVENT_ENTRY PI spec
bug
MdeModulePkg: stop abusing EFI_HANDLE for keystroke notify
registration
MdeModulePkg: PEI Core: clean up "AprioriFile" handling in
FindFileEx()
MdeModulePkg: fix UninstallMultipleProtocolInterfaces() calls
MdeModulePkg/PiSmmCore: make type punning consistent
MdeModulePkg/S3SaveState: cast Position for S3BootScriptLib explicitly
MdePkg/DxeServicesLib: remove bogus cast
NetworkPkg/DxeNetLib: fix type typo in NetLibGetMacAddress()
NetworkPkg: fix CloseProtocol & UninstallMultipleProtocolInterfaces
calls
NetworkPkg/Ip4Dxe: fix NetLibDestroyServiceChild() call
NetworkPkg/TcpDxe: fix SockFreeFoo() parameter list
OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() call
OvmfPkg/VirtioNetDxe: fix SignalEvent() call
OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal
functions
OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call
SecurityPkg: fix UninstallMultipleProtocolInterfaces() calls
SecurityPkg: stop abusing EFI_EVENT for protocol notify registration
ShellPkg/UefiShellDriver1CommandsLib: fix parameter list typo
ShellPkg: stop using EFI_HANDLE in place of EFI_HII_HANDLE
ShellPkg: stop taking EFI_HANDLE in place of SHELL_FILE_HANDLE
ShellPkg/UefiShellDebug1CommandsLib: fix ShellCloseFile() call
ShellPkg/UefiShellLib: clarify workaround for unfixable EdkShell bug
StandaloneMmPkg/Core: stop abusing EFI_HANDLE for FwVolHeader tracking
UefiPayloadPkg/BlSupportPei: fix MMCONFIG assignment from XSDT
UefiPayloadPkg/BlSupportDxe: fix ReserveResourceInGcd() calls

EmbeddedPkg/Drivers/AndroidFastbootTransportTcpDxe/FastbootTransportTcp.=
c | 2 +-
EmbeddedPkg/Drivers/ConsolePrefDxe/ConsolePrefDxe.c =
| 1 +
EmbeddedPkg/Drivers/Lan9118Dxe/Lan9118Dxe.c =
| 1 +
EmbeddedPkg/Drivers/SataSiI3132Dxe/SataSiI3132.h =
| 32 ++++++--
EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c =
| 8 ++
EmbeddedPkg/GdbStub/GdbStubInternal.h =
| 9 +++
EmbeddedPkg/MetronomeDxe/Metronome.c =
| 1 +
EmbeddedPkg/Universal/MmcDxe/Mmc.c =
| 5 +-
EmulatorPkg/EmuGopDxe/GopInput.c =
| 4 +-
EmulatorPkg/Library/DxeTimerLib/DxeTimerLib.c =
| 2 +-
MdeModulePkg/Bus/I2c/I2cDxe/I2cBus.c =
| 2 +-
MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.c =
| 2 +-
MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c =
| 6 +-
MdeModulePkg/Bus/Pci/PciSioSerialDxe/Serial.c =
| 2 +-
MdeModulePkg/Bus/Sd/EmmcDxe/EmmcDxe.c =
| 2 +-
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbEnumer.c =
| 2 +-
MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassImpl.c =
| 2 +-
MdeModulePkg/Core/Dxe/Event/Event.c =
| 8 ++
MdeModulePkg/Core/Dxe/Event/Event.h =
| 2 +-
MdeModulePkg/Core/Dxe/Hand/Handle.h =
| 2 +-
MdeModulePkg/Core/Pei/FwVol/FwVol.c =
| 2 +-
MdeModulePkg/Core/Pei/FwVol/FwVol.h =
| 2 +-
MdeModulePkg/Core/PiSmmCore/PiSmmCore.h =
| 2 +-
MdeModulePkg/Core/PiSmmCore/Smi.c =
| 8 +-
MdeModulePkg/Core/RuntimeDxe/Runtime.c =
| 10 ++-
MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c =
| 12 +--
MdeModulePkg/Library/PlatformVarCleanupLib/PlatVarCleanupLib.c =
| 6 +-
MdeModulePkg/Library/SmmCorePerformanceLib/SmmCorePerformanceLib.c =
| 8 +-
MdeModulePkg/Library/UefiHiiLib/HiiString.c =
| 4 +-
MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiSdt.h =
| 2 +-
MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c =
| 4 +-
MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c =
| 4 +-
MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitter.c =
| 2 +-
MdeModulePkg/Universal/DriverSampleDxe/DriverSample.c =
| 4 +-
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.c =
| 2 +-
MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmm.c =
| 2 +-
MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabase.h =
| 2 +-
MdeModulePkg/Universal/LoadFileOnFv2/LoadFileOnFv2.c =
| 2 +-
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c =
| 2 +-
MdePkg/Include/Pi/PiPeiCis.h =
| 6 +-
MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h =
| 3 +-
MdePkg/Include/Protocol/Bis.h =
| 3 +-
MdePkg/Include/Protocol/Eap.h =
| 3 +-
MdePkg/Include/Protocol/HiiFont.h =
| 3 +-
MdePkg/Include/Protocol/MmMp.h =
| 3 +-
MdePkg/Include/Protocol/S3SaveState.h =
| 2 +-
MdePkg/Include/Protocol/Shell.h =
| 3 +-
MdePkg/Include/Protocol/UserManager.h =
| 9 ++-
MdePkg/Include/Uefi/UefiBaseType.h =
| 6 +-
MdePkg/Include/Uefi/UefiInternalFormRepresentation.h =
| 3 +-
MdePkg/Library/DxeServicesLib/DxeServicesLib.c =
| 2 +-
NetworkPkg/DnsDxe/DnsDriver.c =
| 4 +-
NetworkPkg/IScsiDxe/IScsiConfig.c =
| 2 +-
NetworkPkg/Ip4Dxe/Ip4Driver.c =
| 2 +-
NetworkPkg/Ip4Dxe/Ip4If.c =
| 4 +-
NetworkPkg/Ip6Dxe/Ip6Driver.c =
| 2 +-
NetworkPkg/Library/DxeNetLib/DxeNetLib.c =
| 2 +-
NetworkPkg/Mtftp4Dxe/Mtftp4Driver.c =
| 2 +-
NetworkPkg/TcpDxe/SockImpl.c =
| 4 +-
NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.c =
| 2 +-
OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c =
| 6 +-
OvmfPkg/PlatformDxe/Platform.c =
| 4 +-
OvmfPkg/VirtioNetDxe/Events.c =
| 2 +-
OvmfPkg/XenBusDxe/XenBus.c =
| 2 +-
SecurityPkg/HddPassword/HddPasswordDxe.c =
| 2 +-
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c =
| 2 +-
SecurityPkg/Tcg/TcgConfigDxe/TcgConfigDriver.c =
| 2 +-
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDr=
iver.c | 2 +-
ShellPkg/DynamicCommand/DpDynamicCommand/Dp.c =
| 6 +-
ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h =
| 4 +-
ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c =
| 6 +-
ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.h =
| 4 +-
ShellPkg/Include/Library/ShellCommandLib.h =
| 2 +-
ShellPkg/Include/Library/ShellLib.h =
| 4 +-
ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c =
| 2 +-
ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.c =
| 2 +-
ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c =
| 2 +-
ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.h =
| 2 +-
ShellPkg/Library/UefiShellDebug1CommandsLib/Edit/FileBuffer.c =
| 2 +-
ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.c=
| 2 +-
ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.h=
| 2 +-
ShellPkg/Library/UefiShellDriver1CommandsLib/Connect.c =
| 4 +-
ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib=
.c | 2 +-
ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib=
.h | 2 +-
ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.c=
| 2 +-
ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.h=
| 2 +-
ShellPkg/Library/UefiShellLevel2CommandsLib/Rm.c =
| 2 +-
ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.c=
| 2 +-
ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h=
| 2 +-
ShellPkg/Library/UefiShellLevel3CommandsLib/Touch.c =
| 2 +-
ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.c=
| 2 +-
ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.h=
| 2 +-
ShellPkg/Library/UefiShellLib/UefiShellLib.c =
| 26 ++++++-
ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsL=
ib.c | 2 +-
ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsL=
ib.h | 2 +-
ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsL=
ib.c | 2 +-
ShellPkg/Library/UefiShellNetwork2CommandsLib/UefiShellNetwork2CommandsL=
ib.h | 2 +-
StandaloneMmPkg/Core/Dispatcher.c =
| 80 +++++++++++---------
StandaloneMmPkg/Core/FwVol.c =
| 16 ++--
StandaloneMmPkg/Core/StandaloneMmCore.h =
| 4 +-
UefiPayloadPkg/BlSupportDxe/BlSupportDxe.c =
| 4 +-
UefiPayloadPkg/BlSupportPei/BlSupportPei.c =
| 19 +++--
102 files changed, 294 insertions(+), 194 deletions(-)

--=20
2.19.1.3.g30247aa5d201

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

no-reply@...
 

Patchew URL: https://patchew.org/QEMU/20190917130708.10281-1-imammedo@.../



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
make docker-image-fedora V=1 NETWORK=1
time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 NETWORK=1
=== TEST SCRIPT END ===

./tests/docker/docker.py --engine auto build qemu:fedora tests/docker/dockerfiles/fedora.docker --add-current-user
Image is up to date.
LD docker-test-debug@...
cc: fatal error: no input files
compilation terminated.
make: *** [docker-test-debug@...] Error 4



The full log is available at
http://patchew.org/logs/20190917130708.10281-1-imammedo@.../testing.asan/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@...

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

no-reply@...
 

Patchew URL: https://patchew.org/QEMU/20190917130708.10281-1-imammedo@.../



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 ===
#! /bin/bash
make docker-image-fedora V=1 NETWORK=1
time make docker-test-mingw@fedora J=14 NETWORK=1
=== TEST SCRIPT END ===

./tests/docker/docker.py --engine auto build qemu:fedora tests/docker/dockerfiles/fedora.docker --add-current-user
Image is up to date.
LD docker-test-mingw@...
cc: fatal error: no input files
compilation terminated.
make: *** [docker-test-mingw@...] Error 4



The full log is available at
http://patchew.org/logs/20190917130708.10281-1-imammedo@.../testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@...

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

Michael D Kinney
 

Series Reviewed-by: Michael D Kinney <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 the
discussion on the macros.

Mike

-----Original Message-----
From: Laszlo Ersek <lersek@...>
Sent: Wednesday, September 11, 2019 10:51 AM
To: devel@edk2.groups.io; ryszard.knop@...;
leif.lindholm@...
Cc: Andrew Fish <afish@...>; Kinney, Michael D
<michael.d.kinney@...>; Rebecca Cran
<@bcran>; Philippe Mathieu-Daude
<philmd@...>
Subject: Re: [edk2-devel] [PATCH edk2-CCSS 0/3] Coding
Standards: add rule for documenting spurious variable
assignments

On 09/10/19 17:44, Ryszard Knop wrote:
On Tue, 2019-09-10 at 16:33 +0100, Leif Lindholm
wrote:
On Mon, Sep 09, 2019 at 02:35:15PM +0200, Laszlo
Ersek wrote:
On 09/06/19 14:26, Leif Lindholm wrote:
On Thu, Sep 05, 2019 at 08:38:17PM +0200, Laszlo
Ersek wrote:
Repo:
https://github.com/lersek/edk2-
CCodingStandardsSpecification.git
Branch: spurious_assign_bz_607

HTML-rendered views of the modified pages:
-
https://lersek.gitbooks.io/laszlo-s-fork-of-the-
edk-ii-c-coding-st
andards-sp/content/v/spurious_assign_bz_607
-
https://lersek.gitbooks.io/laszlo-s-fork-of-the-
edk-ii-c-coding-st
andards-
sp/content/v/spurious_assign_bz_607/6_documenting_softw
are
/62_comments.html
-
https://lersek.gitbooks.io/laszlo-s-fork-of-the-
edk-ii-c-coding-st
andards-
sp/content/v/spurious_assign_bz_607/6_documenting_softw
are
/64_what_you_must_comment.html

The first two patches are cleanups for things
that popped up in
the discussion in <
https://bugzilla.tianocore.org/show_bug.cgi?id=607>;.

The third patch is the one fixing the BZ.
For 1 and 2,
Reviewed-by: Leif Lindholm
<leif.lindholm@...>

For 3, I see no issue with it, but I do feel
tempted by Phil's
input of using explicit macros (obviating the need
for specific
comment).
I seem to recall back in the mists of time we
considered something
similar.
Yes, I remember similarly.

Vaguely. Am I misremembering, or did we disount
that option?

Phil's current recommendation is what I would have
preferred back
then, but it was rejected, as far as I recall. If I
remember
correctly, most developers preferred naked NULLs /
zeroes. I
insisted on the comment as a fallback / compromise,
so that we'd
have at least some visual cue.
I'm not even sure I wasn't one of the people opposed
to it then.
But if I was, I would appear to have changed my
mind.

I could be mis-remembering; we can restart that
discussion if now
the macros are preferred.
I would be all for that.
If my 2 cents are worth anything, that'd be preferred
by some folks in
my team too. Although something shorter like
"UNINITIALIZED_INT/PTR"
would be nicer, IMO. Both work of course.
Thanks everyone for the feedback thus far on this
series. It looks like I could go ahead and push the
patches, minimally for bringing the CCSS in closer sync
with reality -- and then we could improve
incrementally, for example with macros.

But, before I push the set, I'd really like hear Mike's
opinion too -- I vaguely recall he was active in the
original discussion. I wouldn't like to back out the
patches in case Mike rejected them retroactively.

I believe Mike will have a bit of an email backlog to
process ;) so I'll wait some more in this thread.

Thanks!
Laszlo

However, I see no reason why we shouldn't document
the current
process in the meantime, so for 3/3 also:
Reviewed-by: Leif Lindholm
<leif.lindholm@...>

Best Regards,

Leif

Thanks,
Laszlo

Regards,

Leif

Thanks,
Laszlo

Cc: Andrew Fish <afish@...>
Cc: Leif Lindholm <leif.lindholm@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Rebecca Cran <@bcran>

Laszlo Ersek (3):
comments: remove "Horror Vacui" rule
comments: restrict and clarify applicability of
"/*" comments
must comment: add rule for documenting spurious
variable
assignments

6_documenting_software/62_comments.md
| 20 +-----
----
6_documenting_software/64_what_you_must_comment.md | 39
++++++++++++++++++++
README.md
| 1 +
3 files changed, 42 insertions(+), 18
deletions(-)

--
2.19.1.3.g30247aa5d201



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

Tyler J Erickson <tyler.j.erickson@...>
 

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 current NSID and nothing else. This is ok since I can load the EDK2 driver in place instead.

Since this is unclear in the documentation for the passthru function, can we make a documentation change instead?

Thanks,
-Tyler


On Wed, Sep 4, 2019 at 8:07 PM Wu, Hao A <hao.a.wu@...> wrote:

Hello Tyler,

 

Some inline comments below.

 

Best Regards,

Hao Wu

 

From: Tyler J Erickson [mailto:tyler.j.erickson@...]
Sent: Wednesday, September 04, 2019 11:07 PM
To: Wu, Hao A
Cc: devel@edk2.groups.io; Ni, Ray
Subject: Re: [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other NSIDs for Admin commands

 

Hi Hao,

 

I tried making both the NamespaceID and NSID values the same when calling the passthru function for these admin commands and it didn't work. I think that is due to another place in the passthru code filtering the NamespaceId input values on line 517-520.

The NamespaceId parameter is being checked to make sure it isn't greater than the number of supported namespaces by the controller and it makes sure it isn't set to (UINT32)-1 (All F's). 

 

 

[Hao]: I think the check on line 517-520 blocks ‘NamespaceId’ with value greater than the number of namespace. But it allows the value to be MAX_UINT32, which means the command takes effect on all namespaces.

 

 

I think this is correct since the NamespaceId input is what is discovered when calling the EFI_NVM_EXPRESS_PASS_THRU_GET_NEXT_NAMESPACE function. This is what I used to get the available namespaces available in the system.

 

In my case I'm sending some commands in my application with the NSID set to UINT32_MAX in order to request controller wide SMART/Health log data among other things. There are some commands where setting the NSID to another value may also be useful. For example, DST can use the NSID in the command to change between testing only the controller (0), testing all namespaces (UINT32_MAX), and a specific namespace.

 

 

[Hao]: Yes. Just as you said, commands like DST or Get Log Page will have different target when different Namespace values are provided.

I think for your case, you can:

1.       Set both the 'NamespaceId' parameter and 'Nsid' field to 0 if the target is the controller;

2.       Set both of them MAX_UINT32 if the target is all the namespaces;

3.       Set both of them to a corresponding ID if the target is a specific namespace.

 

As you can see from the current implementation of NvmExpressPassThru() function, the 'NamespaceId' parameter does not affect the construct of the submission queue item.

The 'NamespaceId' parameter only serves as a valid check for the 'Nsid' field in the EFI_NVM_EXPRESS_COMMAND structure.

 

 

The modification I made was done where the passthru command's NSID was actually being checked, which seemed like the best place to add this exception for admin commands.


-Tyler

 

 

On Tue, Sep 3, 2019 at 9:39 PM Wu, Hao A <hao.a.wu@...> wrote:

> -----Original Message-----
> From: Wu, Hao A
> Sent: Wednesday, September 04, 2019 11:39 AM
> To: devel@edk2.groups.io; Tyler Erickson
> Cc: Wu, Hao A; Ni, Ray
> Subject: [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other NSIDs
> for Admin commands
>
> Repost the mail to the list.
>
> Best Regards,
> Hao Wu
>
> -----Original Message-----
> From: Tyler Erickson [mailto:tyler.j.erickson@...]
> Sent: Tuesday, September 03, 2019 9:55 PM
> To: edk2-devel@...
> Cc: Wu, Hao A; Ni, Ray
> Subject: [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Allow other NSIDs
> for Admin commands
>
> Cc: Hao A Wu <hao.a.wu@...>
> Cc: Ray Ni <ray.ni@...>
> Signed-off-by: Tyler Erickson <tyler.j.erickson@...>
> ---
>  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
> b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
> index 8e721379466a..78a3c663ded4 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c
> @@ -561,7 +561,7 @@ NvmExpressPassThru (
>    Sq  = Private->SqBuffer[QueueId] + Private->SqTdbl[QueueId].Sqt;
>    Cq  = Private->CqBuffer[QueueId] + Private->CqHdbl[QueueId].Cqh;
>
> -  if (Packet->NvmeCmd->Nsid != NamespaceId) {
> +  if (Packet->QueueType != NVME_ADMIN_QUEUE && Packet->NvmeCmd-
> >Nsid != NamespaceId) {


Hello,

Per my understanding to the codes, I think the:

* Input parameter 'NamespaceId' for the PassThru() service
* The 'Nsid' field of the EFI_NVM_EXPRESS_COMMAND

are of the same meaning.

Do you think setting these 2 values identical when calling the PassThru()
service can resolve the issue you met?

Best Regards,
Hao Wu


>      return EFI_INVALID_PARAMETER;
>    }
>
> --
> 2.17.1

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

Andy Hayes
 

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 <leif.lindholm@...>
Sent: 17 September 2019 16:28
To: Andy Hayes <andy.hayes@...>
Cc: devel@edk2.groups.io; Ard Biesheuvel <ard.biesheuvel@...>
Subject: [External] Re: [PATCH v1 1/1] Drivers/DisplayLink/DisplayLinkPkg DisplayLinkGop

 

On Wed, Sep 11, 2019 at 07:42:03AM +0000, 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? Nevertheless, a clear fix.

> Cc: Leif Lindholm <leif.lindholm@...>
> Cc: Ard Biesheuvel <ard.biesheuvel@...>
> Signed-off-by: Andy Hayes <andy.hayes@...>

Reviewed-by: Leif Lindholm <leif.lindholm@...>
Pushed as 958aaf600728.

/
Leif

> ---
> Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c b/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
> index 252293da39d4..9871ab0378ce 100644
> --- a/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
> +++ b/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
> @@ -107,7 +107,7 @@ DlUsbSendControlWriteMessage (
> UINT32 UsbStatus;
> EFI_USB_DEVICE_REQUEST UsbRequest;
>
> - ZeroMem (&Request, sizeof (Request));
> + ZeroMem (&UsbRequest, sizeof (UsbRequest));
> UsbRequest.RequestType = USB_REQ_TYPE_VENDOR | USB_TARGET_INTERFACE;
> UsbRequest.Index = Device->InterfaceDescriptor.InterfaceNumber;
> UsbRequest.Request = Request;
> --
> 1.8.3.1
>

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

Leif Lindholm
 

On Wed, Sep 11, 2019 at 07:42:03AM +0000, 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? Nevertheless, a clear fix.

Cc: Leif Lindholm <leif.lindholm@...>
Cc: Ard Biesheuvel <ard.biesheuvel@...>
Signed-off-by: Andy Hayes <andy.hayes@...>
Reviewed-by: Leif Lindholm <leif.lindholm@...>
Pushed as 958aaf600728.

/
Leif

---
Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c b/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
index 252293da39d4..9871ab0378ce 100644
--- a/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
+++ b/Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/UsbTransfer.c
@@ -107,7 +107,7 @@ DlUsbSendControlWriteMessage (
UINT32 UsbStatus;
EFI_USB_DEVICE_REQUEST UsbRequest;

- ZeroMem (&Request, sizeof (Request));
+ ZeroMem (&UsbRequest, sizeof (UsbRequest));
UsbRequest.RequestType = USB_REQ_TYPE_VENDOR | USB_TARGET_INTERFACE;
UsbRequest.Index = Device->InterfaceDescriptor.InterfaceNumber;
UsbRequest.Request = Request;
--
1.8.3.1

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

devel@edk2.groups.io Calendar <devel@...>
 

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

Organizer: Stephano Cetola stephano.cetola@...

Description:

Join Zoom Meeting

https://zoom.us/j/695893389

 

One tap mobile

+17207072699,,695893389# US

+16465588656,,695893389# US (New York)

 

Dial by your location

        +1 720 707 2699 US

        +1 646 558 8656 US (New York)

Meeting ID: 695 893 389

Find your local number: https://zoom.us/u/abOtdJckxL

 

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

Liming Gao
 

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, September 17, 2019 11:23 AM
To: devel@edk2.groups.io; Cheng, Ching JenX <ching.jenx.cheng@...>
Subject: Re: [edk2-devel] [PATCH v2 0/2] *** Add VS2019 Support ***

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2182

In order to support VS2019 on EDK2, the following patches was modified def and batch files 1. Add VS2019 x86/64 definitions on
tools_def.template 2. Add VS2019 support on toolsetup batches, and add version check with command vswhere
Because VS2019 and VS2017 using the same vswhere to get the InstallationPath

v2: In 01/02, add ARM/AARCH64/EBC Definitions, Combine VS2017_HOST and VS2019_HOST to VS_HOST

Ching JenX Cheng (2):
Add VS2019 Toolchain def
Add VS2019 Support on ToolSetup Batches

BaseTools/Conf/tools_def.template | 220
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------------
BaseTools/get_vsvars.bat | 37 ++++++++++++++++++++++++++++++-------
BaseTools/set_vsprefix_envs.bat | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----
BaseTools/toolsetup.bat | 16 +++++++++++++---
edksetup.bat | 6 ++++--
5 files changed, 313 insertions(+), 36 deletions(-)

--
2.21.0.windows.1





Re: [PATCH] MdePkg:Include: Update SmBios header file

Liming Gao
 

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 <abner.chang@...>
Cc: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>; Gao, Liming <liming.gao@...>; Gilbert Chen
<gilbert.chen@...>
Subject: 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.
Please submit BZ https://bugzilla.tianocore.org/ for this update. This is a new feature.

However, you can carry this in your edk2-staging branch, and once the
specification gets released we can take it into edk2.

(After code review, a couple of minor comments below.)

The major update is to add definitions of SMBIOS Type 44h record.

Signed-off-by: Abner Chang <abner.chang@...>

Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <liming.gao@...>
Cc: Leif Lindholm <leif.lindholm@...>
Cc: Gilbert Chen <gilbert.chen@...>

---
MdePkg/Include/IndustryStandard/SmBios.h | 74 +++++++++++++++++++++++++++++++-
1 file changed, 72 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/SmBios.h b/MdePkg/Include/IndustryStandard/SmBios.h
index f3b6f18..ebf0ceb 100644
--- a/MdePkg/Include/IndustryStandard/SmBios.h
+++ b/MdePkg/Include/IndustryStandard/SmBios.h
@@ -3,6 +3,7 @@

Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.<BR>
(C) Copyright 2015-2017 Hewlett Packard Enterprise Development LP<BR>
+(C) Copyright 2015 - 2019 Hewlett Packard Enterprise Development LP<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
File header should be updated.

Industry Standard Definitions of SMBIOS Table Specification v3.2.0.
==>
Industry Standard Definitions of SMBIOS Table Specification v3.3.0.

And, please refer to https://bugzilla.tianocore.org/show_bug.cgi?id=1099 for 3.2 update,
prepare all changes for SmBios 3.3 update.

Thanks
Liming

**/
@@ -46,7 +47,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#define SMBIOS_3_0_TABLE_MAX_LENGTH 0xFFFFFFFF

//
-// SMBIOS type macros which is according to SMBIOS 2.7 specification.
+// SMBIOS type macros which is according to SMBIOS 3.3.0 specification.
//
#define SMBIOS_TYPE_BIOS_INFORMATION 0
#define SMBIOS_TYPE_SYSTEM_INFORMATION 1
@@ -92,6 +93,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#define SMBIOS_TYPE_ONBOARD_DEVICES_EXTENDED_INFORMATION 41
#define SMBIOS_TYPE_MANAGEMENT_CONTROLLER_HOST_INTERFACE 42
#define SMBIOS_TYPE_TPM_DEVICE 43
+#define SMBIOS_TYPE_PROCESSOR_ADDITIONAL_INFORMATION 44

///
/// Inactive type is added from SMBIOS 2.2. Reference SMBIOS 2.6, chapter 3.3.43.
@@ -727,7 +729,10 @@ typedef enum {
ProcessorFamilyMII = 0x012E,
ProcessorFamilyWinChip = 0x0140,
ProcessorFamilyDSP = 0x015E,
- ProcessorFamilyVideoProcessor = 0x01F4
+ ProcessorFamilyVideoProcessor = 0x01F4,
+ ProcessorFamilyRiscvRV32 = 0x0200, ///< SMBIOS spec 3.3.0 added
Please drop the "///< SMBIOS spec 3.3.0 added" comment. Here and below.

+ ProcessorFamilyRiscVRV64 = 0x0201, ///< SMBIOS spec 3.3.0 added
+ ProcessorFamilyRiscVRV128 = 0x0202 ///< SMBIOS spec 3.3.0 added
No further comments from me (MdePkg maintainers may have some).

/
Leif

} PROCESSOR_FAMILY2_DATA;

///
@@ -857,6 +862,19 @@ typedef struct {
} PROCESSOR_FEATURE_FLAGS;

typedef struct {
+ UINT32 ProcessorReserved1 :1;
+ UINT32 ProcessorUnknown :1;
+ UINT32 Processor64BitCapble :1;
+ UINT32 ProcessorMultiCore :1;
+ UINT32 ProcessorHardwareThread :1;
+ UINT32 ProcessorExecuteProtection :1;
+ UINT32 ProcessorEnhancedVirtulization :1;
+ UINT32 ProcessorPowerPerformanceCtrl :1;
+ UINT32 Processor128bitCapble :1;
+ UINT32 ProcessorReserved2 :7;
+} PROCESSOR_CHARACTERISTIC_FLAGS;
+
+typedef struct {
PROCESSOR_SIGNATURE Signature;
PROCESSOR_FEATURE_FLAGS FeatureFlags;
} PROCESSOR_ID_DATA;
@@ -2508,6 +2526,57 @@ typedef struct {
UINT8 InterfaceTypeSpecificData[4]; ///< This field has a minimum of four bytes
} SMBIOS_TABLE_TYPE42;

+
+///
+/// Processor Specific Block - Processor Architecture Type
+///
+typedef enum{
+ ProcessorSpecificBlockArchTypeReserved = 0x00,
+ ProcessorSpecificBlockArchTypeIa32 = 0x01,
+ ProcessorSpecificBlockArchTypeX64 = 0x02,
+ ProcessorSpecificBlockArchTypeItanium = 0x03,
+ ProcessorSpecificBlockArchTypeAarch32 = 0x04,
+ ProcessorSpecificBlockArchTypeAarch64 = 0x05,
+ ProcessorSpecificBlockArchTypeRiscVRV32 = 0x06,
+ ProcessorSpecificBlockArchTypeRiscVRV64 = 0x07,
+ ProcessorSpecificBlockArchTypeRiscVRV128 = 0x08
+} PROCESSOR_SPECIFIC_BLOCK_ARCH_TYPE;
+
+///
+/// Processor Specific Block is the standard container of processor-specific data.
+///
+typedef struct {
+ UINT8 Length;
+ UINT8 ProcessorArchType;
+ ///
+ /// Below followed by Processor-specific data
+ ///
+ ///
+} PROCESSOR_SPECIFIC_BLOCK;
+
+///
+/// Processor Additional Information(Type 44).
+///
+/// The information in this structure defines the processor additional information in case
+/// SMBIOS type 4 is not sufficient to describe processor characteristics.
+/// The SMBIOS type 44 structure has a reference handle field to link back to the related
+/// SMBIOS type 4 structure. There may be multiple SMBIOS type 44 structures linked to the
+/// same SMBIOS type 4 structure. For example, when cores are not identical in a processor,
+/// SMBIOS type 44 structures describe different core-specific information.
+///
+/// SMBIOS type 44 defines the standard header for the processor-specific block, while the
+/// contents of processor-specific data are maintained by processor
+/// architecture workgroups or vendors in separate documents.
+///
+typedef struct {
+ SMBIOS_STRUCTURE Hdr;
+ SMBIOS_HANDLE RefHandle; ///< This field refer to associated SMBIOS type 4
+ ///
+ /// Below followed by Processor-specific block
+ ///
+ PROCESSOR_SPECIFIC_BLOCK ProcessorSpecificBlock;
+} SMBIOS_TABLE_TYPE44;
+
///
/// TPM Device (Type 43).
///
@@ -2586,6 +2655,7 @@ typedef union {
SMBIOS_TABLE_TYPE41 *Type41;
SMBIOS_TABLE_TYPE42 *Type42;
SMBIOS_TABLE_TYPE43 *Type43;
+ SMBIOS_TABLE_TYPE44 *Type44;
SMBIOS_TABLE_TYPE126 *Type126;
SMBIOS_TABLE_TYPE127 *Type127;
UINT8 *Raw;
--
2.7.4

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

Minnow Ware
 

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 POST.

 

My design goals were:

  1. to rewrite the whole thing from scratch, without using any public source code from GNU, BSD, Watcom or Intel EDK2 / tiano core
  2. completeness: full blown C90 + C95 support, no C99, no non-specified extensions at all , e.g. itoa(), stricmp()...
  3. small code size, for UEFI-POST-driver uses a C-Library-Driver, that contains core/worker functions for realloc() ==  malloc() and free(),

entire printf-family, entire scanf-family.

UEFI-POST-driver just uses small wrapper functions to run the C-Library-Driver code.

  1. stable, exact, chipset independent (w/o ACPI timer) "clock()” with CLOCKS_PER_SEC == 1000
  2. complete set of the Microsoft C-compiler intrinsic functions
  3. ROM-able! Runs with stack but w/o any static storage duration in .data segment, e.g. for rand(), strtok(), tmpfile()

This is required for early PEI before memory sizing, when PEI-images run directly out of flash.

  1. Microsoft bug compatible (as far as possible)
    1. to save my lifetime writing a documentation  https://github.com/JoaquinConoBolillo/torito-C-Library/blob/master/implemented.md
    2. use original Microsoft header files for UEFI Shell Apps created in VS2017/19
    3. “debug”-mode for UEFI Shell executable in VS2017/19, that truly runs on Windows (that works

when using library functions only, no HW access, not UEFI-API use) to debug the library

itself – but this just links the same .OBJ module with the WinNT-EntryPoint instead of UEFI-EntryPoint

(The entry point module pulls in the appropriate OS-interface branch dispatcher)

  1. all that in one single C-Library CdeLib.lib

 

The Readme.MD is here: https://github.com/MinnowWare/CdePkg#cdepkg

 

CdePkg shall be adjusted to other compilers/tool chains too, once it is feature complete and accepted by the UEFI community,

as long as it is for Microsoft VS2017/19 only.

 

The CdePkg is integrated into the “vUDK2018”-EDK2, which in turn runs in a MinnowBoard build.

It can be emulated in the Nt32Pkg, since EmulatorPkg in “vUDK2018” doesn’t support Windows…

 

I would like to move the “vUDK2018”-EDK2 to the edk2-staging branch CdePkg, but need to have access granted.

 

Can anyone kindly grant access rights to me?

 

Best Regards,

Kilian

 

 

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

Liming Gao
 

Leif:

-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@...]
Sent: Tuesday, September 17, 2019 5:15 PM
To: devel@edk2.groups.io; Zhang, Shenglei <shenglei.zhang@...>
Cc: ard.biesheuvel@...; Wang, Jian J <jian.j.wang@...>; Wu, Hao A <hao.a.wu@...>; Ni, Ray <ray.ni@...>;
Laszlo Ersek <lersek@...>; Gao, Liming <liming.gao@...>; Gao, Zhichao <zhichao.gao@...>
Subject: Re: [edk2-devel] [PATCH V2 0/3] MdeModulePkg/TerminalConsole: Extend the support terminal types

On Tue, Sep 17, 2019 at 07:17:27AM +0000, 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 guid used in the file.
Determining what affects build and not is something humans are very
bad at and computers are very good at.

So you should build check every patch you submit to the list, no
matter how trivial.

In normal circumstances, so should the maintainers before pushing the
patch.
I push this change. I should double confirm its test result. I will improve my rule.


We now have a commit in the tree known to break the build of pretty
much all ARM/AARCH64 platforms. This will be very unpleasant for
future bisect.
I agree the build break is the big impact. I expect we can speed up to enable EDK II Continuous Integration.
If so, we can avoid such break again.

Thanks
Liming

Best Regards,

Leif

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

Leif Lindholm
 

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 toolchain still has to be
stick on https://github.com/riscv/riscv-gnu-toolchain @64879b24. We
got problem on the version higher than this, system hangs at SEC to
PEI transition if use GCC version higher than @64879b24.

We will figure it out later.
I suppose this is fine as long as this is specifically on the
edk2-staging branch. We will need to resolve it before we bring the
port to edk2 master.

I would still like this support to be tweaked to the point where I can
build with either the Fedora or the Debian packaged cross compiler.

So how can I mention this restrictions in tool_def?
I would suggest the following:
- The above information in the top-level Readme.md on the staging branch.
- A single line in the "GCC5 RISCV64 definitions" comment block.
- Adding the above to the commit message.
Oh, and please add information to that Readme.md on which toolchains
have successfully built this toolchain. Debian's gcc8 fails.

Best Regards,

Leif

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

Leif Lindholm
 

On Mon, Sep 16, 2019 at 07:01:50AM +0000, Chang, Abner (HPS SW/FW Technologist) wrote:
-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@...]
Sent: Friday, September 6, 2019 12:17 AM
To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
<abner.chang@...>
Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 13/22]:
MdePkg/Include: Update SmBios header file.

On Wed, Sep 04, 2019 at 06:43:08PM +0800, Abner Chang wrote:
Update SmBios header file to conform with SMBIOS v3.3.0.
The major update is to add definitions of SMBIOS Type 44h record.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Abner Chang <abner.chang@...>
This would be really useful to get straight into edk2 - could you submit it
straight for inclusion in edk2 master? We can then cherry-pick that back to
the edk2-staging branch.
Forgive me that I don't want to increase the complexity to RISC-V
edk2 submittal. We can send SMBIOS patch apart from RISC-V patches
with specific subject for SMBIOS change.
Yes, sorry, that was exactly what I meant :)
Thank you for doing that.

Best Regards,

Leif

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

Leif Lindholm
 

On Mon, Sep 16, 2019 at 05:37:51AM +0000, Chang, Abner (HPS SW/FW Technologist) wrote:
-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@...]
Sent: Thursday, September 5, 2019 10:28 PM
To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
<abner.chang@...>
Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 07/22]:
MdePkg/BaseIoLibIntrinsic: RISC-V I/O intrinsic functions.

On Wed, Sep 04, 2019 at 06:43:02PM +0800, Abner Chang wrote:
RISC-V MMIO library instance. RISC-V only supports memory map I/O.
However the first implementation of RISC-V EDK2 port uses PC/AT as the
RISC-V platform spec. We have to keep the I/O functions as the temporary
solution.

Can you expand on the I/O port situation?
Since the architecture doesn't support it, what do these functions do?

For the pure MMIO ops using compliant C, we really don't need yet another
implementation pretending it's architecture specific. We should just have a
single IoLibMmio.c and an IoLibMmioNonCompliant.c if the x86 folks want to
keep their current one.
Hmm. That was for the old RISC-V PC/AT QEUM version back to 2016. We
pulled in some X86 peripherals to build up RISC-V PC/AT like
platform . will remove this.
Excellent, thanks.

/
Leif

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

Leif Lindholm
 

On Mon, Sep 16, 2019 at 05:31:40AM +0000, Chang, Abner (HPS SW/FW Technologist) wrote:
-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@...]
Sent: Thursday, September 5, 2019 4:40 AM
To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
<abner.chang@...>
Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 04/22]:
MdePkg/Include: RISC-V definitions.

On Wed, Sep 04, 2019 at 06:42:59PM +0800, Abner Chang wrote:
Add RISC-V processor related definitions.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Abner Chang <abner.chang@...>
---
MdePkg/Include/IndustryStandard/PeImage.h | 14 +-
MdePkg/Include/Library/BaseLib.h | 67 ++++++
MdePkg/Include/Protocol/DebugSupport.h | 55 +++++
MdePkg/Include/Protocol/PxeBaseCode.h | 8 +
MdePkg/Include/RiscV64/ProcessorBind.h | 336
++++++++++++++++++++++++++++++
MdePkg/Include/Uefi/UefiBaseType.h | 25 +++
MdePkg/Include/Uefi/UefiSpec.h | 11 +
7 files changed, 513 insertions(+), 3 deletions(-) create mode
100644 MdePkg/Include/RiscV64/ProcessorBind.h

diff --git a/MdePkg/Include/IndustryStandard/PeImage.h
b/MdePkg/Include/IndustryStandard/PeImage.h
index 720bb08..47796b2 100644
--- a/MdePkg/Include/IndustryStandard/PeImage.h
+++ b/MdePkg/Include/IndustryStandard/PeImage.h
@@ -9,6 +9,8 @@

Copyright (c) 2006 - 2018, Intel Corporation. All rights
reserved.<BR> Portions copyright (c) 2008 - 2009, Apple Inc. All
rights reserved.<BR>
+Portions Copyright (c) 2016, Hewlett Packard Enterprise Development
+LP. All rights reserved.<BR>
+
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -34,6 +36,9 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#define IMAGE_FILE_MACHINE_X64 0x8664
#define IMAGE_FILE_MACHINE_ARMTHUMB_MIXED 0x01c2
#define IMAGE_FILE_MACHINE_ARM64 0xAA64
+#define IMAGE_FILE_MACHINE_RISCV32 0x5032
+#define IMAGE_FILE_MACHINE_RISCV64 0x5064
+#define IMAGE_FILE_MACHINE_RISCV128 0x5128

//
// EXE file formats
@@ -478,9 +483,9 @@ typedef struct {
///
#define EFI_IMAGE_SIZEOF_BASE_RELOCATION 8

-//
-// Based relocation types.
-//
+///
+/// Based relocation types.
+///
I don't know if this change to the comment block is a wonky rebase or
whatever, but please drop it.
No, I revised it to three back slash because most of comment block
use three back slash.
It is always appreciated when people provide style fixes, but they
should be provided as separate patches.

In this case I don't see the value in doing that however, since // is
the comment format specified by the coding standars.

A separate patch fixing the existing incorrect ones would be
preferable (but not important).

Best Regards,

Leif

Re: [edk2-staging/RISC-V-V2 PATCH v1 01/22]: RiscVPkg: RISC-V processor package.

Leif Lindholm
 

On Mon, Sep 16, 2019 at 05:15:08AM +0000, Chang, Abner (HPS SW/FW Technologist) wrote:
-----Original Message-----
From: Leif Lindholm [mailto:leif.lindholm@...]
Sent: Thursday, September 5, 2019 1:51 AM
To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
<abner.chang@...>
Subject: Re: [edk2-devel] [edk2-staging/RISC-V-V2 PATCH v1 01/22]:
RiscVPkg: RISC-V processor package.

Hi Abner,

On Wed, Sep 04, 2019 at 06:42:56PM +0800, Abner Chang wrote:
- Add RiscVPkg package which provides RISC-V processor related drivers
and libraries.
- Support RISC-V OpenSBI and RISC-V platforms

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Abner Chang <abner.chang@...>
---
RiscVPkg/RiscVPkg.dec | 57
+++++++++++++++++++++++++++++++++++++++++++++
RiscVPkg/RiscVPkg.uni | Bin 0 -> 1718 bytes
RiscVPkg/RiscVPkgExtra.uni | Bin 0 -> 1374 bytes
3 files changed, 57 insertions(+)
create mode 100644 RiscVPkg/RiscVPkg.dec create mode 100644
RiscVPkg/RiscVPkg.uni create mode 100644 RiscVPkg/RiscVPkgExtra.uni

diff --git a/RiscVPkg/RiscVPkg.dec b/RiscVPkg/RiscVPkg.dec new file
mode 100644 index 0000000..acf71fe
--- /dev/null
+++ b/RiscVPkg/RiscVPkg.dec
@@ -0,0 +1,57 @@
+## @file RiscVPkg.dec
+# This Package provides UEFI RISC-V modules and libraries.
+#
+# Copyright (c) 2016 - 2019, Hewlett Packard Enterprise Development
+LP. All rights reserved.<BR> # # This program and the accompanying
+materials are licensed and made available under # the terms and
+conditions of the BSD License which accompanies this distribution.
+# The full text of the license may be found at #
+INVALID URI REMOVED
3A__opensource.org_li
+censes_bsd-
2Dlicense.php&d=DwIBAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=_SN6FZBN
+4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=1PSVwg69_Y8lpR9wdv1TN7
kg2brsZYR
+sj5F_hpyPrv4&s=USJlvms7O9ZDAsM0U-
FGng8i0uJkAMNbDEp1S_C4p0A&e=
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
+BASIS, # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
EITHER EXPRESS OR IMPLIED.
+#
+##
+
+[Defines]
+ DEC_SPECIFICATION = 0x00010005
+ PACKAGE_NAME = RiscVPkg
+ PACKAGE_UNI_FILE = RiscVPkg.uni
+ PACKAGE_GUID = 993C7CAC-C87C-4F08-A2CF-AD3AABA859D1
+ PACKAGE_VERSION = 0.1
+
+[Includes]
+ Include
+ opensbi/include
+ opensbi/lib/utils/libfdt
This one is something we need to sort out (together). Having multiple copies
of libfdt in the tree is not on.

I personally think we need a longer-term encapsulation of libfdt that doesn't
mess up the coding style. But until then, I would be much happier if you used
the half measure we have in EmbeddedPkg:
EmbeddedPkg/Library/FdtLib/ and EmbeddedPkg/Include/.
We may not go this way due to everything is from OpenSBI and we
don't want to maintain the difference to open source OpenSBI. Just
take what OpenSBI provides.
If libfdt was a very quickly changing project, I might agree with you.
But it is not. It is a very simple piece of code that performs a small
set of operations on a very well defined structured encapsulation
format.

So please use the one from EmbeddedPkg. On the very unlikely
occurrence that you require functionality not provided by the version
in there, we can update it.

/
Leif