date:20231020

Re: [edk2-devel] Question about OvmfPackage cxl emulation support

2023-10-20 Thread Yoshinoya

Hi, Lersek:
Got it!


Thanks

















At 2023-10-19 19:58:52, "Laszlo Ersek"  wrote:
>On 10/19/23 03:51, Yoshinoya wrote:
>> Hi,
>> I findd qemu supports cxl emulation, but it uses seabios as virtual
>> machine firmware.
>> 
>> Does UEFI OvmfPackage have a plan to support CXL device enumeration and
>> declaration?
>
>I expect MdeModulePkg would have to add some generic CXL device driver,
>which we could perhaps include in OVMF.
>
>Some register definitions were added to core edk2 under
>, but I can't
>easily find any CXL driver.
>
>Laszlo
>
>
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109873): https://edk2.groups.io/g/devel/message/109873
Mute This Topic: https://groups.io/mt/102052612/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] OvmfPkg/VirtioFsDxe: tolerate opening an abs. pathname rel. to a reg. file

2023-10-20 Thread Pedro Falcato

On Thu, Oct 19, 2023 at 3:16 PM Laszlo Ersek  wrote:
>
> On 10/19/23 15:50, Pedro Falcato wrote:
> > On Wed, Oct 18, 2023 at 6:24 PM Laszlo Ersek  wrote:
> >>
> >> Referring to a file relative to a regular file makes no sense (or at least
> >> it cannot be implemented consistently with how a file is referred to
> >> relative to a directory). VirtioFsSimpleFileOpen() has enforced this
> >> strictly since the beginning, and a few months ago I reported USWG Mantis
> >> ticket #2367 [1] too, for clearing up the related confusion in the UEFI
> >> spec.
> >>
> >> Unfortunately, the shim boot loader contains such a bug [2] [3]. I don't
> >> believe the shim bug is ever going to be fixed. We can however relax the
> >> check in VirtioFsSimpleFileOpen() a bit: if the pathname that's being
> >> opened relative to a regular file is absolute, then the base file is going
> >> to be ignored anyway, so we can let the caller's bug slide. This happens
> >> to make shim work.
> >>
> >> Why this matters: UEFI-bootable Linux installer ISOs tend to come with
> >> shim and grub in the embedded (ElTorito) FAT image (ESP). Sometimes you
> >> want to build upstream shim/grub binaries, but boot the same ISO
> >> otherwise. The fastest way for overriding the ESP for this purpose is to
> >> copy its original contents to a virtio filesystem, then overwrite the shim
> >> and grub binaries from the host side. Note that this is different from
> >> direct-booting a kernel (via fw_cfg); the point is to check whether the
> >> just-built shim and grub are able to boot the rest of the ISO.
> >>
> >> [1] https://mantis.uefi.org/mantis/view.php?id=2367
> >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1966973
> >> [3] https://github.com/rhboot/shim/issues/382
> >>
> >> Cc: Ard Biesheuvel 
> >> Cc: Gerd Hoffmann 
> >> Cc: Jiewen Yao 
> >> Cc: Jordan Justen 
> >> Signed-off-by: Laszlo Ersek 
> >> ---
> >>
> >> Notes:
> >> context:-U4
> >>
> >>  OvmfPkg/VirtioFsDxe/SimpleFsOpen.c | 17 ++---
> >>  1 file changed, 14 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c 
> >> b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> >> index a13d4f6a1e2d..2ecf3d6c2325 100644
> >> --- a/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> >> +++ b/OvmfPkg/VirtioFsDxe/SimpleFsOpen.c
> >> @@ -394,22 +394,33 @@ VirtioFsSimpleFileOpen (
> >>
> >>//
> >>// Referring to a file relative to a regular file makes no sense (or at 
> >> least
> >>// it cannot be implemented consistently with how a file is referred to
> >> -  // relative to a directory).
> >> +  // relative to a directory). See USWG Mantis ticket #2367.
> >>//
> >>if (!VirtioFsFile->IsDirectory) {
> >> +BOOLEAN  BugCompat;
> >> +
> >> +//
> >> +// Tolerate this bug in the caller if FileName is absolute. If 
> >> FileName is
> >> +// absolute, then VirtioFsAppendPath() below will disregard
> >> +// VirtioFsFile->CanonicalPathname.
> >> +//
> >> +BugCompat = (FileName[0] == L'\\');
> >> +
> >>  DEBUG ((
> >> -  DEBUG_ERROR,
> >> +  BugCompat ? DEBUG_WARN : DEBUG_ERROR,
> >>("%a: Label=\"%s\" CanonicalPathname=\"%a\" FileName=\"%s\": "
> >> "nonsensical request to open a file or directory relative to a 
> >> regular "
> >> "file\n"),
> >>__func__,
> >>VirtioFs->Label,
> >>VirtioFsFile->CanonicalPathname,
> >>FileName
> >>));
> >> -return EFI_INVALID_PARAMETER;
> >> +if (!BugCompat) {
> >> +  return EFI_INVALID_PARAMETER;
> >> +}
> >>}
> >>
> >>//
> >>// Allocate the new VIRTIO_FS_FILE object.
> >>
> >
> > Aww, you should've CC'd me.
>
> Ouch! I'm sorry. I've grown to (quite mechanically) consult
> $EDK_TOOLS_PATH/Scripts/GetMaintainer.py for the Cc list :(

No biggie :)

>
> > Anyway, retroactive
> > Acked-by: Pedro Falcato 
>
> Thank you! (I've pushed the patch already, so can't record your A-b on
> it, but the mailing list will preserve it at least.)
>
> >
> > If this is the new pseudo-sanctioned behavior for filesystem drivers,
> > I'll make sure to do the same adjustments for Ext4Dxe.
> >
>
> I think that would be useful.
>
> (Of course I don't "insist" that you share my opinion on whether this
> new behavior is for bug compatibility with the UEFI spec and shim (which
> I think it is), or because it is the right/intuitive thing to do (which
> I don't think it is) -- just feel entirely free to word the Ext4Pkg
> comments and commit message as you see fit! ... And I probably don't
> even have to state this, but let me just state it anyway. :) )

Of course :) Honestly, I'd be okay with either behavior *but* now that
the standard has been really loose with the language all these years,
I just think it makes sense to adopt a looser posture for this stuff.
It reminds me of when POSIX has/had really poorly defined interfaces
and they end up taking whatever behaviors are out in the wild.
In our case, you could keep strict IsDirectory() c

Re: [edk2-devel] [edk2-libc Patch 1/1] ek2-libc: Enhance StdLib for supporting Aarch64 and ARM

2023-10-20 Thread Pedro Falcato

On Fri, Oct 20, 2023 at 3:04 PM Jayaprakash, N  wrote:
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4570
>
> This commit is for processing the below PR on edk2-libc repo
> https://github.com/tianocore/edk2-libc/pull/3
> These are the changes introduced to StdLib to build
> an application for the UEFI shell.
> Added format macros for int types to Aarch64, ARM, and Ia32.
> Also modified the X64 macros so that everything would build
> when they are used.
> Added some macros that can be used for compatibility that define when
> socklen_t has been defined.
> Added getopt_long parser from OpenBSD to provide long and
> short option parsing capability with getopt.

This patch is unreviewable. You'd think (from the subject) that it's
an ARM centric change, but it ends up being a whole squashed up
sequence of unrelated changes.
Please separate this into one commit per change.
>
> Cc: Rebecca Cran 
> Cc: Michael D Kinney 
> Cc: Jayaprakash N 
> Signed-off-by: Tyler Erickson 

AIUI, if this is Tyler's commit, you need a From: Tyler Erickson
 (since this is his commit?). Also
probably your own Signed-off-by, I'm not sure.

Lastly, you can't just take NetBSD's headers like this for one simple
reason: UNIX systems have used LP64 for ages, Windows systems use
LLP64. What does this mean?
UNIX (and thus, code compiled using gcc or clang
linux/netbsd/whatever) has sizeof(long) = 8 for 64-bit systems,
whereas in MSVC sizeof(long) = 4.

So macros like:
> #define PRIdPTR "ld"/* intptr_t */
> #define PRIuPTR "lu"/* uintptr_t */

etc, are not correct on MSVC.

Tip: since it's pretty safe, you can probably have two headers: 32-bit
architectures (ILP32, should not change between MSVC and GCC/clang)
and 64-bit architectures (LP64 on GCC/clang, LLP64 on MSVC). The same
goes for the other type-related headers (I have *no* idea if those are
correct).

-- 
Pedro

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109871): https://edk2.groups.io/g/devel/message/109871
Mute This Topic: https://groups.io/mt/102081650/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-libc Patch 1/1] ek2-libc: Enhance StdLib for supporting Aarch64 and ARM

2023-10-20 Thread Michael D Kinney

+Ard
+Leif


> -Original Message-
> From: Jayaprakash, N 
> Sent: Friday, October 20, 2023 7:04 AM
> To: devel@edk2.groups.io
> Cc: Jayaprakash, N ; Rebecca Cran
> ; Kinney, Michael D ;
> Tyler Erickson 
> Subject: [edk2-libc Patch 1/1] ek2-libc: Enhance StdLib for supporting
> Aarch64 and ARM
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4570
> 
> This commit is for processing the below PR on edk2-libc repo
> https://github.com/tianocore/edk2-libc/pull/3
> These are the changes introduced to StdLib to build
> an application for the UEFI shell.
> Added format macros for int types to Aarch64, ARM, and Ia32.
> Also modified the X64 macros so that everything would build
> when they are used.
> Added some macros that can be used for compatibility that define when
> socklen_t has been defined.
> Added getopt_long parser from OpenBSD to provide long and
> short option parsing capability with getopt.
> 
> Cc: Rebecca Cran 
> Cc: Michael D Kinney 
> Cc: Jayaprakash N 
> Signed-off-by: Tyler Erickson 
> ---
>  StdLib/Include/Aarch64/machine/int_fmtio.h | 211 +
>  StdLib/Include/Arm/machine/int_fmtio.h | 211 +
>  StdLib/Include/Ia32/machine/int_fmtio.h| 212 +
>  StdLib/Include/X64/machine/int_fmtio.h | 324 ++---
>  StdLib/Include/getopt.h|  76 +++
>  StdLib/Include/inttypes.h  |   2 +-
>  StdLib/Include/sys/socket.h|   6 +
>  StdLib/Include/unistd.h|   7 +-
>  StdLib/LibC/LibC.inf   |   1 +
>  StdLib/LibC/Uefi/Uefi.inf  |   1 +
>  StdLib/LibC/Uefi/compat.c  |  40 +-
>  StdLib/LibC/Uefi/getopt_long.c | 523
> +
>  12 files changed, 1406 insertions(+), 208 deletions(-)
>  create mode 100644 StdLib/Include/Aarch64/machine/int_fmtio.h
>  create mode 100644 StdLib/Include/Arm/machine/int_fmtio.h
>  create mode 100644 StdLib/Include/Ia32/machine/int_fmtio.h
>  create mode 100644 StdLib/Include/getopt.h
>  create mode 100644 StdLib/LibC/Uefi/getopt_long.c
> 
> diff --git a/StdLib/Include/Aarch64/machine/int_fmtio.h
> b/StdLib/Include/Aarch64/machine/int_fmtio.h
> new file mode 100644
> index 000..f091a7d
> --- /dev/null
> +++ b/StdLib/Include/Aarch64/machine/int_fmtio.h
> @@ -0,0 +1,211 @@
> +/*  $NetBSD: int_fmtio.h,v 1.10 2018/07/15 00:36:13 christos Exp $
> */
> +
> +/*-
> + * Copyright (c) 2001 The NetBSD Foundation, Inc.
> + * All rights reserved.
> + *
> + * This code is derived from software contributed to The NetBSD
> Foundation
> + * by Klaus Klein.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above
> copyright
> + *notice, this list of conditions and the following disclaimer in
> the
> + *documentation and/or other materials provided with the
> distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND
> CONTRIBUTORS
> + * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT
> NOT LIMITED
> + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR
> + * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR
> CONTRIBUTORS
> + * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
> EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
> OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifndef _ARM_INT_FMTIO_H_
> +#define _ARM_INT_FMTIO_H_
> +
> +/*
> + * 7.8.1 Macros for format specifiers
> + */
> +
> +/* fprintf macros for signed integers */
> +#define PRId8   "d" /* int8_t   */
> +#define PRId16  "d" /* int16_t  */
> +#define PRId32  "d" /* int32_t  */
> +#define PRId64  "lld"   /* int64_t  */
> +#define PRIdLEAST8  "d" /* int_least8_t */
> +#define PRIdLEAST16 "d" /* int_least16_t*/
> +#define PRIdLEAST32 "d" /* int_least32_t*/
> +#define PRIdLEAST64 "lld"   /* int_least64_t*/
> +#define PRIdFAST8   "d" /* int_fast8_t  */
> +#define PRIdFAST16  "d" /* int_fast16_t */
> +#define PRIdFAST32  "d" /* int_fast32_t */
> +#define PRIdFAST64  "lld"   /* int_fast64_t */
> +#define PRIdMAX "lld"   /* intmax_t */
> +#define PRIdPTR "ld"/* intptr_t */
> +
> +#define PRIi8   "i" /* int8_t   */
> +#define PRIi16  "i" /* int16_t  */
> +#define PRIi32  "i" /*

[edk2-devel] [edk2-libc Patch 1/1] ek2-libc: Enhance StdLib for supporting Aarch64 and ARM

2023-10-20 Thread Jayaprakash, N

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

This commit is for processing the below PR on edk2-libc repo
https://github.com/tianocore/edk2-libc/pull/3
These are the changes introduced to StdLib to build
an application for the UEFI shell.
Added format macros for int types to Aarch64, ARM, and Ia32.
Also modified the X64 macros so that everything would build
when they are used.
Added some macros that can be used for compatibility that define when
socklen_t has been defined.
Added getopt_long parser from OpenBSD to provide long and
short option parsing capability with getopt.

Cc: Rebecca Cran 
Cc: Michael D Kinney 
Cc: Jayaprakash N 
Signed-off-by: Tyler Erickson 
---
 StdLib/Include/Aarch64/machine/int_fmtio.h | 211 +
 StdLib/Include/Arm/machine/int_fmtio.h | 211 +
 StdLib/Include/Ia32/machine/int_fmtio.h| 212 +
 StdLib/Include/X64/machine/int_fmtio.h | 324 ++---
 StdLib/Include/getopt.h|  76 +++
 StdLib/Include/inttypes.h  |   2 +-
 StdLib/Include/sys/socket.h|   6 +
 StdLib/Include/unistd.h|   7 +-
 StdLib/LibC/LibC.inf   |   1 +
 StdLib/LibC/Uefi/Uefi.inf  |   1 +
 StdLib/LibC/Uefi/compat.c  |  40 +-
 StdLib/LibC/Uefi/getopt_long.c | 523 +
 12 files changed, 1406 insertions(+), 208 deletions(-)
 create mode 100644 StdLib/Include/Aarch64/machine/int_fmtio.h
 create mode 100644 StdLib/Include/Arm/machine/int_fmtio.h
 create mode 100644 StdLib/Include/Ia32/machine/int_fmtio.h
 create mode 100644 StdLib/Include/getopt.h
 create mode 100644 StdLib/LibC/Uefi/getopt_long.c

diff --git a/StdLib/Include/Aarch64/machine/int_fmtio.h 
b/StdLib/Include/Aarch64/machine/int_fmtio.h
new file mode 100644
index 000..f091a7d
--- /dev/null
+++ b/StdLib/Include/Aarch64/machine/int_fmtio.h
@@ -0,0 +1,211 @@
+/*  $NetBSD: int_fmtio.h,v 1.10 2018/07/15 00:36:13 christos Exp $  */
+
+/*-
+ * Copyright (c) 2001 The NetBSD Foundation, Inc.
+ * All rights reserved.
+ *
+ * This code is derived from software contributed to The NetBSD Foundation
+ * by Klaus Klein.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+ * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
+ * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _ARM_INT_FMTIO_H_
+#define _ARM_INT_FMTIO_H_
+
+/*
+ * 7.8.1 Macros for format specifiers
+ */
+
+/* fprintf macros for signed integers */
+#define PRId8   "d" /* int8_t   */
+#define PRId16  "d" /* int16_t  */
+#define PRId32  "d" /* int32_t  */
+#define PRId64  "lld"   /* int64_t  */
+#define PRIdLEAST8  "d" /* int_least8_t */
+#define PRIdLEAST16 "d" /* int_least16_t*/
+#define PRIdLEAST32 "d" /* int_least32_t*/
+#define PRIdLEAST64 "lld"   /* int_least64_t*/
+#define PRIdFAST8   "d" /* int_fast8_t  */
+#define PRIdFAST16  "d" /* int_fast16_t */
+#define PRIdFAST32  "d" /* int_fast32_t */
+#define PRIdFAST64  "lld"   /* int_fast64_t */
+#define PRIdMAX "lld"   /* intmax_t */
+#define PRIdPTR "ld"/* intptr_t */
+
+#define PRIi8   "i" /* int8_t   */
+#define PRIi16  "i" /* int16_t  */
+#define PRIi32  "i" /* int32_t  */
+#define PRIi64  "lli"   /* int64_t  */
+#define PRIiLEAST8  "i" /* int_least8_t */
+#define PRIiLEAST16 "i" /* int_least16_t*/
+#define PRIiLEAST32 "i" /* int_least32_t*/
+#define PRIiLEAST64 "lli"   /* int_least64_t*/
+#define PRIiFAST8   "i" /* int_fast8_t  */
+#define PRIiFAST16  "i" /* int_fast16_t */
+#define PRIiFAST32  "i" /* int_fast32_t */
+#define PRIiFAST64  "lli"   /* int_fast64_t */
+#define PRIiMAX "lli"   /* intmax_t */
+#define PRIiPTR "li"/* int

[edk2-devel] [edk2-libc Patch 0/1] edk2-libc - Enhancements to StdLibc

2023-10-20 Thread Jayaprakash, N

This patch request contains enhancements made to StdLibc
through BZ https://bugzilla.tianocore.org/show_bug.cgi?id=4570


