Date   

Re: RFC: Add BaseLib/QuickSort in MdePkg

Ni, Ray
 

Thanks everyone.
We will post patches to this mailing list that aligns to this proposal.

Thanks,
Ray

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of gaoliming
Sent: Wednesday, September 29, 2021 8:51 AM
To: 'Brian J. Johnson' <brian.johnson@...>; devel@edk2.groups.io; Ni, Ray <ray.ni@...>; 'Marvin Häuser' <mhaeuser@...>; fanjianfeng@...; Chan, Amy <amy.chan@...>; 'Andrew Fish' <afish@...>
Cc: Kinney, Michael D <michael.d.kinney@...>; 'Gao, Liming' <liming.gao@...>; Liu, Zhiguang <zhiguang.liu@...>; Wang, Jian J <jian.j.wang@...>; Gao, Zhichao <zhichao.gao@...>
Subject: 回复: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

Johnson:
I also agree this proposal to make BufferOneElement parameter mandatory.

Thanks
Liming
-----邮件原件-----
发件人: Brian J. Johnson <brian.johnson@...>
发送时间: 2021年9月29日 6:26
收件人: devel@edk2.groups.io; ray.ni@...; Marvin Häuser
<mhaeuser@...>; fanjianfeng@...; 'gaoliming'
<gaoliming@...>; Chan, Amy <amy.chan@...>; 'Andrew
Fish' <afish@...>
抄送: Kinney, Michael D <michael.d.kinney@...>; 'Gao, Liming'
<liming.gao@...>; Liu, Zhiguang <zhiguang.liu@...>; Wang,
Jian J <jian.j.wang@...>; Gao, Zhichao <zhichao.gao@...>
主题: Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

I'll add my agreement to Marvin and Jeff: a low-level sort routine
like this should let the caller be in charge of memory allocation, so
it can be used in the widest variety of contexts (SEC, exception
handlers, APs,
etc.) So let's make the BufferOneElement parameter mandatory.

Brian J. Johnson

-------- Original Message --------
From: Ni, Ray [mailto:ray.ni@...]
Sent: Monday, September 27, 2021, 8:49 PM
To: Marvin Häuser <mhaeuser@...>, fanjianfeng@...
<fanjianfeng@...>, devel@edk2.groups.io
<devel@edk2.groups.io>, 'gaoliming' <gaoliming@...>, Chan,
Amy <amy.chan@...>, 'Andrew Fish' <afish@...>
Cc: Kinney, Michael D <michael.d.kinney@...>, 'Gao, Liming'
<liming.gao@...>, Liu, Zhiguang <zhiguang.liu@...>, Wang,
Jian J <jian.j.wang@...>, Gao, Zhichao <zhichao.gao@...>
Subject: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

Marvin,
I agree with your concerns, in a certain level. But I didn't treat it
as a very big problem of having caller pass the BufferOneElement
"intelligently".

I am ok to use your option 1), making BufferOneElement mandatory.
Caller should always supply the buffer that's sufficient to hold one
element.

By the way, I don't want to propose "swap-without-using-temporary-value"
method to avoid using the "BufferOneElement"?
Because that makes the simple thing complicated!

Thanks,
Ray

-----Original Message-----
From: Marvin Häuser <mhaeuser@...>
Sent: Monday, September 27, 2021 5:09 PM
To: fanjianfeng@...; devel@edk2.groups.io; Ni, Ray
<ray.ni@...>; 'gaoliming'
<gaoliming@...>; Chan, Amy <amy.chan@...>; 'Andrew
Fish' <afish@...>
Cc: Kinney, Michael D <michael.d.kinney@...>; 'Gao, Liming'
<liming.gao@...>; Liu, Zhiguang
<zhiguang.liu@...>; Wang, Jian J <jian.j.wang@...>; Gao,
Zhichao <zhichao.gao@...>
Subject: Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

On 27/09/2021 10:50, fanjianfeng@... wrote:
For former caller, they could still keep as is to call the old API
in MdeModulePkg. I think Ray's design is compatible change for existing code.
Only when the existing code wants to remove the dependency on
MdeModuelPkg, they could migrate to the new API in baselib.

I agree with one split-API desgin what you mentioned.
But my point is to define one API in baselib and to make the
baselib not depend on memory allocation. And another wrapper API
could be designed to be placed in any other class.
Oh sure, it could totally live in another class. I'd just like to
have those two models (caller- and callee-owned buffer) strictly
separate, I personally do not mind where exactly they are implemented. Thanks!

Best regards,
Marvin


-------------------------------------------------------------------
-----
Jeff
fanjianfeng@...

*From:* Marvin Häuser <mailto:mhaeuser@...>
*Date:* 2021-09-27 16:14
*To:* fanjianfeng@...
<mailto:fanjianfeng@...>; devel@edk2.groups.io
<mailto:devel@edk2.groups.io>; Ni, Ray <mailto:ray.ni@...>;
'gaoliming' <mailto:gaoliming@...>; Chan, Amy
<mailto:amy.chan@...>; 'Andrew Fish'
<mailto:afish@...>
*CC:* Kinney, Michael D <mailto:michael.d.kinney@...>;
'Gao,
Liming' <mailto:liming.gao@...>; Liu, Zhiguang
<mailto:zhiguang.liu@...>; Wang, Jian J
<mailto:jian.j.wang@...>; Gao, Zhichao
<mailto:zhichao.gao@...>
*Subject:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort in
MdePkg
On 27/09/2021 02:45, fanjianfeng@... wrote:
> Making baselib implementation depend on MemoryAllocationLib
> (indirectly on Pei Service and gBS), it may prevent
> this base API using at some seneraio. i don't think it's better.
That is why I asked about a split-API scenario, one of which
does
not
depend on dynamic memory allocation (SetVariable-like) and one
does
(wrapper-like).
> Add this parameter and make this parameter is optional,
> 1, when NULL, use the local 256 bytes stack
> 2, if 256 bytes stack is not enough, return
RETURE_BUFFER_TOO_SAMLL,
> 3, caller check the return status, to do nothing or to allocate
enough
> buffer for retry
>
> This is just like SetVariable()'s implementation.
Yes, and because that is SetVariable's implementation, we have
library
functions to make it less error-prone and more convenient [1]. As a
matter of fact, we have a (semi-lax) policy in our codebases to avoid
such functions like the plague and use those library wrappers
where-ever
it can make sense. The only super-rare exceptions I can think of are
when we know the size of the element ahead of time. Also
SetVariable has
no arbitrary constraint on when it may work the first time, and
there is
code that will fail when the first return is not
EFI_BUFFER_TOO_SMALL.
This solution honestly yields even more problems, because it
introduces
a Status return which was not there before. For common code
safety
and
quality policy, this requires the value *must* be retrieved and
checked
in some fashion. So all callers, no matter the prior knowledge of the
element size, now need either a runtime check and handling for a
status
that they (may) know can never be returned, or ASSERTs if the
function
spec really imposes the arbitrary 256 Bytes constraint. Latter
doesn't
really work I think. What if someone wants to sort in SEC and
noticed
they only have 64 Bytes on the stack to work with, realistically? Any
code depending on the 256 Byte constraint, passing NULL and
not
doing
additional handling, would seize to work. Former is too
complicated, see
wrappers. In my opinion, the memory must *either* be fully
managed by
the caller *or* the callee (and you may have both in separate
functions,
as I suggested), but not sometimes here, sometimes there.
Best regards,
Marvin
[1]
https://github.com/tianocore/edk2/blob/46b4606ba23498d3d0e66b53e498e
b3d5d592586/MdePkg/Library/UefiLib/UefiLib.c#L
1309-L1360
>
>
------------------------------------------------------------------------
> Jeff
> fanjianfeng@...
>
> *From:* Marvin Häuser <mailto:mhaeuser@...>
> *Date:* 2021-09-26 19:20
> *To:* devel <mailto:devel@edk2.groups.io>; ray.ni
> <mailto:ray.ni@...>; gaoliming
> <mailto:gaoliming@...>; Chan, Amy
> <mailto:amy.chan@...>; 'Andrew Fish'
<mailto:afish@...>
> *CC:* Kinney, Michael D
<mailto:michael.d.kinney@...>;
'Gao,
> Liming' <mailto:liming.gao@...>; Liu, Zhiguang
> <mailto:zhiguang.liu@...>; Wang, Jian J
> <mailto:jian.j.wang@...>; Gao, Zhichao
> <mailto:zhichao.gao@...>
> *Subject:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort
in MdePkg
> Hey Ray,
> In my opinion that spec is too complicated. For some cases
it is
> obvious, but I think the last anyone wants to see is a
> (STATIC_)ASSERT
> before most QuickSort calls to ensure the element size
*really* is <=
> 256 Bytes. In my opinion, there are two roads:
> 1) Make the parameter required (I think this is what Liming
> suggested).
> The caller would always need to provide said buffer, and it
can do
> as it
> sees fit - on the stack, in a pool, in a page, who knows.
> 2) Remove the parameter entirely. The library would
depend on
> MemoryAllocationLib again, but also would have an
optimisation by
> choosing stack vs pool based on ElementSize.
> Usually I would prefer 2), as it is less prone to caller
errors, but
> considering the low-level nature of edk2, I can totally see
the
> point to
> allow the caller to control whether there are dynamic
memory
> allocations
> made or not as possible with 1). 2) could technically also be
a
> wrapper
> for 1) if you want granular control and convenience/safety
(why not
> actually?).
> Both approaches have the advantage that it is crystal-clear
what the
> caller's job is - to always or to never allocate the buffer.
> Best regards,
> Marvin
> On 26/09/2021 04:24, Ni, Ray wrote:
> >
> > Liming,
> >
> > The purpose of the optional BufferOneElement is to ease
consumer’s
> > life assuming most of the time the element size should be
> smaller than
> > 256.
> >
> > Are you saying that it’s a bit hard to calculate the actual
> value of
> > sizeof (Element) when writing code?
> >
> > I recommend consumer always allocates memory if it’s
hard
to judge
> > sizeof (Element) < 256.
> >
> > Searching edk2 code, I can find below code using
PerformQuickSort():
> >
> > 1. ShellPkg/UefiShellCommandLib: It’s sorting array of
> > (EFI_DEVICE_PATH_PROTOCOL *).
> > 2. UefiCpuPkg/CpuCacheInfoLib: It’s sorting array of
> CPU_CACHE_INFO.
> > 3. MinPlatformPkg/AcpiTables: It’s sorting array of
> EFI_CPU_ID_ORDER_MAP.
> > 4. MdeModulePkg/UefiBootManagerLib: It’s sorting
array of
> > EFI_BOOT_MANAGER_LOAD_OPTION.
> > 5. MdeModulePkg/CapsuleApp: It’s sorting array of
(EFI_FILE_INFO *)
> > 6. CryptoPkg/CrtWrapper: It’s sorting array of
(unknown
type).
> > 7. RedfishPkg/RedfishCrtLib: It’s sorting array of
(unknown type).
> >
> > For 1~5, it’s easy to know that the size of the element is
smaller
> > than 256. The AllocatePool() can be skipped.
> >
> > Thanks,
> >
> > Ray
> >
> > *From:*gaoliming <gaoliming@...>
> > *Sent:* Sunday, September 26, 2021 10:01 AM
> > *To:* Ni, Ray <ray.ni@...>; devel@edk2.groups.io;
Chan, Amy
> > <amy.chan@...>; 'Andrew Fish'
<afish@...>
> > *Cc:* Kinney, Michael D <michael.d.kinney@...>;
'Gao, Liming'
> > <liming.gao@...>; Liu, Zhiguang
<zhiguang.liu@...>;
> Wang,
> > Jian J <jian.j.wang@...>; Gao, Zhichao
<zhichao.gao@...>
> > *Subject:* 回复: [edk2-devel] RFC: Add
BaseLib/QuickSort in
MdePkg
> >
> > Ray:
> >
> > I may suggest to always require BufferOneElement. The
consumer code
> > may not know ElementSize. To avoid the error, the
consumer
must
> > allocate buffer for BufferOneElement. If so,
BufferOneElement is
> the
> > required parameter.
> >
> > Thanks
> >
> > Liming
> >
> > *发件人**:*Ni, Ray <ray.ni@...
<mailto:ray.ni@...>>
> > *发送时间:* 2021年9月24日 11:53
> > *收件人:* devel@edk2.groups.io
<mailto:devel@edk2.groups.io>;
Ni,
> Ray
> > <ray.ni@... <mailto:ray.ni@...>>; Chan,
Amy
> > <amy.chan@... <mailto:amy.chan@...>>;
gaoliming
> > <gaoliming@...
<mailto:gaoliming@...>>;
> 'Andrew
> > Fish' <afish@... <mailto:afish@...>>
> > *抄送:* Kinney, Michael D <michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; 'Gao, Liming'
> > <liming.gao@... <mailto:liming.gao@...>>;
Liu,
Zhiguang
> > <zhiguang.liu@...
<mailto:zhiguang.liu@...>>;
Wang,
> Jian J
> > <jian.j.wang@... <mailto:jian.j.wang@...>>;
Gao,
> Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>
> > *主题:* RE: [edk2-devel] RFC: Add BaseLib/QuickSort in
MdePkg
> >
> > More details on new QuickSort() API:
> >
> > The new API needs to carry additional parameter
“BufferOneElement”.
> >
> > This parameter gives QuickSort() the temporary buffer for
> swapping in
> > sorting.
> >
> > It’s to avoid BaseLib depends on MemoryAllocationLib.
> >
> > …
> >
> > @param [in] BufferOneElement When ElementSize >
256, caller
> needs to
> > provide a buffer whose size
> > equals to
ElementSize. It’s
used by
> > QuickSort() for swapping in sorting.
> >
> > When ElementSize <= 256, QuickSort() uses a local stack
256-byte
> buffer.
> >
> > @retval EFI_INVALID_PARAMETER When (ElementSize >
256) and
> > (BufferOneElement == NULL).
> >
> > …
> >
> > VOID
> >
> > EFIAPI
> >
> > QuickSort (
> >
> > IN OUT
VOID *BufferToSort,
> >
> > IN CONST UINTN ElementCount,
> >
> > IN CONST UINTN ElementSize,
> >
> > IN SORT_COMPARE CompareFunction,
> >
> > IN VOID *BufferOneElement OPTIONAL
> >
> > );
> >
> > Any comments?
> >
> > *From:*devel@edk2.groups.io
<mailto:devel@edk2.groups.io>
> > <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
*On
Behalf Of
> > *Ni, Ray
> > *Sent:* Wednesday, September 22, 2021 2:04 PM
> > *To:* Chan, Amy <amy.chan@...
<mailto:amy.chan@...>>;
> > gaoliming <gaoliming@...
> > <mailto:gaoliming@...>>; 'Andrew Fish'
<afish@...
> > <mailto:afish@...>>; 'edk2-devel-groups-io'
> > <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
> > *Cc:* Kinney, Michael D <michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; 'Gao, Liming'
> > <liming.gao@... <mailto:liming.gao@...>>;
Liu,
Zhiguang
> > <zhiguang.liu@...
<mailto:zhiguang.liu@...>>;
Wang,
> Jian J
> > <jian.j.wang@... <mailto:jian.j.wang@...>>;
Gao,
> Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>
> > *Subject:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort
in
MdePkg
> >
> > I don’t see objection so far.
> >
> > So, the final solution is:
> >
> > 1. Add QuickSort() API to BaseLib in MdePkg.
> > 2. Update existing MdeModulePkg/SortLib to use
QuickSort() in the
> > implementation (proposed by Andrew Fish and
Liming Gao)
> > 3. Update UefiCpuPkg to use QuickSortLib to remove
improper
> > dependency on MdeModulePkg
> >
> > Thanks,
> >
> > Ray
> >
> > *From:*Ni, Ray
> > *Sent:* Thursday, September 16, 2021 10:48 AM
> > *To:* Chan, Amy <amy.chan@...
<mailto:amy.chan@...>>;
> > gaoliming <gaoliming@...
> > <mailto:gaoliming@...>>; 'Andrew Fish'
<afish@...
> > <mailto:afish@...>>; 'edk2-devel-groups-io'
> > <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
> > *Cc:* Kinney, Michael D <michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; 'Gao, Liming'
> > <liming.gao@... <mailto:liming.gao@...>>;
Liu,
Zhiguang
> > <Zhiguang.Liu@...
<mailto:Zhiguang.Liu@...>>;
Wang,
> Jian J
> > <jian.j.wang@... <mailto:jian.j.wang@...>>;
Gao,
> Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>
> > *Subject:* RE: [edk2-devel] RFC: Add BaseLib/QuickSort
in
MdePkg
> >
> > Amy,
> >
> > No. We only Add QuickSort() function API into BaseLib.h.
> >
> > *From:*Chan, Amy <amy.chan@...
<mailto:amy.chan@...>>
> > *Sent:* Thursday, September 16, 2021 10:46 AM
> > *To:* gaoliming <gaoliming@...
> > <mailto:gaoliming@...>>; 'Andrew Fish'
<afish@...
> > <mailto:afish@...>>; 'edk2-devel-groups-io'
> > <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
> > *Cc:* Ni, Ray <ray.ni@...
<mailto:ray.ni@...>>; Kinney,
> > Michael D <michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; 'Gao, Liming'
> > <liming.gao@... <mailto:liming.gao@...>>;
Liu,
Zhiguang
> > <zhiguang.liu@...
<mailto:zhiguang.liu@...>>;
Wang,
> Jian J
> > <jian.j.wang@... <mailto:jian.j.wang@...>>;
Gao,
> Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>
> > *Subject:* RE: [edk2-devel] RFC: Add BaseLib/QuickSort
in
MdePkg
> >
> > Just to double confirm, will we have the null instance of
> QuickSort in
> > MdePkg?
> >
> > Regards,
> >
> > Amy
> >
> > *From:*gaoliming <gaoliming@...
> > <mailto:gaoliming@...>>
> > *Sent:* Thursday, September 16, 2021 10:23 AM
> > *To:* 'Andrew Fish' <afish@...
<mailto:afish@...>>;
> > 'edk2-devel-groups-io' <devel@edk2.groups.io
> > <mailto:devel@edk2.groups.io>>
> > *Cc:* Ni, Ray <ray.ni@...
<mailto:ray.ni@...>>; Kinney,
> > Michael D <michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; 'Gao, Liming'
> > <liming.gao@... <mailto:liming.gao@...>>;
Liu,
Zhiguang
> > <zhiguang.liu@...
<mailto:zhiguang.liu@...>>;
Wang,
> Jian J
> > <jian.j.wang@... <mailto:jian.j.wang@...>>;
Gao,
> Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>;
Chan, Amy
> > <amy.chan@... <mailto:amy.chan@...>>
> > *Subject:* 回复: [edk2-devel] RFC: Add
BaseLib/QuickSort in
MdePkg
> >
> > Andrew:
> >
> > Thanks for your suggestion. I think your idea is better.
We add new
> > QuickSort() API to BaseLib, and update SortLib library
instance to
> > consume BaseLib QuickSort() API. This way has no change
in
current
> > SortLib library class. It is the compatible solution.
> >
> > Thanks
> >
> > Liming
> >
> > *发件人**:*Andrew Fish <afish@...
<mailto:afish@...>>
> > *发送时间:* 2021年9月16日 10:13
> > *收件人:* edk2-devel-groups-io <devel@edk2.groups.io
> > <mailto:devel@edk2.groups.io>>; Liming Gao
> <gaoliming@...
> > <mailto:gaoliming@...>>
> > *抄送:* Ni, Ray <ray.ni@...
<mailto:ray.ni@...>>; Mike
> > Kinney <michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; Gao, Liming
> > <liming.gao@... <mailto:liming.gao@...>>;
Liu,
Zhiguang
> > <zhiguang.liu@...
<mailto:zhiguang.liu@...>>;
Wang,
> Jian J
> > <jian.j.wang@... <mailto:jian.j.wang@...>>;
Gao,
> Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>;
Chan, Amy
> > <amy.chan@... <mailto:amy.chan@...>>
> > *主题:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort in
MdePkg
> >
> > On Sep 15, 2021, at 6:26 PM, gaoliming
<gaoliming@...
> > <mailto:gaoliming@...>> wrote:
> >
> > Ray:
> >
> > SortLib has been added since 2015. I would
suggest to
still keep
> > this library class. To resolve the package
dependency, my
> proposal
> > is to move the library class header file SortLib.h
from
> > MdeModulePkg to MdePkg, and still keep the
library
instance in
> > MdeModulePkg. This proposal has no impact on
the existing
> platform.
> >
> > If we add QuickSort() API to the BaseLib can we not just
port the
> > existing MdeModulePkg/SortLib to use QuickSort() in the
> > implementation? Or is there some other way to add the
new
thing
> in a
> > backward compatible way.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> > Thanks
> >
> > Liming
> >
> > *发件人**:*devel@edk2.groups.io
> > <mailto:devel@edk2.groups.io><devel@edk2.groups.io
> > <mailto:devel@edk2.groups.io>>*代表***Ni, Ray
> > *发送时间:*2021年9月14日14:15
> > *收件人:*Kinney, Michael D
<michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; Gao, Liming
> > <liming.gao@...
<mailto:liming.gao@...>>; Liu,
> > Zhiguang <zhiguang.liu@...
> <mailto:zhiguang.liu@...>>;
> > Wang, Jian J <jian.j.wang@...
> > <mailto:jian.j.wang@...>>; Gao, Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>
> > *抄送:*devel@edk2.groups.io
<mailto:devel@edk2.groups.io>;
> Chan, Amy
> > <amy.chan@...
<mailto:amy.chan@...>>
> > *主题:*[edk2-devel] RFC: Add BaseLib/QuickSort
in MdePkg
> >
> > Hi package maintainers of MdePkg,
MdeModulePkg and
ShellPkg,
> > community,
> >
> > A commit (UefiCpuPkg/CpuCacheInfoLib: Sort
CpuCacheInfo array
> >
>
<https://github.com/tianocore/edk2/commit/4de77ae9890d241271f543e919
5ab3516f3abec6>)
> > to UefiCpuPkg let
> > UefiCpuPkg depend on MdeModulePkg because
the SortLib
class and
> > instances are all in MdeModulePkg.
> >
> > UefiCpuPkg depending on MdeModulePkg breaks
the rule that
> > “UefiCpuPkg should ONLY depend on MdePkg”.
> >
> > To address this issue, there are two approaches:
> >
> > 1. Duplicate the sort logic in UefiCpuPkg to not
depend on
> > MdeModulePkg/SortLib
> > 2. Add QuickSort() API to BaseLib in MdePkg.
> >
> > Approach #2 (MdePkg/BaseLib/QuickSort) makes
more
sense because
> > quick sort is a standard algorithm.
> >
> > We encourage consumers to update their code to
use the
quick
> sort
> > in MdePkg and gradually deprecate today’s
MdeModulePkg/SortLib.
> >
> > If you don’t have concerns, I plan to:
> >
> > 1. “Add QuickSort() to BaseLib” and update all
existing
> consumers
> > to use this API instead.
> >
> > VOID
> >
> > EFIAPI
> >
> > QuickSort (
> >
> > IN OUT VOID *BufferT
oSort,
> >
> > IN CONST UINTN Count,
> >
> > IN CONST UINTN ElementSize,
> >
> > IN SORT_COMPARE Compare
Function
> >
> > );
> >
> > 2. “Add new ShellPkg/SortCompareLib”
> >
> > Background: ShellPkg requires to sort
devicepath/string so 3
> APIs
> > in UefiSortLib (DevicePathCompare,
StringNoCaseCompare,
> > StringCompare) are provided for Shell usage. we
can
move the 3
> > APIs to the SortCompareLib and update Shell code
to use
> > BaseLib/QuickSort directly, with the sort compare
function from
> > SortCompareLib.
> >
> > Any concerns?
> >
> > Thanks,
> >
> > Ray
> >
> >
>
>