Jayaprakash N (1):
  ek2-libc: Enhance StdLib for supporting Aarch64 and ARM

 StdLib/Include/Aarch64/machine/int_fmtio.h | 211 +
 StdLib/Include/Arm/machine/int_fmtio.h | 211 +
 StdLib/Include/Ia32/machine/int_fmtio.h| 212 +
 StdLib/Include/X64/machine/int_fmtio.h | 324 ++---
 StdLib/Include/getopt.h|  76 +++
 StdLib/Include/inttypes.h  |   2 +-
 StdLib/Include/sys/socket.h|   6 +
 StdLib/Include/unistd.h|   7 +-
 StdLib/LibC/LibC.inf   |   1 +
 StdLib/LibC/Uefi/Uefi.inf  |   1 +
 StdLib/LibC/Uefi/compat.c  |  40 +-
 StdLib/LibC/Uefi/getopt_long.c | 523 +
 12 files changed, 1406 insertions(+), 208 deletions(-)
 create mode 100644 StdLib/Include/Aarch64/machine/int_fmtio.h
 create mode 100644 StdLib/Include/Arm/machine/int_fmtio.h
 create mode 100644 StdLib/Include/Ia32/machine/int_fmtio.h
 create mode 100644 StdLib/Include/getopt.h
 create mode 100644 StdLib/LibC/Uefi/getopt_long.c

-- 
2.40.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109868): https://edk2.groups.io/g/devel/message/109868
Mute This Topic: https://groups.io/mt/102081649/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device list

2023-10-20 Thread Laszlo Ersek

On 10/20/23 14:25, Ard Biesheuvel wrote:
> On Fri, 20 Oct 2023 at 11:49, Laszlo Ersek  wrote:
>>
>> On 10/18/23 10:57, Ard Biesheuvel wrote:
>>> On Wed, 18 Oct 2023 at 10:49, YuinYee Chew
>>>  wrote:

 Dear Maintainers,

 Just a friendly reminder to ask if you could take a look at my patch. I'd 
 really appreciate your feedback and help.

>>>
>>> Thanks for the reminder. I don't have time to review this myself but
>>> I'm happy to merge it if someone else reviews it
>>
>> Heinrich gave an Acked-by up-thread.
>>
>> (I'd just go ahead and merge this myself to help you out a bit, but I
>> don't have access to the original patch!)
>>
> 
> OK, thanks.
> 
> I'll queue this up.

Thanks, Ard --> , commit
c591395f4ab5.

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109867): https://edk2.groups.io/g/devel/message/109867
Mute This Topic: https://groups.io/mt/101660590/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 15/15] PldmSmbiosTransferDxe: Implement Set PLDM terminus ID API

2023-10-20 Thread Konstantin Aladyshev

From: Abner Chang 

Currently all PLDM functions inside the PLDM_SMBIOS_TRANSFER_PROTOCOL
use PLDM terminus PCDs for the MCTP addressing.
Add additional function to the protocol API to provide user a way to
use custom TIDs.

Signed-off-by: Abner Chang 
Signed-off-by: Konstantin Aladyshev 
---
 .../Protocol/PldmSmbiosTransferProtocol.h | 26 +
 .../PldmSmbiosTransferDxe.c   | 28 +++
 2 files changed, 54 insertions(+)

diff --git 
a/Features/ManageabilityPkg/Include/Protocol/PldmSmbiosTransferProtocol.h 
b/Features/ManageabilityPkg/Include/Protocol/PldmSmbiosTransferProtocol.h
index 7903e12726..8b23d39682 100644
--- a/Features/ManageabilityPkg/Include/Protocol/PldmSmbiosTransferProtocol.h
+++ b/Features/ManageabilityPkg/Include/Protocol/PldmSmbiosTransferProtocol.h
@@ -23,6 +23,31 @@ typedef struct  _EDKII_PLDM_SMBIOS_TRANSFER_PROTOCOL 
EDKII_PLDM_SMBIOS_TRANSFER_
 #define EDKII_PLDM_SMBIOS_TRANSFER_PROTOCOL_VERSION
((EDKII_PLDM_SMBIOS_TRANSFER_PROTOCOL_VERSION_MAJOR << 8) |\

EDKII_PLDM_SMBIOS_TRANSFER_PROTOCOL_VERSION_MINOR)
 