--

Brian

--------------------------------------------------------------------

"Remember that ignorance is expensive."
-- From LLIB


Re: [`edk2-devel][PATCH] UefiPayloadPkg: Build a HOB from bootloader ACPI table

Ni, Ray
 

Guo,
Thank you!:)

-----Original Message-----
From: Dong, Guo <guo.dong@...>
Sent: Wednesday, September 29, 2021 1:20 AM
To: Ni, Ray <ray.ni@...>; devel@edk2.groups.io
Cc: Ma, Maurice <maurice.ma@...>; You, Benjamin <benjamin.you@...>
Subject: RE: [`edk2-devel][PATCH] UefiPayloadPkg: Build a HOB from bootloader ACPI table


Sure. I updated the patch per comments.

Thanks,
Guo

-----Original Message-----
From: Ni, Ray <ray.ni@...>
Sent: Monday, September 27, 2021 7:11 PM
To: Dong, Guo <guo.dong@...>; devel@edk2.groups.io
Cc: Ma, Maurice <maurice.ma@...>; You, Benjamin <benjamin.you@...>
Subject: RE: [`edk2-devel][PATCH] UefiPayloadPkg: Build a HOB from bootloader ACPI table

I prefer we still let caller to provide the HOB pointer.
This also eliminates a global variable "mAcpiBoardInfo".

You could change the BuildHobFromAcpi() to return the HOB pointer.
So that the pointer can be directly passed to ParseMemoryInfo().

Thanks,
Ray

-----Original Message-----
From: Dong, Guo <guo.dong@...>
Sent: Monday, September 27, 2021 2:32 AM
To: Ni, Ray <ray.ni@...>; devel@edk2.groups.io
Cc: Ma, Maurice <maurice.ma@...>; You, Benjamin <benjamin.you@...>
Subject: RE: [`edk2-devel][PATCH] UefiPayloadPkg: Build a HOB from bootloader ACPI table


Hi Ray,

In this patch, we added a shared file AcpiTable.c for both universal payload and non-universal payload.
The exposed API from this file is: EFI_STATUS BuildHobFromAcpi ( IN UINT64 AcpiTableBase);
This function will build an ACPI board HOB based on the information from ACPI table.

For universal payload, it calls this function to build a hob for other modules. The main function is very simple and clear.

For non-universal payload, ACPI board HOB is used in the ParseMemoryInfo() callback for PCIE base info.
So we could get this HOB from the caller, or get this HOB inside the callback. I select to do it inside the callback.

Thanks,
Guo

-----Original Message-----
From: Ni, Ray <ray.ni@...>
Sent: Saturday, September 25, 2021 7:48 PM
To: Dong, Guo <guo.dong@...>; devel@edk2.groups.io
Cc: Ma, Maurice <maurice.ma@...>; You, Benjamin <benjamin.you@...>
Subject: RE: [`edk2-devel][PATCH] UefiPayloadPkg: Build a HOB from bootloader ACPI table


- Status = ParseMemoryInfo (MemInfoCallbackMmio, &AcpiBoardInfo);

+ Status = ParseMemoryInfo (MemInfoCallbackMmio, NULL);

Guo,
I am curious why you changed this part.
Without this change, MemInfoCallbackMmio() can get the AcpiBoardInfo from the parameter.
With the change, it has to locate the Guided HOB itself.


Other parts look good to me.

Thanks,
Ray


Re: [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg/AspireVn7Dash572G: Fix Visual Studio Build

Nate DeSimone
 

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Nate DeSimone
Sent: Tuesday, September 28, 2021 6:03 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel <chasel.chiu@...>; Benjamin Doron <benjamin.doron00@...>
Subject: [edk2-devel] [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg/AspireVn7Dash572G: Fix Visual Studio Build

AspireVn7Dash572G currently does not build with Visual Studio.
This is due to the Visual C++ compiler generating warnings with the GCC compiler does not. The two classes of issues are unused local variables and implicit integer casts that could result in truncation. Visual C++ requires an explicit cast in cases where integer truncation is possible.

Cc: Chasel Chiu <chasel.chiu@...>
Cc: Benjamin Doron <benjamin.doron00@...>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@...>
---
.../AspireVn7Dash572G/Library/BoardEcLib/EcCommands.c | 9 +++++----
.../Library/BoardInitLib/DxeBoardInitLib.c | 3 ++-
.../Library/BoardInitLib/PeiAspireVn7Dash572GDetect.c | 3 +--
.../BoardInitLib/PeiAspireVn7Dash572GInitPostMemLib.c | 7 +++----
.../PeiSiliconPolicyUpdateLib.inf | 2 ++
5 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardEcLib/EcCommands.c b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardEcLib/EcCommands.c
index ea8a8ae11e..6e752b4e22 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardEcLib/EcCommands.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/Boar
+++ dEcLib/EcCommands.c
@@ -2,6 +2,7 @@
Board-specific EC commands.

Copyright (c) 2021, Baruch Binyamin Doron
+ Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -167,8 +168,8 @@ EcIdxRead (
return;
}

- IoWrite8 (EC_INDEX_IO_HIGH_ADDR_PORT, Address >> 8);
- IoWrite8 (EC_INDEX_IO_LOW_ADDR_PORT, Address);
+ IoWrite8 (EC_INDEX_IO_HIGH_ADDR_PORT, (UINT8) (Address >> 8));
+ IoWrite8 (EC_INDEX_IO_LOW_ADDR_PORT, (UINT8) Address);
*Data = IoRead8 (EC_INDEX_IO_DATA_PORT); }

@@ -184,8 +185,8 @@ EcIdxWrite (
IN UINT8 Data
)
{
- IoWrite8 (EC_INDEX_IO_HIGH_ADDR_PORT, Address >> 8);
- IoWrite8 (EC_INDEX_IO_LOW_ADDR_PORT, Address);
+ IoWrite8 (EC_INDEX_IO_HIGH_ADDR_PORT, (UINT8) (Address >> 8));
+ IoWrite8 (EC_INDEX_IO_LOW_ADDR_PORT, (UINT8) Address);
IoWrite8 (EC_INDEX_IO_DATA_PORT, Data); }

diff --git a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/DxeBoardInitLib.c b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/DxeBoardInitLib.c
index 4bce51886e..5c5c26d85c 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/DxeBoardInitLib.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/Boar
+++ dInitLib/DxeBoardInitLib.c
@@ -2,6 +2,7 @@
Aspire VN7-572G Board Initialization DXE library

Copyright (c) 2021, Baruch Binyamin Doron
+ Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -46,7 +47,7 @@ EcSendTime (
SendEcCommand (0xE0);
for (Index = 0; Index < 4; Index++) {
// Shift bytes
- EcTimeByte = EcTime >> Index*8;
+ EcTimeByte = (UINT8) (EcTime >> (Index * 8));
DEBUG ((DEBUG_INFO, "EC: Sending 0x%x (iteration %d)\n", EcTimeByte, Index));
SendEcData (EcTimeByte);
}
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GDetect.c b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GDetect.c
index d379fdb0d4..344e06859e 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GDetect.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/Boar
+++ dInitLib/PeiAspireVn7Dash572GDetect.c
@@ -1,6 +1,6 @@
/** @file

-Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -29,7 +29,6 @@ GetAspireVn7Dash572GBoardId (
OUT UINT8 *BoardId
)
{
- EFI_STATUS Status;
UINT16 DataBuffer;

ReadEcAdcConverter (MODEL_ID_AD, &DataBuffer); diff --git a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GInitPostMemLib.c b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GInitPostMemLib.c
index 2946e174ca..77722f5d60 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GInitPostMemLib.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/Boar
+++ dInitLib/PeiAspireVn7Dash572GInitPostMemLib.c
@@ -1,6 +1,6 @@
/** @file

-Copyright (c) 2017, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -40,7 +40,6 @@ EcInit (
UINT16 ABase;
UINT16 Pm1Sts;
UINT32 GpeSts;
- UINT16 XhciPmCs;

/* This is called via a "$FNC" in a PeiOemModule pointer table, with "$DPX" on SiInit */
IoWrite8 (0x6C, 0x5A); // 6Ch is the EC sideband port @@ -66,13 +65,13 @@ EcInit (
IoWrite32 (ABase + R_PCH_ACPI_GPE0_STS_127_96, GpeSts);
/* Clear xHCI PM_CS[PME_Status] - RW/1C - and disable xHCI PM_CS[PME_En] */
PciAndThenOr16 (PCI_LIB_ADDRESS(PCI_BUS_NUMBER_PCH_XHCI, PCI_DEVICE_NUMBER_PCH_XHCI, PCI_FUNCTION_NUMBER_PCH_XHCI, R_PCH_XHCI_PWR_CNTL_STS),
- ~B_PCH_XHCI_PWR_CNTL_STS_PME_EN,
+ (UINT16) ~B_PCH_XHCI_PWR_CNTL_STS_PME_EN,
B_PCH_XHCI_PWR_CNTL_STS_PME_STS
);

/* Enter S3 sleep */
IoAndThenOr32 (ABase + R_PCH_ACPI_PM1_CNT,
- ~(B_PCH_ACPI_PM1_CNT_SLP_TYP | B_PCH_ACPI_PM1_CNT_SLP_EN),
+ (UINT32) ~(B_PCH_ACPI_PM1_CNT_SLP_TYP |
+ B_PCH_ACPI_PM1_CNT_SLP_EN),
V_PCH_ACPI_PM1_CNT_S3
);
IoWrite32 (ABase + R_PCH_ACPI_PM1_CNT, B_PCH_ACPI_PM1_CNT_SLP_EN); diff --git a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
index ad85326bf9..0a8cf91b07 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Libra
+++ ry/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
@@ -53,6 +53,8 @@
gHsioSataPreMemConfigGuid ## CONSUMES
gSaMiscPeiPreMemConfigGuid ## CONSUMES
gFspNonVolatileStorageHobGuid ## CONSUMES
+ gIoApicConfigGuid ## CONSUMES
+ gHpetPreMemConfigGuid ## CONSUMES
gLockDownConfigGuid
gPchGeneralConfigGuid
gCpuPowerMgmtBasicConfigGuid
--
2.27.0.windows.1


Re: [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Fix Build

Nate DeSimone
 

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Nate DeSimone
Sent: Tuesday, September 28, 2021 6:03 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel <chasel.chiu@...>
Subject: [edk2-devel] [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Fix Build

Commit d281e9e broke the build for KabylakeOpenBoardPkg due to DxeMultiBoardAcpiSupportLib having a dependency on BoardAcpiTableLib that was never declared. This change adds a correct declaration of the library dependency and fixes the build.

Cc: Chasel Chiu <chasel.chiu@...>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@...>
---
.../Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf | 3 ++-
.../Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf
index 9fe27f9fda..dc597c4808 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLi
+++ b/DxeMultiBoardAcpiSupportLib.inf
@@ -1,7 +1,7 @@
### @file
# System 76 GalagoPro3 board multi-board DXE ACPI table support functionality.
#
-# Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2019 - 2021, Intel Corporation. All rights
+reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -26,6 +26,7 @@
BaseLib
IoLib
PciLib
+ BoardAcpiTableLib
AslUpdateLib

[Packages]
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf
index e5de9268e7..8438b16a6e 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpi
+++ Lib/DxeMultiBoardAcpiSupportLib.inf
@@ -1,7 +1,7 @@
### @file
# Kaby Lake RVP 3 Multi-Board ACPI Support library # -# Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2017 - 2021, Intel Corporation. All rights
+reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -26,6 +26,7 @@
BaseLib
IoLib
PciLib
+ BoardAcpiTableLib
AslUpdateLib

[Packages]
--
2.27.0.windows.1


Re: [PATCH V2 0/9] Migrate ArmVirtPkg modules to OvmfPkg

Abner Chang
 

Oops..I should create one for this.
Thanks for the reminder.

Abner


From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of gaoliming <gaoliming@...>
Sent: Wednesday, September 29, 2021 9:30:44 AM
To: devel@edk2.groups.io <devel@edk2.groups.io>; Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Schaefer, Daniel <daniel.schaefer@...>
Cc: 'Ard Biesheuvel' <ardb+tianocore@...>; 'Leif Lindholm' <leif@...>; 'Sami Mujawar' <sami.mujawar@...>; 'Jiewen Yao' <jiewen.yao@...>; 'Jordan Justen' <jordan.l.justen@...>; 'Gerd Hoffmann' <kraxel@...>; 'Sunil V L' <sunilvl@...>; 'Zhiguang Liu' <zhiguang.liu@...>; 'Michael D Kinney' <michael.d.kinney@...>
Subject: 回复: [edk2-devel] [PATCH V2 0/9] Migrate ArmVirtPkg modules to OvmfPkg
 
Abner:
  Is there one BZ for this change?

Thanks
Liming
> -----邮件原件-----
> 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Abner Chang
> 发送时间: 2021年9月29日 8:54
> 收件人: Schaefer, Daniel <daniel.schaefer@...>; devel@edk2.groups.io
> 抄送: Ard Biesheuvel <ardb+tianocore@...>; Leif Lindholm
> <leif@...>; Sami Mujawar <sami.mujawar@...>; Jiewen Yao
> <jiewen.yao@...>; Jordan Justen <jordan.l.justen@...>; Gerd
> Hoffmann <kraxel@...>; Sunil V L <sunilvl@...>;
> Liming Gao <gaoliming@...>; Zhiguang Liu
> <zhiguang.liu@...>; Michael D Kinney <michael.d.kinney@...>
> 主题: Re: [edk2-devel] [PATCH V2 0/9] Migrate ArmVirtPkg modules to
> OvmfPkg
>
>
>
> > -----Original Message-----
> > From: Schaefer, Daniel
> > Sent: Wednesday, September 29, 2021 7:12 AM
> > To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
> > devel@edk2.groups.io
> > Cc: Ard Biesheuvel <ardb+tianocore@...>; Leif Lindholm
> > <leif@...>; Sami Mujawar <sami.mujawar@...>; Jiewen
> Yao
> > <jiewen.yao@...>; Jordan Justen <jordan.l.justen@...>; Gerd
> > Hoffmann <kraxel@...>; Sunil V L <sunilvl@...>;
> > Liming Gao <gaoliming@...>; Zhiguang Liu
> > <zhiguang.liu@...>; Michael D Kinney <michael.d.kinney@...>
> > Subject: Re: [PATCH V2 0/9] Migrate ArmVirtPkg modules to OvmfPkg
> >
> > Is there CI to check that the ArmVirtPkg platforms still builds with this?
> > I assume you haven't checked, Abner?
> Yes, this patch set passed the CI before I sending it out :).
> Abner
>
> >
> > On 9/28/21 16:30, Abner Chang wrote:
> > > In V2: Remove HPE license on the files that just moved around or
> > >        the changes in the file are just code removal.
> > >
> > > This pacthes set is to migrate some modules from ArmVirtPkg
> > > to under OvmfPkg for the upcoming RiscVVirtPkg that can leverage
> > > those modules without the dependency with Arm*Pkg.
> > >
> > > The modules moved from ArmVirtPkg to OvmfPkg are,
> > > - FdtClientDxe
> > > - PciPcdProducerLib
> > > - HighMemDxe
> > > - QemuFwCfgLib
> > > - FdtPciHostBridgeLib
> > > - VirtioFdtDxe
> > >
> > > Below PCDs are moved to under MdePkg and leverage by RiscVVirtPkg.
> > > This change also remove the dependency on ArmPkg of OvmfPkg.
> > > - PcdPciIoTranslation
> > > - PcdPciIoTranslation
> > > - PcdPciMmio32(64)Translation
> > >
> > > Signed-off-by: Abner Chang <abner.chang@...>
> > > Cc: Ard Biesheuvel <ardb+tianocore@...>
> > > Cc: Leif Lindholm <leif@...>
> > > Cc: Sami Mujawar <sami.mujawar@...>
> > > Cc: Jiewen Yao <jiewen.yao@...>
> > > Cc: Jordan Justen <jordan.l.justen@...>
> > > Cc: Gerd Hoffmann <kraxel@...>
> > > Cc: Daniel Schaefer <daniel.schaefer@...>
> > > Cc: Sunil V L <sunilvl@...>
> > > Cc: Liming Gao <gaoliming@...>
> > > Cc: Zhiguang Liu <zhiguang.liu@...>
> > > Cc: Michael D Kinney <michael.d.kinney@...>
> > >
> > > Abner Chang (9):
> > >   ArmVirtPkg/FdtClintDxe: Move FdtClientDxe to EmbeddedPkg
> > >   MdePkg: Add PcdPciIoTranslation PCD
> > >   ArmPkg: Use PcdPciIoTranslation PCD from MdePkg
> > >   ArmVirtPkg/FdtPciPcdProducerLib: Relocate PciPcdProducerLib to
> > OvmfPkg
> > >   ArmVirtPkg/HighMemDxe: Relocate HighMemDxe to OvmfPkg
> > >   ArmVirtPkg/QemuFwCfgLib: Relocate QemuFwCfgLib to OvmfPkg
> > >   MdePkg: Add PcdPciMmio32(64)Translation PCDs
> > >   ArmVirtPkg/FdtPciHostBridgeLib: Relocate FdtPciHostBridgeLib to
> > >     OvmfPkg/Fdt
> > >   ArmVirtPkg/VirtioFdtDxe: Relocate VirtioFdtDxe to OvmfPkg/Fdt
> > >
> > >  ArmPkg/ArmPkg.dec                             | 15
> ++++++--------
> > >  ArmVirtPkg/ArmVirtPkg.dec                     |  3 ---
> > >  EmbeddedPkg/EmbeddedPkg.dec                   |  1 +
> > >  MdePkg/MdePkg.dec                             | 12
> +++++++++++
> > >  ArmVirtPkg/ArmVirtCloudHv.dsc                 | 18
> ++++++++---------
> > >  ArmVirtPkg/ArmVirtKvmTool.dsc                 | 18
> ++++++++---------
> > >  ArmVirtPkg/ArmVirtQemu.dsc                    | 20
> +++++++++----------
> > >  ArmVirtPkg/ArmVirtQemuKernel.dsc              | 20
> +++++++++----------
> > >  ArmVirtPkg/ArmVirtXen.dsc                     |  2 +-
> > >  EmbeddedPkg/EmbeddedPkg.dsc                   |  1 +
> > >  ArmVirtPkg/ArmVirtCloudHv.fdf                 |  6 +++---
> > >  ArmVirtPkg/ArmVirtKvmTool.fdf                 |  6 +++---
> > >  ArmVirtPkg/ArmVirtXen.fdf                     |  2 +-
> > >  ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc          |  6 +++---
> > >  .../ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf       |  2 +-
> > >  .../ArmVirtGicArchLib/ArmVirtGicArchLib.inf   |  1 +
> > >  .../ArmVirtPL031FdtClientLib.inf              |  1 +
> > >  .../ArmVirtPsciResetSystemLib.inf             |  1 +
> > >  .../ArmVirtTimerFdtClientLib.inf              |  1 +
> > >  .../KvmtoolRtcFdtClientLib.inf                |  1 +
> > >  .../NorFlashKvmtoolLib/NorFlashKvmtoolLib.inf |  1 +
> > >  .../NorFlashQemuLib/NorFlashQemuLib.inf       |  1 +
> > >  .../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf |  1 +
> > >  ArmVirtPkg/XenioFdtDxe/XenioFdtDxe.inf        |  1 +
> > >  .../Drivers}/FdtClientDxe/FdtClientDxe.inf    |  1 -
> > >  .../FdtPciHostBridgeLib.inf                   | 11 +++++-----
> > >  .../FdtPciPcdProducerLib.inf                  |  5 ++---
> > >  .../Fdt}/HighMemDxe/HighMemDxe.inf            |  4 ++--
> > >  .../Fdt}/VirtioFdtDxe/VirtioFdtDxe.inf        |  2 +-
> > >  .../Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf |  6 +++---
> > >  .../Include/Protocol/FdtClient.h              |  0
> > >  .../Drivers}/FdtClientDxe/FdtClientDxe.c      |  0
> > >  .../FdtPciHostBridgeLib/FdtPciHostBridgeLib.c |  0
> > >  .../FdtPciPcdProducerLib.c                    |  0
> > >  .../Fdt}/HighMemDxe/HighMemDxe.c              |  0
> > >  .../Fdt}/VirtioFdtDxe/VirtioFdtDxe.c          |  0
> > >  .../Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c   |  7 ++++---
> > >  Maintainers.txt                               |  6 ++++++
> > >  38 files changed, 102 insertions(+), 81 deletions(-)
> > >  rename {ArmVirtPkg =>
> > EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.inf (92%)
> > >  rename {ArmVirtPkg/Library =>
> > OvmfPkg/Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf (77%)
> > >  rename {ArmVirtPkg/Library =>
> > OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf (87%)
> > >  rename {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.inf
> > (91%)
> > >  rename {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.inf
> (92%)
> > >  rename ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf =>
> > OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf (86%)
> > >  rename {ArmVirtPkg => EmbeddedPkg}/Include/Protocol/FdtClient.h
> > (100%)
> > >  rename {ArmVirtPkg =>
> > EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.c (100%)
> > >  rename {ArmVirtPkg/Library =>
> > OvmfPkg/Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c (100%)
> > >  rename {ArmVirtPkg/Library =>
> > OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c (100%)
> > >  rename {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.c
> > (100%)
> > >  rename {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.c
> (100%)
> > >  rename ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c =>
> > OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c (93%)
> > >
>
>
>
>









回复: [edk2-devel] [PATCH V3] MdeModulePkg/BootManagerMenuApp: Limit string drawing within one line

gaoliming
 

I just merge it.

Thanks
Liming

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Gao, Zhichao
发送时间: 2021年9月29日 9:32
收件人: devel@edk2.groups.io; gaoliming@...
抄送: Wang, Jian J <jian.j.wang@...>; Ni, Ray <ray.ni@...>
主题: Re: [edk2-devel] [PATCH V3] MdeModulePkg/BootManagerMenuApp:
Limit string drawing within one line

I have created the PR at: https://github.com/tianocore/edk2/pull/2019.
It shows all the checks are passed. Can you help to add your 'push' label and
reopen it?

Thanks,
Zhichao

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
gaoliming
Sent: Tuesday, September 28, 2021 1:27 PM
To: devel@edk2.groups.io; Gao, Zhichao <zhichao.gao@...>
Cc: Wang, Jian J <jian.j.wang@...>; Ni, Ray <ray.ni@...>
Subject: 回复: [edk2-devel] [PATCH V3]
MdeModulePkg/BootManagerMenuApp: Limit string drawing within one
line

I am ok for this change. Reviewed-by: Liming Gao
<gaoliming@...>

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Gao,
Zhichao
发送时间: 2021年9月28日 13:18
收件人: devel@edk2.groups.io; Gao, Zhichao <zhichao.gao@...>
抄送: Wang, Jian J <jian.j.wang@...>; Liming Gao
<gaoliming@...>; Ni, Ray <ray.ni@...>
主题: Re: [edk2-devel] [PATCH V3]
MdeModulePkg/BootManagerMenuApp:
Limit string drawing within one line

Hi Liming/Ray,

I have updated the commit message and the BZ comments. Do you agree
to
merge the code?

Thanks,
Zhichao

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
Gao,
Zhichao
Sent: Monday, September 27, 2021 3:10 PM
To: devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Liming Gao
<gaoliming@...>; Ni, Ray <ray.ni@...>
Subject: [edk2-devel] [PATCH V3]
MdeModulePkg/BootManagerMenuApp:
Limit string drawing within one line

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

Limit the draw box always within the screen's column and row.
Limit the string drawing within one line.For the incompleted string
the
last 3
characters in one line wouldbe replaced with "...".

Cc: Jian J Wang <jian.j.wang@...>
Cc: Liming Gao <gaoliming@...>
Cc: Ray Ni <ray.ni@...>
Signed-off-by: Zhichao Gao <zhichao.gao@...>Reviewed-by: Ray
Ni <ray.ni@...> ---V2:Drop the change in UefiBootManagerLib in
V1.Add
the limitation in BootManagerMenuApp instead.V3:Update the commit
message only.
.../BootManagerMenuApp/BootManagerMenu.c | 72
++++++++++++++++++-
1 file changed, 69 insertions(+), 3 deletions(-)

diff --git
a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
c
b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
c
index 9e729074ec..d4bdeba073 100644
---
a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
c
+++
b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
c
@@ -1,7 +1,7 @@
/** @file The application to show the Boot Manager Menu.
-Copyright
(c)
2011 - 2018, Intel Corporation. All rights reserved.<BR>+Copyright
(c)
2011 -
2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier:
BSD-2-Clause-Patent **/@@ -45,9 +45,56 @@ PrintStringAt (
IN CHAR16 *String ) {+ UINTN ScreenWidth;+
UINTN
ScreenRows;+ CHAR16 *TurncateString;+ EFI_STATUS
Status;+ UINTN
ShowingLength; gST->ConOut->SetCursorPosition (gST->ConOut,
Column,
Row);- return Print (L"%s", String);++ gST->ConOut->QueryMode (+
gST->ConOut,+ gST->ConOut->Mode->Mode,+
&ScreenWidth,+
&ScreenRows+ );++ if (Column >
(ScreenWidth - 1) || Row > (ScreenRows - 1)) {+ return 0;+ }++ if
((StrLen
(String) + Column) > (ScreenWidth - 1)) {+ //+ // | -
ScreenWidth - |+
// ...Column.....................+ // TurncateString length should
leave one
character for draw box and+ // require one character for string
end.+
//+
ShowingLength = ScreenWidth - Column - 1;+ TurncateString =
AllocatePool
((ShowingLength + 1) * sizeof (CHAR16));++ if (TurncateString ==
NULL)
{+
return 0;+ }++ Status = StrnCpyS (TurncateString,
ShowingLength +
1,
String, ShowingLength - 3);++ if (EFI_ERROR (Status)) {+
FreePool
(TurncateString);+ return 0;+ }++ *(TurncateString +
ShowingLength - 3)
= L'.';+ *(TurncateString + ShowingLength - 2) = L'.';+
*(TurncateString +
ShowingLength - 1) = L'.';+ *(TurncateString + ShowingLength)
=
L'\0';+
ShowingLength = Print (L"%s", TurncateString);+ FreePool
(TurncateString);+ return ShowingLength;+ } else {+ return
Print
(L"%s",
String);+ } } /**@@ -68,7 +115,22 @@ PrintCharAt (
CHAR16 Character ) {+ UINTN
ScreenWidth;+
UINTN
ScreenRows;+ gST->ConOut->SetCursorPosition (gST->ConOut,
Column,
Row);++ gST->ConOut->QueryMode (+
gST->ConOut,+ gST-
ConOut->Mode->Mode,+ &ScreenWidth,+
&ScreenRows+ );++ if (Column > (ScreenWidth - 1)
||
Row >
(ScreenRows - 1)) {+ return 0;+ }+ return Print (L"%c",
Character); }
@@ -
193,7 +255,11 @@ InitializeBootMenuScreen (
MaxPrintRows = Row - 6; UnSelectableItmes =
TITLE_TOKEN_COUNT + 2 +
HELP_TOKEN_COUNT + 2;- BootMenuData->MenuScreen.Width =
MaxStrWidth + 8;+ if (MaxStrWidth + 8 > Column) {+
BootMenuData-
MenuScreen.Width = Column;+ } else {+ BootMenuData-
MenuScreen.Width = MaxStrWidth + 8;+ } if
(BootMenuData->ItemCount
+ UnSelectableItmes > MaxPrintRows) { BootMenuData-
MenuScreen.Height = MaxPrintRows; BootMenuData-
ScrollBarControl.HasScrollBar = TRUE;--
2.31.1.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81153):
https://edk2.groups.io/g/devel/message/81153
Mute This Topic: https://groups.io/mt/85895022/1768756
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[zhichao.gao@...]
-=-=-=-=-=-=












回复: [edk2-devel] 回复: [PATCH v1 0/4] Set default Makefile name

gaoliming
 

Reviewed-by: Liming Gao <gaoliming@...>

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表
PierreGondois
发送时间: 2021年9月24日 19:57
收件人: gaoliming <gaoliming@...>; devel@edk2.groups.io; 'Bob
Feng' <bob.c.feng@...>; 'Sami Mujawar' <sami.mujawar@...>
抄送: 'Christopher Jones' <Christopher.Jones@...>
主题: Re: [edk2-devel] 回复: [PATCH v1 0/4] Set default Makefile name

Hi Liming,

I created: https://bugzilla.tianocore.org/show_bug.cgi?id=3653

Regards,

Pierre

On 9/24/21 1:48 AM, gaoliming wrote:
Pierre:
Can you submit BZ for this change request?

Thanks
Liming
-----邮件原件-----
发件人: Pierre.Gondois@... <Pierre.Gondois@...>
发送时间: 2021年9月23日 16:59
收件人: devel@edk2.groups.io; Bob Feng <bob.c.feng@...>;
Liming
Gao <gaoliming@...>; Sami Mujawar
<sami.mujawar@...>
主题: [PATCH v1 0/4] Set default Makefile name

From: Pierre Gondois <Pierre.Gondois@...>

A Makefile name is not set in BaseTools when only building modules
or libraries. This patch-set sets a default Makefile name for the
"build" command.

The patch-set also:
- Removes unsused Makefile variables
- Removes hard-coded references to "target.txt" and "tools_def.txt"

The changes can be seen at:
https://github.com/PierreARM/edk2/tree/1868_BaseTools_build_py_correcti
ons_v1

Pierre Gondois (4):
BaseTools/GenMake: Use ToolDefinition as fallback option
BaseTools/build: Set MakefileName
BaseTools: Remove Makefile/MakefileName fields
BaseTools: Remove hard-coded strings for target and tools_def

BaseTools/Source/Python/AutoGen/GenMake.py | 8
++++----
BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 1 -
BaseTools/Source/Python/GenFds/GenFds.py | 4 ++--
.../Source/Python/GenFds/GenFdsGlobalVariable.py | 4 ++--
BaseTools/Source/Python/TargetTool/TargetTool.py | 3 ++-
BaseTools/Source/Python/Workspace/BuildClassObject.py | 2 --
BaseTools/Source/Python/Workspace/DscBuildData.py | 9
++++-----
BaseTools/Source/Python/build/build.py | 11
++++-------
8 files changed, 18 insertions(+), 24 deletions(-)

--
2.17.1





Re: [PATCH V3] MdeModulePkg/BootManagerMenuApp: Limit string drawing within one line

Gao, Zhichao
 

I have created the PR at: https://github.com/tianocore/edk2/pull/2019.
It shows all the checks are passed. Can you help to add your 'push' label and reopen it?

Thanks,
Zhichao

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
gaoliming
Sent: Tuesday, September 28, 2021 1:27 PM
To: devel@edk2.groups.io; Gao, Zhichao <zhichao.gao@...>
Cc: Wang, Jian J <jian.j.wang@...>; Ni, Ray <ray.ni@...>
Subject: 回复: [edk2-devel] [PATCH V3]
MdeModulePkg/BootManagerMenuApp: Limit string drawing within one line

I am ok for this change. Reviewed-by: Liming Gao
<gaoliming@...>

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Gao,
Zhichao
发送时间: 2021年9月28日 13:18
收件人: devel@edk2.groups.io; Gao, Zhichao <zhichao.gao@...>
抄送: Wang, Jian J <jian.j.wang@...>; Liming Gao
<gaoliming@...>; Ni, Ray <ray.ni@...>
主题: Re: [edk2-devel] [PATCH V3]
MdeModulePkg/BootManagerMenuApp:
Limit string drawing within one line

Hi Liming/Ray,

I have updated the commit message and the BZ comments. Do you agree
to
merge the code?

Thanks,
Zhichao

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Gao,
Zhichao
Sent: Monday, September 27, 2021 3:10 PM
To: devel@edk2.groups.io
Cc: Wang, Jian J <jian.j.wang@...>; Liming Gao
<gaoliming@...>; Ni, Ray <ray.ni@...>
Subject: [edk2-devel] [PATCH V3]
MdeModulePkg/BootManagerMenuApp:
Limit string drawing within one line

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

Limit the draw box always within the screen's column and row.
Limit the string drawing within one line.For the incompleted string
the
last 3
characters in one line wouldbe replaced with "...".

Cc: Jian J Wang <jian.j.wang@...>
Cc: Liming Gao <gaoliming@...>
Cc: Ray Ni <ray.ni@...>
Signed-off-by: Zhichao Gao <zhichao.gao@...>Reviewed-by: Ray
Ni <ray.ni@...> ---V2:Drop the change in UefiBootManagerLib in
V1.Add
the limitation in BootManagerMenuApp instead.V3:Update the commit
message only.
.../BootManagerMenuApp/BootManagerMenu.c | 72
++++++++++++++++++-
1 file changed, 69 insertions(+), 3 deletions(-)

diff --git
a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
c
b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
c
index 9e729074ec..d4bdeba073 100644
---
a/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
c
+++
b/MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenu.
c
@@ -1,7 +1,7 @@
/** @file The application to show the Boot Manager Menu. -Copyright
(c)
2011 - 2018, Intel Corporation. All rights reserved.<BR>+Copyright
(c)
2011 -
2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier:
BSD-2-Clause-Patent **/@@ -45,9 +45,56 @@ PrintStringAt (
IN CHAR16 *String ) {+ UINTN ScreenWidth;+
UINTN
ScreenRows;+ CHAR16 *TurncateString;+ EFI_STATUS
Status;+ UINTN
ShowingLength; gST->ConOut->SetCursorPosition (gST->ConOut,
Column,
Row);- return Print (L"%s", String);++ gST->ConOut->QueryMode (+
gST->ConOut,+ gST->ConOut->Mode->Mode,+
&ScreenWidth,+
&ScreenRows+ );++ if (Column >
(ScreenWidth - 1) || Row > (ScreenRows - 1)) {+ return 0;+ }++ if
((StrLen
(String) + Column) > (ScreenWidth - 1)) {+ //+ // | -
ScreenWidth - |+
// ...Column.....................+ // TurncateString length should
leave one
character for draw box and+ // require one character for string end.+
//+
ShowingLength = ScreenWidth - Column - 1;+ TurncateString =
AllocatePool
((ShowingLength + 1) * sizeof (CHAR16));++ if (TurncateString ==
NULL)
{+
return 0;+ }++ Status = StrnCpyS (TurncateString, ShowingLength +
1,
String, ShowingLength - 3);++ if (EFI_ERROR (Status)) {+
FreePool
(TurncateString);+ return 0;+ }++ *(TurncateString +
ShowingLength - 3)
= L'.';+ *(TurncateString + ShowingLength - 2) = L'.';+
*(TurncateString +
ShowingLength - 1) = L'.';+ *(TurncateString + ShowingLength) =
L'\0';+
ShowingLength = Print (L"%s", TurncateString);+ FreePool
(TurncateString);+ return ShowingLength;+ } else {+ return Print
(L"%s",
String);+ } } /**@@ -68,7 +115,22 @@ PrintCharAt (
CHAR16 Character ) {+ UINTN ScreenWidth;+
UINTN
ScreenRows;+ gST->ConOut->SetCursorPosition (gST->ConOut, Column,
Row);++ gST->ConOut->QueryMode (+
gST->ConOut,+ gST-
ConOut->Mode->Mode,+ &ScreenWidth,+
&ScreenRows+ );++ if (Column > (ScreenWidth - 1) ||
Row >
(ScreenRows - 1)) {+ return 0;+ }+ return Print (L"%c",
Character); }
@@ -
193,7 +255,11 @@ InitializeBootMenuScreen (
MaxPrintRows = Row - 6; UnSelectableItmes =
TITLE_TOKEN_COUNT + 2 +
HELP_TOKEN_COUNT + 2;- BootMenuData->MenuScreen.Width =
MaxStrWidth + 8;+ if (MaxStrWidth + 8 > Column) {+ BootMenuData-
MenuScreen.Width = Column;+ } else {+ BootMenuData-
MenuScreen.Width = MaxStrWidth + 8;+ } if
(BootMenuData->ItemCount
+ UnSelectableItmes > MaxPrintRows) { BootMenuData-
MenuScreen.Height = MaxPrintRows; BootMenuData-
ScrollBarControl.HasScrollBar = TRUE;--
2.31.1.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81153):
https://edk2.groups.io/g/devel/message/81153
Mute This Topic: https://groups.io/mt/85895022/1768756
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[zhichao.gao@...]
-=-=-=-=-=-=









回复: [edk2-devel] [PATCH V2 0/9] Migrate ArmVirtPkg modules to OvmfPkg

gaoliming
 

Abner:
Is there one BZ for this change?

Thanks
Liming

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Abner Chang
发送时间: 2021年9月29日 8:54
收件人: Schaefer, Daniel <daniel.schaefer@...>; devel@edk2.groups.io
抄送: Ard Biesheuvel <ardb+tianocore@...>; Leif Lindholm
<leif@...>; Sami Mujawar <sami.mujawar@...>; Jiewen Yao
<jiewen.yao@...>; Jordan Justen <jordan.l.justen@...>; Gerd
Hoffmann <kraxel@...>; Sunil V L <sunilvl@...>;
Liming Gao <gaoliming@...>; Zhiguang Liu
<zhiguang.liu@...>; Michael D Kinney <michael.d.kinney@...>
主题: Re: [edk2-devel] [PATCH V2 0/9] Migrate ArmVirtPkg modules to
OvmfPkg



-----Original Message-----
From: Schaefer, Daniel
Sent: Wednesday, September 29, 2021 7:12 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
devel@edk2.groups.io
Cc: Ard Biesheuvel <ardb+tianocore@...>; Leif Lindholm
<leif@...>; Sami Mujawar <sami.mujawar@...>; Jiewen
Yao
<jiewen.yao@...>; Jordan Justen <jordan.l.justen@...>; Gerd
Hoffmann <kraxel@...>; Sunil V L <sunilvl@...>;
Liming Gao <gaoliming@...>; Zhiguang Liu
<zhiguang.liu@...>; Michael D Kinney <michael.d.kinney@...>
Subject: Re: [PATCH V2 0/9] Migrate ArmVirtPkg modules to OvmfPkg

Is there CI to check that the ArmVirtPkg platforms still builds with this?
I assume you haven't checked, Abner?
Yes, this patch set passed the CI before I sending it out :).
Abner


On 9/28/21 16:30, Abner Chang wrote:
In V2: Remove HPE license on the files that just moved around or
the changes in the file are just code removal.

This pacthes set is to migrate some modules from ArmVirtPkg
to under OvmfPkg for the upcoming RiscVVirtPkg that can leverage
those modules without the dependency with Arm*Pkg.

The modules moved from ArmVirtPkg to OvmfPkg are,
- FdtClientDxe
- PciPcdProducerLib
- HighMemDxe
- QemuFwCfgLib
- FdtPciHostBridgeLib
- VirtioFdtDxe

Below PCDs are moved to under MdePkg and leverage by RiscVVirtPkg.
This change also remove the dependency on ArmPkg of OvmfPkg.
- PcdPciIoTranslation
- PcdPciIoTranslation
- PcdPciMmio32(64)Translation

Signed-off-by: Abner Chang <abner.chang@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Leif Lindholm <leif@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jordan Justen <jordan.l.justen@...>
Cc: Gerd Hoffmann <kraxel@...>
Cc: Daniel Schaefer <daniel.schaefer@...>
Cc: Sunil V L <sunilvl@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Michael D Kinney <michael.d.kinney@...>

Abner Chang (9):
ArmVirtPkg/FdtClintDxe: Move FdtClientDxe to EmbeddedPkg
MdePkg: Add PcdPciIoTranslation PCD
ArmPkg: Use PcdPciIoTranslation PCD from MdePkg
ArmVirtPkg/FdtPciPcdProducerLib: Relocate PciPcdProducerLib to
OvmfPkg
ArmVirtPkg/HighMemDxe: Relocate HighMemDxe to OvmfPkg
ArmVirtPkg/QemuFwCfgLib: Relocate QemuFwCfgLib to OvmfPkg
MdePkg: Add PcdPciMmio32(64)Translation PCDs
ArmVirtPkg/FdtPciHostBridgeLib: Relocate FdtPciHostBridgeLib to
OvmfPkg/Fdt
ArmVirtPkg/VirtioFdtDxe: Relocate VirtioFdtDxe to OvmfPkg/Fdt

ArmPkg/ArmPkg.dec | 15
++++++--------
ArmVirtPkg/ArmVirtPkg.dec | 3 ---
EmbeddedPkg/EmbeddedPkg.dec | 1 +
MdePkg/MdePkg.dec | 12
+++++++++++
ArmVirtPkg/ArmVirtCloudHv.dsc | 18
++++++++---------
ArmVirtPkg/ArmVirtKvmTool.dsc | 18
++++++++---------
ArmVirtPkg/ArmVirtQemu.dsc | 20
+++++++++----------
ArmVirtPkg/ArmVirtQemuKernel.dsc | 20
+++++++++----------
ArmVirtPkg/ArmVirtXen.dsc | 2 +-
EmbeddedPkg/EmbeddedPkg.dsc | 1 +
ArmVirtPkg/ArmVirtCloudHv.fdf | 6 +++---
ArmVirtPkg/ArmVirtKvmTool.fdf | 6 +++---
ArmVirtPkg/ArmVirtXen.fdf | 2 +-
ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 6 +++---
.../ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf | 2 +-
.../ArmVirtGicArchLib/ArmVirtGicArchLib.inf | 1 +
.../ArmVirtPL031FdtClientLib.inf | 1 +
.../ArmVirtPsciResetSystemLib.inf | 1 +
.../ArmVirtTimerFdtClientLib.inf | 1 +
.../KvmtoolRtcFdtClientLib.inf | 1 +
.../NorFlashKvmtoolLib/NorFlashKvmtoolLib.inf | 1 +
.../NorFlashQemuLib/NorFlashQemuLib.inf | 1 +
.../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf | 1 +
ArmVirtPkg/XenioFdtDxe/XenioFdtDxe.inf | 1 +
.../Drivers}/FdtClientDxe/FdtClientDxe.inf | 1 -
.../FdtPciHostBridgeLib.inf | 11 +++++-----
.../FdtPciPcdProducerLib.inf | 5 ++---
.../Fdt}/HighMemDxe/HighMemDxe.inf | 4 ++--
.../Fdt}/VirtioFdtDxe/VirtioFdtDxe.inf | 2 +-
.../Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf | 6 +++---
.../Include/Protocol/FdtClient.h | 0
.../Drivers}/FdtClientDxe/FdtClientDxe.c | 0
.../FdtPciHostBridgeLib/FdtPciHostBridgeLib.c | 0
.../FdtPciPcdProducerLib.c | 0
.../Fdt}/HighMemDxe/HighMemDxe.c | 0
.../Fdt}/VirtioFdtDxe/VirtioFdtDxe.c | 0
.../Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c | 7 ++++---
Maintainers.txt | 6 ++++++
38 files changed, 102 insertions(+), 81 deletions(-)
rename {ArmVirtPkg =>
EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.inf (92%)
rename {ArmVirtPkg/Library =>
OvmfPkg/Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf (77%)
rename {ArmVirtPkg/Library =>
OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf (87%)
rename {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.inf
(91%)
rename {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.inf
(92%)
rename ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf =>
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf (86%)
rename {ArmVirtPkg => EmbeddedPkg}/Include/Protocol/FdtClient.h
(100%)
rename {ArmVirtPkg =>
EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.c (100%)
rename {ArmVirtPkg/Library =>
OvmfPkg/Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c (100%)
rename {ArmVirtPkg/Library =>
OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c (100%)
rename {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.c
(100%)
rename {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.c
(100%)
rename ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c =>
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c (93%)



回复: 回复: [edk2-devel] [PATCH v3 0/2] BaseTools: Switch to downloading the ARM and AARCH64 compilers from Arm's site

gaoliming
 

-----邮件原件-----
发件人: Leif Lindholm <leif@...>
发送时间: 2021年9月28日 18:49
收件人: devel@edk2.groups.io; gaoliming@...
抄送: 'Rebecca Cran' <rebecca@...>; 'Bob Feng'
<bob.c.feng@...>; 'Yuwei Chen' <yuwei.chen@...>; 'Sean
Brogan' <sean.brogan@...>; 'Sami Mujawar'
<sami.mujawar@...>; 'Ard Biesheuvel' <ardb+tianocore@...>
主题: Re: 回复: [edk2-devel] [PATCH v3 0/2] BaseTools: Switch to
downloading the ARM and AARCH64 compilers from Arm's site

Could one of the BaseTools maintainers merge this set?

On Fri, Sep 24, 2021 at 08:44:42 +0800, gaoliming wrote:
Leif:
I gave my Acked-by for this patch set V2. I think it can be merged now.

Thanks
Liming
-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Leif
Lindholm
发送时间: 2021年9月24日 2:17
收件人: Rebecca Cran <rebecca@...>
抄送: devel@edk2.groups.io; Bob Feng <bob.c.feng@...>; Liming
Gao
<gaoliming@...>; Yuwei Chen <yuwei.chen@...>;
Sean
Brogan <sean.brogan@...>; Sami Mujawar
<sami.mujawar@...>; Ard Biesheuvel
<ardb+tianocore@...>
主题: Re: [edk2-devel] [PATCH v3 0/2] BaseTools: Switch to downloading
the
ARM and AARCH64 compilers from Arm's site

Hi Rebecca,

I think I already gave v2 an Acked-by, but just in case:
Acked-by: Leif Lindholm <leif@...>

Bob, Liming, Yuwei - any comments?

/
Leif

Thu, Sep 23, 2021 at 10:09:55 -0600, Rebecca Cran wrote:
BaseTools/Bin/gcc_[arm,aarch64]_linux_ext_dep.yaml downloads GCC
releases
from
https://releases.linaro.org/components/toolchain/binaries/7.4-2019.02 .

As indicated in the URL, those builds are from 2019 because Linaro no
longer do GCC releases, with that task having moved to Arm.

The Arm GCC page is
https://developer.arm.com/tools-and-software/open-source-software/devel
oper-tools/gnu-toolchain/gnu-a/downloads,
with the latest release being 10.3-2021.07.

gcc_aarch64_linux_ext_dep.yaml is used when setting up a CI
environment using the stuart tools.

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3594
PR: https://github.com/tianocore/edk2/pull/1909

Changes from v2 to v3:

Fixed the author to be @nuviainc.com instead of @bsdio.com.

Rebecca Cran (2):
BaseTools: Switch to downloading the ARM compiler from Arm's site
BaseTools: Switch to downloading the AARCH64 compiler from Arm's
site

BaseTools/Bin/gcc_aarch64_linux_ext_dep.yaml | 10
+++++-----
BaseTools/Bin/gcc_arm_linux_ext_dep.yaml |
10
+++++-----
BaseTools/Plugin/LinuxGcc5ToolChain/LinuxGcc5ToolChain.py | 4
++--
3 files changed, 12 insertions(+), 12 deletions(-)

--
2.31.1









Re: [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Fix Build

Chiu, Chasel
 

Reviewed-by: Chasel Chiu <chasel.chiu@...>

-----Original Message-----
From: Desimone, Nathaniel L <nathaniel.l.desimone@...>
Sent: Wednesday, September 29, 2021 9:03 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel <chasel.chiu@...>
Subject: [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Fix Build

Commit d281e9e broke the build for KabylakeOpenBoardPkg due to
DxeMultiBoardAcpiSupportLib having a dependency on BoardAcpiTableLib that
was never declared. This change adds a correct declaration of the library
dependency and fixes the build.

Cc: Chasel Chiu <chasel.chiu@...>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@...>
---
.../Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf | 3 ++-
.../Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)

diff --git
a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/Dx
eMultiBoardAcpiSupportLib.inf
b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/Dx
eMultiBoardAcpiSupportLib.inf
index 9fe27f9fda..dc597c4808 100644
---
a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/Dx
eMultiBoardAcpiSupportLib.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLi
+++ b/DxeMultiBoardAcpiSupportLib.inf
@@ -1,7 +1,7 @@
### @file
# System 76 GalagoPro3 board multi-board DXE ACPI table support functionality.
#
-# Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2019 - 2021, Intel Corporation. All rights
+reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -26,6 +26,7 @@
BaseLib
IoLib
PciLib
+ BoardAcpiTableLib
AslUpdateLib

[Packages]
diff --git
a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/D
xeMultiBoardAcpiSupportLib.inf
b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/D
xeMultiBoardAcpiSupportLib.inf
index e5de9268e7..8438b16a6e 100644
---
a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/D
xeMultiBoardAcpiSupportLib.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpi
+++ Lib/DxeMultiBoardAcpiSupportLib.inf
@@ -1,7 +1,7 @@
### @file
# Kaby Lake RVP 3 Multi-Board ACPI Support library # -# Copyright (c) 2017 -
2019, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2017 - 2021, Intel Corporation. All rights
+reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -26,6 +26,7 @@
BaseLib
IoLib
PciLib
+ BoardAcpiTableLib
AslUpdateLib

[Packages]
--
2.27.0.windows.1


Re: [edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg/AspireVn7Dash572G: Fix Visual Studio Build

Chiu, Chasel
 

Reviewed-by: Chasel Chiu <chasel.chiu@...>

-----Original Message-----
From: Desimone, Nathaniel L <nathaniel.l.desimone@...>
Sent: Wednesday, September 29, 2021 9:03 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel <chasel.chiu@...>; Benjamin Doron
<benjamin.doron00@...>
Subject: [edk2-platforms] [PATCH V1]
KabylakeOpenBoardPkg/AspireVn7Dash572G: Fix Visual Studio Build

AspireVn7Dash572G currently does not build with Visual Studio.
This is due to the Visual C++ compiler generating warnings with the GCC
compiler does not. The two classes of issues are unused local variables and
implicit integer casts that could result in truncation. Visual C++ requires an
explicit cast in cases where integer truncation is possible.

Cc: Chasel Chiu <chasel.chiu@...>
Cc: Benjamin Doron <benjamin.doron00@...>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@...>
---
.../AspireVn7Dash572G/Library/BoardEcLib/EcCommands.c | 9 +++++----
.../Library/BoardInitLib/DxeBoardInitLib.c | 3 ++-
.../Library/BoardInitLib/PeiAspireVn7Dash572GDetect.c | 3 +--
.../BoardInitLib/PeiAspireVn7Dash572GInitPostMemLib.c | 7 +++----
.../PeiSiliconPolicyUpdateLib.inf | 2 ++
5 files changed, 13 insertions(+), 11 deletions(-)

diff --git
a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardEcL
ib/EcCommands.c
b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardEcL
ib/EcCommands.c
index ea8a8ae11e..6e752b4e22 100644
---
a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardEcL
ib/EcCommands.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/Boar
+++ dEcLib/EcCommands.c
@@ -2,6 +2,7 @@
Board-specific EC commands.

Copyright (c) 2021, Baruch Binyamin Doron
+ Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -167,8 +168,8 @@ EcIdxRead (
return;
}

- IoWrite8 (EC_INDEX_IO_HIGH_ADDR_PORT, Address >> 8);
- IoWrite8 (EC_INDEX_IO_LOW_ADDR_PORT, Address);
+ IoWrite8 (EC_INDEX_IO_HIGH_ADDR_PORT, (UINT8) (Address >> 8));
+ IoWrite8 (EC_INDEX_IO_LOW_ADDR_PORT, (UINT8) Address);
*Data = IoRead8 (EC_INDEX_IO_DATA_PORT); }

@@ -184,8 +185,8 @@ EcIdxWrite (
IN UINT8 Data
)
{
- IoWrite8 (EC_INDEX_IO_HIGH_ADDR_PORT, Address >> 8);
- IoWrite8 (EC_INDEX_IO_LOW_ADDR_PORT, Address);
+ IoWrite8 (EC_INDEX_IO_HIGH_ADDR_PORT, (UINT8) (Address >> 8));
+ IoWrite8 (EC_INDEX_IO_LOW_ADDR_PORT, (UINT8) Address);
IoWrite8 (EC_INDEX_IO_DATA_PORT, Data); }

diff --git
a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInit
Lib/DxeBoardInitLib.c
b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInit
Lib/DxeBoardInitLib.c
index 4bce51886e..5c5c26d85c 100644
---
a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInit
Lib/DxeBoardInitLib.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/Boar
+++ dInitLib/DxeBoardInitLib.c
@@ -2,6 +2,7 @@
Aspire VN7-572G Board Initialization DXE library

Copyright (c) 2021, Baruch Binyamin Doron
+ Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -46,7 +47,7 @@ EcSendTime (
SendEcCommand (0xE0);
for (Index = 0; Index < 4; Index++) {
// Shift bytes
- EcTimeByte = EcTime >> Index*8;
+ EcTimeByte = (UINT8) (EcTime >> (Index * 8));
DEBUG ((DEBUG_INFO, "EC: Sending 0x%x (iteration %d)\n", EcTimeByte,
Index));
SendEcData (EcTimeByte);
}
diff --git
a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInit
Lib/PeiAspireVn7Dash572GDetect.c
b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInit
Lib/PeiAspireVn7Dash572GDetect.c
index d379fdb0d4..344e06859e 100644
---
a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInit
Lib/PeiAspireVn7Dash572GDetect.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/Boar
+++ dInitLib/PeiAspireVn7Dash572GDetect.c
@@ -1,6 +1,6 @@
/** @file

-Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -29,7 +29,6 @@ GetAspireVn7Dash572GBoardId (
OUT UINT8 *BoardId
)
{
- EFI_STATUS Status;
UINT16 DataBuffer;

ReadEcAdcConverter (MODEL_ID_AD, &DataBuffer); diff --git
a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInit
Lib/PeiAspireVn7Dash572GInitPostMemLib.c
b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInit
Lib/PeiAspireVn7Dash572GInitPostMemLib.c
index 2946e174ca..77722f5d60 100644
---
a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInit
Lib/PeiAspireVn7Dash572GInitPostMemLib.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/Boar
+++ dInitLib/PeiAspireVn7Dash572GInitPostMemLib.c
@@ -1,6 +1,6 @@
/** @file

-Copyright (c) 2017, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -40,7 +40,6 @@ EcInit (
UINT16 ABase;
UINT16 Pm1Sts;
UINT32 GpeSts;
- UINT16 XhciPmCs;

/* This is called via a "$FNC" in a PeiOemModule pointer table, with "$DPX" on
SiInit */
IoWrite8 (0x6C, 0x5A); // 6Ch is the EC sideband port @@ -66,13 +65,13 @@
EcInit (
IoWrite32 (ABase + R_PCH_ACPI_GPE0_STS_127_96, GpeSts);
/* Clear xHCI PM_CS[PME_Status] - RW/1C - and disable xHCI
PM_CS[PME_En] */
PciAndThenOr16 (PCI_LIB_ADDRESS(PCI_BUS_NUMBER_PCH_XHCI,
PCI_DEVICE_NUMBER_PCH_XHCI, PCI_FUNCTION_NUMBER_PCH_XHCI,
R_PCH_XHCI_PWR_CNTL_STS),
- ~B_PCH_XHCI_PWR_CNTL_STS_PME_EN,
+ (UINT16) ~B_PCH_XHCI_PWR_CNTL_STS_PME_EN,
B_PCH_XHCI_PWR_CNTL_STS_PME_STS
);

/* Enter S3 sleep */
IoAndThenOr32 (ABase + R_PCH_ACPI_PM1_CNT,
- ~(B_PCH_ACPI_PM1_CNT_SLP_TYP |
B_PCH_ACPI_PM1_CNT_SLP_EN),
+ (UINT32) ~(B_PCH_ACPI_PM1_CNT_SLP_TYP |
+ B_PCH_ACPI_PM1_CNT_SLP_EN),
V_PCH_ACPI_PM1_CNT_S3
);
IoWrite32 (ABase + R_PCH_ACPI_PM1_CNT,
B_PCH_ACPI_PM1_CNT_SLP_EN); diff --git
a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/Pe
iSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/Pe
iSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
index ad85326bf9..0a8cf91b07 100644
---
a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/Pe
iSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Libra
+++ ry/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
@@ -53,6 +53,8 @@
gHsioSataPreMemConfigGuid ## CONSUMES
gSaMiscPeiPreMemConfigGuid ## CONSUMES
gFspNonVolatileStorageHobGuid ## CONSUMES
+ gIoApicConfigGuid ## CONSUMES
+ gHpetPreMemConfigGuid ## CONSUMES
gLockDownConfigGuid
gPchGeneralConfigGuid
gCpuPowerMgmtBasicConfigGuid
--
2.27.0.windows.1


回复: [edk2-devel] [PATCH V2 2/9] MdePkg: Add PcdPciIoTranslation PCD

gaoliming
 

Daniel:
We should try to keep single patch in one package. For this patch set, patch 3 depends on patch 2, every patch doesn't break the platform. So, I agree to keep them as the separate one.

Thanks
Liming

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Daniel
Schaefer
发送时间: 2021年9月29日 7:11
收件人: Abner Chang <abner.chang@...>; devel@edk2.groups.io
抄送: Michael D Kinney <michael.d.kinney@...>; Liming Gao
<gaoliming@...>; Zhiguang Liu <zhiguang.liu@...>; Ard
Biesheuvel <ardb+tianocore@...>; Leif Lindholm <leif@...>;
Sami Mujawar <sami.mujawar@...>; Gerd Hoffmann
<kraxel@...>; Sunil V L <sunilvl@...>
主题: Re: [edk2-devel] [PATCH V2 2/9] MdePkg: Add PcdPciIoTranslation PCD

I think it would make sense to combine this patch with
3/9 ArmPkg: Use PcdPciIoTranslation PCD from MdePkg

It's pointless by itself.

On 9/28/21 16:31, Abner Chang wrote:
This PCD is moved from ArmPkg that is used to set the base address
of PCI MMIO window that provides I/O access. We relocate this PCD
because this PCD is common to ARM and RSIC-V arch.

Signed-off-by: Abner Chang <abner.chang@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Leif Lindholm <leif@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Gerd Hoffmann <kraxel@...>
Cc: Daniel Schaefer <daniel.schaefer@...>
Cc: Sunil V L <sunilvl@...>
---
MdePkg/MdePkg.dec | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index a28a2daaff..08d259764a 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2302,6 +2302,10 @@
# @Prompt PCI Express Base Address.
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE0000000|UINT64
|0x0000000a

+ ## This value is used to set the base address of PCI MMIO window that
provides I/O access.
+ # @Prompt PCI I/O Memory Map Window Base Address.
+
gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation|0x0|UINT64|0x00000040
+
## This value is used to set the size of PCI express hierarchy. The
default is 256 MB.
# @Prompt PCI Express Base Size.
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize|0x10000000|UINT64|0x
0000000f



[edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg/AspireVn7Dash572G: Fix Visual Studio Build

Nate DeSimone
 

AspireVn7Dash572G currently does not build with Visual Studio.
This is due to the Visual C++ compiler generating warnings with the GCC
compiler does not. The two classes of issues are unused local variables
and implicit integer casts that could result in truncation. Visual C++
requires an explicit cast in cases where integer truncation is possible.

Cc: Chasel Chiu <chasel.chiu@...>
Cc: Benjamin Doron <benjamin.doron00@...>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@...>
---
.../AspireVn7Dash572G/Library/BoardEcLib/EcCommands.c | 9 +++++----
.../Library/BoardInitLib/DxeBoardInitLib.c | 3 ++-
.../Library/BoardInitLib/PeiAspireVn7Dash572GDetect.c | 3 +--
.../BoardInitLib/PeiAspireVn7Dash572GInitPostMemLib.c | 7 +++----
.../PeiSiliconPolicyUpdateLib.inf | 2 ++
5 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardEcLib/EcCommands.c b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardEcLib/EcCommands.c
index ea8a8ae11e..6e752b4e22 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardEcLib/EcCommands.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardEcLib/EcCommands.c
@@ -2,6 +2,7 @@
Board-specific EC commands.

Copyright (c) 2021, Baruch Binyamin Doron
+ Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -167,8 +168,8 @@ EcIdxRead (
return;
}

- IoWrite8 (EC_INDEX_IO_HIGH_ADDR_PORT, Address >> 8);
- IoWrite8 (EC_INDEX_IO_LOW_ADDR_PORT, Address);
+ IoWrite8 (EC_INDEX_IO_HIGH_ADDR_PORT, (UINT8) (Address >> 8));
+ IoWrite8 (EC_INDEX_IO_LOW_ADDR_PORT, (UINT8) Address);
*Data = IoRead8 (EC_INDEX_IO_DATA_PORT);
}

@@ -184,8 +185,8 @@ EcIdxWrite (
IN UINT8 Data
)
{
- IoWrite8 (EC_INDEX_IO_HIGH_ADDR_PORT, Address >> 8);
- IoWrite8 (EC_INDEX_IO_LOW_ADDR_PORT, Address);
+ IoWrite8 (EC_INDEX_IO_HIGH_ADDR_PORT, (UINT8) (Address >> 8));
+ IoWrite8 (EC_INDEX_IO_LOW_ADDR_PORT, (UINT8) Address);
IoWrite8 (EC_INDEX_IO_DATA_PORT, Data);
}

diff --git a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/DxeBoardInitLib.c b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/DxeBoardInitLib.c
index 4bce51886e..5c5c26d85c 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/DxeBoardInitLib.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/DxeBoardInitLib.c
@@ -2,6 +2,7 @@
Aspire VN7-572G Board Initialization DXE library

Copyright (c) 2021, Baruch Binyamin Doron
+ Copyright (c) 2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -46,7 +47,7 @@ EcSendTime (
SendEcCommand (0xE0);
for (Index = 0; Index < 4; Index++) {
// Shift bytes
- EcTimeByte = EcTime >> Index*8;
+ EcTimeByte = (UINT8) (EcTime >> (Index * 8));
DEBUG ((DEBUG_INFO, "EC: Sending 0x%x (iteration %d)\n", EcTimeByte, Index));
SendEcData (EcTimeByte);
}
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GDetect.c b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GDetect.c
index d379fdb0d4..344e06859e 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GDetect.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GDetect.c
@@ -1,6 +1,6 @@
/** @file

-Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -29,7 +29,6 @@ GetAspireVn7Dash572GBoardId (
OUT UINT8 *BoardId
)
{
- EFI_STATUS Status;
UINT16 DataBuffer;

ReadEcAdcConverter (MODEL_ID_AD, &DataBuffer);
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GInitPostMemLib.c b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GInitPostMemLib.c
index 2946e174ca..77722f5d60 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GInitPostMemLib.c
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Library/BoardInitLib/PeiAspireVn7Dash572GInitPostMemLib.c
@@ -1,6 +1,6 @@
/** @file

-Copyright (c) 2017, Intel Corporation. All rights reserved.<BR>
+Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent

**/
@@ -40,7 +40,6 @@ EcInit (
UINT16 ABase;
UINT16 Pm1Sts;
UINT32 GpeSts;
- UINT16 XhciPmCs;

/* This is called via a "$FNC" in a PeiOemModule pointer table, with "$DPX" on SiInit */
IoWrite8 (0x6C, 0x5A); // 6Ch is the EC sideband port
@@ -66,13 +65,13 @@ EcInit (
IoWrite32 (ABase + R_PCH_ACPI_GPE0_STS_127_96, GpeSts);
/* Clear xHCI PM_CS[PME_Status] - RW/1C - and disable xHCI PM_CS[PME_En] */
PciAndThenOr16 (PCI_LIB_ADDRESS(PCI_BUS_NUMBER_PCH_XHCI, PCI_DEVICE_NUMBER_PCH_XHCI, PCI_FUNCTION_NUMBER_PCH_XHCI, R_PCH_XHCI_PWR_CNTL_STS),
- ~B_PCH_XHCI_PWR_CNTL_STS_PME_EN,
+ (UINT16) ~B_PCH_XHCI_PWR_CNTL_STS_PME_EN,
B_PCH_XHCI_PWR_CNTL_STS_PME_STS
);

/* Enter S3 sleep */
IoAndThenOr32 (ABase + R_PCH_ACPI_PM1_CNT,
- ~(B_PCH_ACPI_PM1_CNT_SLP_TYP | B_PCH_ACPI_PM1_CNT_SLP_EN),
+ (UINT32) ~(B_PCH_ACPI_PM1_CNT_SLP_TYP | B_PCH_ACPI_PM1_CNT_SLP_EN),
V_PCH_ACPI_PM1_CNT_S3
);
IoWrite32 (ABase + R_PCH_ACPI_PM1_CNT, B_PCH_ACPI_PM1_CNT_SLP_EN);
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
index ad85326bf9..0a8cf91b07 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/Policy/Library/PeiSiliconPolicyUpdateLib/PeiSiliconPolicyUpdateLib.inf
@@ -53,6 +53,8 @@
gHsioSataPreMemConfigGuid ## CONSUMES
gSaMiscPeiPreMemConfigGuid ## CONSUMES
gFspNonVolatileStorageHobGuid ## CONSUMES
+ gIoApicConfigGuid ## CONSUMES
+ gHpetPreMemConfigGuid ## CONSUMES
gLockDownConfigGuid
gPchGeneralConfigGuid
gCpuPowerMgmtBasicConfigGuid
--
2.27.0.windows.1


[edk2-platforms] [PATCH V1] KabylakeOpenBoardPkg: Fix Build

Nate DeSimone
 

Commit d281e9e broke the build for KabylakeOpenBoardPkg due
to DxeMultiBoardAcpiSupportLib having a dependency on
BoardAcpiTableLib that was never declared. This change adds
a correct declaration of the library dependency and fixes the build.

Cc: Chasel Chiu <chasel.chiu@...>
Signed-off-by: Nate DeSimone <nathaniel.l.desimone@...>
---
.../Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf | 3 ++-
.../Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf
index 9fe27f9fda..dc597c4808 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf
@@ -1,7 +1,7 @@
### @file
# System 76 GalagoPro3 board multi-board DXE ACPI table support functionality.
#
-# Copyright (c) 2019, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2019 - 2021, Intel Corporation. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -26,6 +26,7 @@
BaseLib
IoLib
PciLib
+ BoardAcpiTableLib
AslUpdateLib

[Packages]
diff --git a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf
index e5de9268e7..8438b16a6e 100644
--- a/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf
+++ b/Platform/Intel/KabylakeOpenBoardPkg/KabylakeRvp3/Library/BoardAcpiLib/DxeMultiBoardAcpiSupportLib.inf
@@ -1,7 +1,7 @@
### @file
# Kaby Lake RVP 3 Multi-Board ACPI Support library
#
-# Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.<BR>
+# Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.<BR>
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -26,6 +26,7 @@
BaseLib
IoLib
PciLib
+ BoardAcpiTableLib
AslUpdateLib

[Packages]
--
2.27.0.windows.1


Re: [PATCH V2 7/9] MdePkg: Add PcdPciMmio32(64)Translation PCDs

Abner Chang
 

-----Original Message-----
From: Schaefer, Daniel
Sent: Wednesday, September 29, 2021 7:36 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
devel@edk2.groups.io
Cc: Michael D Kinney <michael.d.kinney@...>; Liming Gao
<gaoliming@...>; Zhiguang Liu <zhiguang.liu@...>; Ard
Biesheuvel <ardb+tianocore@...>; Leif Lindholm
<leif@...>; Sami Mujawar <sami.mujawar@...>; Gerd
Hoffmann <kraxel@...>; Sunil V L <sunilvl@...>
Subject: Re: [PATCH V2 7/9] MdePkg: Add PcdPciMmio32(64)Translation
PCDs

Also here. I think this should be combined into patch 8.
Same reason as the previous one.

Because there are different maintainers for MdePkg and Arm*Pkg, thus we have to separate the patches for them based on Maintainers.txt. MdePkg owners just give their reviewed-by for the MdePkg changes but not Arm*Pkg changes. So those changes can't be in the same patch.
The cover letter gives each module maintainers the whole picture of this patch set. So they can understand the reason having the changes on their module.

Abner


On 9/28/21 16:31, Abner Chang wrote:
PcdPciMmio32Translation and PcdPciMmio64Translation PCDs are added
to MdePkg as the common PCDs for ARM and RSIC-V archs.

The one under ArmPkg is removed in the next patch.

Signed-off-by: Abner Chang <abner.chang@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Leif Lindholm <leif@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Gerd Hoffmann <kraxel@...>
Cc: Daniel Schaefer <daniel.schaefer@...>
Cc: Sunil V L <sunilvl@...>
---
MdePkg/MdePkg.dec | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 08d259764a..9df95abc50 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2306,6 +2306,14 @@
# @Prompt PCI I/O Memory Map Window Base Address.
gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation|0x0|UINT64|0x00000040

+ ## This value is used for the 32-bit PCI memory map I/O base address
translation.
+ # @Prompt 32-bit PCI Memory Map I/O Base Address translation.
+
gEfiMdePkgTokenSpaceGuid.PcdPciMmio32Translation|0x0|UINT64|0x0000
0041
+
+ ## This value is used for the 64-bit PCI memory map I/O base address
translation.
+ # @Prompt 64-bit PCI Memory Map I/O Base Address translation.
+
gEfiMdePkgTokenSpaceGuid.PcdPciMmio64Translation|0x0|UINT64|0x0000
0042
+
## This value is used to set the size of PCI express hierarchy. The default
is 256 MB.
# @Prompt PCI Express Base Size.
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize|0x10000000|UINT64|0x
0000000f


Re: [PATCH V2 0/9] Migrate ArmVirtPkg modules to OvmfPkg

Abner Chang
 

-----Original Message-----
From: Schaefer, Daniel
Sent: Wednesday, September 29, 2021 7:12 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
devel@edk2.groups.io
Cc: Ard Biesheuvel <ardb+tianocore@...>; Leif Lindholm
<leif@...>; Sami Mujawar <sami.mujawar@...>; Jiewen Yao
<jiewen.yao@...>; Jordan Justen <jordan.l.justen@...>; Gerd
Hoffmann <kraxel@...>; Sunil V L <sunilvl@...>;
Liming Gao <gaoliming@...>; Zhiguang Liu
<zhiguang.liu@...>; Michael D Kinney <michael.d.kinney@...>
Subject: Re: [PATCH V2 0/9] Migrate ArmVirtPkg modules to OvmfPkg

Is there CI to check that the ArmVirtPkg platforms still builds with this?
I assume you haven't checked, Abner?
Yes, this patch set passed the CI before I sending it out :).
Abner


On 9/28/21 16:30, Abner Chang wrote:
In V2: Remove HPE license on the files that just moved around or
the changes in the file are just code removal.

This pacthes set is to migrate some modules from ArmVirtPkg
to under OvmfPkg for the upcoming RiscVVirtPkg that can leverage
those modules without the dependency with Arm*Pkg.

The modules moved from ArmVirtPkg to OvmfPkg are,
- FdtClientDxe
- PciPcdProducerLib
- HighMemDxe
- QemuFwCfgLib
- FdtPciHostBridgeLib
- VirtioFdtDxe

Below PCDs are moved to under MdePkg and leverage by RiscVVirtPkg.
This change also remove the dependency on ArmPkg of OvmfPkg.
- PcdPciIoTranslation
- PcdPciIoTranslation
- PcdPciMmio32(64)Translation

Signed-off-by: Abner Chang <abner.chang@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Leif Lindholm <leif@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jordan Justen <jordan.l.justen@...>
Cc: Gerd Hoffmann <kraxel@...>
Cc: Daniel Schaefer <daniel.schaefer@...>
Cc: Sunil V L <sunilvl@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Michael D Kinney <michael.d.kinney@...>

Abner Chang (9):
ArmVirtPkg/FdtClintDxe: Move FdtClientDxe to EmbeddedPkg
MdePkg: Add PcdPciIoTranslation PCD
ArmPkg: Use PcdPciIoTranslation PCD from MdePkg
ArmVirtPkg/FdtPciPcdProducerLib: Relocate PciPcdProducerLib to
OvmfPkg
ArmVirtPkg/HighMemDxe: Relocate HighMemDxe to OvmfPkg
ArmVirtPkg/QemuFwCfgLib: Relocate QemuFwCfgLib to OvmfPkg
MdePkg: Add PcdPciMmio32(64)Translation PCDs
ArmVirtPkg/FdtPciHostBridgeLib: Relocate FdtPciHostBridgeLib to
OvmfPkg/Fdt
ArmVirtPkg/VirtioFdtDxe: Relocate VirtioFdtDxe to OvmfPkg/Fdt

ArmPkg/ArmPkg.dec | 15 ++++++--------
ArmVirtPkg/ArmVirtPkg.dec | 3 ---
EmbeddedPkg/EmbeddedPkg.dec | 1 +
MdePkg/MdePkg.dec | 12 +++++++++++
ArmVirtPkg/ArmVirtCloudHv.dsc | 18 ++++++++---------
ArmVirtPkg/ArmVirtKvmTool.dsc | 18 ++++++++---------
ArmVirtPkg/ArmVirtQemu.dsc | 20 +++++++++----------
ArmVirtPkg/ArmVirtQemuKernel.dsc | 20 +++++++++----------
ArmVirtPkg/ArmVirtXen.dsc | 2 +-
EmbeddedPkg/EmbeddedPkg.dsc | 1 +
ArmVirtPkg/ArmVirtCloudHv.fdf | 6 +++---
ArmVirtPkg/ArmVirtKvmTool.fdf | 6 +++---
ArmVirtPkg/ArmVirtXen.fdf | 2 +-
ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 6 +++---
.../ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf | 2 +-
.../ArmVirtGicArchLib/ArmVirtGicArchLib.inf | 1 +
.../ArmVirtPL031FdtClientLib.inf | 1 +
.../ArmVirtPsciResetSystemLib.inf | 1 +
.../ArmVirtTimerFdtClientLib.inf | 1 +
.../KvmtoolRtcFdtClientLib.inf | 1 +
.../NorFlashKvmtoolLib/NorFlashKvmtoolLib.inf | 1 +
.../NorFlashQemuLib/NorFlashQemuLib.inf | 1 +
.../XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf | 1 +
ArmVirtPkg/XenioFdtDxe/XenioFdtDxe.inf | 1 +
.../Drivers}/FdtClientDxe/FdtClientDxe.inf | 1 -
.../FdtPciHostBridgeLib.inf | 11 +++++-----
.../FdtPciPcdProducerLib.inf | 5 ++---
.../Fdt}/HighMemDxe/HighMemDxe.inf | 4 ++--
.../Fdt}/VirtioFdtDxe/VirtioFdtDxe.inf | 2 +-
.../Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf | 6 +++---
.../Include/Protocol/FdtClient.h | 0
.../Drivers}/FdtClientDxe/FdtClientDxe.c | 0
.../FdtPciHostBridgeLib/FdtPciHostBridgeLib.c | 0
.../FdtPciPcdProducerLib.c | 0
.../Fdt}/HighMemDxe/HighMemDxe.c | 0
.../Fdt}/VirtioFdtDxe/VirtioFdtDxe.c | 0
.../Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c | 7 ++++---
Maintainers.txt | 6 ++++++
38 files changed, 102 insertions(+), 81 deletions(-)
rename {ArmVirtPkg =>
EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.inf (92%)
rename {ArmVirtPkg/Library =>
OvmfPkg/Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf (77%)
rename {ArmVirtPkg/Library =>
OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf (87%)
rename {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.inf
(91%)
rename {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.inf (92%)
rename ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.inf =>
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.inf (86%)
rename {ArmVirtPkg => EmbeddedPkg}/Include/Protocol/FdtClient.h
(100%)
rename {ArmVirtPkg =>
EmbeddedPkg/Drivers}/FdtClientDxe/FdtClientDxe.c (100%)
rename {ArmVirtPkg/Library =>
OvmfPkg/Fdt}/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c (100%)
rename {ArmVirtPkg/Library =>
OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c (100%)
rename {ArmVirtPkg => OvmfPkg/Fdt}/HighMemDxe/HighMemDxe.c
(100%)
rename {ArmVirtPkg => OvmfPkg/Fdt}/VirtioFdtDxe/VirtioFdtDxe.c (100%)
rename ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c =>
OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLibMMIO.c (93%)


Re: [PATCH V2 2/9] MdePkg: Add PcdPciIoTranslation PCD

Abner Chang
 

-----Original Message-----
From: Schaefer, Daniel
Sent: Wednesday, September 29, 2021 7:11 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
devel@edk2.groups.io
Cc: Michael D Kinney <michael.d.kinney@...>; Liming Gao
<gaoliming@...>; Zhiguang Liu <zhiguang.liu@...>; Ard
Biesheuvel <ardb+tianocore@...>; Leif Lindholm
<leif@...>; Sami Mujawar <sami.mujawar@...>; Gerd
Hoffmann <kraxel@...>; Sunil V L <sunilvl@...>
Subject: Re: [PATCH V2 2/9] MdePkg: Add PcdPciIoTranslation PCD

I think it would make sense to combine this patch with
3/9 ArmPkg: Use PcdPciIoTranslation PCD from MdePkg

It's pointless by itself.
Because there are different maintainers for MdePkg and Arm*Pkg, thus we have to separate the patches for them based on Maintainers.txt. MdePkg owners just give their reviewed-by for the MdePkg changes but not Arm*Pkg changes. So those changes can't be in the same patch.
The cover letter gives each module maintainers the whole picture of this patch set. So they can understand the reason having the changes on their module.

Abner

On 9/28/21 16:31, Abner Chang wrote:
This PCD is moved from ArmPkg that is used to set the base address
of PCI MMIO window that provides I/O access. We relocate this PCD
because this PCD is common to ARM and RSIC-V arch.

Signed-off-by: Abner Chang <abner.chang@...>
Cc: Michael D Kinney <michael.d.kinney@...>
Cc: Liming Gao <gaoliming@...>
Cc: Zhiguang Liu <zhiguang.liu@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Leif Lindholm <leif@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Gerd Hoffmann <kraxel@...>
Cc: Daniel Schaefer <daniel.schaefer@...>
Cc: Sunil V L <sunilvl@...>
---
MdePkg/MdePkg.dec | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index a28a2daaff..08d259764a 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2302,6 +2302,10 @@
# @Prompt PCI Express Base Address.
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE0000000|UINT6
4|0x0000000a

+ ## This value is used to set the base address of PCI MMIO window that
provides I/O access.
+ # @Prompt PCI I/O Memory Map Window Base Address.
+
gEfiMdePkgTokenSpaceGuid.PcdPciIoTranslation|0x0|UINT64|0x00000040
+
## This value is used to set the size of PCI express hierarchy. The default
is 256 MB.
# @Prompt PCI Express Base Size.
gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize|0x10000000|UINT64|0x
0000000f


回复: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

gaoliming
 

Johnson:
I also agree this proposal to make BufferOneElement parameter mandatory.

Thanks
Liming

-----邮件原件-----
发件人: Brian J. Johnson <brian.johnson@...>
发送时间: 2021年9月29日 6:26
收件人: devel@edk2.groups.io; ray.ni@...; Marvin Häuser
<mhaeuser@...>; fanjianfeng@...; 'gaoliming'
<gaoliming@...>; Chan, Amy <amy.chan@...>; 'Andrew
Fish' <afish@...>
抄送: Kinney, Michael D <michael.d.kinney@...>; 'Gao, Liming'
<liming.gao@...>; Liu, Zhiguang <zhiguang.liu@...>; Wang, Jian
J <jian.j.wang@...>; Gao, Zhichao <zhichao.gao@...>
主题: Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

I'll add my agreement to Marvin and Jeff: a low-level sort routine like
this should let the caller be in charge of memory allocation, so it can
be used in the widest variety of contexts (SEC, exception handlers, APs,
etc.) So let's make the BufferOneElement parameter mandatory.

Brian J. Johnson

-------- Original Message --------
From: Ni, Ray [mailto:ray.ni@...]
Sent: Monday, September 27, 2021, 8:49 PM
To: Marvin Häuser <mhaeuser@...>, fanjianfeng@...
<fanjianfeng@...>, devel@edk2.groups.io
<devel@edk2.groups.io>, 'gaoliming' <gaoliming@...>, Chan,
Amy <amy.chan@...>, 'Andrew Fish' <afish@...>
Cc: Kinney, Michael D <michael.d.kinney@...>, 'Gao, Liming'
<liming.gao@...>, Liu, Zhiguang <zhiguang.liu@...>, Wang,
Jian J <jian.j.wang@...>, Gao, Zhichao <zhichao.gao@...>
Subject: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

Marvin,
I agree with your concerns, in a certain level. But I didn't treat it
as a very big problem of having caller pass the BufferOneElement
"intelligently".

I am ok to use your option 1), making BufferOneElement mandatory.
Caller should always supply the buffer that's sufficient to hold one
element.

By the way, I don't want to propose "swap-without-using-temporary-value"
method to avoid using the "BufferOneElement"?
Because that makes the simple thing complicated!

Thanks,
Ray

-----Original Message-----
From: Marvin Häuser <mhaeuser@...>
Sent: Monday, September 27, 2021 5:09 PM
To: fanjianfeng@...; devel@edk2.groups.io; Ni, Ray
<ray.ni@...>; 'gaoliming'
<gaoliming@...>; Chan, Amy <amy.chan@...>; 'Andrew
Fish' <afish@...>
Cc: Kinney, Michael D <michael.d.kinney@...>; 'Gao, Liming'
<liming.gao@...>; Liu, Zhiguang
<zhiguang.liu@...>; Wang, Jian J <jian.j.wang@...>; Gao,
Zhichao <zhichao.gao@...>
Subject: Re: [edk2-devel] RFC: Add BaseLib/QuickSort in MdePkg

On 27/09/2021 10:50, fanjianfeng@... wrote:
For former caller, they could still keep as is to call the old API in
MdeModulePkg. I think Ray's design is compatible change for existing code.
Only when the existing code wants to remove the dependency on
MdeModuelPkg, they could migrate to the new API in baselib.

I agree with one split-API desgin what you mentioned.
But my point is to define one API in baselib and to make the baselib
not depend on memory allocation. And another wrapper API could be
designed to be placed in any other class.
Oh sure, it could totally live in another class. I'd just like to have
those two models (caller- and callee-owned buffer) strictly separate, I
personally do not mind where exactly they are implemented. Thanks!

Best regards,
Marvin


------------------------------------------------------------------------
Jeff
fanjianfeng@...

*From:* Marvin Häuser <mailto:mhaeuser@...>
*Date:* 2021-09-27 16:14
*To:* fanjianfeng@...
<mailto:fanjianfeng@...>; devel@edk2.groups.io
<mailto:devel@edk2.groups.io>; Ni, Ray <mailto:ray.ni@...>;
'gaoliming' <mailto:gaoliming@...>; Chan, Amy
<mailto:amy.chan@...>; 'Andrew Fish'
<mailto:afish@...>
*CC:* Kinney, Michael D <mailto:michael.d.kinney@...>;
'Gao,
Liming' <mailto:liming.gao@...>; Liu, Zhiguang
<mailto:zhiguang.liu@...>; Wang, Jian J
<mailto:jian.j.wang@...>; Gao, Zhichao
<mailto:zhichao.gao@...>
*Subject:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort in
MdePkg
On 27/09/2021 02:45, fanjianfeng@... wrote:
> Making baselib implementation depend on MemoryAllocationLib
> (indirectly on Pei Service and gBS), it may prevent
> this base API using at some seneraio. i don't think it's better.
That is why I asked about a split-API scenario, one of which does
not
depend on dynamic memory allocation (SetVariable-like) and one
does
(wrapper-like).
> Add this parameter and make this parameter is optional,
> 1, when NULL, use the local 256 bytes stack
> 2, if 256 bytes stack is not enough, return
RETURE_BUFFER_TOO_SAMLL,
> 3, caller check the return status, to do nothing or to allocate
enough
> buffer for retry
>
> This is just like SetVariable()'s implementation.
Yes, and because that is SetVariable's implementation, we have
library
functions to make it less error-prone and more convenient [1]. As a
matter of fact, we have a (semi-lax) policy in our codebases to avoid
such functions like the plague and use those library wrappers
where-ever
it can make sense. The only super-rare exceptions I can think of are
when we know the size of the element ahead of time. Also
SetVariable has
no arbitrary constraint on when it may work the first time, and
there is
code that will fail when the first return is not
EFI_BUFFER_TOO_SMALL.
This solution honestly yields even more problems, because it
introduces
a Status return which was not there before. For common code
safety
and
quality policy, this requires the value *must* be retrieved and
checked
in some fashion. So all callers, no matter the prior knowledge of the
element size, now need either a runtime check and handling for a
status
that they (may) know can never be returned, or ASSERTs if the
function
spec really imposes the arbitrary 256 Bytes constraint. Latter
doesn't
really work I think. What if someone wants to sort in SEC and
noticed
they only have 64 Bytes on the stack to work with, realistically? Any
code depending on the 256 Byte constraint, passing NULL and not
doing
additional handling, would seize to work. Former is too
complicated, see
wrappers. In my opinion, the memory must *either* be fully
managed by
the caller *or* the callee (and you may have both in separate
functions,
as I suggested), but not sometimes here, sometimes there.
Best regards,
Marvin
[1]
https://github.com/tianocore/edk2/blob/46b4606ba23498d3d0e66b53e498e
b3d5d592586/MdePkg/Library/UefiLib/UefiLib.c#L
1309-L1360
>
>
------------------------------------------------------------------------
> Jeff
> fanjianfeng@...
>
> *From:* Marvin Häuser <mailto:mhaeuser@...>
> *Date:* 2021-09-26 19:20
> *To:* devel <mailto:devel@edk2.groups.io>; ray.ni
> <mailto:ray.ni@...>; gaoliming
> <mailto:gaoliming@...>; Chan, Amy
> <mailto:amy.chan@...>; 'Andrew Fish'
<mailto:afish@...>
> *CC:* Kinney, Michael D
<mailto:michael.d.kinney@...>;
'Gao,
> Liming' <mailto:liming.gao@...>; Liu, Zhiguang
> <mailto:zhiguang.liu@...>; Wang, Jian J
> <mailto:jian.j.wang@...>; Gao, Zhichao
> <mailto:zhichao.gao@...>
> *Subject:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort
in MdePkg
> Hey Ray,
> In my opinion that spec is too complicated. For some cases
it is
> obvious, but I think the last anyone wants to see is a
> (STATIC_)ASSERT
> before most QuickSort calls to ensure the element size
*really* is <=
> 256 Bytes. In my opinion, there are two roads:
> 1) Make the parameter required (I think this is what Liming
> suggested).
> The caller would always need to provide said buffer, and it
can do
> as it
> sees fit - on the stack, in a pool, in a page, who knows.
> 2) Remove the parameter entirely. The library would
depend on
> MemoryAllocationLib again, but also would have an
optimisation by
> choosing stack vs pool based on ElementSize.
> Usually I would prefer 2), as it is less prone to caller
errors, but
> considering the low-level nature of edk2, I can totally see
the
> point to
> allow the caller to control whether there are dynamic
memory
> allocations
> made or not as possible with 1). 2) could technically also be
a
> wrapper
> for 1) if you want granular control and convenience/safety
(why not
> actually?).
> Both approaches have the advantage that it is crystal-clear
what the
> caller's job is - to always or to never allocate the buffer.
> Best regards,
> Marvin
> On 26/09/2021 04:24, Ni, Ray wrote:
> >
> > Liming,
> >
> > The purpose of the optional BufferOneElement is to ease
consumer’s
> > life assuming most of the time the element size should be
> smaller than
> > 256.
> >
> > Are you saying that it’s a bit hard to calculate the actual
> value of
> > sizeof (Element) when writing code?
> >
> > I recommend consumer always allocates memory if it’s
hard
to judge
> > sizeof (Element) < 256.
> >
> > Searching edk2 code, I can find below code using
PerformQuickSort():
> >
> > 1. ShellPkg/UefiShellCommandLib: It’s sorting array of
> > (EFI_DEVICE_PATH_PROTOCOL *).
> > 2. UefiCpuPkg/CpuCacheInfoLib: It’s sorting array of
> CPU_CACHE_INFO.
> > 3. MinPlatformPkg/AcpiTables: It’s sorting array of
> EFI_CPU_ID_ORDER_MAP.
> > 4. MdeModulePkg/UefiBootManagerLib: It’s sorting
array of
> > EFI_BOOT_MANAGER_LOAD_OPTION.
> > 5. MdeModulePkg/CapsuleApp: It’s sorting array of
(EFI_FILE_INFO *)
> > 6. CryptoPkg/CrtWrapper: It’s sorting array of
(unknown
type).
> > 7. RedfishPkg/RedfishCrtLib: It’s sorting array of
(unknown type).
> >
> > For 1~5, it’s easy to know that the size of the element is
smaller
> > than 256. The AllocatePool() can be skipped.
> >
> > Thanks,
> >
> > Ray
> >
> > *From:*gaoliming <gaoliming@...>
> > *Sent:* Sunday, September 26, 2021 10:01 AM
> > *To:* Ni, Ray <ray.ni@...>; devel@edk2.groups.io;
Chan, Amy
> > <amy.chan@...>; 'Andrew Fish'
<afish@...>
> > *Cc:* Kinney, Michael D <michael.d.kinney@...>;
'Gao, Liming'
> > <liming.gao@...>; Liu, Zhiguang
<zhiguang.liu@...>;
> Wang,
> > Jian J <jian.j.wang@...>; Gao, Zhichao
<zhichao.gao@...>
> > *Subject:* 回复: [edk2-devel] RFC: Add
BaseLib/QuickSort in
MdePkg
> >
> > Ray:
> >
> > I may suggest to always require BufferOneElement. The
consumer code
> > may not know ElementSize. To avoid the error, the
consumer
must
> > allocate buffer for BufferOneElement. If so,
BufferOneElement is
> the
> > required parameter.
> >
> > Thanks
> >
> > Liming
> >
> > *发件人**:*Ni, Ray <ray.ni@...
<mailto:ray.ni@...>>
> > *发送时间:* 2021年9月24日 11:53
> > *收件人:* devel@edk2.groups.io
<mailto:devel@edk2.groups.io>;
Ni,
> Ray
> > <ray.ni@... <mailto:ray.ni@...>>; Chan,
Amy
> > <amy.chan@... <mailto:amy.chan@...>>;
gaoliming
> > <gaoliming@...
<mailto:gaoliming@...>>;
> 'Andrew
> > Fish' <afish@... <mailto:afish@...>>
> > *抄送:* Kinney, Michael D <michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; 'Gao, Liming'
> > <liming.gao@... <mailto:liming.gao@...>>;
Liu,
Zhiguang
> > <zhiguang.liu@...
<mailto:zhiguang.liu@...>>;
Wang,
> Jian J
> > <jian.j.wang@... <mailto:jian.j.wang@...>>;
Gao,
> Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>
> > *主题:* RE: [edk2-devel] RFC: Add BaseLib/QuickSort in
MdePkg
> >
> > More details on new QuickSort() API:
> >
> > The new API needs to carry additional parameter
“BufferOneElement”.
> >
> > This parameter gives QuickSort() the temporary buffer for
> swapping in
> > sorting.
> >
> > It’s to avoid BaseLib depends on MemoryAllocationLib.
> >
> > …
> >
> > @param [in] BufferOneElement When ElementSize >
256, caller
> needs to
> > provide a buffer whose size
> > equals to
ElementSize. It’s
used by
> > QuickSort() for swapping in sorting.
> >
> > When ElementSize <= 256, QuickSort() uses a local stack
256-byte
> buffer.
> >
> > @retval EFI_INVALID_PARAMETER When (ElementSize >
256) and
> > (BufferOneElement == NULL).
> >
> > …
> >
> > VOID
> >
> > EFIAPI
> >
> > QuickSort (
> >
> > IN OUT
VOID *BufferToSort,
> >
> > IN CONST UINTN ElementCount,
> >
> > IN CONST UINTN ElementSize,
> >
> > IN SORT_COMPARE CompareFunction,
> >
> > IN VOID *BufferOneElement OPTIONAL
> >
> > );
> >
> > Any comments?
> >
> > *From:*devel@edk2.groups.io
<mailto:devel@edk2.groups.io>
> > <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
*On
Behalf Of
> > *Ni, Ray
> > *Sent:* Wednesday, September 22, 2021 2:04 PM
> > *To:* Chan, Amy <amy.chan@...
<mailto:amy.chan@...>>;
> > gaoliming <gaoliming@...
> > <mailto:gaoliming@...>>; 'Andrew Fish'
<afish@...
> > <mailto:afish@...>>; 'edk2-devel-groups-io'
> > <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
> > *Cc:* Kinney, Michael D <michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; 'Gao, Liming'
> > <liming.gao@... <mailto:liming.gao@...>>;
Liu,
Zhiguang
> > <zhiguang.liu@...
<mailto:zhiguang.liu@...>>;
Wang,
> Jian J
> > <jian.j.wang@... <mailto:jian.j.wang@...>>;
Gao,
> Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>
> > *Subject:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort
in
MdePkg
> >
> > I don’t see objection so far.
> >
> > So, the final solution is:
> >
> > 1. Add QuickSort() API to BaseLib in MdePkg.
> > 2. Update existing MdeModulePkg/SortLib to use
QuickSort() in the
> > implementation (proposed by Andrew Fish and
Liming Gao)
> > 3. Update UefiCpuPkg to use QuickSortLib to remove
improper
> > dependency on MdeModulePkg
> >
> > Thanks,
> >
> > Ray
> >
> > *From:*Ni, Ray
> > *Sent:* Thursday, September 16, 2021 10:48 AM
> > *To:* Chan, Amy <amy.chan@...
<mailto:amy.chan@...>>;
> > gaoliming <gaoliming@...
> > <mailto:gaoliming@...>>; 'Andrew Fish'
<afish@...
> > <mailto:afish@...>>; 'edk2-devel-groups-io'
> > <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
> > *Cc:* Kinney, Michael D <michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; 'Gao, Liming'
> > <liming.gao@... <mailto:liming.gao@...>>;
Liu,
Zhiguang
> > <Zhiguang.Liu@...
<mailto:Zhiguang.Liu@...>>;
Wang,
> Jian J
> > <jian.j.wang@... <mailto:jian.j.wang@...>>;
Gao,
> Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>
> > *Subject:* RE: [edk2-devel] RFC: Add BaseLib/QuickSort
in
MdePkg
> >
> > Amy,
> >
> > No. We only Add QuickSort() function API into BaseLib.h.
> >
> > *From:*Chan, Amy <amy.chan@...
<mailto:amy.chan@...>>
> > *Sent:* Thursday, September 16, 2021 10:46 AM
> > *To:* gaoliming <gaoliming@...
> > <mailto:gaoliming@...>>; 'Andrew Fish'
<afish@...
> > <mailto:afish@...>>; 'edk2-devel-groups-io'
> > <devel@edk2.groups.io <mailto:devel@edk2.groups.io>>
> > *Cc:* Ni, Ray <ray.ni@...
<mailto:ray.ni@...>>; Kinney,
> > Michael D <michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; 'Gao, Liming'
> > <liming.gao@... <mailto:liming.gao@...>>;
Liu,
Zhiguang
> > <zhiguang.liu@...
<mailto:zhiguang.liu@...>>;
Wang,
> Jian J
> > <jian.j.wang@... <mailto:jian.j.wang@...>>;
Gao,
> Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>
> > *Subject:* RE: [edk2-devel] RFC: Add BaseLib/QuickSort
in
MdePkg
> >
> > Just to double confirm, will we have the null instance of
> QuickSort in
> > MdePkg?
> >
> > Regards,
> >
> > Amy
> >
> > *From:*gaoliming <gaoliming@...
> > <mailto:gaoliming@...>>
> > *Sent:* Thursday, September 16, 2021 10:23 AM
> > *To:* 'Andrew Fish' <afish@...
<mailto:afish@...>>;
> > 'edk2-devel-groups-io' <devel@edk2.groups.io
> > <mailto:devel@edk2.groups.io>>
> > *Cc:* Ni, Ray <ray.ni@...
<mailto:ray.ni@...>>; Kinney,
> > Michael D <michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; 'Gao, Liming'
> > <liming.gao@... <mailto:liming.gao@...>>;
Liu,
Zhiguang
> > <zhiguang.liu@...
<mailto:zhiguang.liu@...>>;
Wang,
> Jian J
> > <jian.j.wang@... <mailto:jian.j.wang@...>>;
Gao,
> Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>;
Chan, Amy
> > <amy.chan@... <mailto:amy.chan@...>>
> > *Subject:* 回复: [edk2-devel] RFC: Add
BaseLib/QuickSort in
MdePkg
> >
> > Andrew:
> >
> > Thanks for your suggestion. I think your idea is better.
We add new
> > QuickSort() API to BaseLib, and update SortLib library
instance to
> > consume BaseLib QuickSort() API. This way has no change
in
current
> > SortLib library class. It is the compatible solution.
> >
> > Thanks
> >
> > Liming
> >
> > *发件人**:*Andrew Fish <afish@...
<mailto:afish@...>>
> > *发送时间:* 2021年9月16日 10:13
> > *收件人:* edk2-devel-groups-io <devel@edk2.groups.io
> > <mailto:devel@edk2.groups.io>>; Liming Gao
> <gaoliming@...
> > <mailto:gaoliming@...>>
> > *抄送:* Ni, Ray <ray.ni@...
<mailto:ray.ni@...>>; Mike
> > Kinney <michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; Gao, Liming
> > <liming.gao@... <mailto:liming.gao@...>>;
Liu,
Zhiguang
> > <zhiguang.liu@...
<mailto:zhiguang.liu@...>>;
Wang,
> Jian J
> > <jian.j.wang@... <mailto:jian.j.wang@...>>;
Gao,
> Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>;
Chan, Amy
> > <amy.chan@... <mailto:amy.chan@...>>
> > *主题:* Re: [edk2-devel] RFC: Add BaseLib/QuickSort in
MdePkg
> >
> > On Sep 15, 2021, at 6:26 PM, gaoliming
<gaoliming@...
> > <mailto:gaoliming@...>> wrote:
> >
> > Ray:
> >
> > SortLib has been added since 2015. I would
suggest to
still keep
> > this library class. To resolve the package
dependency, my
> proposal
> > is to move the library class header file SortLib.h
from
> > MdeModulePkg to MdePkg, and still keep the
library
instance in
> > MdeModulePkg. This proposal has no impact on
the existing
> platform.
> >
> > If we add QuickSort() API to the BaseLib can we not just
port the
> > existing MdeModulePkg/SortLib to use QuickSort() in the
> > implementation? Or is there some other way to add the
new
thing
> in a
> > backward compatible way.
> >
> > Thanks,
> >
> > Andrew Fish
> >
> > Thanks
> >
> > Liming
> >
> > *发件人**:*devel@edk2.groups.io
> > <mailto:devel@edk2.groups.io><devel@edk2.groups.io
> > <mailto:devel@edk2.groups.io>>*代表***Ni, Ray
> > *发送时间:*2021年9月14日14:15
> > *收件人:*Kinney, Michael D
<michael.d.kinney@...
> > <mailto:michael.d.kinney@...>>; Gao, Liming
> > <liming.gao@...
<mailto:liming.gao@...>>; Liu,
> > Zhiguang <zhiguang.liu@...
> <mailto:zhiguang.liu@...>>;
> > Wang, Jian J <jian.j.wang@...
> > <mailto:jian.j.wang@...>>; Gao, Zhichao
> > <zhichao.gao@...
<mailto:zhichao.gao@...>>
> > *抄送:*devel@edk2.groups.io
<mailto:devel@edk2.groups.io>;
> Chan, Amy
> > <amy.chan@...
<mailto:amy.chan@...>>
> > *主题:*[edk2-devel] RFC: Add BaseLib/QuickSort
in MdePkg
> >
> > Hi package maintainers of MdePkg,
MdeModulePkg and
ShellPkg,
> > community,
> >
> > A commit (UefiCpuPkg/CpuCacheInfoLib: Sort
CpuCacheInfo array
> >
>
<https://github.com/tianocore/edk2/commit/4de77ae9890d241271f543e919
5ab3516f3abec6>)
> > to UefiCpuPkg let
> > UefiCpuPkg depend on MdeModulePkg because
the SortLib
class and
> > instances are all in MdeModulePkg.
> >
> > UefiCpuPkg depending on MdeModulePkg breaks
the rule that
> > “UefiCpuPkg should ONLY depend on MdePkg”.
> >
> > To address this issue, there are two approaches:
> >
> > 1. Duplicate the sort logic in UefiCpuPkg to not
depend on
> > MdeModulePkg/SortLib
> > 2. Add QuickSort() API to BaseLib in MdePkg.
> >
> > Approach #2 (MdePkg/BaseLib/QuickSort) makes
more
sense because
> > quick sort is a standard algorithm.
> >
> > We encourage consumers to update their code to
use the
quick
> sort
> > in MdePkg and gradually deprecate today’s
MdeModulePkg/SortLib.
> >
> > If you don’t have concerns, I plan to:
> >
> > 1. “Add QuickSort() to BaseLib” and update all
existing
> consumers
> > to use this API instead.
> >
> > VOID
> >
> > EFIAPI
> >
> > QuickSort (
> >
> > IN OUT VOID *BufferT
oSort,
> >
> > IN CONST UINTN Count,
> >
> > IN CONST UINTN ElementSize,
> >
> > IN SORT_COMPARE Compare
Function
> >
> > );
> >
> > 2. “Add new ShellPkg/SortCompareLib”
> >
> > Background: ShellPkg requires to sort
devicepath/string so 3
> APIs
> > in UefiSortLib (DevicePathCompare,
StringNoCaseCompare,
> > StringCompare) are provided for Shell usage. we
can
move the 3
> > APIs to the SortCompareLib and update Shell code
to use
> > BaseLib/QuickSort directly, with the sort compare
function from
> > SortCompareLib.
> >
> > Any concerns?
> >
> > Thanks,
> >
> > Ray
> >
> >
>
>








--

Brian

--------------------------------------------------------------------

"Remember that ignorance is expensive."
-- From LLIB


Re: [PATCH V2 4/9] ArmVirtPkg/FdtPciPcdProducerLib: Relocate PciPcdProducerLib to OvmfPkg

Abner Chang
 

-----Original Message-----
From: Schaefer, Daniel
Sent: Wednesday, September 29, 2021 7:41 AM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>;
devel@edk2.groups.io
Cc: Ard Biesheuvel <ardb+tianocore@...>; Leif Lindholm
<leif@...>; Sami Mujawar <sami.mujawar@...>; Jiewen Yao
<jiewen.yao@...>; Jordan Justen <jordan.l.justen@...>; Gerd
Hoffmann <kraxel@...>; Sunil V L <sunilvl@...>
Subject: Re: [edk2-devel] [PATCH V2 4/9] ArmVirtPkg/FdtPciPcdProducerLib:
Relocate PciPcdProducerLib to OvmfPkg

Oh and this also needs to be followed up with a change to edk2-platforms.
Yes, all corresponding patches on edk2-platform are all ready to send. I will send those out once edk2 part gets reviewed-by. Then I will push those patch sets to both repos together.
Abner


On 9/29/21 07:16, Daniel Schaefer wrote:
Please fix the issue in the maintainers file.
Looks good otherwise:

Reviewed-By: Daniel Schaefer <daniel.schaefer@...>

On 9/28/21 16:31, Abner Chang wrote:
Relocate PciPcdProducerLib to OvmfPkg/Fdt, this library is
leverage by both ARM and RISC-V archs.

Add OvmfPkg/Fdt maintainers in Maintainers.txt

Signed-off-by: Abner Chang <abner.chang@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Leif Lindholm <leif@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Jordan Justen <jordan.l.justen@...>
Cc: Gerd Hoffmann <kraxel@...>
Cc: Daniel Schaefer <daniel.schaefer@...>
Cc: Sunil V L <sunilvl@...>
---
ArmVirtPkg/ArmVirtCloudHv.dsc | 8 ++++----
ArmVirtPkg/ArmVirtKvmTool.dsc | 8 ++++----
ArmVirtPkg/ArmVirtQemu.dsc | 8 ++++----
ArmVirtPkg/ArmVirtQemuKernel.dsc | 8 ++++----
.../Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf | 2 --
.../Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c | 0
Maintainers.txt | 6 ++++++
7 files changed, 22 insertions(+), 18 deletions(-)
rename {ArmVirtPkg/Library =>
OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf (92%)
rename {ArmVirtPkg/Library =>
OvmfPkg/Fdt}/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c (100%)

diff --git a/ArmVirtPkg/ArmVirtCloudHv.dsc
b/ArmVirtPkg/ArmVirtCloudHv.dsc
index f159754bf4..2928b9adb5 100644
--- a/ArmVirtPkg/ArmVirtCloudHv.dsc
+++ b/ArmVirtPkg/ArmVirtCloudHv.dsc
@@ -49,7 +49,7 @@
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBuffer
BltLib.inf
QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrder
Lib.inf
FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
-
PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProd
ucerLib.inf
+
PciPcdProducerLib|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLi
b.inf
PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibP
ci.inf
PciHostBridgeLib|ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeL
ib.inf
PciHostBridgeUtilityLib|ArmVirtPkg/Library/ArmVirtPciHostBridgeUtilityLib/A
rmVirtPciHostBridgeUtilityLib.inf
@@ -341,12 +341,12 @@
#
ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf {
<LibraryClasses>
-
NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+ NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
}
MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf {
<LibraryClasses>
-
NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+ NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
}
OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
@@ -360,5 +360,5 @@
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraph
icsResourceTableDxe.inf
ArmVirtPkg/CloudHvAcpiPlatformDxe/CloudHvAcpiPlatformDxe.inf {
<LibraryClasses>
-
NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+ NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
}
diff --git a/ArmVirtPkg/ArmVirtKvmTool.dsc
b/ArmVirtPkg/ArmVirtKvmTool.dsc
index ff70509542..3cc182545c 100644
--- a/ArmVirtPkg/ArmVirtKvmTool.dsc
+++ b/ArmVirtPkg/ArmVirtKvmTool.dsc
@@ -57,7 +57,7 @@

FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf

-
PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProd
ucerLib.inf
+
PciPcdProducerLib|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLi
b.inf
PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibP
ci.inf
PciHostBridgeLib|ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeL
ib.inf
PciHostBridgeUtilityLib|ArmVirtPkg/Library/ArmVirtPciHostBridgeUtilityLib/A
rmVirtPciHostBridgeUtilityLib.inf
@@ -338,17 +338,17 @@
#
ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf {
<LibraryClasses>
-
NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+ NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
NULL|ArmVirtPkg/Library/BaseCachingPciExpressLib/BaseCachingPciExpress
Lib.inf
}
MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
<LibraryClasses>
-
NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+ NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
NULL|ArmVirtPkg/Library/BaseCachingPciExpressLib/BaseCachingPciExpress
Lib.inf
}
MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf {
<LibraryClasses>
-
NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+ NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
NULL|ArmVirtPkg/Library/BaseCachingPciExpressLib/BaseCachingPciExpress
Lib.inf
}
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc
b/ArmVirtPkg/ArmVirtQemu.dsc
index f4bb14903f..85fcf5f310 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -77,7 +77,7 @@
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBuffer
BltLib.inf
QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrder
Lib.inf
FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
-
PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProd
ucerLib.inf
+
PciPcdProducerLib|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLi
b.inf
PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibP
ci.inf
PciHostBridgeLib|ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeL
ib.inf
PciHostBridgeUtilityLib|OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBrid
geUtilityLib.inf
@@ -487,12 +487,12 @@
#
ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf {
<LibraryClasses>
-
NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+ NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
}
MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf {
<LibraryClasses>
-
NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+ NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
}
OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
@@ -543,5 +543,5 @@
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraph
icsResourceTableDxe.inf
OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
<LibraryClasses>
-
NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+ NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
}
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc
b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index eecef1a063..909968d13a 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -75,7 +75,7 @@
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBuffer
BltLib.inf
QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrder
Lib.inf
FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
-
PciPcdProducerLib|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProd
ucerLib.inf
+
PciPcdProducerLib|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLi
b.inf
PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibP
ci.inf
PciHostBridgeLib|ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeL
ib.inf
PciHostBridgeUtilityLib|OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBrid
geUtilityLib.inf
@@ -423,12 +423,12 @@
#
ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf {
<LibraryClasses>
-
NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+ NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
}
MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf {
<LibraryClasses>
-
NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+ NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
}
OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
@@ -459,5 +459,5 @@
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraph
icsResourceTableDxe.inf
OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
<LibraryClasses>
-
NULL|ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+ NULL|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
}
diff --git
a/ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
b/OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
similarity index 92%
rename from
ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
rename to OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
index 1dfe779f6c..0f5156615b 100644
--- a/ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
+++ b/OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
@@ -20,8 +20,6 @@
FdtPciPcdProducerLib.c

[Packages]
- ArmPkg/ArmPkg.dec
- ArmVirtPkg/ArmVirtPkg.dec
EmbeddedPkg/EmbeddedPkg.dec
MdeModulePkg/MdeModulePkg.dec
MdePkg/MdePkg.dec
diff --git
a/ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c
b/OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c
similarity index 100%
rename from
ArmVirtPkg/Library/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c
rename to OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.c
diff --git a/Maintainers.txt b/Maintainers.txt
index 41f491bcae..c77b455381 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -463,6 +463,12 @@ R: Jiewen Yao <jiewen.yao@...> [jyao1]
R: Min Xu <min.m.xu@...> [mxu9]
R: Tom Lendacky <thomas.lendacky@...> [tlendacky]

+OvmfPkg: FDT related modules
+F: OvmfPkg/Fdt/Cc: Leif Lindholm <leif@...>
I think there's an issue with this line. Looks like two lines got mashed
together by accident.

+R: Leif Lindholm <leif@...>
+R: Gerd Hoffmann <kraxel@...>
+R: Abner Chang <abner.chang@...>
+
OvmfPkg: LsiScsi driver
F: OvmfPkg/LsiScsiDxe/
R: Gary Lin <glin@...>



11241 - 11260 of 92428