+/**
+  This function sets PLDM SMBIOS transfer source and destination
+  PLDM terminus ID.
+
+  @param [in]   This   EDKII_PLDM_SMBIOS_TRANSFER_PROTOCOL instance.
+  @param [in]   SourceId   PLDM source teminus ID.
+   Set to PLDM_TERMINUS_ID_UNASSIGNED means use
+   platform default PLDM terminus ID.
+   
(gManageabilityPkgTokenSpaceGuid.PcdPldmSourceTerminusId)
+  @param [in]   DestinationId  PLDM destination teminus ID.
+   Set to PLDM_TERMINUS_ID_UNASSIGNED means use
+   platform default PLDM terminus ID.
+   
(gManageabilityPkgTokenSpaceGuid.PcdPldmDestinationEndpointId)
+
+  @retval   EFI_SUCCESSGet SMBIOS table metadata Successfully.
+  @retval   EFI_INVALID_PARAMETER  Invalid value of source or destination
+   PLDM terminus ID.
+**/
+typedef
+EFI_STATUS
+(EFIAPI *PLDM_GET_SMBIOS_TRANSFER_TERMINUS_ID)(
+  IN  UINT8  SourceId,
+  IN  UINT8  DestinationId
+  );
+
 /**
   This function gets SMBIOS table metadata.
 
@@ -151,6 +176,7 @@ EFI_STATUS
 // EDKII_PLDM_SMBIOS_TRANSFER_PROTOCOL
 //
 typedef struct {
+  PLDM_GET_SMBIOS_TRANSFER_TERMINUS_IDSetPldmSmbiosTransferTerminusId;
   PLDM_GET_SMBIOS_STRUCTURE_TABLE_METADATAGetSmbiosStructureTableMetaData;
   PLDM_SET_SMBIOS_STRUCTURE_TABLE_METADATASetSmbiosStructureTableMetaData;
   PLDM_GET_SMBIOS_STRUCTURE_TABLE GetSmbiosStructureTable;
diff --git 
a/Features/ManageabilityPkg/Universal/PldmSmbiosTransferDxe/PldmSmbiosTransferDxe.c
 
b/Features/ManageabilityPkg/Universal/PldmSmbiosTransferDxe/PldmSmbiosTransferDxe.c
index fdf033f0b1..357a7d49e4 100644
--- 
a/Features/ManageabilityPkg/Universal/PldmSmbiosTransferDxe/PldmSmbiosTransferDxe.c
+++ 
b/Features/ManageabilityPkg/Universal/PldmSmbiosTransferDxe/PldmSmbiosTransferDxe.c
@@ -25,6 +25,33 @@
 
 UINT32  SetSmbiosStructureTableHandle;
 
+/**
+  This function sets PLDM SMBIOS transfer source and destination
+  PLDM terminus ID.
+
+  @param [in]   This   EDKII_PLDM_SMBIOS_TRANSFER_PROTOCOL instance.
+  @param [in]   SourceId   PLDM source teminus ID.
+   Set to PLDM_TERMINUS_ID_UNASSIGNED means use
+   platform default PLDM terminus ID.
+   
(gManageabilityPkgTokenSpaceGuid.PcdPldmSourceTerminusId)
+  @param [in]   DestinationId  PLDM destination teminus ID.
+   Set to PLDM_TERMINUS_ID_UNASSIGNED means use
+   platform default PLDM terminus ID.
+   
(gManageabilityPkgTokenSpaceGuid.PcdPldmDestinationEndpointId)
+
+  @retval   EFI_SUCCESSGet SMBIOS table metadata Successfully.
+  @retval   EFI_INVALID_PARAMETER  Invalid value of source or destination
+   PLDM terminus ID.
+**/
+EFI_STATUS
+SetPldmSmbiosTransferTerminusId (
+  IN  UINT8  SourceId,
+  IN  UINT8  DestinationId
+  )
+{
+  return PldmSetTerminus(SourceId, DestinationId);
+}
+
 /**
   Get the full size of SMBIOS structure including optional strings that follow 
the formatted structure.
 
@@ -457,6 +484,7 @@ GetSmbiosStructureByHandle (
 }
 
 EDKII_PLDM_SMBIOS_TRANSFER_PROTOCOL_V1_0  mPldmSmbiosTransferProtocolV10 = {
+  SetPldmSmbiosTransferTerminusId,
   GetSmbiosStructureTableMetaData,
   SetSmbiosStructureTableMetaData,
   GetSmbiosStructureTable,
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109865): https://edk2.groups.io/g/devel/message/109865
Mute This Topic: https://groups.io/mt/102080245/21656
Group Owner: devel+ow...@edk2.groups.io
Unsub

[edk2-devel] [PATCH edk2-platforms v2 14/15] ManageabilityPkg: Return error on PLDM header check fails

2023-10-20 Thread Konstantin Aladyshev

Currently PldmSubmit command returns EFI_SUCCESS even if the response
header checks have failed.
Correct the code to return errors in such cases.

Signed-off-by: Konstantin Aladyshev 
---
 .../Universal/PldmProtocol/Common/PldmProtocolCommon.c   | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git 
a/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c 
b/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c
index bc72ce07b3..04f250e57c 100644
--- 
a/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c
+++ 
b/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c
@@ -241,7 +241,7 @@ CommonPldmSubmitCommand (
   if (FullPacketResponseData == NULL) {
 DEBUG ((DEBUG_ERROR, "  Not enough memory for 
FullPacketResponseDataSize.\n"));
 Status = EFI_OUT_OF_RESOURCES;
-goto ErrorExit2;
+goto ErrorExit;
   }
 
   // Print out PLDM packet.
@@ -281,6 +281,7 @@ CommonPldmSubmitCommand (
   FullPacketResponseDataSize
   ));
 HelperManageabilityDebugPrint ((VOID *)FullPacketResponseData, 
TransferToken.ReceivePackage.ReceiveSizeInByte, "Failed response payload\n");
+Status = EFI_DEVICE_ERROR;
 goto ErrorExit;
   }
 
@@ -303,6 +304,7 @@ CommonPldmSubmitCommand (
 DEBUG ((DEBUG_ERROR, "Pldm Completion Code = 0x%x\n", 
ResponseHeader->PldmCompletionCode));
 
 HelperManageabilityDebugPrint ((VOID *)FullPacketResponseData, 
TransferToken.ReceivePackage.ReceiveSizeInByte, "Failed response payload\n");
+Status = EFI_DEVICE_ERROR;
 goto ErrorExit;
   }
 
@@ -319,6 +321,7 @@ CommonPldmSubmitCommand (
   ));
 
 HelperManageabilityDebugPrint ((VOID *)FullPacketResponseData, 
TransferToken.ReceivePackage.ReceiveSizeInByte, "Failed response payload\n");
+Status = EFI_DEVICE_ERROR;
 goto ErrorExit;
   }
 
@@ -332,6 +335,7 @@ CommonPldmSubmitCommand (
   ResponseHeader->PldmCompletionCode
   ));
 HelperManageabilityDebugPrint ((VOID *)FullPacketResponseData, 
GET_PLDM_MESSAGE_PAYLOAD_SIZE(TransferToken.ReceivePackage.ReceiveSizeInByte), 
"Failed response payload\n");
+Status = EFI_DEVICE_ERROR;
 goto ErrorExit;
   }
 
@@ -350,13 +354,12 @@ CommonPldmSubmitCommand (
 
   // Return transfer status.
   //
-ErrorExit:
   Status = TransferToken.TransferStatus;
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "%a: Failed to send PLDM command over %s\n", 
__func__, mTransportName));
   }
 
-ErrorExit2:
+ErrorExit:
   if (PldmTransportHeader != NULL) {
 FreePool ((VOID *)PldmTransportHeader);
   }
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109864): https://edk2.groups.io/g/devel/message/109864
Mute This Topic: https://groups.io/mt/102080244/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 13/15] ManageabilityPkg/PldmProtocol: Remove PLDM command table

2023-10-20 Thread Konstantin Aladyshev

From: Abner Chang 

In case of the PLDM/MCTP communication response size doesn't have to be
known beforehand, the caller just need to provide the buffer big enough
to accomodate the response.
Remove PLDM command table for retrieving the response payload size and
correct the code to fix the response buffer size handling.
Also update the message for error conditions.

Signed-off-by: Abner Chang 
Signed-off-by: Konstantin Aladyshev 
---
 .../PldmProtocol/Common/PldmProtocolCommon.c  | 100 +++---
 .../PldmProtocol/Common/PldmProtocolCommon.h  |   3 +
 .../Universal/PldmProtocol/Dxe/PldmProtocol.c |  13 ++-
 3 files changed, 31 insertions(+), 85 deletions(-)

diff --git 
a/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c 
b/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c
index ea3d4a22b2..bc72ce07b3 100644
--- 
a/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c
+++ 
b/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c
@@ -21,42 +21,6 @@
 extern CHAR16  *mTransportName;
 extern UINT8   mPldmRequestInstanceId;
 
-PLDM_MESSAGE_PACKET_MAPPING  PldmMessagePacketMappingTable[] = {
-  { PLDM_TYPE_SMBIOS, PLDM_GET_SMBIOS_STRUCTURE_TABLE_METADATA_COMMAND_CODE, 
sizeof (PLDM_GET_SMBIOS_STRUCTURE_TABLE_METADATA_RESPONSE_FORMAT) },
-  { PLDM_TYPE_SMBIOS, PLDM_SET_SMBIOS_STRUCTURE_TABLE_METADATA_COMMAND_CODE, 
sizeof (PLDM_SET_SMBIOS_STRUCTURE_TABLE_METADATA_RESPONSE_FORMAT) },
-  { PLDM_TYPE_SMBIOS, PLDM_SET_SMBIOS_STRUCTURE_TABLE_COMMAND_CODE,  
sizeof (PLDM_SET_SMBIOS_STRUCTURE_TABLE_REQUEST_FORMAT)   }
-};
-
-/**
-  This function returns the expected full size of PLDM response message.
-
-  @param[in] PldmTypePLDM message type.
-  @param[in] PldmCommand PLDM command of this PLDM type.
-
-  @retval  Zero   No matched entry for this PldmType/PldmCommand.
-  @retval  None-zero  Size of full packet is returned.
-**/
-UINT32
-GetFullPacketResponseSize (
-  IN UINT8  PldmType,
-  IN UINT8  PldmCommand
-  )
-{
-  INT16Index;
-  PLDM_MESSAGE_PACKET_MAPPING  *ThisEntry;
-
-  ThisEntry = PldmMessagePacketMappingTable;
-  for (Index = 0; Index < (sizeof (PldmMessagePacketMappingTable)/ sizeof 
(PLDM_MESSAGE_PACKET_MAPPING)); Index++) {
-if ((PldmType == ThisEntry->PldmType) && (PldmCommand == 
ThisEntry->PldmCommand)) {
-  return ThisEntry->ResponseSize;
-}
-
-ThisEntry++;
-  }
-
-  return 0;
-}
-
 /**
   This functions setup the final header/body/trailer packets for
   the acquired transport interface.
@@ -267,10 +231,10 @@ CommonPldmSubmitCommand (
   TransferToken.TransmitPackage.TransmitTimeoutInMillisecond = 
MANAGEABILITY_TRANSPORT_NO_TIMEOUT;
 
   // Set receive packet.
-  FullPacketResponseDataSize = GetFullPacketResponseSize (PldmType, 
PldmCommand);
-  if (FullPacketResponseDataSize == 0) {
-DEBUG ((DEBUG_ERROR, "  No mapping entry in PldmMessagePacketMappingTable 
for PLDM Type:%d Command %d\n", PldmType, PldmCommand));
-ASSERT (FALSE);
+  if (ResponseData == NULL && *ResponseDataSize == 0) {
+FullPacketResponseDataSize = sizeof (PLDM_RESPONSE_HEADER);
+  } else {
+FullPacketResponseDataSize = *ResponseDataSize + sizeof 
(PLDM_RESPONSE_HEADER);
   }
 
   FullPacketResponseData = (UINT8 *)AllocateZeroPool 
(FullPacketResponseDataSize);
@@ -306,6 +270,7 @@ CommonPldmSubmitCommand (
 );
   //
   // Check the response size.
+  //
   if (TransferToken.ReceivePackage.ReceiveSizeInByte < sizeof 
(PLDM_RESPONSE_HEADER)) {
 DEBUG ((
   DEBUG_MANAGEABILITY_INFO,
@@ -315,21 +280,13 @@ CommonPldmSubmitCommand (
   TransferToken.ReceivePackage.ReceiveSizeInByte,
   FullPacketResponseDataSize
   ));
-if (ResponseDataSize != NULL) {
-  if (*ResponseDataSize > TransferToken.ReceivePackage.ReceiveSizeInByte) {
-*ResponseDataSize = TransferToken.ReceivePackage.ReceiveSizeInByte;
-  }
-}
-
-if (ResponseData != NULL) {
-  CopyMem ((VOID *)ResponseData, (VOID *)FullPacketResponseData, 
*ResponseDataSize);
-}
-
+HelperManageabilityDebugPrint ((VOID *)FullPacketResponseData, 
TransferToken.ReceivePackage.ReceiveSizeInByte, "Failed response payload\n");
 goto ErrorExit;
   }
 
   //
   // Check the integrity of response. data.
+  //
   ResponseHeader = (PLDM_RESPONSE_HEADER *)FullPacketResponseData;
   if ((ResponseHeader->PldmHeader.DatagramBit != 
(!PLDM_MESSAGE_HEADER_IS_DATAGRAM)) ||
   (ResponseHeader->PldmHeader.RequestBit != 
PLDM_MESSAGE_HEADER_IS_RESPONSE) ||
@@ -343,22 +300,16 @@ CommonPldmSubmitCommand (
 DEBUG ((DEBUG_ERROR, "Instance ID  = %d (Expected value: %d)\n", 
ResponseHeader->PldmHeader.InstanceId, mPldmRequestInstanceId));
 DEBUG ((DEBUG_ERROR, "Pldm Type= %d (Expected value: %d)\n", 
ResponseHeader->PldmHeader.PldmType, PldmType));
 DEBUG ((DEBUG_ERROR, "

[edk2-devel] [PATCH edk2-platforms v2 12/15] PldmProtocolDxe: Correct TID argument usage

2023-10-20 Thread Konstantin Aladyshev

From: Abner Chang 

Currently the PLDM source/destination TID arguments for the PldmSubmit
function are not actually used in any way in the underlying MCTP
communication. The code just uses MCTP source/destination EID PCDs. So
we have to restructure code to actually use provided PLDM TIDs.
On the other case the PldmSubmitCommand function from the
PldmProtocolLib doesn't even accept the source/destination TID
arguments.
To address both these facts correct TID argument usage in the following
way:
- by default the TID values are taken from the built-time PCDs,
- user have an ability to provide custom TIDs either via PldmSubmit
function arguments or by calling PldmSetTerminus API.

Signed-off-by: Abner Chang 
Signed-off-by: Konstantin Aladyshev 
---
 .../Include/Library/BasePldmProtocolLib.h | 16 ++
 .../Include/Protocol/PldmProtocol.h   | 18 +++---
 .../PldmProtocolLibrary/Dxe/PldmProtocolLib.c | 49 +++-
 .../Dxe/PldmProtocolLib.inf   |  6 +-
 .../PldmProtocol/Common/PldmProtocolCommon.c  | 28 +++---
 .../PldmProtocol/Common/PldmProtocolCommon.h  | 22 +---
 .../Universal/PldmProtocol/Dxe/PldmProtocol.c | 56 ---
 .../PldmProtocol/Dxe/PldmProtocolDxe.inf  |  4 --
 8 files changed, 162 insertions(+), 37 deletions(-)

diff --git a/Features/ManageabilityPkg/Include/Library/BasePldmProtocolLib.h 
b/Features/ManageabilityPkg/Include/Library/BasePldmProtocolLib.h
index 5523ac3a4d..a698197263 100644
--- a/Features/ManageabilityPkg/Include/Library/BasePldmProtocolLib.h
+++ b/Features/ManageabilityPkg/Include/Library/BasePldmProtocolLib.h
@@ -9,6 +9,22 @@
 #ifndef EDKII_PLDM_PROTOCOL_LIB_H_
 #define EDKII_PLDM_PROTOCOL_LIB_H_
 
+/**
+  This function sets the PLDM source termius and destination terminus
+  ID for SMBIOS PLDM transfer.
+
+  @param[in] SourceId   PLDM source teminus ID.
+  @param[in] DestinationId  PLDM destination teminus ID.
+
+  @retval EFI_SUCCESSThe terminus is set successfully.
+  @retval EFI_INVALID_PARAMETER  The terminus is set unsuccessfully.
+**/
+EFI_STATUS
+PldmSetTerminus (
+  IN  UINT8   SourceId,
+  IN  UINT8   DestinationId
+);
+
 /**
   This service enables submitting commands via EDKII PLDM protocol.
 
diff --git a/Features/ManageabilityPkg/Include/Protocol/PldmProtocol.h 
b/Features/ManageabilityPkg/Include/Protocol/PldmProtocol.h
index 651997e1ad..02efb3015a 100644
--- a/Features/ManageabilityPkg/Include/Protocol/PldmProtocol.h
+++ b/Features/ManageabilityPkg/Include/Protocol/PldmProtocol.h
@@ -26,13 +26,15 @@ typedef struct  _EDKII_PLDM_PROTOCOL EDKII_PLDM_PROTOCOL;
 /**
   This service enables submitting commands via EDKII PLDM protocol.
 
-  @param[in] This  EDKII_PLDM_PROTOCOL instance.
-  @param[in] PldmType  PLDM message type.
-  @param[in] Command   PLDM Command of PLDM message type.
-  @param[in] RequestData   Command Request Data.
-  @param[in] RequestDataSize   Size of Command Request Data.
-  @param[out]ResponseData  Command Response Data. The completion 
code is the first byte of response data.
-  @param[in, out]ResponseDataSize  Size of Command Response Data.
+  @param[in] This   EDKII_PLDM_PROTOCOL instance.
+  @param[in] PldmType   PLDM message type.
+  @param[in] CommandPLDM Command of PLDM message 
type.
+  @param[in] PldmTerminusSourceId   PLDM source teminus ID.
+  @param[in] PldmTerminusDestinationId  PLDM destination teminus ID.
+  @param[in] RequestDataCommand Request Data.
+  @param[in] RequestDataSizeSize of Command Request Data.
+  @param[out]ResponseData   Command Response Data. The 
completion code is the first byte of response data.
+  @param[in, out]ResponseDataSize   Size of Command Response Data.
 
   @retval EFI_SUCCESSThe command byte stream was successfully 
submit to the device and a response was successfully received.
   @retval EFI_NOT_FOUND  The command was not successfully sent to the 
device or a response was not successfully received from the device.
@@ -49,6 +51,8 @@ EFI_STATUS
   IN EDKII_PLDM_PROTOCOL  *This,
   IN UINT8PldmType,
   IN UINT8Command,
+  IN UINT8PldmTerminusSourceId,
+  IN UINT8PldmTerminusDestinationId,
   IN UINT8*RequestData,
   IN UINT32   RequestDataSize,
   OUTUINT8*ResponseData,
diff --git 
a/Features/ManageabilityPkg/Library/PldmProtocolLibrary/Dxe/PldmProtocolLib.c 
b/Features/ManageabilityPkg/Library/PldmProtocolLibrary/Dxe/PldmProtocolLib.c
index 267bd8fbc1..37231b0756 100644
--- 
a/Features/ManageabilityPkg/Library/PldmProtocolLibrary/Dxe/PldmProtocolLib.c
+++ 
b/Features/ManageabilityPkg/Library/P

[edk2-devel] [PATCH edk2-platforms v2 11/15] ManageabilityPkg: Add PLDM terminus PCDs

2023-10-20 Thread Konstantin Aladyshev

From: Abner Chang 

Add PLDM source and destination terminus IDs for transmiting PLDM
message.

Signed-off-by: Abner Chang 
Signed-off-by: Konstantin Aladyshev 
---
 Features/ManageabilityPkg/ManageabilityPkg.dec | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Features/ManageabilityPkg/ManageabilityPkg.dec 
b/Features/ManageabilityPkg/ManageabilityPkg.dec
index 14fe0fd2e0..eb0ee67cba 100644
--- a/Features/ManageabilityPkg/ManageabilityPkg.dec
+++ b/Features/ManageabilityPkg/ManageabilityPkg.dec
@@ -72,6 +72,12 @@
   # @Prompt MCTP KCS (Memory mapped) I/O base address
   gManageabilityPkgTokenSpaceGuid.PcdMctpKcsBaseAddress|0xca2|UINT32|0x0004
 
+  ## This value is the PLDM source and destination terminus ID for transmiting 
PLDM message.
+  # @Prompt PLDM source terminus ID
+  gManageabilityPkgTokenSpaceGuid.PcdPldmSourceTerminusId|0|UINT8|0x0040
+  # @Prompt PLDM destination terminus ID
+  
gManageabilityPkgTokenSpaceGuid.PcdPldmDestinationEndpointId|0|UINT8|0x0041
+
   ## This is the value of SOL channels supported on platform.
   # @Prompt SOL channel number
   gManageabilityPkgTokenSpaceGuid.PcdMaxSolChannels|3|UINT8|0x0100
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109861): https://edk2.groups.io/g/devel/message/109861
Mute This Topic: https://groups.io/mt/102080241/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 10/15] ManageabilityPkg: Return error on multiple-packet MCTP responses

2023-10-20 Thread Konstantin Aladyshev

Since the current driver doesn't yet support handling of
multiple-packet MCTP responses, return EFI_UNSUPPORTED error in such
cases.

Signed-off-by: Konstantin Aladyshev 
---
 .../MctpProtocol/Common/MctpProtocolCommon.c  | 11 +++
 1 file changed, 11 insertions(+)

diff --git 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c 
b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
index 4aae4fcba9..3709ab16eb 100644
--- 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
+++ 
b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
@@ -524,6 +524,17 @@ CommonMctpSubmitMessage (
 FreePool (ResponseBuffer);
 return EFI_DEVICE_ERROR;
   }
+  if ((MctpTransportResponseHeader->Bits.StartOfMessage != 1) ||
+  (MctpTransportResponseHeader->Bits.EndOfMessage != 1) ||
+  (MctpTransportResponseHeader->Bits.PacketSequence != 0)) {
+DEBUG ((
+  DEBUG_ERROR,
+  "%a: Error! Multiple-packet MCTP responses are not supported by the 
current driver\n",
+  __func__
+  ));
+FreePool (ResponseBuffer);
+return EFI_UNSUPPORTED;
+  }
 
   MctpMessageResponseHeader = (MCTP_MESSAGE_HEADER 
*)(MctpTransportResponseHeader + 1);
   if (MctpMessageResponseHeader->Bits.MessageType != MctpType) {
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109860): https://edk2.groups.io/g/devel/message/109860
Mute This Topic: https://groups.io/mt/102080239/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 09/15] ManageabilityPkg: Use correct constants for PLDM header checks

2023-10-20 Thread Konstantin Aladyshev

Currently PldmProtocol code uses magic numbers in the PLDM header
checks. Since PLDM headers have all the necessary definitions replace
magic numbers with the appropriate defines.

Signed-off-by: Konstantin Aladyshev 
---
 .../Universal/PldmProtocol/Common/PldmProtocolCommon.c| 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c 
b/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c
index 1c4506d87f..4edfe05955 100644
--- 
a/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c
+++ 
b/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c
@@ -321,15 +321,15 @@ CommonPldmSubmitCommand (
   //
   // Check the integrity of response. data.
   ResponseHeader = (PLDM_RESPONSE_HEADER *)FullPacketResponseData;
-  if ((ResponseHeader->PldmHeader.DatagramBit != 0) ||
-  (ResponseHeader->PldmHeader.RequestBit != 0) ||
+  if ((ResponseHeader->PldmHeader.DatagramBit != 
(!PLDM_MESSAGE_HEADER_IS_DATAGRAM)) ||
+  (ResponseHeader->PldmHeader.RequestBit != 
PLDM_MESSAGE_HEADER_IS_RESPONSE) ||
   (ResponseHeader->PldmHeader.InstanceId != mPldmRequestInstanceId) ||
   (ResponseHeader->PldmHeader.PldmType != PldmType) ||
   (ResponseHeader->PldmHeader.PldmTypeCommandCode != PldmCommand))
   {
 DEBUG ((DEBUG_ERROR, "PLDM integrity check of response data is 
failed.\n"));
-DEBUG ((DEBUG_ERROR, "Request bit  = %d (Expected value: 0)\n"));
-DEBUG ((DEBUG_ERROR, "Datagram = %d (Expected value: 0)\n"));
+DEBUG ((DEBUG_ERROR, "Datagram = %d (Expected value: %d)\n", 
ResponseHeader->PldmHeader.DatagramBit, (!PLDM_MESSAGE_HEADER_IS_DATAGRAM)));
+DEBUG ((DEBUG_ERROR, "Request bit  = %d (Expected value: %d)\n", 
ResponseHeader->PldmHeader.RequestBit, PLDM_MESSAGE_HEADER_IS_RESPONSE));
 DEBUG ((DEBUG_ERROR, "Instance ID  = %d (Expected value: %d)\n", 
ResponseHeader->PldmHeader.InstanceId, mPldmRequestInstanceId));
 DEBUG ((DEBUG_ERROR, "Pldm Type= %d (Expected value: %d)\n", 
ResponseHeader->PldmHeader.PldmType, PldmType));
 DEBUG ((DEBUG_ERROR, "Pldm Command = %d (Expected value: %d)\n", 
ResponseHeader->PldmHeader.PldmTypeCommandCode, PldmCommand));
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109859): https://edk2.groups.io/g/devel/message/109859
Mute This Topic: https://groups.io/mt/102080238/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 08/15] ManageabilityPkg: Don't check MCTP header fields if transfer has failed

2023-10-20 Thread Konstantin Aladyshev

If MCTP KCS communication has failed we need to abort MCTP transfer
function before checking any MCTP header data.

Signed-off-by: Konstantin Aladyshev 
---
 .../MctpProtocol/Common/MctpProtocolCommon.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c 
b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
index 3128aadd15..4aae4fcba9 100644
--- 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
+++ 
b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
@@ -461,6 +461,13 @@ CommonMctpSubmitMessage (
 &TransferToken
 );
 
+  *AdditionalTransferError = TransferToken.TransportAdditionalStatus;
+  Status = TransferToken.TransferStatus;
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_ERROR, "%a: Failed to send MCTP command over %s: %r\n", 
__func__, mTransportName, Status));
+return Status;
+  }
+
   MctpTransportResponseHeader = (MCTP_TRANSPORT_HEADER *)ResponseBuffer;
   if (MctpTransportResponseHeader->Bits.HeaderVersion != 
MCTP_KCS_HEADER_VERSION) {
 DEBUG ((
@@ -543,18 +550,9 @@ CommonMctpSubmitMessage (
 return EFI_DEVICE_ERROR;
   }
 
-  //
-  // Return transfer status.
-  //
-  *AdditionalTransferError = TransferToken.TransportAdditionalStatus;
   *ResponseDataSize= TransferToken.ReceivePackage.ReceiveSizeInByte - 
sizeof (MCTP_TRANSPORT_HEADER) - sizeof (MCTP_MESSAGE_HEADER);
   CopyMem (ResponseData, ResponseBuffer + sizeof (MCTP_TRANSPORT_HEADER) + 
sizeof (MCTP_MESSAGE_HEADER), *ResponseDataSize);
   FreePool (ResponseBuffer);
-  Status = TransferToken.TransferStatus;
-  if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "%a: Failed to send MCTP command over %s: %r\n", 
__func__, mTransportName, Status));
-return Status;
-  }
 
   return Status;
 }
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109858): https://edk2.groups.io/g/devel/message/109858
Mute This Topic: https://groups.io/mt/102080236/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 07/15] ManageabilityPkg: Correct value for the MCTP TAG_OWNER response bit

2023-10-20 Thread Konstantin Aladyshev

Currently the MCTP TAG_OWNER bit is checked against 1 both in MTCP
request and response.
According to the MTCP Base specification in case of the MCTP response
the TAG_OWNER bit should be equal to 0.
Correct MCTP_MESSAGE_TAG_OWNER_RESPONSE flag value to fix the issue.

Signed-off-by: Konstantin Aladyshev 
---
 .../Include/Library/ManageabilityTransportMctpLib.h   | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportMctpLib.h 
b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportMctpLib.h
index 462e7436e6..a8dc8a8519 100644
--- a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportMctpLib.h
+++ b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportMctpLib.h
@@ -51,8 +51,8 @@ typedef struct {
 // is not defined by the specification.
 #define MCTP_MESSAGE_TAG  0x1
 
-#define MCTP_MESSAGE_TAG_OWNER_REQUEST   0x01
-#define MCTP_MESSAGE_TAG_OWNER_RESPONSE  0x01
+#define MCTP_MESSAGE_TAG_OWNER_REQUEST   1
+#define MCTP_MESSAGE_TAG_OWNER_RESPONSE  0
 
 #define MCTP_PACKET_SEQUENCE_MASK  0x3
 
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109857): https://edk2.groups.io/g/devel/message/109857
Mute This Topic: https://groups.io/mt/102080235/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 06/15] ManageabilityPkg: Update the algorithm of using MCTP endpoint ID PCD

2023-10-20 Thread Konstantin Aladyshev

Although MtcpSubmit function receives source and destination MCTP EID
arguments these value are not used in any way currently. Instead the
code always uses EID values from the PCDs.
To correct this issue modify function interface to receive source and
destination MCTP EIDs via pointers and use PCD values only if the
pointers are NULL.

Signed-off-by: Konstantin Aladyshev 
Signed-off-by: Abner Chang 
---
 .../Include/Protocol/MctpProtocol.h   | 12 --
 .../Dxe/ManageabilityTransportMctp.c  |  4 +-
 .../MctpProtocol/Common/MctpProtocolCommon.c  |  4 +-
 .../Universal/MctpProtocol/Dxe/MctpProtocol.c | 42 ++-
 4 files changed, 44 insertions(+), 18 deletions(-)

diff --git a/Features/ManageabilityPkg/Include/Protocol/MctpProtocol.h 
b/Features/ManageabilityPkg/Include/Protocol/MctpProtocol.h
index 85e42f157d..c96b986c44 100644
--- a/Features/ManageabilityPkg/Include/Protocol/MctpProtocol.h
+++ b/Features/ManageabilityPkg/Include/Protocol/MctpProtocol.h
@@ -28,8 +28,12 @@ typedef struct  _EDKII_MCTP_PROTOCOL EDKII_MCTP_PROTOCOL;
 
   @param[in] This   EDKII_MCTP_PROTOCOL instance.
   @param[in] MctpType   MCTP message type.
-  @param[in] MctpSourceEndpointId   MCTP source endpoint ID.
-  @param[in] MctpDestinationEndpointId  MCTP source endpoint ID.
+  @param[in] MctpSourceEndpointId   Pointer of MCTP source 
endpoint ID.
+Set to NULL means use platform 
PCD value
+(PcdMctpSourceEndpointId).
+  @param[in] MctpDestinationEndpointId  Pointer of MCTP destination 
endpoint ID.
+Set to NULL means use platform 
PCD value
+(PcdMctpDestinationEndpointId).
   @param[in] RequestDataIntegrityCheck  Indicates whether MCTP message 
has
 integrity check byte.
   @param[in] RequestDataMessage Data.
@@ -58,8 +62,8 @@ EFI_STATUS
 (EFIAPI *MCTP_SUBMIT_COMMAND)(
   IN EDKII_MCTP_PROTOCOL  *This,
   IN UINT8MctpType,
-  IN UINT8MctpSourceEndpointId,
-  IN UINT8MctpDestinationEndpointId,
+  IN UINT8*MctpSourceEndpointId,
+  IN UINT8*MctpDestinationEndpointId,
   IN BOOLEAN  RequestDataIntegrityCheck,
   IN UINT8*RequestData,
   IN UINT32   RequestDataSize,
diff --git 
a/Features/ManageabilityPkg/Library/ManageabilityTransportMctpLib/Dxe/ManageabilityTransportMctp.c
 
b/Features/ManageabilityPkg/Library/ManageabilityTransportMctpLib/Dxe/ManageabilityTransportMctp.c
index c520e2302d..249104c873 100644
--- 
a/Features/ManageabilityPkg/Library/ManageabilityTransportMctpLib/Dxe/ManageabilityTransportMctp.c
+++ 
b/Features/ManageabilityPkg/Library/ManageabilityTransportMctpLib/Dxe/ManageabilityTransportMctp.c
@@ -205,8 +205,8 @@ MctpTransportTransmitReceive (
   Status = mMctpProtocol->Functions.Version1_0->MctpSubmitCommand (
   mMctpProtocol,
   
TransmitHeader->MessageHeader.MessageType,
-  
TransmitHeader->SourceEndpointId,
-  
TransmitHeader->DestinationEndpointId,
+  
&TransmitHeader->SourceEndpointId,
+  
&TransmitHeader->DestinationEndpointId,
   
(BOOLEAN)TransmitHeader->MessageHeader.IntegrityCheck,
   
TransferToken->TransmitPackage.TransmitPayload,
   
TransferToken->TransmitPackage.TransmitSizeInByte,
diff --git 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c 
b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
index 5844d54eb2..3128aadd15 100644
--- 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
+++ 
b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
@@ -175,8 +175,8 @@ SetupMctpRequestTransportPacket (
 MctpTransportHeader = (MCTP_TRANSPORT_HEADER 
*)ThisPackage;
 MctpTransportHeader->Bits.Reserved  = 0;
 MctpTransportHeader->Bits.HeaderVersion = MCTP_KCS_HEADER_VERSION;
-MctpTransportHeader->Bits.DestinationEndpointId = PcdGet8 
(PcdMctpDestinationEndpointId);
-MctpTransportHeader->Bits.SourceEndpointIdId= PcdGet8 
(PcdMctpSourceEndpointId);
+MctpTransportHeader->Bits.DestinationEndpointId = 
MctpDestinationEndpointId;
+MctpTransportHeader->Bits.SourceEndpoin

[edk2-devel] [PATCH edk2-platforms v2 04/15] ManageabilityPkg: Check header fields in the MCTP response

2023-10-20 Thread Konstantin Aladyshev

Add checks for the MCTP header fields in the MCTP response.

Signed-off-by: Konstantin Aladyshev 
---
 .../MctpProtocol/Common/MctpProtocolCommon.c  | 82 +++
 1 file changed, 82 insertions(+)

diff --git 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c 
b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
index e560c638d5..5844d54eb2 100644
--- 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
+++ 
b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
@@ -461,6 +461,88 @@ CommonMctpSubmitMessage (
 &TransferToken
 );
 
+  MctpTransportResponseHeader = (MCTP_TRANSPORT_HEADER *)ResponseBuffer;
+  if (MctpTransportResponseHeader->Bits.HeaderVersion != 
MCTP_KCS_HEADER_VERSION) {
+DEBUG ((
+  DEBUG_ERROR,
+  "%a: Error! Response HeaderVersion (0x%02x) doesn't match 
MCTP_KCS_HEADER_VERSION (0x%02x)\n",
+  __func__,
+  MctpTransportResponseHeader->Bits.HeaderVersion,
+  MCTP_KCS_HEADER_VERSION
+  ));
+FreePool (ResponseBuffer);
+return EFI_DEVICE_ERROR;
+  }
+  if (MctpTransportResponseHeader->Bits.MessageTag != MCTP_MESSAGE_TAG) {
+DEBUG ((
+  DEBUG_ERROR,
+  "%a: Error! Response MessageTag (0x%02x) doesn't match MCTP_MESSAGE_TAG 
(0x%02x)\n",
+  __func__,
+  MctpTransportResponseHeader->Bits.MessageTag,
+  MCTP_MESSAGE_TAG
+  ));
+FreePool (ResponseBuffer);
+return EFI_DEVICE_ERROR;
+  }
+  if (MctpTransportResponseHeader->Bits.TagOwner != 
MCTP_MESSAGE_TAG_OWNER_RESPONSE) {
+DEBUG ((
+  DEBUG_ERROR,
+  "%a: Error! Response TagOwner (0x%02x) doesn't match 
MCTP_MESSAGE_TAG_OWNER_RESPONSE (0x%02x)\n",
+  __func__,
+  MctpTransportResponseHeader->Bits.TagOwner,
+  MCTP_MESSAGE_TAG_OWNER_RESPONSE
+  ));
+FreePool (ResponseBuffer);
+return EFI_DEVICE_ERROR;
+  }
+  if (MctpTransportResponseHeader->Bits.SourceEndpointId != 
MctpDestinationEndpointId) {
+DEBUG ((
+  DEBUG_ERROR,
+  "%a: Error! Response SrcEID (0x%02x) doesn't match sent EID (0x%02x)\n",
+  __func__,
+  MctpTransportResponseHeader->Bits.SourceEndpointId,
+  MctpDestinationEndpointId
+  ));
+FreePool (ResponseBuffer);
+return EFI_DEVICE_ERROR;
+  }
+  if (MctpTransportResponseHeader->Bits.DestinationEndpointId != 
MctpSourceEndpointId) {
+DEBUG ((
+  DEBUG_ERROR,
+  "%a: Error! Response DestEID (0x%02x) doesn't match local EID 
(0x%02x)\n",
+  __func__,
+  MctpTransportResponseHeader->Bits.DestinationEndpointId,
+  MctpSourceEndpointId
+  ));
+FreePool (ResponseBuffer);
+return EFI_DEVICE_ERROR;
+  }
+
+  MctpMessageResponseHeader = (MCTP_MESSAGE_HEADER 
*)(MctpTransportResponseHeader + 1);
+  if (MctpMessageResponseHeader->Bits.MessageType != MctpType) {
+DEBUG ((
+  DEBUG_ERROR,
+  "%a: Error! Response MessageType (0x%02x) doesn't match sent MessageType 
(0x%02x)\n",
+  __func__,
+  MctpMessageResponseHeader->Bits.MessageType,
+  MctpType
+  ));
+FreePool (ResponseBuffer);
+return EFI_DEVICE_ERROR;
+  }
+
+  if (MctpMessageResponseHeader->Bits.IntegrityCheck != 
(UINT8)RequestDataIntegrityCheck) {
+DEBUG ((
+  DEBUG_ERROR,
+  "%a: Error! Response IntegrityCheck (%d) doesn't match sent 
IntegrityCheck (%d)\n",
+  __func__,
+  MctpMessageResponseHeader->Bits.IntegrityCheck,
+  (UINT8)RequestDataIntegrityCheck
+  ));
+FreePool (ResponseBuffer);
+return EFI_DEVICE_ERROR;
+  }
+
   //
   // Return transfer status.
   //
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109854): https://edk2.groups.io/g/devel/message/109854
Mute This Topic: https://groups.io/mt/102080231/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 05/15] ManageabilityPkg: Correct typo in MCTP destination EID field

2023-10-20 Thread Konstantin Aladyshev

Correct wrong structure member used for MCTP destination EID.

Signed-off-by: Abner Chang 
Signed-off-by: Konstantin Aladyshev 
---
 .../Universal/PldmProtocol/Common/PldmProtocolCommon.c  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c 
b/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c
index ce1e2cba95..1c4506d87f 100644
--- 
a/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c
+++ 
b/Features/ManageabilityPkg/Universal/PldmProtocol/Common/PldmProtocolCommon.c
@@ -119,7 +119,7 @@ SetupPldmRequestTransportPacket (
 }
 
 MctpHeader->SourceEndpointId = PcdGet8 
(PcdMctpSourceEndpointId);
-MctpHeader->SourceEndpointId = PcdGet8 
(PcdMctpDestinationEndpointId);
+MctpHeader->DestinationEndpointId= PcdGet8 
(PcdMctpDestinationEndpointId);
 MctpHeader->MessageHeader.IntegrityCheck = FALSE;
 MctpHeader->MessageHeader.MessageType= MCTP_MESSAGE_TYPE_PLDM;
 *PacketHeader= (MANAGEABILITY_TRANSPORT_HEADER 
*)MctpHeader;
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109855): https://edk2.groups.io/g/devel/message/109855
Mute This Topic: https://groups.io/mt/102080232/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 03/15] ManageabilityPkg: Support both MCTP and IPMI in KCS tranport library

2023-10-20 Thread Konstantin Aladyshev

The Manageability KCS transport library needs to support requests both
from MCTP and IPMI transports. Currently the code only handles IPMI
case correctly.
In the MCTP case the communication should be based on the MCTP-over-KCS
specification (DSP0254). This specification defines a special KCS
binding header and trailer structures that need to be present in every
MCTP message.
The header structure contains a length field, therefore response packet
size is not needed to be known beforehand.
The trailer structure contains a PEC checksum that can be used to check
itegrity of the response message.
Modify Manageability KCS transport library code to check which message
is processed (IPMI or MCTP) and handle each case correctly based on its
own specification.

Tested:
- The IPMI KCS communication is tested by Abner Chang,
- The MCTP KCS communication is tested by Konstantin Aladyshev on the
AMD EthanolX CRB.

Signed-off-by: Konstantin Aladyshev 
Signed-off-by: Abner Chang 
---
 .../Common/KcsCommon.c| 284 +++---
 .../MctpProtocol/Common/MctpProtocolCommon.c  |  14 +-
 2 files changed, 260 insertions(+), 38 deletions(-)

diff --git 
a/Features/ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsCommon.c
 
b/Features/ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsCommon.c
index d5b54c04be..4f7e7d450f 100644
--- 
a/Features/ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsCommon.c
+++ 
b/Features/ManageabilityPkg/Library/ManageabilityTransportKcsLib/Common/KcsCommon.c
@@ -8,16 +8,19 @@
 **/
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include "ManageabilityTransportKcs.h"
 
 extern MANAGEABILITY_TRANSPORT_KCS_HARDWARE_INFO  mKcsHardwareInfo;
+extern MANAGEABILITY_TRANSPORT_KCS*mSingleSessionToken;
 
 /**
   This function waits for parameter Flag to set.
@@ -379,6 +382,218 @@ KcsTransportRead (
   return EFI_SUCCESS;
 }
 
+/**
+  This funciton checks the KCS response data according to
+  manageability protocol.
+
+  @param[in]  ResponseDataPointer to response data.
+  @param[in]  ResponseDataSizeSize of response data.
+  @param[out] AdditionalStatusPointer to receive the additional status.
+
+  @retval EFI_SUCCESS KCS response header is checked without 
error
+  @retval EFI_DEVICE_ERRORKCS response header has problem.
+**/
+EFI_STATUS
+KcsCheckResponseData (
+  IN UINT8   *ResponseData,
+  IN UINT32  ResponseDataSize,
+  OUT MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS  *AdditionalStatus
+  )
+{
+  EFI_STATUS  Status;
+  MANAGEABILITY_MCTP_KCS_TRAILER  MctpKcsPec;
+  UINT32  PecSize;
+  UINT8   CalculatedPec;
+  CHAR16  *CompletionCodeStr;
+
+  Status= EFI_SUCCESS;
+  *AdditionalStatus = MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_NO_ERRORS;
+  if (CompareGuid (&gManageabilityProtocolMctpGuid, 
mSingleSessionToken->Token.ManageabilityProtocolSpecification)) {
+//
+// For MCTP over KCS, check PEC
+//
+PecSize = sizeof (MANAGEABILITY_MCTP_KCS_TRAILER) + 1;  // +1 to read last 
dummy byte that finishes KCS transfer
+Status  = KcsTransportRead (&MctpKcsPec.Pec, &PecSize);
+if (EFI_ERROR (Status)) {
+  DEBUG ((
+DEBUG_ERROR,
+"%a: Error! Failed to read PEC with Status(%r)\n",
+__func__,
+Status
+));
+  *AdditionalStatus = MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_ERROR;
+  return Status;
+}
+
+if (PecSize != sizeof (MctpKcsPec)) {
+  DEBUG ((
+DEBUG_ERROR,
+"%a: Error! Received PEC size is %d instead of %d\n",
+__func__,
+PecSize,
+sizeof (MctpKcsPec)
+));
+  *AdditionalStatus = MANAGEABILITY_TRANSPORT_ADDITIONAL_STATUS_ERROR;
+  return EFI_DEVICE_ERROR;
+}
+
+HelperManageabilityDebugPrint ((VOID *)&MctpKcsPec.Pec, PecSize - 1, "MCTP 
over KCS Response PEC:\n");
+CalculatedPec = HelperManageabilityGenerateCrc8 
(MCTP_KCS_PACKET_ERROR_CODE_POLY, 0, ResponseData, ResponseDataSize);
+if (CalculatedPec != MctpKcsPec.Pec) {
+  DEBUG ((
+DEBUG_ERROR,
+"%a: Error! Received PEC is 0x%02x instead of 0x%02x\n",
+__func__,
+MctpKcsPec.Pec,
+CalculatedPec
+));
+  Status = EFI_DEVICE_ERROR;
+}
+  } else if (CompareGuid (&gManageabilityProtocolIpmiGuid, 
mSingleSessionToken->Token.ManageabilityProtocolSpecification)) {
+//
+// For IPMI over KCS
+// Check and print Completion Code
+//
+Status = IpmiHelperCheckCompletionCode (*ResponseData, &CompletionCodeStr, 
AdditionalStatus);
+if (!EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_MANAGEABILITY_INFO, "Cc: %02x %s.\n", *((UINT8 
*)ResponseData), CompletionCodeStr));
+

[edk2-devel] [PATCH edk2-platforms v2 02/15] ManageabilityPkg: Check MCTP EIDs for reserved values

2023-10-20 Thread Konstantin Aladyshev

MTCP base specification marks EIDs 1-7 as reserved. Therefore return
EFI_INVALID_PARAMETER if such EIDs were provided to the
MctpSubmitMessage function.

Signed-off-by: Konstantin Aladyshev 
Signed-off-by: Abner Chang 
---
 .../Universal/MctpProtocol/Dxe/MctpProtocol.c   | 17 +
 1 file changed, 17 insertions(+)

diff --git 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocol.c 
b/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocol.c
index 88bfd9b7e7..d0f49a1abb 100644
--- a/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocol.c
+++ b/Features/ManageabilityPkg/Universal/MctpProtocol/Dxe/MctpProtocol.c
@@ -78,6 +78,23 @@ MctpSubmitMessage (
 return EFI_INVALID_PARAMETER;
   }
 
+  //
+  // Check source EID and destination EID
+  //
+  if ((MctpSourceEndpointId >= MCTP_RESERVED_ENDPOINT_START_ID) &&
+  (MctpSourceEndpointId <= MCTP_RESERVED_ENDPOINT_END_ID)
+  ) {
+DEBUG ((DEBUG_ERROR, "%a: The value of MCTP source EID (%x) is 
reserved.\n", __func__, MctpSourceEndpointId));
+return EFI_INVALID_PARAMETER;
+  }
+
+  if ((MctpDestinationEndpointId >= MCTP_RESERVED_ENDPOINT_START_ID) &&
+  (MctpDestinationEndpointId <= MCTP_RESERVED_ENDPOINT_END_ID)
+  ) {
+DEBUG ((DEBUG_ERROR, "%a: The value of MCTP destination EID (%x) is 
reserved.\n", __func__, MctpDestinationEndpointId));
+return EFI_INVALID_PARAMETER;
+  }
+
   Status = CommonMctpSubmitMessage (
  mTransportToken,
  MctpType,
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109852): https://edk2.groups.io/g/devel/message/109852
Mute This Topic: https://groups.io/mt/102080229/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 00/15] MTCP-over-KCS support

2023-10-20 Thread Konstantin Aladyshev

The Manageability KCS transport library needs to support requests both
from MCTP and IPMI transports. Currently the code only handles IPMI
case correctly.
In the MCTP case the communication should be based on the MCTP-over-KCS
specification (DSP0254). This specification defines a special KCS
binding header and trailer structures that need to be present in every
MCTP message.
The header structure contains a length field, therefore response packet
size is not needed to be known beforehand.
The trailer structure contains a PEC checksum that can be used to check
itegrity of the response message.
Modify Manageability KCS transport library code to check which message
is processed (IPMI or MCTP) and handle each case correctly based on its
own specification.
This patch is a result of a joint effort from the Konstantin Aladyshev
 and Abner Chang .

Tested:
PLDM communication between the HOST and BMC was tested with both
components implemented via open-source software:
- The HOST (UEFI firmware) part was based one the edk2 [1] and
edk2-platforms [2] code,
- The BMC part was based on the openbmc [3] distribution.

The testing process and all the necessary utilities are described in
the [4] repository.

The provided changes keep IPMI over KCS stack working as reported by
Abner Chang.

[1]: https://github.com/tianocore/edk2
[2]: https://github.com/tianocore/edk2-platforms
[3]: https://github.com/openbmc/openbmc
[4]: https://github.com/Kostr/PLDM

Changes v1 -> v2:
 - Add new patches with corrections for the PLDM protocol. The
  resulting communication via EDKII_PLDM_PROTOCOL was successfully
  tested.
  

Abner Chang (4):
  ManageabilityPkg: Add PLDM terminus PCDs
  PldmProtocolDxe: Correct TID argument usage
  ManageabilityPkg/PldmProtocol: Remove PLDM command table
  PldmSmbiosTransferDxe: Implement Set PLDM terminus ID API

Konstantin Aladyshev (11):
  ManageabilityPkg: Add definition for the MCTP KCS TRAILER structure
  ManageabilityPkg: Check MCTP EIDs for reserved values
  ManageabilityPkg: Support both MCTP and IPMI in KCS tranport library
  ManageabilityPkg: Check header fields in the MCTP response
  ManageabilityPkg: Correct typo in MCTP destination EID field
  ManageabilityPkg: Update the algorithm of using MCTP endpoint ID PCD
  ManageabilityPkg: Correct value for the MCTP TAG_OWNER response bit
  ManageabilityPkg: Don't check MCTP header fields if transfer has
failed
  ManageabilityPkg: Use correct constants for PLDM header checks
  ManageabilityPkg: Return error on multiple-packet MCTP responses
  ManageabilityPkg: Return error on PLDM header check fails

 .../Include/Library/BasePldmProtocolLib.h |  16 +
 .../Library/ManageabilityTransportMctpLib.h   |   9 +-
 .../Include/Protocol/MctpProtocol.h   |  12 +-
 .../Include/Protocol/PldmProtocol.h   |  18 +-
 .../Protocol/PldmSmbiosTransferProtocol.h |  26 ++
 .../Common/KcsCommon.c| 284 +++---
 .../Dxe/ManageabilityTransportMctp.c  |   4 +-
 .../PldmProtocolLibrary/Dxe/PldmProtocolLib.c |  49 ++-
 .../Dxe/PldmProtocolLib.inf   |   6 +-
 .../ManageabilityPkg/ManageabilityPkg.dec |   6 +
 .../MctpProtocol/Common/MctpProtocolCommon.c  | 129 +++-
 .../Universal/MctpProtocol/Dxe/MctpProtocol.c |  51 +++-
 .../PldmProtocol/Common/PldmProtocolCommon.c  | 145 +++--
 .../PldmProtocol/Common/PldmProtocolCommon.h  |  25 +-
 .../Universal/PldmProtocol/Dxe/PldmProtocol.c |  69 -
 .../PldmProtocol/Dxe/PldmProtocolDxe.inf  |   4 -
 .../PldmSmbiosTransferDxe.c   |  28 ++
 17 files changed, 688 insertions(+), 193 deletions(-)

-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109850): https://edk2.groups.io/g/devel/message/109850
Mute This Topic: https://groups.io/mt/102080227/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms v2 01/15] ManageabilityPkg: Add definition for the MCTP KCS TRAILER structure

2023-10-20 Thread Konstantin Aladyshev

Currently there is only a definition for the MCTP KCS HEADER structure.
Add definition for the MCTP KCS TRAILER structure as well.

Signed-off-by: Konstantin Aladyshev 
Signed-off-by: Abner Chang 
---
 .../Library/ManageabilityTransportMctpLib.h|  5 +
 .../MctpProtocol/Common/MctpProtocolCommon.c   | 14 +++---
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git 
a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportMctpLib.h 
b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportMctpLib.h
index 43bd142f4c..462e7436e6 100644
--- a/Features/ManageabilityPkg/Include/Library/ManageabilityTransportMctpLib.h
+++ b/Features/ManageabilityPkg/Include/Library/ManageabilityTransportMctpLib.h
@@ -39,6 +39,11 @@ typedef struct {
   UINT8DefiningBody; ///< Message type.
   UINT8ByteCount;///< Byte count of payload.
 } MANAGEABILITY_MCTP_KCS_HEADER;
+
+typedef struct {
+  UINT8Pec;  ///< MCTP over KCS Packet Error Code.
+} MANAGEABILITY_MCTP_KCS_TRAILER;
+
 #define MCTP_KCS_NETFN_LUN   0xb0
 #define DEFINING_BODY_DMTF_PRE_OS_WORKING_GROUP  0x01
 
diff --git 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c 
b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
index 1ad48efdc7..7576007f77 100644
--- 
a/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
+++ 
b/Features/ManageabilityPkg/Universal/MctpProtocol/Common/MctpProtocolCommon.c
@@ -132,7 +132,7 @@ SetupMctpRequestTransportPacket (
   MANAGEABILITY_MCTP_KCS_HEADER  *MctpKcsHeader;
   MCTP_TRANSPORT_HEADER  *MctpTransportHeader;
   MCTP_MESSAGE_HEADER*MctpMessageHeader;
-  UINT8  *Pec;
+  MANAGEABILITY_MCTP_KCS_TRAILER *MctpKcsTrailer;
   UINT8  *ThisPackage;
 
   if ((PacketHeader == NULL) || (PacketHeaderSize == NULL) ||
@@ -151,8 +151,8 @@ SetupMctpRequestTransportPacket (
   return EFI_OUT_OF_RESOURCES;
 }
 
-Pec = (UINT8 *)AllocateZeroPool (sizeof (UINT8));
-if (Pec == NULL) {
+MctpKcsTrailer = (MANAGEABILITY_MCTP_KCS_TRAILER *)AllocateZeroPool 
(sizeof (MANAGEABILITY_MCTP_KCS_TRAILER));
+if (MctpKcsTrailer == NULL) {
   DEBUG ((DEBUG_ERROR, "%a: Not enough resource for PEC.\n", __func__));
   FreePool (MctpKcsHeader);
   return EFI_OUT_OF_RESOURCES;
@@ -167,7 +167,7 @@ SetupMctpRequestTransportPacket (
 if (ThisPackage == NULL) {
   DEBUG ((DEBUG_ERROR, "%a: Not enough resource for package.\n", 
__func__));
   FreePool (MctpKcsHeader);
-  FreePool (Pec);
+  FreePool (MctpKcsTrailer);
   return EFI_OUT_OF_RESOURCES;
 }
 
@@ -193,14 +193,14 @@ SetupMctpRequestTransportPacket (
 
 //
 // Generate PEC follow SMBUS 2.0 specification.
-*Pec = HelperManageabilityGenerateCrc8 (MCTP_KCS_PACKET_ERROR_CODE_POLY, 
0, ThisPackage, MctpKcsHeader->ByteCount);
+MctpKcsTrailer->Pec = HelperManageabilityGenerateCrc8 
(MCTP_KCS_PACKET_ERROR_CODE_POLY, 0, ThisPackage, MctpKcsHeader->ByteCount);
 
 *PacketBody= (UINT8 *)ThisPackage;
 *PacketBodySize= MctpKcsHeader->ByteCount;
-*PacketTrailer = (MANAGEABILITY_TRANSPORT_TRAILER)Pec;
+*PacketTrailer = (MANAGEABILITY_TRANSPORT_TRAILER)MctpKcsTrailer;
 *PacketHeader  = (MANAGEABILITY_TRANSPORT_HEADER)MctpKcsHeader;
 *PacketHeaderSize  = sizeof (MANAGEABILITY_MCTP_KCS_HEADER);
-*PacketTrailerSize = 1;
+*PacketTrailerSize = sizeof (MANAGEABILITY_MCTP_KCS_TRAILER);
 return EFI_SUCCESS;
   } else {
 DEBUG ((DEBUG_ERROR, "%a: No implementation of building up packet.", 
__func__));
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109851): https://edk2.groups.io/g/devel/message/109851
Mute This Topic: https://groups.io/mt/102080228/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device list

2023-10-20 Thread Laszlo Ersek

On 10/20/23 14:25, Laszlo Ersek wrote:
> On 10/20/23 13:30, John Chew wrote:
>> Hi Heinrich, Laszlo,
>>
>> Thank you very much for your support! Really appreciate it =D
>>
>> My account just approved few days ago, so original patch (submit few weeks 
>> back) is not in the mailing list.
> 
> Let me rectify that in a minute.

huh, I thought I'd find the patch email as "pending moderation" in the
moderators' queue, but it's not there.

(I can see you having been added as a member; your new messages seem to
be reflected, so that should be fine.)

I assume either one of the mods mis-clicked on your initial submission
(from 29 September, I think?), rejecting or deleting it instead or
approving it, or else nobody had taken notice and your patch email
"timed out". (I don't know if that's possible with groups.io; just
guessing.)

Either way I think I should have it from Heinrich now...

Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109849): https://edk2.groups.io/g/devel/message/109849
Mute This Topic: https://groups.io/mt/101660590/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] ArmPlatformPkg/PL031RealTimeClockLib: remove superfluous instance init steps

2023-10-20 Thread Ard Biesheuvel

On Fri, 20 Oct 2023 at 14:17, Laszlo Ersek  wrote:
>
> RealTimeClockLib instances are consumed by edk2's
> EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
> InitializeRealTimeClock(), the driver:
>
> (1) calls LibRtcInitialize(),
>
> (2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
> runtime services to its own similarly-named functions -- where those
> functions wrap the corresponding RealTimeClockLib APIs,
>
> (3) installs EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL with a NULL protocol
> interface.
>
> Steps (2) and (3) conform to PI v1.8 sections II-9.7.2.4 through
> II-9.7.2.7.
>
> However, this means that LibRtcInitialize() (of any RealTimeClockLib
> instance) should not itself (a) set the GetTime(), SetTime(),
> GetWakeupTime() and SetWakeupTime() runtime services, nor (b) install
> EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL. The runtime service pointers will be
> overwritten in step (2) anyway, and step (3) will uselessly install a
> second (NULL-interface) EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL instance in the
> protocol database. (The protocol only serves to notify the DXE Foundation
> about said runtime services being available.)
>
> Clean up ArmPlatformPkg/PL031RealTimeClockLib accordingly (it only has
> code that's redundant for step (3); it does not try to set "gRT" fields).
>
> (Note that the lib instance INF file already does not list
> gEfiRealTimeClockArchProtocolGuid.)
>
> Tested with ArmVirtQemu.
>
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4565
> Signed-off-by: Laszlo Ersek 
> ---
>
> Notes:
> context:-W
>
>  ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c | 13 
> -
>  1 file changed, 13 deletions(-)
>

Acked-by: Ard Biesheuvel 

Thanks a lot for cleaning up this mess.


> diff --git 
> a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c 
> b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
> index 9e852696d2fd..1896f9d16d3b 100644
> --- a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
> +++ b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
> @@ -1,34 +1,32 @@
>  /** @file
>Implement EFI RealTimeClock runtime services via RTC Lib.
>
>Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
>Copyright (c) 2011 - 2020, Arm Limited. All rights reserved.
>Copyright (c) 2019, Linaro Ltd. All rights reserved.
>
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
>  **/
>
>  #include 
>
>  #include 
>  #include 
>
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>
> -#include 
> -
>  #include "PL031RealTimeClock.h"
>
>  STATIC BOOLEANmPL031Initialized = FALSE;
> @@ -307,52 +305,41 @@ EFIAPI
>  LibRtcInitialize (
>IN EFI_HANDLEImageHandle,
>IN EFI_SYSTEM_TABLE  *SystemTable
>)
>  {
>EFI_STATUS  Status;
> -  EFI_HANDLE  Handle;
>
>// Initialize RTC Base Address
>mPL031RtcBase = PcdGet32 (PcdPL031RtcBase);
>
>// Declare the controller as EFI_MEMORY_RUNTIME
>Status = gDS->AddMemorySpace (
>EfiGcdMemoryTypeMemoryMappedIo,
>mPL031RtcBase,
>SIZE_4KB,
>EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
>);
>if (EFI_ERROR (Status)) {
>  return Status;
>}
>
>Status = gDS->SetMemorySpaceAttributes (mPL031RtcBase, SIZE_4KB, 
> EFI_MEMORY_UC | EFI_MEMORY_RUNTIME);
>if (EFI_ERROR (Status)) {
>  return Status;
>}
>
> -  // Install the protocol
> -  Handle = NULL;
> -  Status = gBS->InstallMultipleProtocolInterfaces (
> -  &Handle,
> -  &gEfiRealTimeClockArchProtocolGuid,
> -  NULL,
> -  NULL
> -  );
> -  ASSERT_EFI_ERROR (Status);
> -
>//
>// Register for the virtual address change event
>//
>Status = gBS->CreateEventEx (
>EVT_NOTIFY_SIGNAL,
>TPL_NOTIFY,
>VirtualNotifyEvent,
>NULL,
>&gEfiEventVirtualAddressChangeGuid,
>&mRtcVirtualAddrChangeEvent
>);
>ASSERT_EFI_ERROR (Status);
>
>return Status;
>  }


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109848): https://edk2.groups.io/g/devel/message/109848
Mute This Topic: https://groups.io/mt/102079629/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms PATCH 0/7] drop needless init steps in RealTimeClockLib instances

2023-10-20 Thread Ard Biesheuvel

On Fri, 20 Oct 2023 at 14:19, Laszlo Ersek  wrote:
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=4565
>
> RealTimeClockLib instances should neither set gRT fields nor install
> EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL in LibRtcInitialize();
> EmbeddedPkg/RealTimeClockRuntimeDxe already performs those actions.
>
> Cc: Ard Biesheuvel 
> Cc: Bibo Mao 
> Cc: Chao Li 
> Cc: Leif Lindholm 
> Cc: Ling Jia 
> Cc: Marcin Wojtas 
> Cc: Peng Xie 
> Cc: Wenyi Xie 
> Cc: Xianglai li 
> Cc: Yiqi Shu 
>
> Thanks
> Laszlo
>
> Laszlo Ersek (7):
>   Hisilicon/DS3231RealTimeClockLib: remove superfluous instance init
> steps
>   LoongArchQemuPkg/LsRealTimeClockLib: remove superfluous instance init
> steps
>   Hisilicon/M41T83RealTimeClockLib: remove superfluous instance init
> steps
>   Hisilicon/RX8900RealTimeClockLib: remove superfluous instance init
> steps
>   Silicon/Marvell/RealTimeClockLib: remove superfluous instance init
> steps
>   FT2000-4Pkg/RealTimeClockLib: remove superfluous instance init steps
>   Omap35xxPkg/RealTimeClockLib: remove superfluous instance init steps
>

For the series,

Acked-by: Ard Biesheuvel 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109847): https://edk2.groups.io/g/devel/message/109847
Mute This Topic: https://groups.io/mt/102079655/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device list

2023-10-20 Thread Heinrich Schuchardt


On 20.10.23 11:49, Laszlo Ersek wrote:

On 10/18/23 10:57, Ard Biesheuvel wrote:

On Wed, 18 Oct 2023 at 10:49, YuinYee Chew
  wrote:

Dear Maintainers,

Just a friendly reminder to ask if you could take a look at my patch. I'd 
really appreciate your feedback and help.


Thanks for the reminder. I don't have time to review this myself but
I'm happy to merge it if someone else reviews it

Heinrich gave an Acked-by up-thread.

(I'd just go ahead and merge this myself to help you out a bit, but I
don't have access to the original patch!)

Laszlo


See appendix.

Best regards

Heinrich


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109846): https://edk2.groups.io/g/devel/message/109846
Mute This Topic: https://groups.io/mt/101660590/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


--- Begin Message ---
Update Gigadevice norflash list:
gd25q16, gd25q32, gd25q64, gd25lq64c, gd25q128, gd25lq128, gd25q256

Add Silicon Kaiser norflash list:
sk25lp128

Cc: Sunil V L 
Cc: Li Yong 
Cc: Heinrich Schuchardt 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Abner Chang 
Cc: Daniel Schaefer 
Signed-off-by: John Chew 
---
 EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c 
b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
index e16c1c6a14..422fdac851 100644
--- a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
+++ b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
@@ -1,6 +1,7 @@
 /** @file
 *
 *  Copyright (c) 2017 Marvell International Ltd.
+*  Copyright (c) 2023 StarFive, Technology Co., Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -33,12 +34,20 @@ STATIC CONST NOR_FLASH_INFO  NorFlashIds[] = {
   { L"en25q128b",  { 0x1c, 0x30, 0x18 }, 3, 256, 64 * 1024,  256,  0   
 },
   { L"en25s64",{ 0x1c, 0x38, 0x17 }, 3, 256, 64 * 1024,  128,  0   
 },
   /* GIGADEVICE */
-  { L"gd25q64b",   { 0xc8, 0x40, 0x17 }, 3, 256, 64 * 1024,  128,  
NOR_FLASH_ERASE_4K   },
+  { L"gd25q16",{ 0xc8, 0x40, 0x15 }, 3, 256, 64 * 1024,  32,   
NOR_FLASH_ERASE_4K   },
+  { L"gd25q32",{ 0xc8, 0x40, 0x16 }, 3, 256, 64 * 1024,  64,   
NOR_FLASH_ERASE_4K   },
   { L"gd25lq32",   { 0xc8, 0x60, 0x16 }, 3, 256, 64 * 1024,  64,   
NOR_FLASH_ERASE_4K   },
+  { L"gd25q64b",   { 0xc8, 0x40, 0x17 }, 3, 256, 64 * 1024,  128,  
NOR_FLASH_ERASE_4K   },
+  { L"gd25lq64c",  { 0xc8, 0x60, 0x17 }, 3, 256, 64 * 1024,  128,  
NOR_FLASH_ERASE_4K   },
+  { L"gd25q128",   { 0xc8, 0x40, 0x18 }, 3, 256, 64 * 1024,  256,  
NOR_FLASH_ERASE_4K   },
+  { L"gd25lq128",  { 0xc8, 0x60, 0x18 }, 3, 256, 64 * 1024,  256,  
NOR_FLASH_ERASE_4K   },
+  { L"gd25q256",   { 0xc8, 0x40, 0x19 }, 3, 256, 64 * 1024,  512,  
NOR_FLASH_ERASE_4K   },
   /* ISSI */
   { L"is25lp032",  { 0x9d, 0x60, 0x16 }, 3, 256, 64 * 1024,  64,   0   
 },
   { L"is25lp064",  { 0x9d, 0x60, 0x17 }, 3, 256, 64 * 1024,  128,  0   
 },
   { L"is25lp128",  { 0x9d, 0x60, 0x18 }, 3, 256, 64 * 1024,  256,  0   
 },
+  /* XINKAI / SILICON KAISER */
+  { L"sk25lp128",  { 0x27, 0x70, 0x18 }, 3, 256, 64 * 1024,  256,  
NOR_FLASH_ERASE_4K   },
   /* MACRONIX */
   { L"mx25l2006e", { 0xc2, 0x20, 0x12 }, 3, 256, 64 * 1024,  4,0   
 },
   { L"mx25l4005",  { 0xc2, 0x20, 0x13 }, 3, 256, 64 * 1024,  8,0   
 },
-- 
2.34.1

--- End Message ---

Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device list

2023-10-20 Thread Ard Biesheuvel

On Fri, 20 Oct 2023 at 11:49, Laszlo Ersek  wrote:
>
> On 10/18/23 10:57, Ard Biesheuvel wrote:
> > On Wed, 18 Oct 2023 at 10:49, YuinYee Chew
> >  wrote:
> >>
> >> Dear Maintainers,
> >>
> >> Just a friendly reminder to ask if you could take a look at my patch. I'd 
> >> really appreciate your feedback and help.
> >>
> >
> > Thanks for the reminder. I don't have time to review this myself but
> > I'm happy to merge it if someone else reviews it
>
> Heinrich gave an Acked-by up-thread.
>
> (I'd just go ahead and merge this myself to help you out a bit, but I
> don't have access to the original patch!)
>

OK, thanks.

I'll queue this up.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109845): https://edk2.groups.io/g/devel/message/109845
Mute This Topic: https://groups.io/mt/101660590/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device list

2023-10-20 Thread Laszlo Ersek

On 10/20/23 13:30, John Chew wrote:
> Hi Heinrich, Laszlo,
> 
> Thank you very much for your support! Really appreciate it =D
> 
> My account just approved few days ago, so original patch (submit few weeks 
> back) is not in the mailing list.

Let me rectify that in a minute.

Laszlo

> 
> Regards,
> John
> 
> -Original Message-
> From: Heinrich Schuchardt  
> Sent: Friday, October 20, 2023 6:44 PM
> To: Laszlo Ersek 
> Cc: Sunil V L ; Li Yong ; Leif 
> Lindholm ; Ard Biesheuvel 
> ; Abner Chang ; Daniel 
> Schaefer ; devel@edk2.groups.io; YuinYee Chew 
> ; a...@kernel.org
> Subject: Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update 
> norflash device list
> 
> On 20.10.23 11:49, Laszlo Ersek wrote:
>> On 10/18/23 10:57, Ard Biesheuvel wrote:
>>> On Wed, 18 Oct 2023 at 10:49, YuinYee Chew 
>>>   wrote:
 Dear Maintainers,

 Just a friendly reminder to ask if you could take a look at my patch. I'd 
 really appreciate your feedback and help.

>>> Thanks for the reminder. I don't have time to review this myself but 
>>> I'm happy to merge it if someone else reviews it
>> Heinrich gave an Acked-by up-thread.
>>
>> (I'd just go ahead and merge this myself to help you out a bit, but I 
>> don't have access to the original patch!)
>>
>> Laszlo
> 
> See appendix.
> 
> Best regards
> 
> Heinrich
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109844): https://edk2.groups.io/g/devel/message/109844
Mute This Topic: https://groups.io/mt/101660590/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms PATCH 6/7] FT2000-4Pkg/RealTimeClockLib: remove superfluous instance init steps

2023-10-20 Thread Laszlo Ersek

RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:

(1) calls LibRtcInitialize(),

(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own similarly-named functions -- where those
functions wrap the corresponding RealTimeClockLib APIs,

(3) installs EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL with a NULL protocol
interface.

Steps (2) and (3) conform to PI v1.8 sections II-9.7.2.4 through
II-9.7.2.7.

However, this means that LibRtcInitialize() (of any RealTimeClockLib
instance) should not itself (a) set the GetTime(), SetTime(),
GetWakeupTime() and SetWakeupTime() runtime services, nor (b) install
EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL. The runtime service pointers will be
overwritten in step (2) anyway, and step (3) will uselessly install a
second (NULL-interface) EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL instance in the
protocol database. (The protocol only serves to notify the DXE Foundation
about said runtime services being available.)

Clean up FT2000-4Pkg/RealTimeClockLib accordingly (it only has code that's
redundant for step (3); it does not try to set "gRT" fields).

(Note that the lib instance INF file already does not list
gEfiRealTimeClockArchProtocolGuid.)

Build-tested only (with "DurianPkg.dsc").

Cc: Leif Lindholm 
Cc: Ling Jia 
Cc: Peng Xie 
Cc: Yiqi Shu 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4565
Signed-off-by: Laszlo Ersek 
---
 Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.c | 13 
-
 1 file changed, 13 deletions(-)

diff --git 
a/Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.c 
b/Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.c
index 5c3d0cdccff8..26fbd7a3552a 100644
--- a/Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.c
+++ b/Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "RealTimeClockLib.h"
 
 STATIC EFI_EVENTmRtcVirtualAddrChangeEvent;
@@ -344,7 +343,6 @@ LibRtcInitialize (
   )
 {
   EFI_STATUSStatus;
-  EFI_HANDLE  Handle;
   INT16 TimeZone;
   UINTN Size;
   EFI_TIMETime;
@@ -437,17 +435,6 @@ LibRtcInitialize (
 return Status;
   }
   //
-  // Install the protocol
-  //
-  Handle = NULL;
-  Status = gBS->InstallMultipleProtocolInterfaces (
-&Handle,
-&gEfiRealTimeClockArchProtocolGuid,
-NULL,
-NULL
-);
-  ASSERT_EFI_ERROR (Status);
-  //
   // Register for the virtual address change event
   //
   Status = gBS->CreateEventEx (



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109842): https://edk2.groups.io/g/devel/message/109842
Mute This Topic: https://groups.io/mt/102079661/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms PATCH 4/7] Hisilicon/RX8900RealTimeClockLib: remove superfluous instance init steps

2023-10-20 Thread Laszlo Ersek

RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:

(1) calls LibRtcInitialize(),

(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own similarly-named functions -- where those
functions wrap the corresponding RealTimeClockLib APIs,

(3) installs EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL with a NULL protocol
interface.

Steps (2) and (3) conform to PI v1.8 sections II-9.7.2.4 through
II-9.7.2.7.

However, this means that LibRtcInitialize() (of any RealTimeClockLib
instance) should not itself (a) set the GetTime(), SetTime(),
GetWakeupTime() and SetWakeupTime() runtime services, nor (b) install
EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL. The runtime service pointers will be
overwritten in step (2) anyway, and step (3) will uselessly install a
second (NULL-interface) EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL instance in the
protocol database. (The protocol only serves to notify the DXE Foundation
about said runtime services being available.)

Clean up Hisilicon/RX8900RealTimeClockLib accordingly.

(Note that the lib instance INF file already does not list
UefiBootServicesTableLib, UefiRuntimeServicesTableLib, and
gEfiRealTimeClockArchProtocolGuid.)

Note that this patch is *untestable* in edk2-platforms (and in
edk2-non-osi too), because no platform consumes RX8900RealTimeClockLib --
worse, there hasn't been a single consumer since the introduction of the
lib instance in commit de704335c47f ("Silicon/Hisilicon: Add
RX8900RealTimeClockLib", 2020-05-20).

Normally this would nominate RX8900RealTimeClockLib to the axe, but commit
de704335c47f said, "There are some boards base on D06, but use RX8900 RTC,
so upstream the RX8900RealTimeClockLib", so I guess there might be
out-of-tree / proprietary consumers. Quite unfortunate.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Wenyi Xie 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4565
Signed-off-by: Laszlo Ersek 
---
 Silicon/Hisilicon/Library/RX8900RealTimeClockLib/RX8900RealTimeClockLib.c | 24 
+++-
 1 file changed, 3 insertions(+), 21 deletions(-)

diff --git 
a/Silicon/Hisilicon/Library/RX8900RealTimeClockLib/RX8900RealTimeClockLib.c 
b/Silicon/Hisilicon/Library/RX8900RealTimeClockLib/RX8900RealTimeClockLib.c
index ea41202fc72a..eaaf95a1979d 100644
--- a/Silicon/Hisilicon/Library/RX8900RealTimeClockLib/RX8900RealTimeClockLib.c
+++ b/Silicon/Hisilicon/Library/RX8900RealTimeClockLib/RX8900RealTimeClockLib.c
@@ -15,11 +15,8 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
-#include 
 #include "RX8900RealTimeClock.h"
 
 extern I2C_DEVICE gRtcDevice;
@@ -417,16 +414,9 @@ LibRtcInitialize (
   )
 {
   EFI_STATUSStatus;
-  EFI_HANDLEHandle;
   EFI_TIME  EfiTime;
 
-  // Setup the setters and getters
-  gRT->GetTime = LibGetTime;
-  gRT->SetTime = LibSetTime;
-  gRT->GetWakeupTime = LibGetWakeupTime;
-  gRT->SetWakeupTime = LibSetWakeupTime;
-
-  Status = gRT->GetTime (&EfiTime, NULL);
+  Status = LibGetTime (&EfiTime, NULL);
   if (EFI_ERROR (Status) || (EfiTime.Year < 2000) || (EfiTime.Year > 2099) ||
   (!IsTimeValid (&EfiTime))) {
EfiTime.Year = 2000;
@@ -439,19 +429,11 @@ LibRtcInitialize (
EfiTime.Daylight = 0;
EfiTime.TimeZone = EFI_UNSPECIFIED_TIMEZONE;
 
-  Status = gRT->SetTime (&EfiTime);
+  Status = LibSetTime (&EfiTime);
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "SetTime Status : %r\n", Status));
   }
   }
 
-  Handle = NULL;
-  Status = gBS->InstallMultipleProtocolInterfaces (
-  &Handle,
-  &gEfiRealTimeClockArchProtocolGuid,
-  NULL,
-  NULL
- );
-
-  return Status;
+  return EFI_SUCCESS;
 }



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109843): https://edk2.groups.io/g/devel/message/109843
Mute This Topic: https://groups.io/mt/102079662/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms PATCH 7/7] Omap35xxPkg/RealTimeClockLib: remove superfluous instance init steps

2023-10-20 Thread Laszlo Ersek

RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:

(1) calls LibRtcInitialize(),

(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own similarly-named functions -- where those
functions wrap the corresponding RealTimeClockLib APIs,

(3) installs EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL with a NULL protocol
interface.

Steps (2) and (3) conform to PI v1.8 sections II-9.7.2.4 through
II-9.7.2.7.

However, this means that LibRtcInitialize() (of any RealTimeClockLib
instance) should not itself (a) set the GetTime(), SetTime(),
GetWakeupTime() and SetWakeupTime() runtime services, nor (b) install
EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL. The runtime service pointers will be
overwritten in step (2) anyway, and step (3) will uselessly install a
second (NULL-interface) EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL instance in the
protocol database. (The protocol only serves to notify the DXE Foundation
about said runtime services being available.)

Clean up Omap35xxPkg/RealTimeClockLib accordingly.

(Note that the lib instance INF file already does not list
UefiRuntimeServicesTableLib and gEfiRealTimeClockArchProtocolGuid.)

Build-tested only (with "BeagleBoardPkg.dsc").

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4565
Signed-off-by: Laszlo Ersek 
---
 
Silicon/TexasInstruments/Omap35xxPkg/Library/RealTimeClockLib/RealTimeClockLib.c
 | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git 
a/Silicon/TexasInstruments/Omap35xxPkg/Library/RealTimeClockLib/RealTimeClockLib.c
 
b/Silicon/TexasInstruments/Omap35xxPkg/Library/RealTimeClockLib/RealTimeClockLib.c
index 10920a13786b..24fcaaf125c4 100644
--- 
a/Silicon/TexasInstruments/Omap35xxPkg/Library/RealTimeClockLib/RealTimeClockLib.c
+++ 
b/Silicon/TexasInstruments/Omap35xxPkg/Library/RealTimeClockLib/RealTimeClockLib.c
@@ -10,11 +10,9 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-#include 
 #include 
 
 #include 
@@ -242,7 +240,6 @@ LibRtcInitialize (
   )
 {
   EFI_STATUSStatus;
-  EFI_HANDLEHandle;
   UINT8 Data;
   EFI_TPL   OldTpl;
 
@@ -255,19 +252,5 @@ LibRtcInitialize (
   ASSERT_EFI_ERROR(Status);
   gBS->RestoreTPL(OldTpl);
 
-  // Setup the setters and getters
-  gRT->GetTime   = LibGetTime;
-  gRT->SetTime   = LibSetTime;
-  gRT->GetWakeupTime = LibGetWakeupTime;
-  gRT->SetWakeupTime = LibSetWakeupTime;
-
-  // Install the protocol
-  Handle = NULL;
-  Status = gBS->InstallMultipleProtocolInterfaces (
-  &Handle,
-  &gEfiRealTimeClockArchProtocolGuid,  NULL,
-  NULL
- );
-
-  return Status;
+  return EFI_SUCCESS;
 }


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109841): https://edk2.groups.io/g/devel/message/109841
Mute This Topic: https://groups.io/mt/102079660/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms PATCH 2/7] LoongArchQemuPkg/LsRealTimeClockLib: remove superfluous instance init steps

2023-10-20 Thread Laszlo Ersek

RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:

(1) calls LibRtcInitialize(),

(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own similarly-named functions -- where those
functions wrap the corresponding RealTimeClockLib APIs,

(3) installs EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL with a NULL protocol
interface.

Steps (2) and (3) conform to PI v1.8 sections II-9.7.2.4 through
II-9.7.2.7.

However, this means that LibRtcInitialize() (of any RealTimeClockLib
instance) should not itself (a) set the GetTime(), SetTime(),
GetWakeupTime() and SetWakeupTime() runtime services, nor (b) install
EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL. The runtime service pointers will be
overwritten in step (2) anyway, and step (3) will uselessly install a
second (NULL-interface) EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL instance in the
protocol database. (The protocol only serves to notify the DXE Foundation
about said runtime services being available.)

Clean up LoongArchQemuPkg/LsRealTimeClockLib accordingly.

(Note that the lib instance INF file already does not list
UefiRuntimeServicesTableLib.)

Build-tested only (with "Loongson.dsc").

Cc: Bibo Mao 
Cc: Chao Li 
Cc: Xianglai li 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4565
Signed-off-by: Laszlo Ersek 
---

Notes:
context:-W

 
Platform/Loongson/LoongArchQemuPkg/Library/LsRealTimeClockLib/LsRealTimeClockLib.inf
 |  3 ---
 
Platform/Loongson/LoongArchQemuPkg/Library/LsRealTimeClockLib/LsRealTimeClockLib.c
   | 16 
 2 files changed, 19 deletions(-)

diff --git 
a/Platform/Loongson/LoongArchQemuPkg/Library/LsRealTimeClockLib/LsRealTimeClockLib.inf
 
b/Platform/Loongson/LoongArchQemuPkg/Library/LsRealTimeClockLib/LsRealTimeClockLib.inf
index 5aa95650f8ba..c5ab1a702167 100644
--- 
a/Platform/Loongson/LoongArchQemuPkg/Library/LsRealTimeClockLib/LsRealTimeClockLib.inf
+++ 
b/Platform/Loongson/LoongArchQemuPkg/Library/LsRealTimeClockLib/LsRealTimeClockLib.inf
@@ -40,8 +40,5 @@ [Pcd]
 [Guids]
   gEfiEventVirtualAddressChangeGuid
 
-[Protocols]
-  gEfiRealTimeClockArchProtocolGuid # PROTOCOL ALWAYS_PRODUCED
-
 [Depex]
   TRUE
diff --git 
a/Platform/Loongson/LoongArchQemuPkg/Library/LsRealTimeClockLib/LsRealTimeClockLib.c
 
b/Platform/Loongson/LoongArchQemuPkg/Library/LsRealTimeClockLib/LsRealTimeClockLib.c
index eeac011a9400..954589ecb328 100644
--- 
a/Platform/Loongson/LoongArchQemuPkg/Library/LsRealTimeClockLib/LsRealTimeClockLib.c
+++ 
b/Platform/Loongson/LoongArchQemuPkg/Library/LsRealTimeClockLib/LsRealTimeClockLib.c
@@ -1,30 +1,28 @@
 /** @file
   Implement EFI RealTimeClock runtime services via RTC Lib.
 
   Copyright (c) 2022, Loongson Limited. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
 #include 
 #include 
 
 #include 
 #include 
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include "LsRealTimeClock.h"
 
 STATIC BOOLEANmInitialized = FALSE;
@@ -291,46 +289,32 @@ EFIAPI
 LibRtcInitialize (
   IN EFI_HANDLEImageHandle,
   IN EFI_SYSTEM_TABLE  *SystemTable
   )
 {
   EFI_STATUSStatus;
-  EFI_HANDLEHandle;
 
   InitRtc ();
   Status = KvmtoolRtcMapMemory (ImageHandle, (mRtcBase & ~EFI_PAGE_MASK));
   if (EFI_ERROR (Status)) {
 DEBUG ((
   DEBUG_ERROR,
   "Failed to map memory for loongson 7A RTC. Status = %r\n",
   Status
   ));
 return Status;
   }
 
-  // Setup the setters and getters
-  gRT->GetTime   = LibGetTime;
-  gRT->SetTime   = LibSetTime;
-
-  // Install the protocol
-  Handle = NULL;
-  Status = gBS->InstallMultipleProtocolInterfaces (
-  &Handle,
-  &gEfiRealTimeClockArchProtocolGuid,  NULL,
-  NULL
- );
-  ASSERT_EFI_ERROR (Status);
-
   //
   // Register for the virtual address change event
   //
   Status = gBS->CreateEventEx (
   EVT_NOTIFY_SIGNAL,
   TPL_NOTIFY,
   VirtualNotifyEvent,
   NULL,
   &gEfiEventVirtualAddressChangeGuid,
   &mRtcVirtualAddrChangeEvent
   );
   ASSERT_EFI_ERROR (Status);
   return Status;
 }



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109840): https://edk2.groups.io/g/devel/message/109840
Mute This Topic: https://groups.io/mt/102079659/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms PATCH 5/7] Silicon/Marvell/RealTimeClockLib: remove superfluous instance init steps

2023-10-20 Thread Laszlo Ersek

RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:

(1) calls LibRtcInitialize(),

(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own similarly-named functions -- where those
functions wrap the corresponding RealTimeClockLib APIs,

(3) installs EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL with a NULL protocol
interface.

Steps (2) and (3) conform to PI v1.8 sections II-9.7.2.4 through
II-9.7.2.7.

However, this means that LibRtcInitialize() (of any RealTimeClockLib
instance) should not itself (a) set the GetTime(), SetTime(),
GetWakeupTime() and SetWakeupTime() runtime services, nor (b) install
EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL. The runtime service pointers will be
overwritten in step (2) anyway, and step (3) will uselessly install a
second (NULL-interface) EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL instance in the
protocol database. (The protocol only serves to notify the DXE Foundation
about said runtime services being available.)

Clean up Silicon/Marvell/RealTimeClockLib accordingly (it only has code
that's redundant for step (3); it does not try to set "gRT" fields).

(Note that the lib instance INF file already does not list
gEfiRealTimeClockArchProtocolGuid.)

Build-tested only (with "Armada70x0Db.dsc").

Cc: Leif Lindholm 
Cc: Marcin Wojtas 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4565
Signed-off-by: Laszlo Ersek 
---

Notes:
context:-W

 Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c | 19 
+--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git 
a/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c 
b/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c
index d538b030b111..c026ac2dee31 100644
--- a/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c
+++ b/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c
@@ -1,30 +1,29 @@
 /** @file
   Implement EFI RealTimeClock runtime services via RTC Lib.
 
   Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
   Copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
   Copyright (c) 2017, Marvell International Ltd. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 /**
   Derived from:
   ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
 
 **/
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include "RealTimeClockLib.h"
 
 STATIC EFI_EVENT  mRtcVirtualAddrChangeEvent;
@@ -245,85 +244,69 @@ EFIAPI
 LibRtcInitialize (
   IN EFI_HANDLEImageHandle,
   IN EFI_SYSTEM_TABLE  *SystemTable
   )
 {
-  EFI_HANDLEHandle;
   EFI_STATUSStatus;
 
   // Obtain RTC device base address
   mArmadaRtcBase = PcdGet64 (PcdRtcBaseAddress);
 
   // Check if the controller can be initialized
   if (mArmadaRtcBase == 0) {
 DEBUG ((DEBUG_ERROR, "RTC: None of controllers enabled\n"));
 return EFI_INVALID_PARAMETER;
   }
 
   // Declare the controller as EFI_MEMORY_RUNTIME
   Status = gDS->AddMemorySpace (
   EfiGcdMemoryTypeMemoryMappedIo,
   mArmadaRtcBase,
   SIZE_4KB,
   EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
   );
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "RTC: Failed to add memory space\n"));
 return Status;
   }
 
   Status = gDS->SetMemorySpaceAttributes (
   mArmadaRtcBase,
   SIZE_4KB,
   EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
   );
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "RTC: Failed to set memory attributes\n"));
 goto ErrSetMem;
   }
 
   /* Update RTC-MBUS bridge timing parameters */
   MmioAndThenOr32 (
   mArmadaRtcBase + RTC_BRIDGE_TIMING_CTRL0_REG_OFFS,
   ~(RTC_WRITE_SETUP_DELAY_MASK | RTC_WRITE_PERIOD_DELAY_MASK),
   (RTC_WRITE_SETUP_DELAY_DEFAULT | RTC_WRITE_PERIOD_DELAY_DEFAULT)
   );
   MmioAndThenOr32 (
   mArmadaRtcBase + RTC_BRIDGE_TIMING_CTRL1_REG_OFFS,
   ~RTC_READ_OUTPUT_DELAY_MASK,
   RTC_READ_OUTPUT_DELAY_DEFAULT
   );
 
-  // Install the protocol
-  Handle = NULL;
-  Status = gBS->InstallMultipleProtocolInterfaces (
-  &Handle,
-  &gEfiRealTimeClockArchProtocolGuid,
-  NULL,
-  NULL
- );
-  if (EFI_ERROR (Status)) {
-DEBUG ((DEBUG_ERROR, "RTC: Failed to install the protocol\n"));
-goto ErrSetMem;
-  }
-
   // Register for the virtual address change event
   Status = gBS->CreateEventEx (
   EVT_NOTIFY_SIGNAL,
   TPL_NOTIFY,
   VirtualNotifyEvent,
   NULL,
   &gEfiEvent

[edk2-devel] [edk2-platforms PATCH 3/7] Hisilicon/M41T83RealTimeClockLib: remove superfluous instance init steps

2023-10-20 Thread Laszlo Ersek

RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:

(1) calls LibRtcInitialize(),

(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own similarly-named functions -- where those
functions wrap the corresponding RealTimeClockLib APIs,

(3) installs EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL with a NULL protocol
interface.

Steps (2) and (3) conform to PI v1.8 sections II-9.7.2.4 through
II-9.7.2.7.

However, this means that LibRtcInitialize() (of any RealTimeClockLib
instance) should not itself (a) set the GetTime(), SetTime(),
GetWakeupTime() and SetWakeupTime() runtime services, nor (b) install
EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL. The runtime service pointers will be
overwritten in step (2) anyway, and step (3) will uselessly install a
second (NULL-interface) EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL instance in the
protocol database. (The protocol only serves to notify the DXE Foundation
about said runtime services being available.)

Clean up Hisilicon/M41T83RealTimeClockLib accordingly (it only has code
that's redundant for step (2); it does not try to install
EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL).

(Note that the lib instance INF file already does not list
UefiRuntimeServicesTableLib.)

Build-tested only (with the D06 platform).

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Wenyi Xie 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4565
Signed-off-by: Laszlo Ersek 
---
 Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.c | 7 
---
 1 file changed, 7 deletions(-)

diff --git 
a/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.c 
b/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.c
index 5f9465843475..3a2cd451c4ef 100644
--- a/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.c
+++ b/Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.c
@@ -18,7 +18,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "M41T83RealTimeClock.h"
 
 extern I2C_DEVICE gRtcDevice;
@@ -427,12 +426,6 @@ LibRtcInitialize (
 
   EfiInitializeLock (&mRtcLock, TPL_CALLBACK);
 
-  // Setup the setters and getters
-  gRT->GetTime   = LibGetTime;
-  gRT->SetTime   = LibSetTime;
-  gRT->GetWakeupTime = LibGetWakeupTime;
-  gRT->SetWakeupTime = LibSetWakeupTime;
-
   Status = InitializeM41T83 ();
   if (EFI_ERROR (Status)) {
 DEBUG ((DEBUG_ERROR, "[%a]:[%dL] Status : %r\nRTC M41T83 Init Failed 
!!!\n",



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109838): https://edk2.groups.io/g/devel/message/109838
Mute This Topic: https://groups.io/mt/102079657/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms PATCH 0/7] drop needless init steps in RealTimeClockLib instances

2023-10-20 Thread Laszlo Ersek

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

RealTimeClockLib instances should neither set gRT fields nor install
EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL in LibRtcInitialize();
EmbeddedPkg/RealTimeClockRuntimeDxe already performs those actions.

Cc: Ard Biesheuvel 
Cc: Bibo Mao 
Cc: Chao Li 
Cc: Leif Lindholm 
Cc: Ling Jia 
Cc: Marcin Wojtas 
Cc: Peng Xie 
Cc: Wenyi Xie 
Cc: Xianglai li 
Cc: Yiqi Shu 

Thanks
Laszlo

Laszlo Ersek (7):
  Hisilicon/DS3231RealTimeClockLib: remove superfluous instance init
steps
  LoongArchQemuPkg/LsRealTimeClockLib: remove superfluous instance init
steps
  Hisilicon/M41T83RealTimeClockLib: remove superfluous instance init
steps
  Hisilicon/RX8900RealTimeClockLib: remove superfluous instance init
steps
  Silicon/Marvell/RealTimeClockLib: remove superfluous instance init
steps
  FT2000-4Pkg/RealTimeClockLib: remove superfluous instance init steps
  Omap35xxPkg/RealTimeClockLib: remove superfluous instance init steps

 Platform/Hisilicon/D03/Library/DS3231RealTimeClockLib/DS3231RealTimeClockLib.c 
  | 27 +++-
 
Platform/Loongson/LoongArchQemuPkg/Library/LsRealTimeClockLib/LsRealTimeClockLib.c
   | 16 
 
Platform/Loongson/LoongArchQemuPkg/Library/LsRealTimeClockLib/LsRealTimeClockLib.inf
 |  3 ---
 Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.c  
  |  7 -
 Silicon/Hisilicon/Library/RX8900RealTimeClockLib/RX8900RealTimeClockLib.c  
  | 24 +++--
 Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c 
  | 19 +-
 Silicon/Phytium/FT2000-4Pkg/Library/RealTimeClockLib/RealTimeClockLib.c
  | 13 --
 
Silicon/TexasInstruments/Omap35xxPkg/Library/RealTimeClockLib/RealTimeClockLib.c
 | 19 +-
 8 files changed, 8 insertions(+), 120 deletions(-)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109837): https://edk2.groups.io/g/devel/message/109837
Mute This Topic: https://groups.io/mt/102079655/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms PATCH 1/7] Hisilicon/DS3231RealTimeClockLib: remove superfluous instance init steps

2023-10-20 Thread Laszlo Ersek

RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:

(1) calls LibRtcInitialize(),

(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own similarly-named functions -- where those
functions wrap the corresponding RealTimeClockLib APIs,

(3) installs EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL with a NULL protocol
interface.

Steps (2) and (3) conform to PI v1.8 sections II-9.7.2.4 through
II-9.7.2.7.

However, this means that LibRtcInitialize() (of any RealTimeClockLib
instance) should not itself (a) set the GetTime(), SetTime(),
GetWakeupTime() and SetWakeupTime() runtime services, nor (b) install
EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL. The runtime service pointers will be
overwritten in step (2) anyway, and step (3) will uselessly install a
second (NULL-interface) EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL instance in the
protocol database. (The protocol only serves to notify the DXE Foundation
about said runtime services being available.)

Clean up Hisilicon/DS3231RealTimeClockLib accordingly.

(Note that the lib instance INF file already does not list
UefiBootServicesTableLib, UefiRuntimeServicesTableLib, and
gEfiRealTimeClockArchProtocolGuid.)

Build-tested only (with the D03 and D05 platforms).

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Wenyi Xie 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4565
Signed-off-by: Laszlo Ersek 
---
 Platform/Hisilicon/D03/Library/DS3231RealTimeClockLib/DS3231RealTimeClockLib.c 
| 27 +++-
 1 file changed, 3 insertions(+), 24 deletions(-)

diff --git 
a/Platform/Hisilicon/D03/Library/DS3231RealTimeClockLib/DS3231RealTimeClockLib.c
 
b/Platform/Hisilicon/D03/Library/DS3231RealTimeClockLib/DS3231RealTimeClockLib.c
index 3a84b6e9297b..be143c47577b 100644
--- 
a/Platform/Hisilicon/D03/Library/DS3231RealTimeClockLib/DS3231RealTimeClockLib.c
+++ 
b/Platform/Hisilicon/D03/Library/DS3231RealTimeClockLib/DS3231RealTimeClockLib.c
@@ -25,11 +25,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include "DS3231RealTimeClock.h"
 #include 
@@ -433,19 +430,9 @@ LibRtcInitialize (
   )
 {
   EFI_STATUSStatus;
-  EFI_HANDLEHandle;
-
-
   EFI_TIME  EfiTime;
 
-  // Setup the setters and getters
-  gRT->GetTime   = LibGetTime;
-  gRT->SetTime   = LibSetTime;
-  gRT->GetWakeupTime = LibGetWakeupTime;
-  gRT->SetWakeupTime = LibSetWakeupTime;
-
-
-  (VOID)gRT->GetTime (&EfiTime, NULL);
+  (VOID)LibGetTime (&EfiTime, NULL);
   if((EfiTime.Year < 2015) || (EfiTime.Year > 2099)){
   EfiTime.Year  = 2015;
   EfiTime.Month = 1;
@@ -454,20 +441,12 @@ LibRtcInitialize (
   EfiTime.Minute= 0;
   EfiTime.Second= 0;
   EfiTime.Nanosecond= 0;
-  Status = gRT->SetTime(&EfiTime);
+  Status = LibSetTime(&EfiTime);
   if (EFI_ERROR(Status))
   {
 DEBUG((EFI_D_ERROR, "[%a]:[%dL] Status : %r\n", __FUNCTION__, 
__LINE__, Status));
   }
   }
 
-  // Install the protocol
-  Handle = NULL;
-  Status = gBS->InstallMultipleProtocolInterfaces (
-  &Handle,
-  &gEfiRealTimeClockArchProtocolGuid,  NULL,
-  NULL
- );
-
-  return Status;
+  return EFI_SUCCESS;
 }



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109836): https://edk2.groups.io/g/devel/message/109836
Mute This Topic: https://groups.io/mt/102079654/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] ArmPlatformPkg/PL031RealTimeClockLib: remove superfluous instance init steps

2023-10-20 Thread Laszlo Ersek

RealTimeClockLib instances are consumed by edk2's
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In its entry point function
InitializeRealTimeClock(), the driver:

(1) calls LibRtcInitialize(),

(2) sets the GetTime(), SetTime(), GetWakeupTime() and SetWakeupTime()
runtime services to its own similarly-named functions -- where those
functions wrap the corresponding RealTimeClockLib APIs,

(3) installs EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL with a NULL protocol
interface.

Steps (2) and (3) conform to PI v1.8 sections II-9.7.2.4 through
II-9.7.2.7.

However, this means that LibRtcInitialize() (of any RealTimeClockLib
instance) should not itself (a) set the GetTime(), SetTime(),
GetWakeupTime() and SetWakeupTime() runtime services, nor (b) install
EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL. The runtime service pointers will be
overwritten in step (2) anyway, and step (3) will uselessly install a
second (NULL-interface) EFI_REAL_TIME_CLOCK_ARCH_PROTOCOL instance in the
protocol database. (The protocol only serves to notify the DXE Foundation
about said runtime services being available.)

Clean up ArmPlatformPkg/PL031RealTimeClockLib accordingly (it only has
code that's redundant for step (3); it does not try to set "gRT" fields).

(Note that the lib instance INF file already does not list
gEfiRealTimeClockArchProtocolGuid.)

Tested with ArmVirtQemu.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4565
Signed-off-by: Laszlo Ersek 
---

Notes:
context:-W

 ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c | 13 
-
 1 file changed, 13 deletions(-)

diff --git 
a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c 
b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
index 9e852696d2fd..1896f9d16d3b 100644
--- a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
+++ b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
@@ -1,34 +1,32 @@
 /** @file
   Implement EFI RealTimeClock runtime services via RTC Lib.
 
   Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
   Copyright (c) 2011 - 2020, Arm Limited. All rights reserved.
   Copyright (c) 2019, Linaro Ltd. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
 
 #include 
 
 #include 
 #include 
 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
-#include 
-
 #include "PL031RealTimeClock.h"
 
 STATIC BOOLEANmPL031Initialized = FALSE;
@@ -307,52 +305,41 @@ EFIAPI
 LibRtcInitialize (
   IN EFI_HANDLEImageHandle,
   IN EFI_SYSTEM_TABLE  *SystemTable
   )
 {
   EFI_STATUS  Status;
-  EFI_HANDLE  Handle;
 
   // Initialize RTC Base Address
   mPL031RtcBase = PcdGet32 (PcdPL031RtcBase);
 
   // Declare the controller as EFI_MEMORY_RUNTIME
   Status = gDS->AddMemorySpace (
   EfiGcdMemoryTypeMemoryMappedIo,
   mPL031RtcBase,
   SIZE_4KB,
   EFI_MEMORY_UC | EFI_MEMORY_RUNTIME
   );
   if (EFI_ERROR (Status)) {
 return Status;
   }
 
   Status = gDS->SetMemorySpaceAttributes (mPL031RtcBase, SIZE_4KB, 
EFI_MEMORY_UC | EFI_MEMORY_RUNTIME);
   if (EFI_ERROR (Status)) {
 return Status;
   }
 
-  // Install the protocol
-  Handle = NULL;
-  Status = gBS->InstallMultipleProtocolInterfaces (
-  &Handle,
-  &gEfiRealTimeClockArchProtocolGuid,
-  NULL,
-  NULL
-  );
-  ASSERT_EFI_ERROR (Status);
-
   //
   // Register for the virtual address change event
   //
   Status = gBS->CreateEventEx (
   EVT_NOTIFY_SIGNAL,
   TPL_NOTIFY,
   VirtualNotifyEvent,
   NULL,
   &gEfiEventVirtualAddressChangeGuid,
   &mRtcVirtualAddrChangeEvent
   );
   ASSERT_EFI_ERROR (Status);
 
   return Status;
 }


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109835): https://edk2.groups.io/g/devel/message/109835
Mute This Topic: https://groups.io/mt/102079629/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device list

2023-10-20 Thread John Chew

Hi Heinrich, Laszlo,

Thank you very much for your support! Really appreciate it =D

My account just approved few days ago, so original patch (submit few weeks 
back) is not in the mailing list.

Regards,
John

-Original Message-
From: Heinrich Schuchardt  
Sent: Friday, October 20, 2023 6:44 PM
To: Laszlo Ersek 
Cc: Sunil V L ; Li Yong ; Leif 
Lindholm ; Ard Biesheuvel 
; Abner Chang ; Daniel Schaefer 
; devel@edk2.groups.io; YuinYee Chew 
; a...@kernel.org
Subject: Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update 
norflash device list

On 20.10.23 11:49, Laszlo Ersek wrote:
> On 10/18/23 10:57, Ard Biesheuvel wrote:
>> On Wed, 18 Oct 2023 at 10:49, YuinYee Chew 
>>   wrote:
>>> Dear Maintainers,
>>>
>>> Just a friendly reminder to ask if you could take a look at my patch. I'd 
>>> really appreciate your feedback and help.
>>>
>> Thanks for the reminder. I don't have time to review this myself but 
>> I'm happy to merge it if someone else reviews it
> Heinrich gave an Acked-by up-thread.
> 
> (I'd just go ahead and merge this myself to help you out a bit, but I 
> don't have access to the original patch!)
> 
> Laszlo

See appendix.

Best regards

Heinrich


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109834): https://edk2.groups.io/g/devel/message/109834
Mute This Topic: https://groups.io/mt/101660590/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 2/5] MdePkg ACPI65: Add 0x0B/PRM to Generic Address Structure

2023-10-20 Thread Jinlong Xu

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

ACPI_Spec_6_5_Aug29 Table 5.1, add 0x0B/Platform Runtime Mechanism (PRM)
in Address Space ID of Generic Address Structure (GAS)

Cc: Michael D Kinney 
Cc: Liming Gao 
Signed-off-by: Jinlong Xu 
---
 MdePkg/Include/IndustryStandard/Acpi65.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdePkg/Include/IndustryStandard/Acpi65.h 
b/MdePkg/Include/IndustryStandard/Acpi65.h
index 6caadf240498..86754a0e123a 100644
--- a/MdePkg/Include/IndustryStandard/Acpi65.h
+++ b/MdePkg/Include/IndustryStandard/Acpi65.h
@@ -43,6 +43,7 @@ typedef struct {
 #define EFI_ACPI_6_5_GENERAL_PURPOSE_IO  0x08
 #define EFI_ACPI_6_5_GENERIC_SERIAL_BUS  0x09
 #define EFI_ACPI_6_5_PLATFORM_COMMUNICATION_CHANNEL  0x0A
+#define EFI_ACPI_6_5_PLATFORM_RUNTIME_MECHANISM  0x0B
 #define EFI_ACPI_6_5_FUNCTIONAL_FIXED_HARDWARE   0x7F
 
 //
-- 
2.39.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109833): https://edk2.groups.io/g/devel/message/109833
Mute This Topic: https://groups.io/mt/102078727/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device list

2023-10-20 Thread Laszlo Ersek

On 10/18/23 10:57, Ard Biesheuvel wrote:
> On Wed, 18 Oct 2023 at 10:49, YuinYee Chew
>  wrote:
>>
>> Dear Maintainers,
>>
>> Just a friendly reminder to ask if you could take a look at my patch. I'd 
>> really appreciate your feedback and help.
>>
> 
> Thanks for the reminder. I don't have time to review this myself but
> I'm happy to merge it if someone else reviews it

Heinrich gave an Acked-by up-thread.

(I'd just go ahead and merge this myself to help you out a bit, but I
don't have access to the original patch!)

Laszlo


> 
> 
>>
>> -Original Message-
>> From: YuinYee Chew
>> Sent: Friday, September 29, 2023 9:35 PM
>> To: 'Heinrich Schuchardt' 
>> Cc: Sunil V L ; Li Yong ; Leif 
>> Lindholm ; Ard Biesheuvel 
>> ; Abner Chang ; Daniel 
>> Schaefer ; devel@edk2.groups.io
>> Subject: RE: [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device 
>> list
>>
>> Hi Heinrich,
>>
>> Both gd25lq128d and gd25lq128e share the same ID "{ 0xc8, 0x60, 0x18}"
>> gd25lq128d : 
>> https://www.gigadevice.com/product/flash/product-series/spi-nor-flash/gd25lq128d.html
>> gd25lq128e : 
>> https://www.gigadevice.com/product/flash/product-series/spi-nor-flash/gd25lq128e
>> So, I'm thinking to put it as "gd25lq128" to represent both "d" and "e".
>> If sync with Linux, gd25lq128d will be better.
>>
>> Do you have any suggestion on this?
>> Or anyone have any opinion?
>>
>> Thanks again for the feedback! =)
>>
>> -Original Message-
>> From: Heinrich Schuchardt 
>> Sent: Friday, September 29, 2023 4:55 PM
>> To: YuinYee Chew 
>> Cc: Sunil V L ; Li Yong ; Leif 
>> Lindholm ; Ard Biesheuvel 
>> ; Abner Chang ; Daniel 
>> Schaefer ; devel@edk2.groups.io
>> Subject: Re: [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device 
>> list
>>
>> On 9/29/23 04:02, John Chew wrote:
>>> Update Gigadevice norflash list:
>>> gd25q16, gd25q32, gd25q64, gd25lq64c, gd25q128, gd25lq128, gd25q256
>>>
>>> Add Silicon Kaiser norflash list:
>>> sk25lp128
>>>
>>> Cc: Sunil V L 
>>> Cc: Li Yong 
>>> Cc: Heinrich Schuchardt 
>>> Cc: Leif Lindholm 
>>> Cc: Ard Biesheuvel 
>>> Cc: Abner Chang 
>>> Cc: Daniel Schaefer 
>>> Signed-off-by: John Chew 
>>> ---
>>>   EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c | 11 ++-
>>>   1 file changed, 10 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
>>> b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
>>> index e16c1c6a14..422fdac851 100644
>>> --- a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
>>> +++ b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
>>> @@ -1,6 +1,7 @@
>>>   /** @file
>>>   *
>>>   *  Copyright (c) 2017 Marvell International Ltd.
>>> +*  Copyright (c) 2023 StarFive, Technology Co., Ltd. All rights
>>> +reserved.
>>>   *
>>>   *  SPDX-License-Identifier: BSD-2-Clause-Patent
>>>   *
>>> @@ -33,12 +34,20 @@ STATIC CONST NOR_FLASH_INFO  NorFlashIds[] = {
>>> { L"en25q128b",  { 0x1c, 0x30, 0x18 }, 3, 256, 64 * 1024,  256,  0  
>>>   },
>>> { L"en25s64",{ 0x1c, 0x38, 0x17 }, 3, 256, 64 * 1024,  128,  0  
>>>   },
>>> /* GIGADEVICE */
>>> -  { L"gd25q64b",   { 0xc8, 0x40, 0x17 }, 3, 256, 64 * 1024,  128,  
>>> NOR_FLASH_ERASE_4K   },
>>> +  { L"gd25q16",{ 0xc8, 0x40, 0x15 }, 3, 256, 64 * 1024,  32,   
>>> NOR_FLASH_ERASE_4K   },
>>> +  { L"gd25q32",{ 0xc8, 0x40, 0x16 }, 3, 256, 64 * 1024,  64,   
>>> NOR_FLASH_ERASE_4K   },
>>> { L"gd25lq32",   { 0xc8, 0x60, 0x16 }, 3, 256, 64 * 1024,  64,   
>>> NOR_FLASH_ERASE_4K   },
>>> +  { L"gd25q64b",   { 0xc8, 0x40, 0x17 }, 3, 256, 64 * 1024,  128,  
>>> NOR_FLASH_ERASE_4K   },
>>
>> Linux calls this gd25q64 but probably we don't want to change the displayed 
>> name.
>>
>>> +  { L"gd25lq64c",  { 0xc8, 0x60, 0x17 }, 3, 256, 64 * 1024,  128,  
>>> NOR_FLASH_ERASE_4K   },
>>> +  { L"gd25q128",   { 0xc8, 0x40, 0x18 }, 3, 256, 64 * 1024,  256,  
>>> NOR_FLASH_ERASE_4K   },
>>> +  { L"gd25lq128",  { 0xc8, 0x60, 0x18 }, 3, 256, 64 * 1024,  256,  
>>> NOR_FLASH_ERASE_4K   },
>>
>> Linux calls this gd25lq128d.
>>
>>> +  { L"gd25q256",   { 0xc8, 0x40, 0x19 }, 3, 256, 64 * 1024,  512,  
>>> NOR_FLASH_ERASE_4K   },
>>
>> Except for the two labels the changes match drivers/mtd/spi-nor/gigadevice.c 
>> in Linux.
>>
>>> /* ISSI */
>>> { L"is25lp032",  { 0x9d, 0x60, 0x16 }, 3, 256, 64 * 1024,  64,   0  
>>>   },
>>> { L"is25lp064",  { 0x9d, 0x60, 0x17 }, 3, 256, 64 * 1024,  128,  0  
>>>   },
>>> { L"is25lp128",  { 0x9d, 0x60, 0x18 }, 3, 256, 64 * 1024,  256,  0  
>>>   },
>>> +  /* XINKAI / SILICON KAISE

Re: [edk2-devel] [PATCH v1 4/6] StarFive/JH7110Pkg: Add PlatformBootManagerLib library

2023-10-20 Thread John Chew

Hi Sunil,

Actually, we can use:

Platform/RISC-V/PlatformPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf

I think there is no need for us to have our own PlatformBootManager library.

This library is here for debugging and development.

I will update this in patch v2.

Thanks! =)

John


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109831): https://edk2.groups.io/g/devel/message/109831
Mute This Topic: https://groups.io/mt/102053683/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v5 1/1] MdePkg: Add Cxl20.h into IndustryStandard

2023-10-20 Thread Chris Li OS via groups.io

@Liming, 

The CI looks good (see https://github.com/tianocore/edk2/pull/4932), and this 
v5 patch only contains space adjustment compared with v4 to make CI happy.
Kindly help merge this patch. Thanks a lot!

--

1) Add CXL 2.0 header file to comply with CXL 2.0 specification
2) CXL 2.0 header will embed Cxl11.h
3) Updated Cxl.h to point to 2.0 header file

Signed-off-by: Chris Li 
Reviewed-by: Liming Gao 
Cc: Ray Ni 
Cc: Yao, Jiewen 
Cc: Nong, Foster 
Cc: Kinney, Michael D 
---
 MdePkg/Include/IndustryStandard/Cxl.h   |   2 +-
 MdePkg/Include/IndustryStandard/Cxl20.h | 463 
 2 files changed, 464 insertions(+), 1 deletion(-)
 mode change 100644 => 100755 MdePkg/Include/IndustryStandard/Cxl.h
 create mode 100755 MdePkg/Include/IndustryStandard/Cxl20.h

diff --git a/MdePkg/Include/IndustryStandard/Cxl.h 
b/MdePkg/Include/IndustryStandard/Cxl.h
old mode 100644
new mode 100755
index 06c1230e3e..9ad3242e25
--- a/MdePkg/Include/IndustryStandard/Cxl.h
+++ b/MdePkg/Include/IndustryStandard/Cxl.h
@@ -12,7 +12,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #ifndef _CXL_MAIN_H_
 #define _CXL_MAIN_H_
 
-#include 
+#include 
 //
 // CXL assigned new Vendor ID
 //
diff --git a/MdePkg/Include/IndustryStandard/Cxl20.h 
b/MdePkg/Include/IndustryStandard/Cxl20.h
new file mode 100755
index 00..574f786881
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Cxl20.h
@@ -0,0 +1,463 @@
+/** @file
+  CXL 2.0 Register definitions
+
+  This file contains the register definitions based on the Compute Express Link
+  (CXL) Specification Revision 2.0.
+
+  Copyright (c) 2023, Ampere Computing LLC. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef CXL20_H_
+#define CXL20_H_
+
+#include 
+
+//
+// CXL DVSEC IDs
+// Compute Express Link Specification Revision 2.0 - Chapter 8.1.1
+//
+#define CXL_DVSEC_ID_PCIE_DVSEC_FOR_CXL_DEVICE 0x0
+#define CXL_DVSEC_ID_NON_CXL_FUNCTION_MAP  0x2
+#define CXL_DVSEC_ID_CXL20_EXTENSIONS_DVSEC_FOR_PORTS  0x3
+#define CXL_DVSEC_ID_GPF_DVSEC_FOR_CXL_PORTS   0x4
+#define CXL_DVSEC_ID_GPF_DVSEC_FOR_CXL_DEVICES 0x5
+#define CXL_DVSEC_ID_PCIE_DVSEC_FOR_FLEX_BUS_PORT  0x7
+#define CXL_DVSEC_ID_REGISTER_LOCATOR  0x8
+#define CXL_DVSEC_ID_MLD   0x9
+#define CXL_DVSEC_ID_PCIE_DVSEC_FOR_TEST_CAPABILITY0xA
+
+//
+// Register Block ID
+// Compute Express Link Specification Revision 2.0 - Chapter 8.1.9.1
+//
+#define CXL_REGISTER_BLOCK_ID_EMPTY   0x0
+#define CXL_REGISTER_BLOCK_ID_COMPONENT   0x1
+#define CXL_REGISTER_BLOCK_ID_BAR_VIRTUALIZATION_ACL  0x2
+#define CXL_REGISTER_BLOCK_ID_DEVICE  0x3
+
+//
+// CXL component register layout
+// Compute Express Link Specification Revision 2.0 - Chapter 8.2.4
+//
+// ||
+// |- Range & Type -|
+// || IO Base - 0KB
+// | (0KB - 4KB)IO Regs |
+// || Cache and Mem Base - 4KB
+// | {4KB - 8KB)Cache & Mem Regs|
+// || Implementation Spec Regs Base - 8KB
+// | (8KB - 56KB)Implement Spec Regs|
+// || ARB/Mux Regs Base - 56KB
+// | (56KB - 57KB)ARBMUX Regs   |
+// || Reserved Base - 57KB
+// | (57KB - 63KB)Reserved  |
+// || End 64KB
+//
+// Component Register Block Register Ranges Offset
+//
+#define CXL_COMPONENT_REGISTER_RANGE_OFFSET_IO 0x0
+#define CXL_COMPONENT_REGISTER_RANGE_OFFSET_CACHE_MEM  0x1000
+#define CXL_COMPONENT_REGISTER_RANGE_OFFSET_ARB_MUX0xE000
+
+//
+// CXL Cache Memory Capability IDs
+// Compute Express Link Specification Revision 2.0 - Chapter 8.2.5
+//
+#define CXL_CACHE_MEM_CAPABILITY_ID_CXL0x1
+#define CXL_CACHE_MEM_CAPABILITY_ID_RAS0x2
+#define CXL_CACHE_MEM_CAPABILITY_ID_SECURITY   0x3
+#define CXL_CACHE_MEM_CAPABILITY_ID_LINK   0x4
+#define CXL_CACHE_MEM_CAPABILITY_ID_HDM_DECODER0x5
+#define CXL_CACHE_MEM_CAPABILITY_ID_EXTENDED_SECURITY  0x6
+#define CXL_CACHE_MEM_CAPABILITY_ID_IDE0x7
+#define CXL_CACHE_MEM_CAPABILITY_ID_SNOOP_FILTER   0x8
+#define CXL_CACHE_MEM_CAPABILITY_ID_MASK   0x
+
+//
+// Generic CXL Device Capability IDs 0x ~ 0x3FFF
+// Compute Express Link Specification Revision 2.0 - Chapter 8.2.8.2.1
+//
+#define CXL_DEVICE_CAPABILITY_ID_CAPABILITIES_ARRAY_REGISTER  0x
+#define CXL_DEVICE_CAPABILITY_ID_DEVICE_STATUS0x0001
+#define CXL_DEVICE_CAPABILITY_ID_PRIMARY_MAILBOX  0x0002
+#define CXL_DEVICE_CAPABILITY_ID_SECONDARY_MAILBOX0x0003
+
+//
+// Specific CXL Device Capability IDs 0x4000 ~ 0x7FFF

Re: [edk2-devel] [PATCH v1 6/6] StarFive/JH7110Pkg: Add JH7110 Silicon Package

2023-10-20 Thread John Chew

On Thu, Oct 19, 2023 at 08:34 PM, Sunil V L wrote:

> 
> The patch should have commit message more than one liner. Same comment
> for PATCH 1/6 and 2/6

Hi Sunil,

Okay sure. I will remove the commented code.

Let me improve the commit message and include all maintainers in patch V2.

Thanks =)

John


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109829): https://edk2.groups.io/g/devel/message/109829
Mute This Topic: https://groups.io/mt/102053687/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/6] Patches for JH7110 SoC platform

2023-10-20 Thread John Chew

Hi Sunil,

Okay, thanks for reminding me. I will include Leif and Mike for all coming 
patches in Patch V2.

Thanks.

John


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109828): https://edk2.groups.io/g/devel/message/109828
Mute This Topic: https://groups.io/mt/102053672/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash device list

2023-10-20 Thread John Chew

Hi Ard

Thanks for your reply. 

I wonder if anyone have time to review this patch?

Thanks!

John

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Ard Biesheuvel
Sent: Wednesday, October 18, 2023 4:58 PM
To: YuinYee Chew 
Cc: devel@edk2.groups.io; Sunil V L ; Li Yong 
; Heinrich Schuchardt ; 
Leif Lindholm ; Ard Biesheuvel 
; Abner Chang ; Daniel Schaefer 

Subject: Re: [edk2-devel] [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update 
norflash device list

On Wed, 18 Oct 2023 at 10:49, YuinYee Chew  
wrote:
>
> Dear Maintainers,
>
> Just a friendly reminder to ask if you could take a look at my patch. I'd 
> really appreciate your feedback and help.
>

Thanks for the reminder. I don't have time to review this myself but I'm happy 
to merge it if someone else reviews it


>
> -Original Message-
> From: YuinYee Chew
> Sent: Friday, September 29, 2023 9:35 PM
> To: 'Heinrich Schuchardt' 
> Cc: Sunil V L ; Li Yong ; 
> Leif Lindholm ; Ard Biesheuvel 
> ; Abner Chang ; Daniel 
> Schaefer ; devel@edk2.groups.io
> Subject: RE: [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash 
> device list
>
> Hi Heinrich,
>
> Both gd25lq128d and gd25lq128e share the same ID "{ 0xc8, 0x60, 0x18}"
> gd25lq128d : 
> https://www.gigadevice.com/product/flash/product-series/spi-nor-flash/
> gd25lq128d.html gd25lq128e : 
> https://www.gigadevice.com/product/flash/product-series/spi-nor-flash/
> gd25lq128e So, I'm thinking to put it as "gd25lq128" to represent both 
> "d" and "e".
> If sync with Linux, gd25lq128d will be better.
>
> Do you have any suggestion on this?
> Or anyone have any opinion?
>
> Thanks again for the feedback! =)
>
> -Original Message-
> From: Heinrich Schuchardt 
> Sent: Friday, September 29, 2023 4:55 PM
> To: YuinYee Chew 
> Cc: Sunil V L ; Li Yong ; 
> Leif Lindholm ; Ard Biesheuvel 
> ; Abner Chang ; Daniel 
> Schaefer ; devel@edk2.groups.io
> Subject: Re: [PATCH v1] EmbeddedPkg/NorFlashInfoLib: Update norflash 
> device list
>
> On 9/29/23 04:02, John Chew wrote:
> > Update Gigadevice norflash list:
> > gd25q16, gd25q32, gd25q64, gd25lq64c, gd25q128, gd25lq128, gd25q256
> >
> > Add Silicon Kaiser norflash list:
> > sk25lp128
> >
> > Cc: Sunil V L 
> > Cc: Li Yong 
> > Cc: Heinrich Schuchardt 
> > Cc: Leif Lindholm 
> > Cc: Ard Biesheuvel 
> > Cc: Abner Chang 
> > Cc: Daniel Schaefer 
> > Signed-off-by: John Chew 
> > ---
> >   EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c | 11 ++-
> >   1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> > b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> > index e16c1c6a14..422fdac851 100644
> > --- a/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> > +++ b/EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.c
> > @@ -1,6 +1,7 @@
> >   /** @file
> >   *
> >   *  Copyright (c) 2017 Marvell International Ltd.
> > +*  Copyright (c) 2023 StarFive, Technology Co., Ltd. All rights 
> > +reserved.
> >   *
> >   *  SPDX-License-Identifier: BSD-2-Clause-Patent
> >   *
> > @@ -33,12 +34,20 @@ STATIC CONST NOR_FLASH_INFO  NorFlashIds[] = {
> > { L"en25q128b",  { 0x1c, 0x30, 0x18 }, 3, 256, 64 * 1024,  256,  0  
> >   },
> > { L"en25s64",{ 0x1c, 0x38, 0x17 }, 3, 256, 64 * 1024,  128,  0  
> >   },
> > /* GIGADEVICE */
> > -  { L"gd25q64b",   { 0xc8, 0x40, 0x17 }, 3, 256, 64 * 1024,  128,  
> > NOR_FLASH_ERASE_4K   },
> > +  { L"gd25q16",{ 0xc8, 0x40, 0x15 }, 3, 256, 64 * 1024,  32,   
> > NOR_FLASH_ERASE_4K   },
> > +  { L"gd25q32",{ 0xc8, 0x40, 0x16 }, 3, 256, 64 * 1024,  64,   
> > NOR_FLASH_ERASE_4K   },
> > { L"gd25lq32",   { 0xc8, 0x60, 0x16 }, 3, 256, 64 * 1024,  64,   
> > NOR_FLASH_ERASE_4K   },
> > +  { L"gd25q64b",   { 0xc8, 0x40, 0x17 }, 3, 256, 64 * 1024,  128,  
> > NOR_FLASH_ERASE_4K   },
>
> Linux calls this gd25q64 but probably we don't want to change the displayed 
> name.
>
> > +  { L"gd25lq64c",  { 0xc8, 0x60, 0x17 }, 3, 256, 64 * 1024,  128,  
> > NOR_FLASH_ERASE_4K   },
> > +  { L"gd25q128",   { 0xc8, 0x40, 0x18 }, 3, 256, 64 * 1024,  256,  
> > NOR_FLASH_ERASE_4K   },
> > +  { L"gd25lq128",  { 0xc8, 0x60, 0x18 }, 3, 256, 64 * 1024,  256,  
> > NOR_FLASH_ERASE_4K   },
>
> Linux calls this gd25lq128d.
>
> > +  { L"gd25q256",   { 0xc8, 0x40, 0x19 }, 3, 256, 64 * 1024,  512,  
> > NOR_FLASH_ERASE_4K   },
>
> Except for the two labels the changes match drivers/mtd/spi-nor/gigadevice.c 
> in Linux.
>
> > /* ISSI */
> > { L"is25lp032",  { 0x9d, 0x60, 0x16 }, 3, 256, 64 * 1024,  64,   0  
> >   },
> > { L"is25lp064",  { 0x9d, 0x60, 0x17 }, 3, 256, 64 * 1024,

Re: [edk2-devel] [PATCH v1 5/6] StarFive/JH7110Pkg: Implement boot services memory allocation driver

2023-10-20 Thread John Chew

Hi Sunil,

You're right.

The MMC DMA destination buffer (64-bit) actually allocated in EDK2 code and 
passed into the EDK2-platform MMC driver.

Now that you mention it, I think I can allocate another buffer (force to use 
32-bit) in the MMC driver and use that buffer for tx/rx.

Then, copy the content from the buffer (32-bit) to the MMC destination buffer 
(64-bit). In this case, there is no need to change any code

in EDK2 and this "boot service memory allocation" driver is no longer needed.

I will remove this driver and add the handling in DwEmmcDxe.c in Patch V2.

Thank you!! =)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109826): https://edk2.groups.io/g/devel/message/109826
Mute This Topic: https://groups.io/mt/102053685/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] Maintainers.txt: Add maintainers for Sophgo platform

2023-10-20 Thread Sunil V L

On Thu, Oct 19, 2023 at 09:48:15PM +0800, caiyuqing...@163.com wrote:
> From: caiyuqing379 
> 
> This "Platform/Sophgo/Maintainers.md" file format is useless with
> edk2's "BaseTools/Scripts/GetMaintainer.py" utility, so delete this
> file. Add add the maintainers to the "Maintainers.txt" file.
> 
> Cc: dahogn 
> Cc: meng-cz 
> Cc: USER0FISH 
> Cc: Sunil V L 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Laszlo Ersek 
> Signed-off-by: caiyuqing379 
> ---
>  Maintainers.txt|   9 ++
>  Platform/Sophgo/Maintainers.md | 105 
>  2 files changed, 9 insertions(+), 105 deletions(-)
> 

Thanks!

Reviewed-by: Sunil V L 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109824): https://edk2.groups.io/g/devel/message/109824
Mute This Topic: https://groups.io/mt/102060867/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

48 matches

Mail list logo