Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

2024-05-02 Thread Leif Lindholm

On 2024-05-02 04:08, Michael Kubacki wrote:
Thank you for this proposal. We've been anticipating this change for 
years and are excited to help support it.


Here's some items we'd like to raise for feedback that we could help 
implement. Many could likely be done in time for the transition.


1. Automate reviewers - We've discussed CODEOWNERS in the past. However, 
a simpler approach (in maintaining/syncing less files) would be to use 
Maintainers.txt directly with a GitHub workflow since the file already 
contains GitHub IDs.


That would be ideal. I know Mike worked on autogenerating CODEOWNERS 
from Maintainers.txt, but ultimately the latter supports more flexible 
use of wildcards (things like */AArch64/ currently requires reconciling 
against the repo contents).


2. Make PR completion contingent on a GitHub review from at least one 
package maintainer/reviewer for each package in the PR.


Yes.

3. Dependabot is already used today to automatically create PRs when 
dependencies like pip modules have updates. To allow this to more 
effectively keep dependencies up-to-date, allow dependabot PRs to be 
completed (after normal acceptance criteria like CI and review 
requirements) without a separate human creating a duplicate PR.


I am not sure what this means in practice :)
This doesn't sound like one we need to worry about before switchover though.

4. Potentially warn users (with an automated comment on the PR) if they 
add a push label to a PR that is less than 24 hours old.


That sounds good.
Is there any way to prevent force-pushes within 24h of previous push?
That would make setting up a transitional review-scraper less lossy.

5. Leave reminder comments on PRs with absolutely no activity after some 
agreed upon time so reviewers are notified to review the PR without the 
submitter having to watch it and send notifications.


Yes. But should take priority below 1, 2, and 4. Unless you have a 
pre-cooked thing to drop in of course.


6. Leave reminder comments on PRs that meet all requirements to be 
completed (all reviews accounted for and status checks pass) but are 
still open so those on the PR are notified to complete it without the 
submitter having to manually watch and send reminders.


Not a response to this, but triggered by reading this:
Is there any way to approve changes within a PR on a commit by commit basis?


7. We are happy to help with process documentation.


Always appreciated,thanks.

Regards,

Leif



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




Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

2024-05-02 Thread Leif Lindholm

On 2024-05-02 07:33, Marcin Juszkiewicz wrote:

W dniu 1.05.2024 o 19:43, Michael D Kinney via groups.io pisze:

I would like to propose that TianoCore move all code review from email
based code reviews to GitHub Pull Requests based code reviews.

The proposed date to switch would be immediately after the next stable
tag which is currently scheduled for May 24, 2024.


O yes! Fully for it!

Does it mean edk2 only or edk2/edk2-platforms/edk2-non-osi and other 
tianocore/ repositories?


I don't see why we couldn't switch all of them. Other than we need to 
get all the Maintainers.txt updated with code forge usernames first.


We may want to do one at a time though.

/
Leif


* The Pull Request submitter is required to invite the required
   maintainers and reviewers to the pull request. This is the same
   set of maintainers and reviewers that are required to be listed in
   Cc: tags in today's process.


That can be done by github action started automatically after opening 
PR. May require changes to GetMaintainer.py script. Would be good to 
have in case someone forget to add one of maintainers.


Also would be nice to have a bot running PatchCheck and uncrustify on PR.









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




Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

2024-05-02 Thread Leif Lindholm

On 2024-05-02 02:28, Rebecca Cran wrote:

On Wed, May 1, 2024, at 11:43 AM, Michael D Kinney wrote:

* The Pull Request submitter is required to invite the required
   maintainers and reviewers to the pull request. This is the same
   set of maintainers and reviewers that are required to be listed in
   Cc: tags in today's process.


This seems like something that could rather easily be automated by parsing the 
maintainers file.


Yes, I pushed an example update to GetMaintainer.py here:
https://github.com/leiflindholm/edk2/tree/getmaintainer-forgeusername

But I think the actual option name, and output behaviour, needs to be 
discussed.


/
Leif



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




Re: [edk2-devel] Proposal to switch TianoCore Code Review from email to GitHub Pull Requests on 5-24-2024

2024-05-01 Thread Leif Lindholm

On 2024-05-01 18:43, Michael D Kinney wrote:

Hello,

I would like to propose that TianoCore move all code review from email
based code reviews to GitHub Pull Requests based code reviews.

The proposed date to switch would be immediately after the next stable
tag which is currently scheduled for May 24, 2024.


Thanks Mike.

I'm in favour of this change, and the date.

I still want us to try to figure out how to retain review history beyond 
what github decides we need, but I don't think it justifies indefinitely 
delaying the switchover. And frankly, it will be easier to experiment 
with what works and not after the switch.


/
Leif


Updates to the following Wiki page would be required to describe the
required process when using GitHub Pull Requests for all code review
related activity.

 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process

A couple examples of the changes that would need to be documented are:

* All contributors, maintainers, and reviewers must have GitHub IDs.
* The commit message would no longer require Cc:, Reviewed-by:, Acked-by:
   or Tested-by: tags.  The only required tag would be Signed-off-by.
* The Pull Request submitter is required to invite the required
   maintainers and reviewers to the pull request. This is the same
   set of maintainers and reviewers that are required to be listed in
   Cc: tags in today's process.
* Maintainers are responsible for verifying that all conversations in
   the code review are resolved and that all review approvals from the
   required set of maintainers are present before setting the 'push' label.


Please provide feedback
1) If you are not in favor of this change.
2) If you are not in favor of the proposed date of this change.
3) On the process changes you would like to see documented in the Wiki
pages related to using GitHub Pull Request based code reviews.

There is some prototype work to automate/simplify some of the PR based
code review process steps. Those could be added over time as resources
are available to finish and support them.

Best regards,

Mike









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




Re: [edk2-devel] [PATCH edk2-platforms v2 0/2] SbsaQemu: some cleanups

2024-04-24 Thread Leif Lindholm
On Wed, Apr 24, 2024 at 13:32:33 +0200, Marcin Juszkiewicz wrote:
> I am working on some changes to SbsaQemu and got some cleanups in
> meantime.
> 
> First patch gets rid of setting Pcds for Timer interrupts. ArmPkg does
> it for us so we do not have to.
> 
> Second changes DSDT nodes so iasl does not complain.
> 
> Marcin Juszkiewicz (2):
>   SbsaQemu: do not set Timer interrupts
>   SbsaQemu: remove some methods from DSDT

For series:
Reviewed-by: Leif Lindholm 

Thanks!

/
Leif

>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc   | 10 --
>  Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl | 23 ---
>  2 files changed, 8 insertions(+), 25 deletions(-)
> 
> -- 
> 2.44.0
> 
> 
> 
> 
> 
> 


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




[edk2-devel] [PATCH edk2-non-osi 1/1] Maintainers.txt: add maintainers for SbsaQemu platform

2024-04-23 Thread Leif Lindholm
Signed-off-by: Leif Lindholm 
---

p.s. Mike, could you add write access for Marcin in this repo as well?
 It was a pure oversight not to ask this at the same time as for
 edk2-platforms.

 Maintainers.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index eaf13fda6af0..2cdff26facaf 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -63,6 +63,11 @@ Platform/Intel/CometlakeSiliconBinPkg
 M: Kathappan Esakkithevar 
 M: Sai Chaganty 
 
+Platform/Qemu/SbsaQemu
+M: Ard Biesheuvel  [ardbiesheuvel]
+M: Leif Lindholm  [leiflindholm]
+M: Marcin Juszkiewicz  [hrw]
+
 Silicon/AMD
 M: Abner Chang 
 M: Abdul Lateef Attar 
-- 
2.30.2



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




Re: [edk2-devel] [PATCH edk2-non-osi 1/1] Qemu/Sbsa: update TF-A binaries for QEMU v9.0+

2024-04-23 Thread Leif Lindholm
On Tue, Apr 23, 2024 at 12:25:55 +0200, Marcin Juszkiewicz wrote:
> QEMU v9 uses 1GHz frequency for generic timers as required for Arm v8.6+
> cpu cores. TF-A was hardcoding 62.5MHz value which is used for older
> designs. Now it will use value present in CNTFRQ_EL0 register (set by
> QEMU).
> 
> Enable FEAT_ECV for QEMU v9.0+ to get access to CNTPOFF register.
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 
Thanks!

Can you push the change yourself?

/
Leif

> ---
>  Platform/Qemu/Sbsa/Readme.md |  55 ++-
>  Platform/Qemu/Sbsa/bl1.bin   | Bin 23365 -> 23349 bytes
>  Platform/Qemu/Sbsa/fip.bin   | Bin 82722 -> 82722 bytes
>  3 files changed, 28 insertions(+), 27 deletions(-)
> 
> diff --git a/Platform/Qemu/Sbsa/Readme.md b/Platform/Qemu/Sbsa/Readme.md
> index 5ed05f0f3021..b1351043d2b4 100644
> --- a/Platform/Qemu/Sbsa/Readme.md
> +++ b/Platform/Qemu/Sbsa/Readme.md
> @@ -4,50 +4,51 @@ Qemu SBSA TF-A binaries
>  These binaries have been created from the mainline TF-A
>  code checked out at the following commit ID:
>  
> -commit f36faa71578a14a8c9910aaa57e761f0256ccd52 (HEAD -> master, 
> origin/master, origin/integration, origin/HEAD)
> -Merge: 8dad296d6 57ab6d897
> -Author: Lauren Wehrmeister 
> -Date:   Tue Mar 12 19:17:49 2024 +0100
> +commit 56b263cb2a25892038761acea8c2b57a638d19bf (HEAD -> integration, 
> origin/integration, gerrit/integration)
> +Merge: 09d3fd141 e769f830d
> +Author: Yann Gautier 
> +Date:   Tue Apr 23 10:42:01 2024 +0200
>  
> -Merge "fix(cpus): fix a defect in Cortex-A715 erratum 2561034" into 
> integration
> +Merge "feat(qemu): allow ARM_ARCH_MAJOR/MINOR override" into integration
>  
>  
>  This ensures that the following features for qemu_sbsa platform are
>  merged upstream and included in the build:
>  
> -commit 42925c15bee09162c6dfc8c2204843ffac6201c1
> +commit 5436047a0e1f32543042d6de9f1f6a3edcd47591
>  Author: Marcin Juszkiewicz 
> -Date:   Tue Nov 21 14:53:26 2023 +0100
> +Date:   Mon Apr 22 17:27:56 2024 +0200
>  
> -feat(qemu-sbsa): handle CPU information
> +refactor(qemu): do not hardcode counter frequency
>  
> -We want to remove use of DeviceTree from EDK2. So we move
> -functions to TF-A:
> +From QEMU change:
>  
> -- counting cpu cores
> -- checking NUMA node id
> -- checking MPIDR
> +> In previous versions of the Arm architecture, the frequency of the
> +> generic timers as reported in CNTFRQ_EL0 could be any IMPDEF value,
> +> and for QEMU we picked 62.5MHz, giving a timer tick period of 16ns.
> +> In Armv8.6, the architecture standardized this frequency to 1GHz.
>  
> -And then it gets passed to EDK2 via SMC calls.
> +This change stops TF-A from hardcoding 62.5MHz frequency. Instead value
> +stored in CNTFRQ_EL0 would be used. As a result we get 62.5MHz on older
> +cores and 1GHz on newer ones.
>  
> -Change-Id: I1c7fc234ba90ba32433b6e4aa2cf127f26da00fd
> +Change-Id: I7d414ce6d3708e598bbb5a6f79eb2d4ec8e15ac4
>  Signed-off-by: Marcin Juszkiewicz 
>  
> -commit 8b7dd8397dd017b61ecda8447e8956a1d9d6d5d3
> -Author: Xiong Yining 
> -Date:   Fri Jan 12 10:47:03 2024 +
> +commit 1b694c77c497cb8272c97417ef1fa4f5f9c869c1
> +Author: Jean-Philippe Brucker 
> +Date:   Mon Apr 15 14:28:11 2024 +0100
>  
> -feat(qemu-sbsa): handle memory information
> +feat(qemu): enable FEAT_ECV when present
>  
> -As a part of removing DeviceTree from EDK2, we move functions to TF-A:
> +QEMU supports FEAT_ECV since commit 2808d3b38a52 ("target/arm: Implement
> +FEAT_ECV CNTPOFF_EL2 handling"), in the v9.0.0 release. Enable
> +auto-detecting the feature on the QEMU platforms, in order to set
> +SCR.ECVEN. Without this, EL2 gets undefined instruction exceptions when
> +trying to access the new CNTPOFF register.
>  
> -- counting the number of memory nodes
> -- checking NUMA node id
> -- checking the memory address
> -
> -Signed-off-by: Xiong Yining 
> -Signed-off-by: Chen Baozi 
> -Change-Id: Ib7bce3a65c817a5b3bef6c9e0a459c7ce76c7e35
> +Change-Id: I555a5f9a9a84fd23e64ca85219ed1599204c6bb2
> +Signed-off-by: Jean-Philippe Brucker 
>  
>  
>  NOTE: No modifications to the source code have been done.
> diff --git a/Platform/Qemu/Sbsa/bl1.bin b/Platform/Qemu/Sbsa/bl1.bin
> index 
> 8eac6204b64be03036c6aabe84618a7c979e78e0..6ad39377a464050dcc714d1316ff8981ad637ded
>  100755
> GIT binary patch
> delta 4429
> zcmZ{n4OCQR8poe^=7KXg&4Jm~vLHTho2gO`Bjw?y!*(?Xe
> zQ=M4#_He@8+5)pe^K?|K zd*0`L-p@Pp!Q1Sux0wk-YkQmGUb_s{kYW

Re: [edk2-devel] [PATCH edk2-platforms 1/1] Maintainers.txt: Update maintainers for Marvell platforms

2024-04-03 Thread Leif Lindholm
Thanks all, update pushed as 8b29c9255d44.

/
Leif

On Wed, Apr 03, 2024 at 14:28:45 +, Narinder Dhillon wrote:
> 
> 
> > -Original Message-
> > From: Marcin Wojtas 
> > Sent: Wednesday, April 3, 2024 6:36 AM
> > To: devel@edk2.groups.io; michael.d.kin...@intel.com
> > Cc: Leif Lindholm ; Narinder Dhillon
> > 
> > Subject: [EXTERNAL] Re: [edk2-devel] [PATCH edk2-platforms 1/1]
> > Maintainers.txt: Update maintainers for Marvell platforms
> > 
> > Prioritize security for external emails: Confirm sender and content safety
> > before clicking links or opening attachments
> > 
> > --
> > wt., 2 kwi 2024 o 17:59 Michael D Kinney 
> > napisał(a):
> > >
> > > Reviewed-by: Michael D Kinney 
> > >
> > > > -Original Message-
> > > > From: Leif Lindholm 
> > > > Sent: Tuesday, April 2, 2024 8:40 AM
> > > > To: devel@edk2.groups.io
> > > > Cc: Marcin Wojtas ; Narinder Dhillon
> > > > ; Kinney, Michael D
> > > > 
> > > > Subject: [PATCH edk2-platforms 1/1] Maintainers.txt: Update
> > > > maintainers for Marvell platforms
> > > >
> > > > Marcin and Narinder are the people most familiar with the Marvell
> > > > platforms, so make them the maintainers.
> > > > I move myself down to Reviewer for now.
> > > >
> > > > Cc: Marcin Wojtas 
> > > > Cc: Narinder Dhillon 
> > > > Cc: Michael D Kinney 
> > > > Signed-off-by: Leif Lindholm 
> > > > ---
> > > >  Maintainers.txt | 5 +++--
> > > >  1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/Maintainers.txt b/Maintainers.txt index
> > > > ca36aa679470..877620a1b02c 100644
> > > > --- a/Maintainers.txt
> > > > +++ b/Maintainers.txt
> > > > @@ -357,8 +357,9 @@ Marvell platforms and silicon
> > > >  F: Platform/Marvell/
> > > >  F: Platform/SolidRun/
> > > >  F: Silicon/Marvell/
> > > > -R: Marcin Wojtas 
> > > > -M: Leif Lindholm 
> > > > +M: Marcin Wojtas  [wojtas-marcin]
> > > > +M: Narinder Dhillon  [ndhillonm]
> > > > +R: Leif Lindholm  [leiflindholm]
> > > >
> > 
> > Reviewed-by: Marcin Wojtas 
> > 
> > Thanks,
> > Marcin
> > 
> 
> Reviewed-by: Narinder Dhillon 
> 
> Thanks,
> Narinder
> 
> > > >  Miscellaneous drivers
> > > >  F: Silicon/Atmel/
> > > > --
> > > > 2.30.2
> > >
> > >
> > >
> > > 
> > >
> > >


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




[edk2-devel] [PATCH edk2-platforms 1/1] Maintainers.txt: Update maintainers for Marvell platforms

2024-04-02 Thread Leif Lindholm
Marcin and Narinder are the people most familiar with the Marvell
platforms, so make them the maintainers.
I move myself down to Reviewer for now.

Cc: Marcin Wojtas 
Cc: Narinder Dhillon 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
 Maintainers.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index ca36aa679470..877620a1b02c 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -357,8 +357,9 @@ Marvell platforms and silicon
 F: Platform/Marvell/
 F: Platform/SolidRun/
 F: Silicon/Marvell/
-R: Marcin Wojtas 
-M: Leif Lindholm 
+M: Marcin Wojtas  [wojtas-marcin]
+M: Narinder Dhillon  [ndhillonm]
+R: Leif Lindholm  [leiflindholm]
 
 Miscellaneous drivers
 F: Silicon/Atmel/
-- 
2.30.2



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




Re: [edk2-devel] [PATCH v4 1/1] SbsaQemu: AcpiDxe: Create SRAT table at runtime

2024-03-28 Thread Leif Lindholm
On Thu, Mar 28, 2024 at 06:19:35 +, Xiong Yining wrote:
> Add support to create SRAT(System resource affinity table) for
> sbsa platform at runtime.
> 
> Signed-off-by: Xiong Yining 
> Reviewed-by: Marcin Juszkiewicz 
> Reviewed-by: Leif Lindholm 

You are not supposed to add Reviewed-by: or Acked-by: tags unless
whoever is commenting on your code indicates so by posting (for me)
Reviewed-by: Leif Lindholm 

It is not an indicator of work in progress, it is a flag that the
patch has been Reviewed and is ready to merge.

This also means that if Reviewed-by: is given early in the process,
but then you need to do substantial rework, you should *drop* any
previously given Reviewed-by: tags.

Marcin has never given his Reviewed-by for this patch, so I have
dropped this before pushing. Pushed as 7c26299112f3.

Thanks!

/
Leif

> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h | 27 ++
>  .../Include/Library/HardwareInfoLib.h | 10 ++
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 92 +++
>  .../SbsaQemuHardwareInfoLib.c | 36 
>  4 files changed, 165 insertions(+)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> index 7595df4c8a2d..83a085cd86f4 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> @@ -63,4 +63,31 @@ typedef struct {
>  
>  #define GTDT_WDTIMER_FLAGS  (GTDT_WDTIMER_ACTIVE_HIGH | 
> GTDT_WDTIMER_LEVEL_TRIGGERED)
>  
> +#define SBSAQEMU_ACPI_MEMORY_AFFINITY_STRUCTURE_INIT(
>  \
> +  ProximityDomain, Base, Length, Flags)  
>  \
> +  {  
>  \
> +1,  /* Type */   
>  \
> +sizeof (EFI_ACPI_6_4_MEMORY_AFFINITY_STRUCTURE),/* Length */ 
>  \
> +ProximityDomain,/* Proximity Domain 
> */\
> +0,  /* Reserved */   
>  \
> +(Base) & 0x,/* Base Address Low 
> */\
> +((Base) >> 32) & 0x ,   /* Base Address High 
> */   \
> +(Length) & 0x,  /* Length Low */ 
>  \
> +((Length) >> 32) & 0x,  /* Length High */
>  \
> +0,  /* Reserved */   
>  \
> +Flags,  /* Flags */  
>  \
> +0   /* Reserved */   
>  \
> +  }
> +
> +#define SBSAQEMU_ACPI_GICC_AFFINITY_STRUCTURE_INIT(  
>  \
> +  ProximityDomain, ACPIProcessorUID, Flags, ClockDomain) 
>  \
> +  {  
>  \
> +3,  /* Type */   
>  \
> +sizeof (EFI_ACPI_6_4_GICC_AFFINITY_STRUCTURE),  /* Length */ 
>  \
> +ProximityDomain,/* Proximity Domain 
> */\
> +ACPIProcessorUID,   /* ACPI Processor 
> UID */  \
> +Flags,  /* Flags */  
>  \
> +ClockDomain /* Clock Domain */   
>  \
> +  }
> +
>  #endif
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> index 5db0eacc9d2d..46fdad45353c 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> @@ -73,4 +73,14 @@ GetMemInfo (
>OUT MemoryInfo  *MemInfo
>);
>  
> +/**
> +  Get the number of numa node from device tree passed by Qemu.
> +
> +  @retvalthe number of numa node.
> +**/
> +UINT64
> +GetNumaNodeCount (
> +  VOID
> +  );
> +
>  #endif /* HARDWARE_INFO_LIB */
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index 4ebe2a445344..30239e7dca0d 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -6

Re: [edk2-devel] [PATCH v4 1/1] SbsaQemu: add memory space for the high memory nodes

2024-03-28 Thread Leif Lindholm
On Wed, Mar 27, 2024 at 14:01:43 +, Xiong Yining wrote:
> To support more memory nodes, we refer to the implement of
> "OvmfPkg/Fdt/HighMemDxe" to add memory space for the high memory nodes
> except the first one.

"HighMem" doesn't really make sense outside x86.
But I also don't want to delay merging this any furtner because of
arguing about names.

There are a few stule things below that I will fix up before pushing
though:

> Signed-off-by: Xiong Yining 
> Signed-off-by: Chen Baozi 

Drop additional Signed-off-by, as discussed on other set.

> Tested-by: Marcin Juszkiewicz 
> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc   |   1 +
>  Platform/Qemu/SbsaQemu/SbsaQemu.fdf   |   1 +
>  .../SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf |  45 ++
>  .../SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c   | 134 ++
>  4 files changed, 181 insertions(+)
>  create mode 100644 
> Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
>  create mode 100644 
> Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c
> 
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 3b936f6e6386..22017792bad2 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -671,6 +671,7 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
>ArmPkg/Drivers/TimerDxe/TimerDxe.inf
>OvmfPkg/VirtNorFlashDxe/VirtNorFlashDxe.inf
>MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
> +  Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
>  
>#
># FAT filesystem + GPT/MBR partitioning
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> index 6fcfd25faaeb..b35f42e11aa4 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> @@ -161,6 +161,7 @@ READ_LOCK_STATUS   = TRUE
>  
>INF MdeModulePkg/Core/Dxe/DxeMain.inf
>INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
> +  INF Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
>  
>#
># PI DXE Drivers producing Architectural Protocols (EFI Services)
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
> new file mode 100644
> index ..304f47392298
> --- /dev/null
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.inf
> @@ -0,0 +1,45 @@
> +## @file
> +#  High memory node enumeration DXE driver for SbsaQemu
> +#
> +#  Copyright (c) 2023, Linaro Ltd. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = SbsaQemuHighMemDxe
> +  FILE_GUID  = 9E749C5E-C282-32F8-7CC3-E5A3DDE15329
> +  MODULE_TYPE= DXE_DRIVER
> +  VERSION_STRING = 1.0
> +
> +  ENTRY_POINT= InitializeHighMemDxe
> +
> +[Sources]
> +  SbsaQemuHighMemDxe.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
> +  ArmPkg/ArmPkg.dec
> +  Silicon/Qemu/SbsaQemu/SbsaQemu.dec

Sort these alphabetically.

> +
> +[LibraryClasses]
> +  BaseLib
> +  DebugLib
> +  DxeServicesTableLib
> +  PcdLib
> +  UefiBootServicesTableLib
> +  UefiDriverEntryPoint
> +  HardwareInfoLib

Sort these alphabetically.

> +
> +[Protocols]
> +  gEfiCpuArchProtocolGuid ## CONSUMES
> +
> +[Pcd]
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy
> +  gArmTokenSpaceGuid.PcdSystemMemoryBase

Sort these alphabetically.

> +
> +[Depex]
> +  gEfiCpuArchProtocolGuid
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c
> new file mode 100644
> index ..004a8c0cf654
> --- /dev/null
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuHighMemDxe/SbsaQemuHighMemDxe.c
> @@ -0,0 +1,134 @@
> +/** @file
> +*  High memory node enumeration DXE driver for SbsaQemu
> +*  Virtual Machines
> +*
> +*  Copyright (c) 2023, Linaro Ltd. All rights reserved.
> +*
> +*  SPDX-License-Identifier: BSD-2-Clause-Patent
> +*
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +EFI_STATUS
> +EFIAPI
> +InitializeHighMemDxe (
> +  IN EFI_HANDLEImageHandle,
> +  IN EFI_SYSTEM_TABLE  *SystemTable
> +  )
> +{
> +  EFI_CPU_ARC

Re: [edk2-devel] [PATCH v11 2/4] Platform/SbsaQemu: use SbsaQemuHardwareInfoLib for cpu information

2024-03-28 Thread Leif Lindholm
On Thu, Mar 28, 2024 at 07:46:28 +, Xiong Yining wrote:
> From: Marcin Juszkiewicz 
> 
> We have SbsaQemuHardwareInfoLib to ask for hardware details. No need to
> parse DeviceTree anymore.
> 
> Signed-off-by: Marcin Juszkiewicz 
> Signed-off-by: Xiong Yining 
> Reviewed-by: Leif Lindholm 
> ---
>  .../Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf   |  6 ++
>  .../SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf   |  5 ++---
>  .../Library/SbsaQemuLib/SbsaQemuLib.inf   |  4 ++--
>  .../Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c | 11 +-
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 21 +++
>  5 files changed, 18 insertions(+), 29 deletions(-)
> 

Two mistakes in this file breaks bisect again, this time between 2/4
and 3/4.

> diff --git a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> index c067a80cc715..07e6bc4e9b11 100644
> --- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> +++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> @@ -1,6 +1,6 @@
>  #/* @file
>  #
> -#  Copyright (c) 2019, Linaro Limited. All rights reserved.
> +#  Copyright (c) 2019-2024, Linaro Limited. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -32,9 +32,9 @@
>ArmLib
>BaseMemoryLib
>DebugLib
> -  FdtLib

1) We don't update the memory discovery to use HardwareInfoLib until
the next commit.

>MemoryAllocationLib
>PcdLib
> +  SbsaQemuHardwareInfoLib

2) This is now just called HardwareInfoLib.

I really don't want to see a v12, so I have fixed this up locally and
pushed this set as 8e5981584663..4e77c070c070.

Thanks!

(But please be more careful with bisect breakage in future.)

/
Leif


>  
>  [Pcd]
>gArmTokenSpaceGuid.PcdSystemMemoryBase
> diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c 
> b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> index c38f2851904f..854f6f4072d5 100644
> --- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> +++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> @@ -2,7 +2,7 @@
>  *  OemMiscLib.c
>  *
>  *  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +*  Copyright (c) 2020-2024, Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -12,14 +12,13 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> -#include 
>  
>  /** Returns whether the specified processor is present or not.
>  
> @@ -33,7 +32,7 @@ OemIsProcessorPresent (
>UINTN ProcessorIndex
>)
>  {
> -  if (ProcessorIndex < FdtHelperCountCpus ()) {
> +  if (ProcessorIndex < GetCpuCount ()) {
>  return TRUE;
>}
>  
> @@ -76,7 +75,7 @@ OemGetProcessorInformation (
>  {
>UINT16 ProcessorCount;
>  
> -  ProcessorCount = FdtHelperCountCpus ();
> +  ProcessorCount = GetCpuCount ();
>  
>if (ProcessorIndex < ProcessorCount) {
>  ProcessorStatus->Bits.CpuStatus   = 1; // CPU enabled
> @@ -121,7 +120,7 @@ OemGetMaxProcessors (
>VOID
>)
>  {
> -  return FdtHelperCountCpus ();
> +  return GetCpuCount ();
>  }
>  
>  /** Gets information about the cache at the specified cache level.
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index 9fb17151d7b8..4ebe2a445344 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -1,7 +1,7 @@
>  /** @file
>  *  This file is an ACPI driver for the Qemu SBSA platform.
>  *
> -*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +*  Copyright (c) 2020-2024, Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -15,10 +15,10 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -255,8 +255,7 @@ AddMadtTable (
>   // Initialize GIC Redistributor Structure
>EFI_ACPI_6_0_GICR_STRUCTURE Gicr = SBSAQEMU_MADT_GICR_INIT();
>  
> -  // Get CoreCount which was determined eariler after parsing device tree
> -  NumCores = PcdGet32 (PcdCoreCount);
> +  NumCores = GetCpuCount ();
>  
>// Calculate the new table size based on the number of cores
>TableSize = sizeof (EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER) +
> @@ -291,1

Re: [edk2-devel] [PATCH v10 4/4] Platform/SbsaQemu: get the information of memory via SMC calls

2024-03-27 Thread Leif Lindholm
I think the patch ordering relative to 3/4 breaks bisect?

/
Leif

On Wed, Mar 27, 2024 at 14:03:05 +, Xiong Yining wrote:
> Provide functions to check for memory information:
> 
> - amount of memory nodes
> - memory address
> - NUMA node id for memory
> 
> Values are read from TF-A using platform specific SMC calls.
> 
> Signed-off-by: Xiong Yining 
> Signed-off-by: Chen Baozi 
> Signed-off-by: Marcin Juszkiewicz 
> Reviewed-by: Ard Biesheuvel 
> ---
>  .../Library/SbsaQemuLib/SbsaQemuLib.inf   |  3 +-
>  .../Include/IndustryStandard/SbsaQemuSmc.h|  2 +
>  .../Include/Library/HardwareInfoLib.h | 31 +++
>  .../SbsaQemuHardwareInfoLib.c | 49 +
>  .../Library/SbsaQemuLib/SbsaQemuMem.c | 54 +--
>  5 files changed, 96 insertions(+), 43 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> index 07e6bc4e9b11..384cbb349200 100644
> --- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> +++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> @@ -32,14 +32,13 @@
>ArmLib
>BaseMemoryLib
>DebugLib
> +  HardwareInfoLib
>MemoryAllocationLib
>PcdLib
> -  SbsaQemuHardwareInfoLib
>  
>  [Pcd]
>gArmTokenSpaceGuid.PcdSystemMemoryBase
>gArmTokenSpaceGuid.PcdSystemMemorySize
> -  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
>  
>  [FixedPcd]
>gArmTokenSpaceGuid.PcdFdBaseAddress
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> index 2317c1f0ae69..e3092007d27d 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> @@ -16,6 +16,8 @@
>  #define SIP_SVC_GET_GIC_ITSSMC_SIP_FUNCTION_ID(101)
>  #define SIP_SVC_GET_CPU_COUNT  SMC_SIP_FUNCTION_ID(200)
>  #define SIP_SVC_GET_CPU_NODE   SMC_SIP_FUNCTION_ID(201)
> +#define SIP_SVC_GET_MEMORY_NODE_COUNT SMC_SIP_FUNCTION_ID(300)
> +#define SIP_SVC_GET_MEMORY_NODE SMC_SIP_FUNCTION_ID(301)
>  
>  /*
>   *  SMCC does not define return codes for SiP functions.
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> index 8b1b5e5e1b93..5db0eacc9d2d 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> @@ -9,6 +9,12 @@
>  #ifndef HARDWARE_INFO_LIB
>  #define HARDWARE_INFO_LIB
>  
> +typedef struct{
> +  UINT32  NodeId;
> +  UINT64  AddressBase;
> +  UINT64  AddressSize;
> +} MemoryInfo;
> +
>  /**
>Get CPU count from information passed by Qemu.
>  
> @@ -42,4 +48,29 @@ GetCpuNumaNode (
>IN UINTN  CpuId
>);
>  
> +/**
> +  Get the number of memory node from device tree passed by Qemu.
> +
> +  @retval   the number of memory nodes.
> +**/
> +UINT32
> +GetMemNodeCount (
> +  VOID
> +  );
> +
> +/**
> +  Get memory information(node-id, addressbase, addresssize) for a given 
> memory node from device tree passed by Qemu.
> +
> +  @param [in]   MemoryIdIndex of memory to retrieve memory information.
> +  @param [out]  MemInfo A pointer to the memory information of given 
> memory-id.
> +
> +
> +  @retval   memory infomation for given memory node.
> +**/
> +VOID
> +GetMemInfo (
> +  IN  UINTN   MemoryId,
> +  OUT MemoryInfo  *MemInfo
> +  );
> +
>  #endif /* HARDWARE_INFO_LIB */
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> index e96328978a55..b178cf6c6c43 100644
> --- 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> @@ -94,3 +94,52 @@ GetCpuNumaNode (
>  
>return Arg0;
>  }
> +
> +UINT32
> +GetMemNodeCount (
> +  VOID
> +  )
> +{
> +  UINTNSmcResult;
> +  UINTNArg0;
> +
> +  SmcResult = ArmCallSmc0 (SIP_SVC_GET_MEMORY_NODE_COUNT, , NULL, NULL);
> +  if (SmcResult != SMC_SIP_CALL_SUCCESS) {
> +DEBUG ((DEBUG_ERROR, "%a: SIP_SVC_GET_MEMORY_NODE_COUNT call failed. We 
> have no memory information.\n", __FUNCTION__));
> +ResetShutdown ();
> +  }
> +
> +  DEBUG (( DEBUG_INFO, "%a: The number of the memory nodes is %ld\n", 
> __FUNCTION__, Arg0));
> +  return (UINT32)Arg0;
> +}
> +
> +VOID
> +GetMemInfo (
> +  IN  UINTN   MemoryId,
> +  OUT MemoryInfo  *MemInfo 
> +  )
> +{
> +  UINTN   SmcResult;
> +  UINTN   Arg0;
> +  UINTN   Arg1;
> +  UINTN   Arg2;
> +
> +  Arg0 = MemoryId;
> +
> +  SmcResult = ArmCallSmc1 (SIP_SVC_GET_MEMORY_NODE, , , );
> +  if (SmcResult != SMC_SIP_CALL_SUCCESS) {
> +DEBUG ((DEBUG_ERROR, 

Re: [edk2-devel] [PATCH v10 1/4] Platform/SbsaQemu: add SbsaQemuHardwareInfoLib

2024-03-27 Thread Leif Lindholm
On Wed, Mar 27, 2024 at 14:03:02 +, Xiong Yining wrote:
> From: Marcin Juszkiewicz 
> 
> This library provides functions to check for hardware information.
> For now it covers CPU ones:
> 
> - amount of cpu cores
> - MPIDR value for cpu core
> - NUMA node id for cpu core
> 
> Values are read from TF-A using platform specific SMC calls.
> 
> Signed-off-by: Marcin Juszkiewicz 

This is fine, because you're re-submitting a patch already sent out
for review by Marcin. There is public record that he made this
statement.
But when resubmitting patches, you should also add your own
signed-off-by, to indicate that you, to the best of your
knowledge, complies with the statements in
https://github.com/tianocore/edk2?tab=readme-ov-file#developer-certificate-of-origin

/
Leif

> ---
>  Silicon/Qemu/SbsaQemu/SbsaQemu.dec|  2 +
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc   |  3 +-
>  .../SbsaQemuHardwareInfoLib.inf   | 29 ++
>  .../Include/IndustryStandard/SbsaQemuSmc.h| 17 +++-
>  .../Include/Library/HardwareInfoLib.h | 45 +
>  .../SbsaQemuHardwareInfoLib.c | 96 +++
>  6 files changed, 187 insertions(+), 5 deletions(-)
>  create mode 100644 
> Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  create mode 100644 Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
>  create mode 100644 
> Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> 
> diff --git a/Silicon/Qemu/SbsaQemu/SbsaQemu.dec 
> b/Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> index 913d1d75ef29..427ff8b31aac 100644
> --- a/Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> +++ b/Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> @@ -12,6 +12,8 @@
>PACKAGE_GUID   = 8db32c5a-2821-43e2-b4ac-bc148e2b0b05
>PACKAGE_VERSION= 0.1
>  
> +[LibraryClasses]
> +HardwareInfoLib|Include/Library/HardwareInfoLib.h
>  
> 
>  #
>  # Include Section - list of Include Paths that are provided by this package.
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 378600050df9..3c3d2449bff4 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -1,6 +1,6 @@
>  #
>  #  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -#  Copyright (c) 2019, Linaro Limited. All rights reserved.
> +#  Copyright (c) 2019-2024, Linaro Ltd. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -128,6 +128,7 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE   = FALSE
>  
>FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
>OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> +  
> HardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
># Debug Support
>
> PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> new file mode 100644
> index ..2acb2a1e7c76
> --- /dev/null
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> @@ -0,0 +1,29 @@
> +#/* @file
> +#
> +#  Copyright (c) 2024, Linaro Ltd. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +#*/
> +
> +[Defines]
> +  INF_VERSION= 0x0001001c
> +  BASE_NAME  = SbsaQemuHardwareInfoLib
> +  FILE_GUID  = 6454006f-6502-46e2-9be4-4bba8d4b29fb
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = HardwareInfoLib
> +
> +[Sources]
> +  SbsaQemuHardwareInfoLib.c
> +
> +[Packages]
> +  ArmPkg/ArmPkg.dec
> +  EmbeddedPkg/EmbeddedPkg.dec
> +  MdePkg/MdePkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
> +  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> +
> +[LibraryClasses]
> +  ArmSmcLib
> +  ResetSystemLib
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> index 7934875e4aba..2317c1f0ae69 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> @@ -1,6 +1,6 @@
>  /** @file
>  *
> -*  Copyright (c) 2023, Linaro Ltd. All rights reserved.
> +*  Copyright (c) 2023-2024, Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -11,8 +11,17 @@
>  
>  #include 
>  
> -#define SIP_SVC_VERSION  SMC_SIP_FUNCTION_ID(1)
> -#define SIP_SVC_GET_GIC  SMC_SIP_FUNCTION_ID(100)
> -#define SIP_SVC_GET_GIC_ITS  SMC_SIP_FUNCTION_ID(101)
> +#define SIP_SVC_VERSIONSMC_SIP_FUNCTION_ID(1)
> 

Re: [edk2-devel] [PATCH v3 1/1] SbsaQemu: AcpiDxe: Create SRAT table at runtime

2024-03-27 Thread Leif Lindholm
On Wed, Mar 27, 2024 at 13:59:34 +, Xiong Yining wrote:
> Add support to create SRAT(System resource affinity table) for
> sbsa platform at runtime.
> 
> Signed-off-by: Xiong Yining 
> Signed-off-by: Chen Baozi 

No one can sign off patches on behalf of someone else. Please only
include your own signed-off-by.

> Reviewed-by: Marcin Juszkiewicz 
> Change-Id: I4a65084e6ade66d87ea935adfa4be15a7030d3eb

We don't use gerrit. Please drop Change-Id:s before upstreaming.

> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h | 27 ++
>  .../Include/Library/HardwareInfoLib.h | 10 ++
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 92 +++
>  .../SbsaQemuHardwareInfoLib.c | 36 
>  4 files changed, 165 insertions(+)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> index 7595df4c8a2d..83a085cd86f4 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.h
> @@ -63,4 +63,31 @@ typedef struct {
>  
>  #define GTDT_WDTIMER_FLAGS  (GTDT_WDTIMER_ACTIVE_HIGH | 
> GTDT_WDTIMER_LEVEL_TRIGGERED)
>  
> +#define SBSAQEMU_ACPI_MEMORY_AFFINITY_STRUCTURE_INIT(
>  \
> +  ProximityDomain, Base, Length, Flags)  
>  \
> +  {  
>  \
> +1,  /* Type */   
>  \
> +sizeof (EFI_ACPI_6_4_MEMORY_AFFINITY_STRUCTURE),/* Length */ 
>  \
> +ProximityDomain,/* Proximity Domain 
> */\
> +0,  /* Reserved */   
>  \
> +(Base) & 0x,/* Base Address Low 
> */\
> +((Base) >> 32) & 0x ,   /* Base Address High 
> */   \
> +(Length) & 0x,  /* Length Low */ 
>  \
> +((Length) >> 32) & 0x,  /* Length High */
>  \
> +0,  /* Reserved */   
>  \
> +Flags,  /* Flags */  
>  \
> +0   /* Reserved */   
>  \
> +  }
> +
> +#define SBSAQEMU_ACPI_GICC_AFFINITY_STRUCTURE_INIT(  
>  \
> +  ProximityDomain, ACPIProcessorUID, Flags, ClockDomain) 
>  \
> +  {  
>  \
> +3,  /* Type */   
>  \
> +sizeof (EFI_ACPI_6_4_GICC_AFFINITY_STRUCTURE),  /* Length */ 
>  \
> +ProximityDomain,/* Proximity Domain 
> */\
> +ACPIProcessorUID,   /* ACPI Processor 
> UID */  \
> +Flags,  /* Flags */  
>  \
> +ClockDomain /* Clock Domain */   
>  \
> +  }
> +
>  #endif
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> index 5db0eacc9d2d..46fdad45353c 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> @@ -73,4 +73,14 @@ GetMemInfo (
>OUT MemoryInfo  *MemInfo
>);
>  
> +/**
> +  Get the number of numa node from device tree passed by Qemu.
> +
> +  @retvalthe number of numa node.
> +**/
> +UINT64
> +GetNumaNodeCount (
> +  VOID
> +  );
> +
>  #endif /* HARDWARE_INFO_LIB */
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index 4ebe2a445344..30239e7dca0d 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -682,6 +682,91 @@ AddGtdtTable (
>return Status;
>  }
>  
> +/*
> + * A function that adds the SRAT ACPI table.
> + */
> +EFI_STATUS
> +AddSratTable (
> +  IN EFI_ACPI_TABLE_PROTOCOL   *AcpiTable
> +  )
> +{
> +  EFI_STATUSStatus;
> +  UINT8 *New;
> +  EFI_PHYSICAL_ADDRESS  PageAddress;
> +  UINTN TableHandle;
> +  UINT32TableSize;
> +  UINT32Index;
> +  UINT32NodeId;
> +  UINT32NumMemNodes;
> +  MemoryInfoMemInfo;
> +  UINT32NumCores = GetCpuCount ();
> +
> +  // Initialize SRAT ACPI Header
> +  EFI_ACPI_6_4_SYSTEM_RESOURCE_AFFINITY_TABLE_HEADER 

Re: [edk2-devel] [PATCH edk2-platforms v2 1/1] Maintainers.txt: add myself as QemuSbsa maintainer

2024-03-26 Thread Leif Lindholm
On Tue, Mar 26, 2024 at 13:10:58 +0100, Marcin Juszkiewicz wrote:
> With all changes going around sbsa-ref/QemuSbsa platform Leif suggested
> that I should become maintainer as well.
> 
> My GitHub account name is "hrw".
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 
Tweaked subject line and pushed as 8e5981584663.

Thanks!

> ---
>  Maintainers.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index e57c32f16a05..ca36aa679470 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -383,8 +383,8 @@ F: Platform/Qemu/SbsaQemu/
>  F: Silicon/Qemu/SbsaQemu/
>  M: Ard Biesheuvel 
>  M: Leif Lindholm 
> +M: Marcin Juszkiewicz  [hrw]
>  R: Graeme Gregory 
> -R: Marcin Juszkiewicz 
>  
>  Raspberry Pi platforms and silicon
>  F: Platform/RaspberryPi/
> -- 
> 2.44.0
> 


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




Re: [edk2-devel] [PATCH edk2-platforms 1/1] Maintainers.txt: add myself as QemuSbsa maintainer

2024-03-26 Thread Leif Lindholm
On Tue, Mar 26, 2024 at 12:24:10 +0100, Marcin Juszkiewicz wrote:
> With all changes going around sbsa-ref/QemuSbsa platform Leif suggested
> that I should become maintainer as well.
> 
> My GitHub account name is "hrw".
> 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  Maintainers.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index e57c32f16a05..a37fc9e60723 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -383,8 +383,8 @@ F: Platform/Qemu/SbsaQemu/
>  F: Silicon/Qemu/SbsaQemu/
>  M: Ard Biesheuvel 
>  M: Leif Lindholm 
> +M: Marcin Juszkiewicz 

Ah - could you add your github username in [] after the email?
I see now we haven't added that to other maintainers in this file, but
we need to info to give you the access privileges.

/
Leif

>  R: Graeme Gregory 
> -R: Marcin Juszkiewicz 
>  
>  Raspberry Pi platforms and silicon
>  F: Platform/RaspberryPi/
> -- 
> 2.44.0
> 


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




Re: [edk2-devel] [PATCH edk2-platforms v9 4/4] Platform/SbsaQemu: get the information of memory via SMC calls

2024-03-25 Thread Leif Lindholm
On Fri, Mar 22, 2024 at 17:08:50 +0100, Marcin Juszkiewicz wrote:
> From: Xiong Yining 
> 
> Provide functions to check for memory information:
> 
> - amount of memory nodes
> - memory address
> - NUMA node id for memory
> 
> Values are read from TF-A using platform specific SMC calls.

Same namespace comments as on 1/4, but given I've dragged my heels
reviewing, I see no need to delay further for that. Current naming can
go in, and we can worry about appropriate naming if we promote this
the hwinfo library to a core interface later.

You did however say this one needs reworking, so won't give r-b on
this one yet.

/
Leif

> Signed-off-by: Xiong Yining 
> Signed-off-by: Chen Baozi 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  .../SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf |  3 +-
>  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  |  2 +
>  .../Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h  | 28 ++
>  .../SbsaQemuHardwareInfoLib.c| 50 ++
>  .../Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c  | 54 
> +---
>  5 files changed, 94 insertions(+), 43 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> index 07e6bc4e9b11..384cbb349200 100644
> --- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> +++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> @@ -32,14 +32,13 @@ [LibraryClasses]
>ArmLib
>BaseMemoryLib
>DebugLib
> +  HardwareInfoLib
>MemoryAllocationLib
>PcdLib
> -  SbsaQemuHardwareInfoLib
>  
>  [Pcd]
>gArmTokenSpaceGuid.PcdSystemMemoryBase
>gArmTokenSpaceGuid.PcdSystemMemorySize
> -  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
>  
>  [FixedPcd]
>gArmTokenSpaceGuid.PcdFdBaseAddress
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> index 2317c1f0ae69..e3092007d27d 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> @@ -16,6 +16,8 @@
>  #define SIP_SVC_GET_GIC_ITSSMC_SIP_FUNCTION_ID(101)
>  #define SIP_SVC_GET_CPU_COUNT  SMC_SIP_FUNCTION_ID(200)
>  #define SIP_SVC_GET_CPU_NODE   SMC_SIP_FUNCTION_ID(201)
> +#define SIP_SVC_GET_MEMORY_NODE_COUNT SMC_SIP_FUNCTION_ID(300)
> +#define SIP_SVC_GET_MEMORY_NODE SMC_SIP_FUNCTION_ID(301)
>  
>  /*
>   *  SMCC does not define return codes for SiP functions.
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> index 9c7281f123d2..c7d397c590a8 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h
> @@ -9,6 +9,12 @@
>  #ifndef HARDWARE_INFO_LIB
>  #define HARDWARE_INFO_LIB
>  
> +typedef struct{
> +  UINT32  NodeId;
> +  UINT64  AddressBase;
> +  UINT64  AddressSize;
> +} MemoryInfo;
> +
>  /**
>Get CPU count from information passed by Qemu.
>  
> @@ -42,4 +48,26 @@ GetCpuNumaNode (
>IN UINTN  CpuId
>);
>  
> +/**
> +  Get the number of memory node from device tree passed by Qemu.
> +
> +  @retval   the number of memory nodes.
> +**/
> +UINT32
> +GetMemNodeCount (
> +  VOID
> +  );
> +
> +/**
> +  Get memory infomation(node-id, addressbase, addresssize) for a given 
> memory node from device tree passed by Qemu.
> +
> +  @param [in]   MemoryIdIndex of memory to retrieve memory information.
> +
> +  @retval   memory infomation for given memory node.
> +**/
> +MemoryInfo
> +GetMemInfo (
> +  IN UINTN   MemoryId
> +  );
> +
>  #endif /* HARDWARE_INFO_LIB */
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> index e96328978a55..4f49ae7e1862 100644
> --- 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> @@ -94,3 +94,53 @@ GetCpuNumaNode (
>  
>return Arg0;
>  }
> +
> +UINT32
> +GetMemNodeCount (
> +  VOID
> +  )
> +{
> +  UINTNSmcResult;
> +  UINTNArg0;
> +
> +  SmcResult = ArmCallSmc0 (SIP_SVC_GET_MEMORY_NODE_COUNT, , NULL, NULL);
> +  if (SmcResult != SMC_SIP_CALL_SUCCESS) {
> +DEBUG ((DEBUG_ERROR, "%a: SIP_SVC_GET_MEMORY_NODE_COUNT call failed. We 
> have no memory information.\n", __FUNCTION__));
> +ResetShutdown ();
> +  }
> +
> +  DEBUG (( DEBUG_INFO, "%a: The number of the memory nodes is %ld\n", 
> __FUNCTION__, Arg0));
> +  return (UINT32)Arg0;
> +}
> +
> +MemoryInfo
> +GetMemInfo (
> +  IN UINTN   MemoryId
> +  )
> +{
> +  UINTN   SmcResult;
> +  UINTN   Arg0;
> +  UINTN   Arg1;
> +  UINTN  

Re: [edk2-devel] [PATCH edk2-platforms v9 3/4] Platform/SbsaQemu: drop use of DeviceTree

2024-03-25 Thread Leif Lindholm
On Fri, Mar 22, 2024 at 17:08:49 +0100, Marcin Juszkiewicz wrote:
> There is no need for EDK2 to know that there is DeviceTree around.
> All hardware information is read using functions from
> SbsaQemuHardwareInfoLib library.
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 

/
Leif

> ---
>  Silicon/Qemu/SbsaQemu/SbsaQemu.dec   |  1 -
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  6 --
>  .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf   | 33 ---
>  Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h | 36 ---
>  .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c|  2 -
>  .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c | 98 
> 
>  6 files changed, 176 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/SbsaQemu.dec 
> b/Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> index 427ff8b31aac..8f3533800767 100644
> --- a/Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> +++ b/Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> @@ -36,7 +36,6 @@ [PcdsFixedAtBuild.common]
>
> gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformAhciSize|0x1|UINT32|0x0002
>
> gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformXhciBase|0|UINT64|0x0003
>
> gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformXhciSize|0x1|UINT32|0x0004
> -  
> gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress|0x100|UINT64|0x0005
>  
># PCDs complementing PCIe layout pulled into ACPI tables
># Limit = Base + Size - 1
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 3c3d2449bff4..3d748e289b51 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -80,7 +80,6 @@ [LibraryClasses.common]
>FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>
> ImagePropertiesRecordLib|MdeModulePkg/Library/ImagePropertiesRecordLib/ImagePropertiesRecordLib.inf
>  
> -  FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
>UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
>
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>  
> @@ -126,7 +125,6 @@ [LibraryClasses.common]
># ARM PL011 UART Driver
>PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
>  
> -  FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
>OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
>
> HardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
> @@ -430,9 +428,6 @@ [PcdsFixedAtBuild.common]
>#
>gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16
>  
> -  # Initial Device Tree Location
> -  
> gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress|0x100
> -
># Non discoverable devices (AHCI,XHCI)
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformAhciBase|0x6010
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdPlatformAhciSize|0x0001
> @@ -731,7 +726,6 @@ [Components.common]
>#
>ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClassDxe.inf
>ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
> -  EmbeddedPkg/Library/FdtLib/FdtLib.inf
>MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
>Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuSmbiosDxe/SbsaQemuSmbiosDxe.inf
>  
> diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf 
> b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
> deleted file mode 100644
> index 9c059f3e5851..
> --- a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -#/** @file
> -#
> -#  Component description file for FdtHelperLib module
> -#
> -#  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -#
> -#  SPDX-License-Identifier: BSD-2-Clause-Patent
> -#
> -#**/
> -
> -[Defines]
> -  INF_VERSION= 1.29
> -  BASE_NAME  = FdtHelperLib
> -  FILE_GUID  = 34e4396f-c2fc-4f9e-ad58-0f98e99e3875
> -  MODULE_TYPE= BASE
> -  VERSION_STRING = 1.0
> -  LIBRARY_CLASS  = FdtHelperLib
> -
> -[Sources.common]
> -  FdtHelperLib.c
> -
> -[Packages]
> -  EmbeddedPkg/EmbeddedPkg.dec
> -  MdePkg/MdePkg.dec
> -  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> -
> -[LibraryClasses]
> -  DebugLib
> -  FdtLib
> -  PcdLib
> -
> -[FixedPcd]
> -  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/F

Re: [edk2-devel] [PATCH edk2-platforms v9 2/4] Platform/SbsaQemu: use SbsaQemuHardwareInfoLib for cpu information

2024-03-25 Thread Leif Lindholm
On Fri, Mar 22, 2024 at 17:08:48 +0100, Marcin Juszkiewicz wrote:
> We have SbsaQemuHardwareInfoLib to ask for hardware details. No need to
> parse DeviceTree anymore.
> 
> Signed-off-by: Marcin Juszkiewicz 

Nitpicks or changing function calls based on what I commented on in
previous patch does not retract from:
Reviewed-by: Leif Lindholm 

> ---
>  Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf |  6 ++
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  5 ++---
>  .../SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf |  4 ++--
>  Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c   | 11 +-
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 21 
> +++-
>  5 files changed, 18 insertions(+), 29 deletions(-)
> 
> diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf 
> b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> index a34f54d431d4..f959d8e0e4ee 100644
> --- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> +++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> @@ -3,7 +3,7 @@
>  #
>  #Copyright (c) 2021, NUVIA Inc. All rights reserved.
>  #Copyright (c) 2018, Hisilicon Limited. All rights reserved.
> -#Copyright (c) 2018, Linaro Limited. All rights reserved.
> +#Copyright (c) 2018-2024, Linaro Ltd. All rights reserved.
>  #
>  #SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -29,8 +29,7 @@ [Packages]
>  
>  [LibraryClasses]
>BaseMemoryLib
> -  FdtLib
> -  FdtHelperLib
> +  HardwareInfoLib
>IoLib
>PcdLib
>  
> @@ -40,7 +39,6 @@ [Guids]
>  [Pcd]
>gArmTokenSpaceGuid.PcdEmbeddedControllerFirmwareRelease
>gArmTokenSpaceGuid.PcdSystemBiosRelease
> -  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
>  
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemManufacturer
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemSerialNumber
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
> index 291743b19115..727c8e82d16e 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  This driver modifies ACPI tables for the Qemu SBSA platform
>  #
> -#  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +#  Copyright (c) 2020-2024, Linaro Ltd. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -35,7 +35,7 @@ [LibraryClasses]
>BaseLib
>DebugLib
>DxeServicesLib
> -  FdtHelperLib
> +  HardwareInfoLib
>PcdLib
>PrintLib
>UefiDriverEntryPoint
> @@ -44,7 +44,6 @@ [LibraryClasses]
>  
>  [Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiTableStorageFile
> -  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdClusterCount
>  
>gArmTokenSpaceGuid.PcdGicDistributorBase
> diff --git a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> index c067a80cc715..07e6bc4e9b11 100644
> --- a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> +++ b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuLib.inf
> @@ -1,6 +1,6 @@
>  #/* @file
>  #
> -#  Copyright (c) 2019, Linaro Limited. All rights reserved.
> +#  Copyright (c) 2019-2024, Linaro Limited. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -32,9 +32,9 @@ [LibraryClasses]
>ArmLib
>BaseMemoryLib
>DebugLib
> -  FdtLib
>MemoryAllocationLib
>PcdLib
> +  SbsaQemuHardwareInfoLib

LibraryClass uses different name here?

>  
>  [Pcd]
>gArmTokenSpaceGuid.PcdSystemMemoryBase
> diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c 
> b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> index c38f2851904f..854f6f4072d5 100644
> --- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> +++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> @@ -2,7 +2,7 @@
>  *  OemMiscLib.c
>  *
>  *  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +*  Copyright (c) 2020-2024, Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -12,14 +12,13 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 

Move above HiiLib.h.

>  #include 
>  #include 
> -#include 
>  
>  /** Returns whether the specified processor is present or not.
>  
> @@ -33

Re: [edk2-devel] [PATCH edk2-platforms v9 1/4] Platform/SbsaQemu: add SbsaQemuHardwareInfoLib

2024-03-25 Thread Leif Lindholm
On Fri, Mar 22, 2024 at 17:08:47 +0100, Marcin Juszkiewicz wrote:
> This library provides functions to check for hardware information.
> For now it covers CPU ones:
> 
> - amount of cpu cores
> - MPIDR value for cpu core
> - NUMA node id for cpu core
> 
> Values are read from TF-A using platform specific SMC calls.
> 
> Signed-off-by: Marcin Juszkiewicz 

All comments below are of the variety: "should we namespace separate this"?

> ---
>  Silicon/Qemu/SbsaQemu/SbsaQemu.dec   |  2 +
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc  |  3 +-
>  .../SbsaQemuHardwareInfoLib.inf  | 29 ++
>  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h  | 17 +++-
>  .../Qemu/SbsaQemu/Include/Library/HardwareInfoLib.h  | 45 +
>  .../SbsaQemuHardwareInfoLib.c| 96 
> 
>  6 files changed, 187 insertions(+), 5 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/SbsaQemu.dec 
> b/Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> index 913d1d75ef29..427ff8b31aac 100644
> --- a/Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> +++ b/Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> @@ -12,6 +12,8 @@ [Defines]
>PACKAGE_GUID   = 8db32c5a-2821-43e2-b4ac-bc148e2b0b05
>PACKAGE_VERSION= 0.1
>  
> +[LibraryClasses]
> +HardwareInfoLib|Include/Library/HardwareInfoLib.h

We don't *have* to address this now, but it would be worth considering
what function this could have as a core, rather than
platform-specific, library.

What hardware? SoC or whole platform?

As it stands, the name is very generic.
I think we'll eventually want standardised APIs for these kinds of
queries. But maybe until then it would be easier to prepend SbsaQemu
to both filename and LibraryClass (like you do in the actual implementation)?

>  
> 
>  #
>  # Include Section - list of Include Paths that are provided by this package.
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 378600050df9..3c3d2449bff4 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -1,6 +1,6 @@
>  #
>  #  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -#  Copyright (c) 2019, Linaro Limited. All rights reserved.
> +#  Copyright (c) 2019-2024, Linaro Ltd. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -128,6 +128,7 @@ [LibraryClasses.common]
>  
>FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
>OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> +  
> HardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf

Like you do here.

>  
># Debug Support
>
> PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> new file mode 100644
> index ..2acb2a1e7c76
> --- /dev/null
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> @@ -0,0 +1,29 @@
> +#/* @file
> +#
> +#  Copyright (c) 2024, Linaro Ltd. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +#*/
> +
> +[Defines]
> +  INF_VERSION= 0x0001001c
> +  BASE_NAME  = SbsaQemuHardwareInfoLib
> +  FILE_GUID  = 6454006f-6502-46e2-9be4-4bba8d4b29fb
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = HardwareInfoLib
> +
> +[Sources]
> +  SbsaQemuHardwareInfoLib.c
> +
> +[Packages]
> +  ArmPkg/ArmPkg.dec
> +  EmbeddedPkg/EmbeddedPkg.dec
> +  MdePkg/MdePkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
> +  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> +
> +[LibraryClasses]
> +  ArmSmcLib
> +  ResetSystemLib
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> index 7934875e4aba..2317c1f0ae69 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> @@ -1,6 +1,6 @@
>  /** @file
>  *
> -*  Copyright (c) 2023, Linaro Ltd. All rights reserved.
> +*  Copyright (c) 2023-2024, Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -11,8 +11,17 @@
>  
>  #include 
>  
> -#define SIP_SVC_VERSION  SMC_SIP_FUNCTION_ID(1)
> -#define SIP_SVC_GET_GIC  SMC_SIP_FUNCTION_ID(100)
> -#define SIP_SVC_GET_GIC_ITS  SMC_SIP_FUNCTION_ID(101)
> +#define SIP_SVC_VERSIONSMC_SIP_FUNCTION_ID(1)
> +#define SIP_SVC_GET_GICSMC_SIP_FUNCTION_ID(100)
> +#define SIP_SVC_GET_GIC_ITSSMC_SIP_FUNCTION_ID(101)
> +#define 

Re: [edk2-devel] [PATCH 1/1] EmbeddedPkg/NonCoherentIoMmuDxe: Make SetAttributes always succeed

2024-03-12 Thread Leif Lindholm

On 2024-03-12 09:58, Ard Biesheuvel wrote:

On Tue, 12 Mar 2024 at 17:56, Leif Lindholm  wrote:


On 2024-03-12 09:50, Ard Biesheuvel wrote:

On Tue, 12 Mar 2024 at 17:38, Leif Lindholm  wrote:


On 2024-03-12 08:17, Ard Biesheuvel wrote:

From: Ard Biesheuvel 

NonCoherentIoMmuSetAttribute() does nothing except return
EFI_UNSUPPORTED. This was fine when it was introduced, but now, the PCI
bus driver will fail a PCI I/O Map() operation if the SetAttributes
fails.

So return EFI_SUCCESS instead.


It's unclear to me why this change is safe (looking forward).
Does NonCoherentIoMmuDxe also imply no IoMmu actually exists?



Basically. NonCoherentIoMmuDxe is just a vehicle to allow
NonCoherentDmaLib to be plugged into the PCI host bridge driver. It is
not intended to ever do anything more than that.


Not that it needs to happen for this
(Reviewed-by: Leif Lindholm )
but maybe we ought to consider renaming it then?
DummyIoMmuDxe?


Fair point. Or PassThroughIoMmuDxe perhaps?


Works for me.
Or, hmm...
Is there a risk that sounds a bit like a driver that actively configures 
IoMmus into passthrough mode?


/
Leif



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




Re: [edk2-devel] [PATCH 1/1] EmbeddedPkg/NonCoherentIoMmuDxe: Make SetAttributes always succeed

2024-03-12 Thread Leif Lindholm

On 2024-03-12 09:50, Ard Biesheuvel wrote:

On Tue, 12 Mar 2024 at 17:38, Leif Lindholm  wrote:


On 2024-03-12 08:17, Ard Biesheuvel wrote:

From: Ard Biesheuvel 

NonCoherentIoMmuSetAttribute() does nothing except return
EFI_UNSUPPORTED. This was fine when it was introduced, but now, the PCI
bus driver will fail a PCI I/O Map() operation if the SetAttributes
fails.

So return EFI_SUCCESS instead.


It's unclear to me why this change is safe (looking forward).
Does NonCoherentIoMmuDxe also imply no IoMmu actually exists?



Basically. NonCoherentIoMmuDxe is just a vehicle to allow
NonCoherentDmaLib to be plugged into the PCI host bridge driver. It is
not intended to ever do anything more than that.


Not that it needs to happen for this
(Reviewed-by: Leif Lindholm )
but maybe we ought to consider renaming it then?
DummyIoMmuDxe?

/
Leif



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




Re: [edk2-devel] [PATCH 0/2] ArmPkg/MdePkg: Move Chipset/* files to MdePkg

2024-03-12 Thread Leif Lindholm

On 2024-03-12 02:18, Pierre Gondois wrote:

This patch relies on [1].

Following the RFC v1: ArmPkg,MdePkg: move ArmLib.h to MdePkg [1],
move the Chipset/* files to the MdePkg as the Armlib.h relies on
them.

These patches span over multiple packages as these Chipset/* files
are relocated to a new directory and include paths must be updated.


I like this!
Traveling this week, so unable to test until Wednesday next week at the 
earliest, which I would like to do for something this core before giving 
a Reviewed-by. So for now, for the series:

Acked-by: Leif Lindholm 


[1] https://edk2.groups.io/g/devel/message/111566

Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Leif Lindholm 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Cc: Zhiguang Liu 

Pierre Gondois (2):
   ArmPkg,MdePkg: Move ArmPkg/Chipset/ArmV7[|Mmu].h to MdePkg
   ArmPkg,MdePkg: Move ArmPkg/Chipset/Aarch64[|Mmu].h to MdePkg

  ArmPkg/Library/ArmExceptionLib/AArch64/AArch64Exception.c | 2 +-
  ArmPkg/Library/ArmExceptionLib/AArch64/ExceptionSupport.S | 2 +-
  ArmPkg/Library/ArmExceptionLib/Arm/ArmException.c | 2 +-
  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c| 2 +-
  ArmPkg/Library/ArmLib/AArch64/AArch64Support.S| 2 +-
  ArmPkg/Library/ArmLib/Arm/ArmV7Lib.c  | 2 +-
  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c  | 2 +-
  ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibConvert.c   | 2 +-
  ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibCore.c  | 2 +-
  ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibUpdate.c| 2 +-
  ArmPlatformPkg/PrePeiCore/AArch64/Exception.S | 2 +-
  ArmPlatformPkg/PrePeiCore/AArch64/Helper.S| 2 +-
  ArmPlatformPkg/PrePi/AArch64/ArchPrePi.c  | 2 +-
  ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S   | 2 +-
  ArmVirtPkg/PrePi/AArch64/ArchPrePi.c  | 2 +-
  {ArmPkg/Include/Chipset => MdePkg/Include/AArch64}/AArch64.h  | 2 +-
  .../Include/Chipset => MdePkg/Include/AArch64}/AArch64Mmu.h   | 0
  .../Include/Chipset/ArmV7.h => MdePkg/Include/Arm/AArch32.h   | 2 +-
  .../Chipset/ArmV7Mmu.h => MdePkg/Include/Arm/AArch32Mmu.h | 0
  MdePkg/Include/Library/ArmLib.h   | 4 ++--
  20 files changed, 19 insertions(+), 19 deletions(-)
  rename {ArmPkg/Include/Chipset => MdePkg/Include/AArch64}/AArch64.h (94%)
  rename {ArmPkg/Include/Chipset => MdePkg/Include/AArch64}/AArch64Mmu.h (100%)
  rename ArmPkg/Include/Chipset/ArmV7.h => MdePkg/Include/Arm/AArch32.h (95%)
  rename ArmPkg/Include/Chipset/ArmV7Mmu.h => MdePkg/Include/Arm/AArch32Mmu.h 
(100%)





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




Re: [edk2-devel] [PATCH 1/1] EmbeddedPkg/NonCoherentIoMmuDxe: Make SetAttributes always succeed

2024-03-12 Thread Leif Lindholm

On 2024-03-12 08:17, Ard Biesheuvel wrote:

From: Ard Biesheuvel 

NonCoherentIoMmuSetAttribute() does nothing except return
EFI_UNSUPPORTED. This was fine when it was introduced, but now, the PCI
bus driver will fail a PCI I/O Map() operation if the SetAttributes
fails.

So return EFI_SUCCESS instead.


It's unclear to me why this change is safe (looking forward).
Does NonCoherentIoMmuDxe also imply no IoMmu actually exists?

/
Leif


Signed-off-by: Ard Biesheuvel 
---
This fixes a regression on Raspberry Pi4, which no longer boots.

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

diff --git a/EmbeddedPkg/Drivers/NonCoherentIoMmuDxe/NonCoherentIoMmuDxe.c 
b/EmbeddedPkg/Drivers/NonCoherentIoMmuDxe/NonCoherentIoMmuDxe.c
index 4e7a5698c162..f02a76a62ea8 100644
--- a/EmbeddedPkg/Drivers/NonCoherentIoMmuDxe/NonCoherentIoMmuDxe.c
+++ b/EmbeddedPkg/Drivers/NonCoherentIoMmuDxe/NonCoherentIoMmuDxe.c
@@ -70,7 +70,7 @@ NonCoherentIoMmuSetAttribute (
IN UINT64IoMmuAccess
)
  {
-  return EFI_UNSUPPORTED;
+  return EFI_SUCCESS;
  }
  
  /**




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




Re: [edk2-devel] [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg

2024-03-01 Thread Leif Lindholm

Thank you.

OK, that's logically consistent.
So we'd need an ArmLibNull in MdePkg until ArmLib itself migrates there 
(ideally subsumed into BaseLib).


But the dependency in .inf should still be able to be declared under
[LibraryClasses.AArch64, LibraryClasses.ARM]?

Regards,

Leif

On 2024-03-01 01:00, Yao, Jiewen wrote:

Sure.

When we say "dependency", what we really mean is the dependency in INF file, not 
"dependency" in DSC file.

 From package release perspective, only INF is the interface to other package.
The DSC is only the package internal stuff, you can create multiple DSCs or 
add/remove DSC freely.

Having "dependency" in DSC does not matter.
Having dependency in INF is something we should care about.

Thank you
Yao, Jiewen



-----Original Message-
From: Leif Lindholm 
Sent: Tuesday, February 13, 2024 1:38 AM
To: Pierre Gondois ; devel@edk2.groups.io; Yao,
Jiewen 
Cc: Ard Biesheuvel ; Liming Gao
; Kinney, Michael D ;
Sami Mujawar ; Liu, Zhiguang

Subject: Re: [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg

Jiewen, can you clarify what you said back in
https://edk2.groups.io/g/devel/message/111551
?

On 2024-02-12 17:24, Pierre Gondois wrote:

A ArmLibNull.inf library might also need to be created. If the
OpensslLibFullAccel.inf module will depend on the ArmLib library,
a Null implementation will be necessary for non-Arm architectures.


Can ArmLib be declared under a [LibraryClasses.AArch64,
LibraryClasses.ARM]? Have I forgotten something that we discussed back
in ... November?


  From [1], it seems the MdePkg/CryptoPkg should build without a dependency
on the ArmPkg. This is currently not really the case. cf. [2].

However, having a ArmLibNull implementation in the MdePkg would allow to
avoid going in this direction when providing libraries to CryptoPkg.dsc.

(Just in case, I think this ArmLibNull is a minor point.)


Well, sure, it is now.
Until we need a RiscV64LibNull, LoongarchLibNull, ...


[1] https://edk2.groups.io/g/devel/message/111545
[2]


https://github.com/tianocore/edk2/blob/8801c75b4d77c2e6e06b3ddc8560e0db
590f6342/CryptoPkg/CryptoPkg.dsc#L117





Otherwise I could apply and run the CryptoPkg/Arm native instructions
patchset on top of this patch.

---

As a side note, it also seems that:
- ArmPkg/Include/Chipset/ArmCortexA5x.h
     isn't used anymore in edk2/edk2-platorms
- ArmPkg/Include/Chipset/ArmCortexA9.h
     is barely used in edk2-platforms.
Maybe the files should have been removed/simplified as part of
- cffa7925a293 ("ArmPkg: remove ArmCpuLib header and implementations")
- a913ad02479d ("ArmPlatformPkg: remove ArmVExpressPkg")


I think you're right.
Well, ArmCortexA9.h is still *used*, but I can't imagine the Arm branch
of ArmVExpressLib has been build by anyone for some time. And surely the
inclusion of ArmVExpressLibSec in ArmVExpress-FVP-AArch64.dsc is
superfluous (such that that .inf can be deleted)?


The file could just be moved in the Library. I assume you/Sami/Ard
will know more on the usage of the library itself,


Sami?

/
  Leif







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




Re: [edk2-devel] 回复: [edk2-stable202402] [PATCH v5 1/1] MdeModulePkg/AcpiTableDxe: Prefer xDSDT over DSDT when installing tables

2024-02-15 Thread Leif Lindholm

Excellent, thank you.
And it will still go in within the next few weeks, just not before we 
make the stable tag.


/
Leif

On 2024-02-15 10:40, Dhaval Sharma wrote:
For me it is not impacting a production system so I can wait a cycle 
more. @Liming Gao <mailto:gaolim...@byosoft.com.cn> I will send out the 
PR with your rb tag.


On Thu, Feb 15, 2024 at 3:26 PM Leif Lindholm <mailto:quic_llind...@quicinc.com>> wrote:


Hi Liming,

On 2024-02-15 01:41, gaoliming via groups.io <http://groups.io> wrote:
 > Hi, all
 >   This patch was reviewed before soft feature freeze. I would
like to merge
 > it for this stable tag. If you have any comments, please reply
this mail.

I agree this is a bugfix, but the criterion for hard freeze is supposed
to be *critical* bugfix. By definition this is a very invasive change
for systems where it has any effect. So I would feel more
comfortable if
it had more time before going into a stable tag.

Dhaval, how critical is this fix for you? Are you OK for it to go in
after stable tag?

Regards,

Leif


 > Thanks
 > Liming
 >> -邮件原件-
 >> 发件人: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
mailto:devel@edk2.groups.io>> 代表 gaoliming via
 >> groups.io <http://groups.io>
 >> 发送时间: 2024年1月30日 9:21
 >> 收件人: devel@edk2.groups.io <mailto:devel@edk2.groups.io>;
dha...@rivosinc.com <mailto:dha...@rivosinc.com>
 >> 抄送: zhiguang@intel.com <mailto:zhiguang@intel.com>;
dandan...@intel.com <mailto:dandan...@intel.com>;
 >> pedro.falc...@gmail.com <mailto:pedro.falc...@gmail.com>;
chasel.c...@intel.com <mailto:chasel.c...@intel.com>
 >> 主题: 回复: [edk2-devel] [PATCH v5 1/1] MdeModulePkg/AcpiTableDxe:
 >> Prefer xDSDT over DSDT when installing tables
 >>
 >> This version is good to me. Reviewed-by: Liming Gao
 >> mailto:gaolim...@byosoft.com.cn>>
 >>
 >>> -邮件原件-
 >>> 发件人: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
mailto:devel@edk2.groups.io>> 代表 Dhaval
 >>> Sharma
 >>> 发送时间: 2024年1月28日 21:39
 >>> 收件人: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
 >>> 抄送: gaolim...@byosoft.com.cn
<mailto:gaolim...@byosoft.com.cn>; zhiguang@intel.com
<mailto:zhiguang@intel.com>;
 >>> dandan...@intel.com <mailto:dandan...@intel.com>;
pedro.falc...@gmail.com <mailto:pedro.falc...@gmail.com>;
chasel.c...@intel.com <mailto:chasel.c...@intel.com>
 >>> 主题: [edk2-devel] [PATCH v5 1/1] MdeModulePkg/AcpiTableDxe: Prefer
 >>> xDSDT over DSDT when installing tables
 >>>
 >>> As per ACPI Spec 6.5+ Table 5-9 if xDSDT is available,
 >>> it should be used first. Handle required flow when xDSDT
 >>> is absent or present.
 >>>
 >>> Test: Tested on RISCV64 Qemu platform with xDSDT and booted to
 >>> linux kernel.
 >>>
 >>> Cc: Liming Gao 
 >>> Cc: Zhiguang Liu 
 >>> Cc: Dandan Bi 
 >>> Cc: Pedro Falcato 
 >>> Cc: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
 >>> Signed-off-by: Dhaval Sharma 
 >>> Acked-by: Chasel Chiu 
 >>> ---
 >>>
 >>> Notes:
 >>>      v5:
 >>>      - If DSDT is not found, throw error and continue to build
other
 > tables
 >>>      v4:
 >>>      - Fix typos and commit message adding more clarity to
patch subject
 >>>      v3:
 >>>      - Added description of ACPI spec clarification based on
which this
 >> patch is
 >>> created
 >>>      - Optimizing if-else flow
 >>>      v2:
 >>>      - Added proper indentation for else if
 >>>
 >>>   MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 24
 >>> ++--
 >>>   1 file changed, 17 insertions(+), 7 deletions(-)
 >>>
 >>> diff --git
 >> a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
 >>> b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
 >>> index e09bc9b704f5..3879e10b3349 100644
 >>> --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
 >>> +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c
 >>> @@ -1892,14 +1892,24 @@ InstallAcpiTableFromHob (
 >>>           

Re: [edk2-devel] [PATCH edk2-platforms v2 4/4] Platform/SbsaQemu: move FdtHandlerLib to SbsaQemuHardwareInfoLib

2024-01-19 Thread Leif Lindholm
On Tue, Jan 16, 2024 at 08:48:35 +0100, Marcin Juszkiewicz wrote:
> There is no need for EDK2 to know that there is DeviceTree around.
> All hardware information is read using functions from
> SbsaQemuHardwareInfoLib library.
> 
> Library fallbacks to parsing DT if needed (used with too old TF-A).
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 


> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc |   1 -
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf |   4 +-
>  .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf  |  33 ---
>  .../SbsaQemuHardwareInfoLib.inf |   2 +
>  .../Qemu/SbsaQemu/Include/Library/FdtHelperLib.h|  36 ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c   |   4 +-
>  .../SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c|  98 --
>  .../SbsaQemuHardwareInfoLib.c   | 104 
> 
>  8 files changed, 110 insertions(+), 172 deletions(-)
> 
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 07cb3490f4cf..bde61651da2e 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -126,7 +126,6 @@ [LibraryClasses.common]
># ARM PL011 UART Driver
>PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
>  
> -  FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
>OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
>
> SbsaQemuHardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
> index 291743b19115..9bf0a13de5d1 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  This driver modifies ACPI tables for the Qemu SBSA platform
>  #
> -#  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +#  Copyright (c) Linaro Ltd. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -35,9 +35,9 @@ [LibraryClasses]
>BaseLib
>DebugLib
>DxeServicesLib
> -  FdtHelperLib
>PcdLib
>PrintLib
> +  SbsaQemuHardwareInfoLib
>UefiDriverEntryPoint
>UefiLib
>UefiRuntimeServicesTableLib
> diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf 
> b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
> deleted file mode 100644
> index 9c059f3e5851..
> --- a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -#/** @file
> -#
> -#  Component description file for FdtHelperLib module
> -#
> -#  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -#
> -#  SPDX-License-Identifier: BSD-2-Clause-Patent
> -#
> -#**/
> -
> -[Defines]
> -  INF_VERSION= 1.29
> -  BASE_NAME  = FdtHelperLib
> -  FILE_GUID  = 34e4396f-c2fc-4f9e-ad58-0f98e99e3875
> -  MODULE_TYPE= BASE
> -  VERSION_STRING = 1.0
> -  LIBRARY_CLASS  = FdtHelperLib
> -
> -[Sources.common]
> -  FdtHelperLib.c
> -
> -[Packages]
> -  EmbeddedPkg/EmbeddedPkg.dec
> -  MdePkg/MdePkg.dec
> -  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> -
> -[LibraryClasses]
> -  DebugLib
> -  FdtLib
> -  PcdLib
> -
> -[FixedPcd]
> -  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> index 8c2def1878e6..5358dd339eb3 100644
> --- 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> @@ -27,6 +27,8 @@ [LibraryClasses]
>ArmSmcLib
>BaseMemoryLib
>DebugLib
> +  FdtLib
>  
>   [Pcd]
> +  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
> deleted file mode 100644
> index ea9159857215..
> --- a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
> +++ /dev/null
> @@ -1,36 +0,0 @@
> -/** @file
> -*  FdtHelperLib.h
> -*
> -*  Co

Re: [edk2-devel] [PATCH edk2-platforms v2 3/4] Platform/SbsaQemu: use PcdCoreCount directly

2024-01-19 Thread Leif Lindholm
On Tue, Jan 16, 2024 at 08:48:34 +0100, Marcin Juszkiewicz wrote:
> During platform initialization we read amount of cpu cores and set
> PcdCoreCount so there is no need to call FdtHandler.
> 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf |  6 ++
>  Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c   | 10 --
>  .../Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c  | 12 
> +++-
>  3 files changed, 9 insertions(+), 19 deletions(-)
> 
> diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf 
> b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> index a34f54d431d4..8e2bf8c512f1 100644
> --- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> +++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> @@ -3,7 +3,7 @@
>  #
>  #Copyright (c) 2021, NUVIA Inc. All rights reserved.
>  #Copyright (c) 2018, Hisilicon Limited. All rights reserved.
> -#Copyright (c) 2018, Linaro Limited. All rights reserved.
> +#Copyright (c) 2023, Linaro Ltd. All rights reserved.
>  #
>  #SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -29,8 +29,6 @@ [Packages]
>  
>  [LibraryClasses]
>BaseMemoryLib
> -  FdtLib
> -  FdtHelperLib
>IoLib
>PcdLib
>  
> @@ -40,7 +38,6 @@ [Guids]
>  [Pcd]
>gArmTokenSpaceGuid.PcdEmbeddedControllerFirmwareRelease
>gArmTokenSpaceGuid.PcdSystemBiosRelease
> -  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
>  
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemManufacturer
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemSerialNumber
> @@ -56,3 +53,4 @@ [Pcd]
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdChassisManufacturer
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdChassisAssetTag
>gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdChassisSKU
> +  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
> diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c 
> b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> index c38f2851904f..ab97768b5ddc 100644
> --- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> +++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
> @@ -2,7 +2,7 @@
>  *  OemMiscLib.c
>  *
>  *  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +*  Copyright (c) Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -12,14 +12,12 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  /** Returns whether the specified processor is present or not.
>  
> @@ -33,7 +31,7 @@ OemIsProcessorPresent (
>UINTN ProcessorIndex
>)
>  {
> -  if (ProcessorIndex < FdtHelperCountCpus ()) {
> +  if (ProcessorIndex < PcdGet32 (PcdCoreCount)) {
>  return TRUE;
>}
>  
> @@ -76,7 +74,7 @@ OemGetProcessorInformation (
>  {
>UINT16 ProcessorCount;
>  
> -  ProcessorCount = FdtHelperCountCpus ();
> +  ProcessorCount = PcdGet32 (PcdCoreCount);
>  
>if (ProcessorIndex < ProcessorCount) {
>  ProcessorStatus->Bits.CpuStatus   = 1; // CPU enabled
> @@ -121,7 +119,7 @@ OemGetMaxProcessors (
>VOID
>)
>  {
> -  return FdtHelperCountCpus ();
> +  return PcdGet32 (PcdCoreCount);
>  }
>  
>  /** Gets information about the cache at the specified cache level.
> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index 9fb17151d7b8..7ef314ae9f67 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -1,7 +1,7 @@
>  /** @file
>  *  This file is an ACPI driver for the Qemu SBSA platform.
>  *
> -*  Copyright (c) 2020, Linaro Ltd. All rights reserved.
> +*  Copyright (c) Linaro Ltd. All rights reserved.
>  *
>  *  SPDX-License-Identifier: BSD-2-Clause-Patent
>  *
> @@ -255,7 +255,7 @@ AddMadtTable (
>   // Initialize GIC Redistributor Structure
>EFI_ACPI_6_0_GICR_STRUCTURE Gicr = SBSAQEMU_MADT_GICR_INIT();
>  
> -  // Get CoreCount which was determined eariler after parsing device tree
> +  // Get CoreCount which was determined earlier from TF-A

Where we got the information from no longer matters, since we've
abstracted that away.

/
Leif

>NumCores = PcdGet32 (PcdCoreCount);
>  
>// Calculate the new table size based on the number of cores
> @@ -291,7 +291,7 @@ AddMadtTable (
>New += sizeof (EFI_ACPI_6_0_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER);
>  
>// Add new GICC structures for the Cores
> -  for (CoreIndex = 0; CoreIndex < PcdGet32 (PcdCoreCount); CoreIndex++) {
> +  for (CoreIndex = 0; CoreIndex < NumCores; CoreIndex++) {
>  EFI_ACPI_6_0_GIC_STRUCTURE *GiccPtr;
>  
>  CopyMem (New, , sizeof (EFI_ACPI_6_0_GIC_STRUCTURE));
> @@ -758,12 +758,6 @@ InitializeSbsaQemuAcpiDxe (
>  {
>EFI_STATUS  

Re: [edk2-devel] [PATCH edk2-platforms v2 1/4] Platform/SbsaQemu: add SbsaQemuHardwareInfoLib

2024-01-19 Thread Leif Lindholm
On Tue, Jan 16, 2024 at 08:48:32 +0100, Marcin Juszkiewicz wrote:
> This library provides functions to check for hardware information.
> For now it covers CPU ones:
> 
> - amount of cpu cores
> - MPIDR value for cpu core
> - NUMA node id for cpu core
> 
> Values are read from TF-A using platform specific SMC calls.
> 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc |   3 +-
>  .../SbsaQemuHardwareInfoLib.inf |  32 +++
>  .../SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h |   2 +
>  .../Include/Library/SbsaQemuHardwareInfoLib.h   |  45 +
>  .../SbsaQemuHardwareInfoLib.c   | 100 
> 
>  5 files changed, 181 insertions(+), 1 deletion(-)
> 
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 378600050df9..07cb3490f4cf 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -1,6 +1,6 @@
>  #
>  #  Copyright (c) 2021, NUVIA Inc. All rights reserved.
> -#  Copyright (c) 2019, Linaro Limited. All rights reserved.
> +#  Copyright (c) 2019-2024, Linaro Ltd. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -128,6 +128,7 @@ [LibraryClasses.common]
>  
>FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
>OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
> +  
> SbsaQemuHardwareInfoLib|Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
># Debug Support
>
> PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> new file mode 100644
> index ..8c2def1878e6
> --- /dev/null
> +++ 
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.inf
> @@ -0,0 +1,32 @@
> +#/* @file
> +#
> +#  Copyright (c) Linaro Ltd. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +#*/
> +
> +[Defines]
> +  INF_VERSION= 0x0001001c
> +  BASE_NAME  = SbsaQemuHardwareInfoLib
> +  FILE_GUID  = 6454006f-6502-46e2-9be4-4bba8d4b29fb
> +  MODULE_TYPE= BASE
> +  VERSION_STRING = 1.0
> +  LIBRARY_CLASS  = ArmPlatformLib
> +
> +[Sources]
> +  SbsaQemuHardwareInfoLib.c
> +
> +[Packages]
> +  ArmPkg/ArmPkg.dec
> +  EmbeddedPkg/EmbeddedPkg.dec
> +  MdePkg/MdePkg.dec
> +  Silicon/Qemu/SbsaQemu/SbsaQemu.dec
> +
> +[LibraryClasses]
> +  ArmSmcLib
> +  BaseMemoryLib
> +  DebugLib
> +
> + [Pcd]
> +  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> index 7934875e4aba..e33648ee1462 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuSmc.h
> @@ -14,5 +14,7 @@
>  #define SIP_SVC_VERSION  SMC_SIP_FUNCTION_ID(1)
>  #define SIP_SVC_GET_GIC  SMC_SIP_FUNCTION_ID(100)
>  #define SIP_SVC_GET_GIC_ITS  SMC_SIP_FUNCTION_ID(101)
> +#define SIP_SVC_GET_CPU_COUNT SMC_SIP_FUNCTION_ID(200)
> +#define SIP_SVC_GET_CPU_NODE SMC_SIP_FUNCTION_ID(201)
>  
>  #endif /* SBSA_QEMU_SMC_H_ */
> diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h 
> b/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
> new file mode 100644
> index ..45262baf3511
> --- /dev/null
> +++ b/Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuHardwareInfoLib.h
> @@ -0,0 +1,45 @@
> +/** @file
> +*
> +*  Copyright (c) Linaro Ltd. All rights reserved.
> +*
> +*  SPDX-License-Identifier: BSD-2-Clause-Patent
> +*
> +**/
> +
> +#ifndef SBSA_QEMU_HARDWARE_INFO_
> +#define SBSA_QEMU_HARDWARE_INFO_
> +
> +/**
> +  Get CPU count from information passed by Qemu.
> +
> +**/
> +VOID
> +SbsaQemuGetCpuCount (
> +  VOID
> +  );
> +
> +/**
> +  Get MPIDR for a given cpu from device tree passed by Qemu.
> +
> +  @param [in]   CpuIdIndex of cpu to retrieve MPIDR value for.
> +
> +  @retvalMPIDR value of CPU at index 
> +**/
> +UINT64
> +SbsaQemuGetMpidr (
> +  IN UINTN   CpuId
> +  );
> +
> +/**
> +  Get NUMA node id for a given cpu from device tree passed by Qemu.
> +
> +  @param [in]   CpuIdIndex of cpu to retrieve NUMA node id for.
> +
> +  @retvalNUMA node id for CPU at index 
> +**/
> +UINT64
> +SbsaQemuGetCpuNumaNode (
> +  IN UINTN   CpuId
> +  );
> +
> +#endif /* SBSA_QEMU_HARDWARE_INFO_ */
> diff --git 
> a/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
>  
> b/Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c
> new 

Re: [edk2-devel] [PATCH edk2-platforms 1/1] Platform/SbsaQemu: update doc a bit

2024-01-19 Thread Leif Lindholm
On Tue, Jan 16, 2024 at 19:05:35 +0100, Marcin Juszkiewicz wrote:
> We emulate XHCI controller already. No need to add it.
> 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  Platform/Qemu/SbsaQemu/Readme.md | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Platform/Qemu/SbsaQemu/Readme.md 
> b/Platform/Qemu/SbsaQemu/Readme.md
> index 3355adebd4c6..883535dfd20e 100644
> --- a/Platform/Qemu/SbsaQemu/Readme.md
> +++ b/Platform/Qemu/SbsaQemu/Readme.md
> @@ -113,9 +113,9 @@ Create a directory $WORKSPACE that would hold source code 
> of the components.
>```
>$INSTALL_PATH/qemu-system-aarch64 -m 1024 -M sbsa-ref -pflash 
> SBSA_FLASH0.fd -pflash SBSA_FLASH1.fd -serial stdio
>```
> -  You can add XHCI controller with keyboard and mouse by:
> +  You can keyboard and mouse by:

missing "add".
I added that.
Reviewed-by: Leif Lindholm 
Pushed as 82c4c4b03865.

Thanks!

/
Leif

>```
> -  -device qemu-xhci -device usb-mouse -device usb-kbd
> +  -device usb-mouse -device usb-kbd
>```
>You can add the hard drive to platform AHCI controller by `hda` parameter:
>```
> -- 
> 2.43.0
> 
> 
> 
> 
> 
> 


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




Re: [edk2-devel] [PATCH] MdeModulePkg/ResetSystemRuntimeDxe: Print Reset Data

2024-01-19 Thread Leif Lindholm

Hi Ashish,

On 2024-01-19 18:09, Ashish Singhal via groups.io wrote:

Adding tianocore stewards to see if we can get some traction on this.


You've not cc:d Zhichao - who maintains that component - on this patch, 
I've added them.


Please use BaseTools/Scripts/GetMaintainer.py to see who to cc - 
maintainership of some of the modules are split in multiple dimensions 
and it's basically impossible to work out manually.


/
Leif



*From:* Ashish Singhal 
*Sent:* Wednesday, December 6, 2023 5:21 PM
*To:* devel@edk2.groups.io ; 
gaolim...@byosoft.com.cn ; Jeff Brasen 


*Cc:* Ashish Singhal 
*Subject:* [PATCH] MdeModulePkg/ResetSystemRuntimeDxe: Print Reset Data
ResetSystem runtime call allows for sending reset data that
starts with a NULL terminated string. Add support to print
that string on console.

Signed-off-by: Ashish Singhal 
---
  .../Universal/ResetSystemRuntimeDxe/ResetSystem.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c 
b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c

index 42f1b1d015..72bb1d2be6 100644
--- a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
+++ b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
@@ -252,6 +252,14 @@ RuntimeServiceResetSystem (
  mResetNotifyDepth
  ));

+  if ((ResetData != NULL) && (DataSize != 0)) {
+    DEBUG ((
+  DEBUG_INFO,
+  "DXE ResetSystem2: ResetData: %s\n",
+  ResetData
+  ));
+  }
+
    if (mResetNotifyDepth <= MAX_RESET_NOTIFY_DEPTH) {
  if (!EfiAtRuntime ()) {
    //
--
2.17.1






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




Re: [edk2-devel] [PATCH edk2-platforms 1/1] SbsaQemu: get cpu information from TF-A

2024-01-15 Thread Leif Lindholm

On 2024-01-15 15:11, Marcin Juszkiewicz wrote:

As part of removing DeviceTree use we moved cpu related parts to TF-A.
On EDK2 side we get values via SMC calls during platform initialization.


Could you split this into three patches?:
- Adding new Library (Library name should have a Lib suffix.)
- Using this library to check whether SMCs are supported, falling back
  to FdtHelperLib if not.
- Dropping FdtHelperLib and the fallback paths.

?

/
Leif


Handled are:
- get cpu cores count
- get MPIDR
- get NUMA node id

If too old TF-A is used then cpu count and MPIDR are read directly from
DeviceTree.

Signed-off-by: Marcin Juszkiewicz 
---
  Platform/Qemu/SbsaQemu/SbsaQemu.dsc   |   4 +-
  .../Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf   |   6 +-
  .../SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf   |   4 +-
  .../SbsaQemuPlatformDxe.inf   |   4 +-
  .../Library/FdtHelperLib/FdtHelperLib.inf |  33 ---
  .../Library/SbsaQemuSmc/SbsaQemuSmc.inf   |  34 +++
  .../Include/IndustryStandard/SbsaQemuSmc.h|   2 +
  .../SbsaQemu/Include/Library/FdtHelperLib.h   |  36 
  .../SbsaQemu/Include/Library/SbsaQemuSmc.h|  45 
  .../Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c |  10 +-
  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c |  16 +-
  .../SbsaQemuPlatformDxe/SbsaQemuPlatformDxe.c |   9 +-
  .../Library/FdtHelperLib/FdtHelperLib.c   |  98 -
  .../Library/SbsaQemuSmc/SbsaQemuSmc.c | 204 ++
  14 files changed, 308 insertions(+), 197 deletions(-)
  delete mode 100644 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
  create mode 100644 Silicon/Qemu/SbsaQemu/Library/SbsaQemuSmc/SbsaQemuSmc.inf
  delete mode 100644 Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
  create mode 100644 Silicon/Qemu/SbsaQemu/Include/Library/SbsaQemuSmc.h
  delete mode 100644 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
  create mode 100644 Silicon/Qemu/SbsaQemu/Library/SbsaQemuSmc/SbsaQemuSmc.c

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index 378600050df9..231db11cb07b 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -1,6 +1,6 @@
  #
  #  Copyright (c) 2021, NUVIA Inc. All rights reserved.
-#  Copyright (c) 2019, Linaro Limited. All rights reserved.
+#  Copyright (c) 2023, Linaro Ltd. All rights reserved.
  #
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -126,7 +126,7 @@ [LibraryClasses.common]
# ARM PL011 UART Driver
PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
  
-  FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf

+  SbsaQemuSmc|Silicon/Qemu/SbsaQemu/Library/SbsaQemuSmc/SbsaQemuSmc.inf
OemMiscLib|Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
  
# Debug Support

diff --git a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf 
b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
index a34f54d431d4..8e2bf8c512f1 100644
--- a/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
+++ b/Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
@@ -3,7 +3,7 @@
  #
  #Copyright (c) 2021, NUVIA Inc. All rights reserved.
  #Copyright (c) 2018, Hisilicon Limited. All rights reserved.
-#Copyright (c) 2018, Linaro Limited. All rights reserved.
+#Copyright (c) 2023, Linaro Ltd. All rights reserved.
  #
  #SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -29,8 +29,6 @@ [Packages]
  
  [LibraryClasses]

BaseMemoryLib
-  FdtLib
-  FdtHelperLib
IoLib
PcdLib
  
@@ -40,7 +38,6 @@ [Guids]

  [Pcd]
gArmTokenSpaceGuid.PcdEmbeddedControllerFirmwareRelease
gArmTokenSpaceGuid.PcdSystemBiosRelease
-  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
  
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemManufacturer

gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdSystemSerialNumber
@@ -56,3 +53,4 @@ [Pcd]
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdChassisManufacturer
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdChassisAssetTag
gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdChassisSKU
+  gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdCoreCount
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf 
b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 291743b19115..d23b53586cd3 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -1,7 +1,7 @@
  ## @file
  #  This driver modifies ACPI tables for the Qemu SBSA platform
  #
-#  Copyright (c) 2020, Linaro Ltd. All rights reserved.
+#  Copyright (c) Linaro Ltd. All rights reserved.
  #
  #  SPDX-License-Identifier: BSD-2-Clause-Patent
  #
@@ -35,9 +35,9 @@ [LibraryClasses]
BaseLib
DebugLib
DxeServicesLib
-  FdtHelperLib
PcdLib
PrintLib
+  SbsaQemuSmc
UefiDriverEntryPoint
UefiLib
UefiRuntimeServicesTableLib
diff --git 

Re: [edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

2023-12-19 Thread Leif Lindholm
On Mon, Dec 18, 2023 at 22:55:21 +0100, Ard Biesheuvel wrote:
> Hello all,
> 
> Same question again. Could we please make some progress on this?
> 
> Full thread here:
> https://openfw.io/edk2-devel/20231031173700.647004-1-ngo...@fedoraproject.org/
> 
> If nobody objects, I will assume that the change is acceptable and
> merge it by the end of the week.

I'm OK with this.

The last comment from Liming in
https://bugzilla.tianocore.org/show_bug.cgi?id=2831
was that the fix could be merged after "the next UEFI is published",
which it was - in August 2022.

Reviewed-by: Leif Lindholm 

Regards,

Leif


> Thanks,
> Ard.
> 
> 
> 
> On Tue, 12 Dec 2023 at 09:11, Ard Biesheuvel  wrote:
> >
> > (cc Mike, Leif)
> >
> > On Thu, 7 Dec 2023 at 08:40, Ard Biesheuvel  wrote:
> > >
> > > (cc Liming)
> > >
> > > On Thu, 7 Dec 2023 at 05:48, Neal Gompa  wrote:
> > > >
> > > > On Fri, Nov 24, 2023 at 6:36 PM Neal Gompa  wrote:
> > > > >
> > > > > On Thu, Nov 2, 2023 at 6:35 AM Laszlo Ersek  wrote:
> > > > > >
> > > > > > On 10/31/23 23:27, Jeremy Linton wrote:
> > > > > > > On 10/31/23 12:37, Neal Gompa via groups.io wrote:
> > > > > > >> From: Neal Gompa 
> > > > > > >>
> > > > > > >> Currently, the ReadyToBoot event is only signaled when a formal 
> > > > > > >> Boot
> > > > > > >> Manager option is executed (in BmBoot.c -> EfiBootManagerBoot 
> > > > > > >> ()).
> > > > > > >>
> > > > > > >> However, the introduction of Platform Recovery in UEFI 2.5 makes 
> > > > > > >> it
> > > > > > >> necessary to signal ReadyToBoot when a Platform Recovery boot 
> > > > > > >> loader
> > > > > > >> runs because otherwise it may lead to the execution of a boot 
> > > > > > >> loader
> > > > > > >> that has similar requirements to a regular one that is not 
> > > > > > >> launched
> > > > > > >> as a Boot Manager option.
> > > > > > >>
> > > > > > >> This is especially critical to ensuring that the graphical 
> > > > > > >> console
> > > > > > >> is actually usable during platform recovery, as some platforms do
> > > > > > >> rely on the ConsolePrefDxe driver, which only performs console
> > > > > > >> initialization after ReadyToBoot is triggered.
> > > > > > >>
> > > > > > >> This patch fixes that behavior by calling 
> > > > > > >> EfiSignalEventReadyToBoot ()
> > > > > > >> in EfiBootManagerProcessLoadOption () when invoking platform 
> > > > > > >> recovery,
> > > > > > >> which is the function that sets up the platform recovery boot 
> > > > > > >> process.
> > > > > > >>
> > > > > > >> The expected behavior has been clarified in the UEFI 2.10 
> > > > > > >> specification
> > > > > > >> to explicitly indicate this behavior is required for correct 
> > > > > > >> operation.
> > > > > > >>
> > > > > > >> This is a rebased version of the patch originally written by 
> > > > > > >> Pete Batard.
> > > > > > >
> > > > > > > Took me a bit to swap in that whole conversation again, and 
> > > > > > > recheck the
> > > > > > > spec's and code paths, but this all looks fine to me and should 
> > > > > > > allow
> > > > > > > the PFTF build to drop the similar patch from Pete that has been 
> > > > > > > carried
> > > > > > > downstream for the past couple years.
> > > > > > >
> > > > > > > As for testing the previous patch has been in the field for a 
> > > > > > > couple
> > > > > > > years now and i'm not aware of it causing any issues. The 
> > > > > > > additional
> > > > > > > restriction of limiting it to platform recovery logically makes 
> > > > > > > sense,
> > > > > > > and as far as I can see shoul

Re: [edk2-devel] [PATCH] ArmPkg/DebugPeCoffExtraActionLib: Drop RVCT and Cygwin support

2023-12-14 Thread Leif Lindholm
+Sami (who I know once, a very long time ago, used cygwin)

On Thu, Dec 14, 2023 at 10:20:46 +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel 
> 
> The DebugPeCoffExtraActionLib implemention in ArmPkg contains some cruft
> that dates back to the original RVCT based ARM port, and support for
> RVCT was dropped a while ago.
> 
> Also drop the handling of Cygwin specific paths, which is highly
> unlikely to be still depended upon by anyone.
> 
> Tweak the logic so that only two versions of the DEBUG() invocations
> remain: one for __GNUC__ when PdbPointer is set, and the fallback that
> just prints the image address and the address of the entrypoint.
> 
> Cc: Mike Beaton 
> Signed-off-by: Ard Biesheuvel 

But as far as I'm concerned, cygwin support feels extremely dated
these days and not worth the maintainance overhead to keep around.
So
Reviewed-by: Leif Lindholm 

/
Leif

> ---
>  ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c | 100 
> ++--
>  1 file changed, 31 insertions(+), 69 deletions(-)
> 
> diff --git 
> a/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c 
> b/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
> index 432112354fda..992c14d7ef9b 100644
> --- a/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
> +++ b/ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.c
> @@ -17,45 +17,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #include 
>  #include 
>  
> -/**
> -  If the build is done on cygwin the paths are cygpaths.
> -  /cygdrive/c/tmp.txt vs c:\tmp.txt so we need to convert
> -  them to work with RVD commands
> -
> -  @param  Name  Path to convert if needed
> -
> -**/
> -CHAR8 *
> -DeCygwinPathIfNeeded (
> -  IN  CHAR8  *Name,
> -  IN  CHAR8  *Temp,
> -  IN  UINTN  Size
> -  )
> -{
> -  CHAR8  *Ptr;
> -  UINTN  Index;
> -  UINTN  Index2;
> -
> -  Ptr = AsciiStrStr (Name, "/cygdrive/");
> -  if (Ptr == NULL) {
> -return Name;
> -  }
> -
> -  for (Index = 9, Index2 = 0; (Index < (Size + 9)) && (Ptr[Index] != '\0'); 
> Index++, Index2++) {
> -Temp[Index2] = Ptr[Index];
> -if (Temp[Index2] == '/') {
> -  Temp[Index2] = '\\';
> -}
> -
> -if (Index2 == 1) {
> -  Temp[Index2 - 1] = Ptr[Index];
> -  Temp[Index2] = ':';
> -}
> -  }
> -
> -  return Temp;
> -}
> -
>  /**
>Performs additional actions after a PE/COFF image has been loaded and 
> relocated.
>  
> @@ -71,23 +32,24 @@ PeCoffLoaderRelocateImageExtraAction (
>IN OUT PE_COFF_LOADER_IMAGE_CONTEXT  *ImageContext
>)
>  {
> - #if !defined (MDEPKG_NDEBUG)
> -  CHAR8  Temp[512];
> - #endif
> -
> +#ifdef __GNUC__
>if (ImageContext->PdbPointer) {
> - #ifdef __CC_ARM
> -// Print out the command for the DS-5 to load symbols for this image
> -DEBUG ((DEBUG_LOAD | DEBUG_INFO, "add-symbol-file %a 0x%p\n", 
> DeCygwinPathIfNeeded (ImageContext->PdbPointer, Temp, sizeof (Temp)), 
> (UINTN)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders)));
> - #elif __GNUC__
> -// This may not work correctly if you generate PE/COFF directly as then 
> the Offset would not be required
> -DEBUG ((DEBUG_LOAD | DEBUG_INFO, "add-symbol-file %a 0x%p\n", 
> DeCygwinPathIfNeeded (ImageContext->PdbPointer, Temp, sizeof (Temp)), 
> (UINTN)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders)));
> - #else
> -DEBUG ((DEBUG_LOAD | DEBUG_INFO, "Loading driver at 0x%11p 
> EntryPoint=0x%11p\n", (VOID *)(UINTN)ImageContext->ImageAddress, 
> FUNCTION_ENTRY_POINT (ImageContext->EntryPoint)));
> - #endif
> -  } else {
> -DEBUG ((DEBUG_LOAD | DEBUG_INFO, "Loading driver at 0x%11p 
> EntryPoint=0x%11p\n", (VOID *)(UINTN)ImageContext->ImageAddress, 
> FUNCTION_ENTRY_POINT (ImageContext->EntryPoint)));
> +DEBUG ((
> +  DEBUG_LOAD | DEBUG_INFO,
> +  "add-symbol-file %a 0x%p\n",
> +  ImageContext->PdbPointer,
> +  (UINTN)(ImageContext->ImageAddress + ImageContext->SizeOfHeaders)
> +  ));
> +return;
>}
> +#endif
> +
> +  DEBUG ((
> +DEBUG_LOAD | DEBUG_INFO,
> +"Loading driver at 0x%11p EntryPoint=0x%11p\n",
> +(VOID *)(UINTN)ImageContext->ImageAddress,
> +FUNCTION_ENTRY_POINT (ImageContext->EntryPoint)
> +));
>  }
>  
>  /**
> @@ -106,21 +68,21 @@ PeCoffLoaderUnloadImageExtraAction (
>IN OUT PE_COFF_LOADER_IMAGE_CONTEXT  *ImageContext
>)
>  {
> - #if !defined (MDEPKG_NDEBUG)
> -  CHAR8  Temp[512];
> - #en

Re: [edk2-devel] [PATCH edk2-platforms 1/1] set WritePolicyValid for all cache types

2023-11-22 Thread Leif Lindholm
On Wed, Nov 15, 2023 at 13:46:08 +0100, Marcin Juszkiewicz wrote:
> acpiview complains:
> 
> ERROR: On Arm based systems, all cache properties must be provided in
> the cache type structure. Missing 'Write Policy Valid' flag.
> 
> ACPI specification says:
> 
> > Set to 1 if the write policy attribute described is valid. A value 
> > of 0 indicates that, where possible, processor architecture specific
> > discovery mechanisms should be used to ascertain the value of this
> > attribute.
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 
Pushed as 10e2eb030de3.

Thanks!

> ---
>  Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h | 2 +-
>  Platform/RaspberryPi/AcpiTables/Pptt.aslc | 2 +-
>  Silicon/Marvell/Armada7k8k/AcpiTables/Pptt.aslc   | 2 +-
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Pptt.aslc | 2 +-
>  Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Pptt.aslc  | 2 +-
>  Silicon/Socionext/SynQuacer/AcpiTables/Pptt.aslc  | 2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> index 983d17f6fa50..61d8bce8c959 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> @@ -126,7 +126,7 @@ typedef struct {
>1,   /* AssociativityValid */  
>   \
>1,   /* AllocationTypeValid */ 
>   \
>1,   /* CacheTypeValid */  
>   \
> -  0,   /* WritePolicyValid */
>   \
> +  1,   /* WritePolicyValid */
>   \
>1,   /* LineSizeValid */   
>   \
>  },   
>   \
>  0, /* NextLevelOfCache */
>   \
> diff --git a/Platform/RaspberryPi/AcpiTables/Pptt.aslc 
> b/Platform/RaspberryPi/AcpiTables/Pptt.aslc
> index a52bc5a31adf..b80f5ff1e057 100644
> --- a/Platform/RaspberryPi/AcpiTables/Pptt.aslc
> +++ b/Platform/RaspberryPi/AcpiTables/Pptt.aslc
> @@ -114,7 +114,7 @@ typedef struct {
>1,  /* AssociativityValid */   
>   \
>1,  /* AllocationTypeValid */  
>   \
>1,  /* CacheTypeValid */   
>   \
> -  0,  /* WritePolicyValid */ 
>   \
> +  1,  /* WritePolicyValid */ 
>   \
>1,  /* LineSizeValid */
>   \
>  },   
>   \
>  0,/* NextLevelOfCache */ 
>   \
> diff --git a/Silicon/Marvell/Armada7k8k/AcpiTables/Pptt.aslc 
> b/Silicon/Marvell/Armada7k8k/AcpiTables/Pptt.aslc
> index e03bfcd6211d..f3a9b90fb564 100644
> --- a/Silicon/Marvell/Armada7k8k/AcpiTables/Pptt.aslc
> +++ b/Silicon/Marvell/Armada7k8k/AcpiTables/Pptt.aslc
> @@ -94,7 +94,7 @@ typedef struct {
>1,  /* AssociativityValid */   
>   \
>1,  /* AllocationTypeValid */  
>   \
>1,  /* CacheTypeValid */   
>   \
> -  0,  /* WritePolicyValid */ 
>   \
> +  1,  /* WritePolicyValid */ 
>   \
>1,  /* LineSizeValid */
>   \
>  },   
>   \
>  0,/* NextLevelOfCache */ 
>   \
> diff --git a/Silicon/Marvell/OcteonTx/AcpiTables/T91/Pptt.aslc 
> b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Pptt.aslc
> index f37c7511134d..3793cbbca0b5 100644
> --- a/Silicon/Marvell/OcteonTx/AcpiTables/T91/Pptt.aslc
> +++ b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Pptt.aslc
> @@ -94,7 +94,7 @@ typedef struct {
>1,  /* AssociativityValid */   
>   \
>1,  /* AllocationTypeValid */  
&

Re: [edk2-discuss] [edk2-devel] Soft Feature Freeze starts now for edk2-stable202311

2023-11-22 Thread Leif Lindholm

On 2023-11-22 13:21, Marcin Juszkiewicz wrote:

W dniu 22.11.2023 o 13:26, Leif Lindholm pisze:

On 2023-11-22 11:11, Sami Mujawar wrote:


[SAMI] The proposal above looks good to me. This may be slightly off 
topic, but can we also enable edk2-platform upstream CI as well, 
please? This would be helpful to catch issues much earlier. [/SAMI]


Yes, this is a problem we need to solve, but we don't have the time or 
resources to set up an upstream CI. What we've been thinking of

is to let maintainers set up their own CI infrastructure and then
have that perform any target-specific tasks and report back to
upstream CI. It's been a few months since I last discussed this with
Mike, but I think we were looking at 
https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners

as a possible tool.

This is probably not something we would like to tie into the edk2 
mergify workflow (it would add too much delay), but localised to 
edk2-platforms.


Any help with implementing that would be most appreciated :)


I can write CI jobs which would run tests for QEMU platforms:

- virt/x86-64 (i440fx/q35)
- virt/aarch64


These live in the main edk2 repo though, so are not part of the problem 
that needs solving.



- sbsa-ref/aarch64

Sbsa-ref is something I am working on daily.

If Github Actions is all what's needed then it can be done using 
platform provided runners (no self-hosted needed).


We need the self-hosted for the physical platforms, which are the main 
part of the problem. But setting something like this up for the 
edk2-platforms platforms we can test with qemu could be a good first step.


/
Leif



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




Re: [edk2-discuss] [edk2-devel] Soft Feature Freeze starts now for edk2-stable202311

2023-11-22 Thread Leif Lindholm

On 2023-11-22 11:11, Sami Mujawar wrote:

Hi Leif,

Please see my response inline marked [SAMI].


On the whole, tagging edk2-platforms at the same time as we tag the main
repo is unlikely to be beneficial. We'll need to introduce a freeze of
the platforms tree once the main repo stable tag is made and then wait
for reports/updates from maintainers.
And implement a deprecation/archiving process for platforms where this
does not happen in a timely fashion.
And I guess also tag the edk2-non-osi repo at the same time as the
platforms repo.


[SAMI] The proposal above looks good to me.
This may be slightly off topic, but can we also enable edk2-platform upstream 
CI as well, please? This would be helpful to catch issues much earlier.
There have been several instances where changes in edk2 repo have broken 
platforms in edk2-platforms and this has gone unnoticed until someone tried to 
build that platform.
I understand the proposal above requires maintainers to build and test the 
platforms once the platform freeze is announced.
However, I think having an upstream edk2-platforms CI may reduce some of the 
burden and last-minute rush for the maintainers.
Please let me know your thoughts.
[/SAMI]


TL;DR: not exactly.

Yes, this is a problem we need to solve, but we don't have the time or 
resources to set up an upstream CI.
What we've been thinking of is to let maintainers set up their own CI 
infrastructure and then have that perform any target-specific tasks and 
report back to upstream CI.
It's been a few months since I last discussed this with Mike, but I 
think we were looking at

https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners
as a possible tool.

This is probably not something we would like to tie into the edk2 
mergify workflow (it would add too much delay), but localised to 
edk2-platforms.


Any help with implementing that would be most appreciated :)

/
Leif



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




Re: [edk2-devel] [PATCH v3 10/11] DynamicTablesPkg: Add DynamicTablesScmiInfoLib

2023-11-21 Thread Leif Lindholm
On Tue, Nov 21, 2023 at 17:50:06 +0100, Pierre Gondois wrote:
> The SCP holds some power information that could be advertised
> through the _CPC object. The communication with the SCP is done
> through SCMI protocols (c.f. ArmScmiDxe).
> 
> Use the SCMI protocols to query information and feed it to
> the DynamicTablesPkg.
> 
> Signed-off-by: Pierre Gondois 

Acked-by: Leif Lindholm 

/
Leif

> ---
>  DynamicTablesPkg/DynamicTables.dsc.inc|   1 +
>  DynamicTablesPkg/DynamicTablesPkg.dec |   3 +
>  DynamicTablesPkg/DynamicTablesPkg.dsc |   1 +
>  .../Library/DynamicTablesScmiInfoLib.h|  33 ++
>  .../DynamicTablesScmiInfoLib.c| 297 ++
>  .../DynamicTablesScmiInfoLib.inf  |  31 ++
>  6 files changed, 366 insertions(+)
>  create mode 100644 
> DynamicTablesPkg/Include/Library/DynamicTablesScmiInfoLib.h
>  create mode 100644 
> DynamicTablesPkg/Library/DynamicTablesScmiInfoLib/DynamicTablesScmiInfoLib.c
>  create mode 100644 
> DynamicTablesPkg/Library/DynamicTablesScmiInfoLib/DynamicTablesScmiInfoLib.inf
> 
> diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
> b/DynamicTablesPkg/DynamicTables.dsc.inc
> index 9d4312c4e87d..41947012b92b 100644
> --- a/DynamicTablesPkg/DynamicTables.dsc.inc
> +++ b/DynamicTablesPkg/DynamicTables.dsc.inc
> @@ -15,6 +15,7 @@ [BuildOptions]
>  [LibraryClasses.common]
>
> AcpiHelperLib|DynamicTablesPkg/Library/Common/AcpiHelperLib/AcpiHelperLib.inf
>AmlLib|DynamicTablesPkg/Library/Common/AmlLib/AmlLib.inf
> +  
> DynamicTablesScmiInfoLib|DynamicTablesPkg/Library/DynamicTablesScmiInfoLib/DynamicTablesScmiInfoLib.inf
>
> SsdtPcieSupportLib|DynamicTablesPkg/Library/Common/SsdtPcieSupportLib/SsdtPcieSupportLib.inf
>
> SsdtSerialPortFixupLib|DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.inf
>
> TableHelperLib|DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
> diff --git a/DynamicTablesPkg/DynamicTablesPkg.dec 
> b/DynamicTablesPkg/DynamicTablesPkg.dec
> index cfbcbb9569f1..aa422ce9f6fd 100644
> --- a/DynamicTablesPkg/DynamicTablesPkg.dec
> +++ b/DynamicTablesPkg/DynamicTablesPkg.dec
> @@ -42,6 +42,9 @@ [LibraryClasses]
>##  @libraryclass  Defines a set of SMBIOS string helper methods.
>SmbiosStringTableLib|Include/Library/SmbiosStringTableLib.h
>  
> +  ##  @libraryclass  Defines a set of APIs to populate CmObj using SCMI.
> +  DynamicTablesScmiInfoLib|Include/Library/DynamicTablesScmiInfoLib.h
> +
>  [Protocols]
># Configuration Manager Protocol GUID
>gEdkiiConfigurationManagerProtocolGuid = { 0xd85a4835, 0x5a82, 0x4894, { 
> 0xac, 0x2, 0x70, 0x6f, 0x43, 0xd5, 0x97, 0x8e } }
> diff --git a/DynamicTablesPkg/DynamicTablesPkg.dsc 
> b/DynamicTablesPkg/DynamicTablesPkg.dsc
> index bd5084a9008f..853ea2a1e4c2 100644
> --- a/DynamicTablesPkg/DynamicTablesPkg.dsc
> +++ b/DynamicTablesPkg/DynamicTablesPkg.dsc
> @@ -39,6 +39,7 @@ [LibraryClasses.ARM, LibraryClasses.AARCH64]
>PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
>  
>  [Components.common]
> +  
> DynamicTablesPkg/Library/DynamicTablesScmiInfoLib/DynamicTablesScmiInfoLib.inf
>DynamicTablesPkg/Library/Common/AcpiHelperLib/AcpiHelperLib.inf
>DynamicTablesPkg/Library/Common/AmlLib/AmlLib.inf
>DynamicTablesPkg/Library/Common/SsdtPcieSupportLib/SsdtPcieSupportLib.inf
> diff --git a/DynamicTablesPkg/Include/Library/DynamicTablesScmiInfoLib.h 
> b/DynamicTablesPkg/Include/Library/DynamicTablesScmiInfoLib.h
> new file mode 100644
> index ..ff6b47d51fe8
> --- /dev/null
> +++ b/DynamicTablesPkg/Include/Library/DynamicTablesScmiInfoLib.h
> @@ -0,0 +1,33 @@
> +/** @file
> +  Arm SCMI Info Library.
> +
> +  Copyright (c) 2022 - 2023, Arm Limited. All rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#ifndef ARM_SCMI_INFO_LIB_H_
> +#define ARM_SCMI_INFO_LIB_H_
> +
> +#include 
> +
> +/** Populate a AML_CPC_INFO object based on SCMI information.
> +
> +  @param[in]  DomainIdIdentifier for the performance domain.
> +  @param[out] CpcInfo If success, this structure was populated from
> +  information queried to the SCP.
> +
> +  @retval EFI_SUCCESS Success.
> +  @retval EFI_DEVICE_ERRORDevice error.
> +  @retval EFI_INVALID_PARAMETER   Invalid parameter.
> +  @retval EFI_TIMEOUT Time out.
> +  @retval EFI_UNSUPPORTED Unsupported.
> +**/
> +EFI_STATUS
> +EFIAPI
> +DynamicTablesScmiInfoGetFastChannel (
> +  IN  UINT32DomainId,
> +  OUT AML_CPC_INFO  *CpcInfo
> +  );
> +
> +#endif // AR

Re: [edk2-devel] [PATCH v3 1/3] Platform/ARM: Juno: Fix typo

2023-11-21 Thread Leif Lindholm
On Tue, Nov 21, 2023 at 17:51:33 +0100, PierreGondois wrote:
> Fix a typo.
> 
> Change-Id: I84807f18855ff4c0a2f34a3556edc4698eea2170

You've accidentally included your internal Change-Id in the commit
messages for all patches in this set.

/
Leif

> Signed-off-by: Pierre Gondois 
> ---
>  .../ConfigurationManagerDxe/ConfigurationManager.c  | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
>  
> b/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
> index 91f035480dcf..2fdb15cc4caf 100644
> --- 
> a/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
> +++ 
> b/Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/ConfigurationManager.c
> @@ -993,7 +993,7 @@ GetGicCInfo (
>return EFI_NOT_FOUND;
>  }
>  
> -/** Return Lpi State Infor.
> +/** Return Lpi State Info.
>  
>@param [in]  This   Pointer to the Configuration Manager 
> Protocol.
>@param [in]  CmObjectId The Object ID of the CM object requested
> -- 
> 2.25.1
> 
> 
> 
> 
> 
> 


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




Re: [edk2-devel] [PATCH v3 01/11] ArmPkg/ArmScmiDxe: Rename PERFORMANCE_PROTOCOL_VERSION

2023-11-21 Thread Leif Lindholm
On Tue, Nov 21, 2023 at 17:49:57 +0100, Pierre Gondois wrote:
> Rename PERFORMANCE_PROTOCOL_VERSION to reflect the different
> versions of the protocol. The macro is neither used in edk2 nor
> in edk2-platforms.
> 
> Signed-off-by: Pierre Gondois 

Reviewed-by: Leif Lindholm 

> ---
>  .../Include/Protocol/ArmScmiPerformanceProtocol.h   | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h 
> b/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
> index 7e548e4765c2..a28f0f766e37 100644
> --- a/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
> +++ b/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
> @@ -1,12 +1,12 @@
>  /** @file
>  
> -  Copyright (c) 2017-2021, Arm Limited. All rights reserved.
> +  Copyright (c) 2017-2023, Arm Limited. All rights reserved.
>  
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
> -  System Control and Management Interface V1.0
> -http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/
> -DEN0056A_System_Control_and_Management_Interface.pdf
> +  System Control and Management Interface V3.2, latest version at:
> +  - https://developer.arm.com/documentation/den0056/latest/
> +
>  **/
>  
>  #ifndef ARM_SCMI_PERFORMANCE_PROTOCOL_H_
> @@ -14,7 +14,10 @@
>  
>  #include 
>  
> -#define PERFORMANCE_PROTOCOL_VERSION  0x1
> +/// Arm Scmi performance protocol versions.
> +#define PERFORMANCE_PROTOCOL_VERSION_V1  0x1
> +#define PERFORMANCE_PROTOCOL_VERSION_V2  0x2
> +#define PERFORMANCE_PROTOCOL_VERSION_V3  0x3
>  
>  #define ARM_SCMI_PERFORMANCE_PROTOCOL_GUID  { \
>0x9b8ba84, 0x3dd3, 0x49a6, {0xa0, 0x5a, 0x31, 0x34, 0xa5, 0xf0, 0x7b, 
> 0xad} \
> -- 
> 2.25.1
> 


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




[edk2-devel] [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg

2023-11-21 Thread Leif Lindholm
Related to https://bugzilla.tianocore.org/show_bug.cgi?id=4121, but not
resolving it. (Nearly?) all of ArmPkg describes industry standard
behaviour, and hence according to general rules, ought to live in MdePkg.

Addressing this will however be a substantial task.
Take a first step by moving the ArmLib interface definition to MdePkg,
as discussed in
https://edk2.groups.io/g/devel/topic/patch_v5_2_6/102725178

Cc: Pierre Gondois 
Cc: Jiewen Yao 
Cc: Ard Biesheuvel 
Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Sami Mujawar 
Cc: Zhiguang Liu 
Signed-off-by: Leif Lindholm 
---

This should have no functional differences (and the set of
platforms I have test built didn't find any problems).
This may result in some modules depending on ArmPkg only
for ArmLib now being able to drop ArmPkg dependency.

 ArmPkg/ArmPkg.dec   | 4 
 MdePkg/MdePkg.dec   | 5 +
 {ArmPkg => MdePkg}/Include/Library/ArmLib.h | 0
 Maintainers.txt | 6 ++
 4 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 7fe2b9bca43b..4ce59f3e1fbd 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -50,10 +50,6 @@ [LibraryClasses.common]
   #
   ArmHvcLib|Include/Library/ArmHvcLib.h
 
-  ##  @libraryclass  Provides an interface to Arm registers.
-  #
-  ArmLib|Include/Library/ArmLib.h
-
   ##  @libraryclass  Provides a Mmu interface.
   #
   ArmMmuLib|Include/Library/ArmMmuLib.h
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index ac54338089e8..78e18ee444cd 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -339,6 +339,11 @@ [LibraryClasses.RISCV64]
   ##  @libraryclass  Provides function to make ecalls to SBI
   BaseRiscVSbiLib|Include/Library/BaseRiscVSbiLib.h
 
+[LibraryClasses.ARM, LibraryClasses.AARCH64]
+  ##  @libraryclass  Provides an interface to Arm registers.
+  #
+  ArmLib|Include/Library/ArmLib.h
+
 [Guids]
   #
   # GUID defined in UEFI2.1/UEFI2.0/EFI1.1
diff --git a/ArmPkg/Include/Library/ArmLib.h b/MdePkg/Include/Library/ArmLib.h
similarity index 100%
rename from ArmPkg/Include/Library/ArmLib.h
rename to MdePkg/Include/Library/ArmLib.h
diff --git a/Maintainers.txt b/Maintainers.txt
index 7c0b4cb58cfd..0315fa23dfce 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -450,6 +450,12 @@ M: Abner Chang  [changab]
 R: Abdul Lateef Attar  [abdattar]
 R: Nickle Wang  [nicklela]
 
+MdePkg: ARM/AARCH64 standard interfaces
+F: MdePkg/Include/Library/ArmLib.h
+M: Leif Lindholm  [leiflindholm]
+M: Ard Biesheuvel  [ardbiesheuvel]
+R: Sami Mujawar  [samimujawar]
+
 NetworkPkg
 F: NetworkPkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/NetworkPkg
-- 
2.30.2



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




Re: [edk2-devel] [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency upon ArmPkg

2023-11-21 Thread Leif Lindholm
On Tue, Nov 21, 2023 at 14:46:05 +, Yao, Jiewen wrote:
> This Bugzilla is filed in 2022-10-26. Now it is 2023-11-21.

Oh, I'm sure I voiced the same opinion for many years before someone
(rightly) told me to go gile that bugzilla.

> I agree with you that it is a big task. May I know what is the plan?
> E.g. who is working on that? When do you expect it will be done?

On my list of "big items" to deal with, this comes after github PR
migration and line-ending conversion.

> According to the dependency rule, what we need is only *interface*
> definition, but not *implementation*.
> That means the really requirement here is to move *interface* from
> ArmPkg to MdePkg, you can still keep the library implementation in
> ArmPkg. (It is just a subset of this Bugzilla)

That ... is an option I had not previously considered.
Long-term we would still like to smash ArmLib into BaseLib, but if
MdePkg maintainers would be OK with moving ArmLib.h into MdePkg...

> Also, I don’t think CPUID check really matters here - since it is only 
> implementation.
> As long as, you have interface in MdePkg, then your INF can declare that 
> interface.
> You can still put real implementation in ArmPkg - no requirement to move.
> That benefit is that you don’t need to add ArmPkg dependency in yaml.

I can spin up a patch for that to get merged shortly after stable tag
to give plenty of time to catch any issues that may arise from moving
such a fundamental file. (These would likely be bugs, but
nevertheless...)

Thanks!

/
Leif


> Thank you
> Yao, Jiewen
> 
> > -Original Message-
> > From: Leif Lindholm 
> > Sent: Tuesday, November 21, 2023 10:26 PM
> > To: Yao, Jiewen 
> > Cc: Pierre Gondois ; devel@edk2.groups.io; Li, Yi1
> > ; Lu, Xiaoyu1 ; Jiang, Guomin
> > ; Ard Biesheuvel ; Sami
> > Mujawar ; Gerd Hoffmann 
> > Subject: Re: [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency
> > upon ArmPkg
> > 
> > Hi Jiewen,
> > 
> > On Tue, Nov 21, 2023 at 13:41:21 +, Yao, Jiewen wrote:
> > > Thanks to let me know the background.
> > >
> > > Please be aware that there is fundamental difference between
> > > dependency in INF and dependency in DSC.
> > >
> > > What we have previously in the ArmPkg in *DSC*. We don’t need add
> > > ArmPkg in yaml.
> > > However, what you try to introduce is ArmPkg in *INF*, e.g. your
> > > patch v5 5/6. Then we have to add ArmPkg in yaml.
> > >
> > > Personally, I don’t think it is a good idea to add ArmPkg to yaml,
> > > because it means that you have to pull ArmPkg when you build
> > > CryptoPkg,.
> > >
> > > As long as what you add is industry standard, it is OK to add to
> > > MdePkg, like what you did in v2. I would like to suggest this
> > > approach.
> > 
> > Ultimately, all of ArmPkg needs to migrate to MdePkg.
> > See https://bugzilla.tianocore.org/show_bug.cgi?id=4121
> > But this is a BIG task.
> > 
> > The reason I asked Pierre to add this functionality in ArmPkg rather
> > than MdePkg is because that is where the existing related discovery
> > code lives. (Think of it as CPUID.)
> > 
> > For historical reasons, predating mine and Ard's involvement with
> > edk2, this functionality (as well as other critical Arm functionality)
> > lives in a library called ArmLib, under ArmPkg.
> > For Ia32/X64, all such support lives in BaseLib, under MdePkg.
> > 
> > This is why I referred to ArmPkg as an exclave of MdePkg in my
> > original reply to Pierre. And until someone untangles this, it's not
> > realistic to treat ArmPkg as anything else.
> > 
> > And I don't think it's fair to expect Pierre to untangle this as part
> > of this series. But I also don't think "Arm architectures need to
> > duplicate their basic support code across multiple packages" is a
> > solution.
> > 
> > Regards,
> > 
> > Leif
> > 
> > > But I would like to have ARM expert to check if those are really ARM
> > > standard, and also have MdePkg owner check if it is acceptable.
> > >
> > > Thank you
> > > Yao, Jiewen
> > >
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Pierre Gondois 
> > > > Sent: Tuesday, November 21, 2023 8:59 PM
> > > > To: Yao, Jiewen ; devel@edk2.groups.io; Leif
> > Lindholm
> > > > 
> > > > Cc: Li, Yi1 ; Lu, Xiaoyu1 ; 
> > > > Jiang,
> > Guomin
> > > > ; Ard Biesheuvel ;
> > Sami
> > > > Mujawar ; 

Re: [edk2-devel] [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency upon ArmPkg

2023-11-21 Thread Leif Lindholm
Hi Jiewen,

On Tue, Nov 21, 2023 at 13:41:21 +, Yao, Jiewen wrote:
> Thanks to let me know the background.
> 
> Please be aware that there is fundamental difference between
> dependency in INF and dependency in DSC.
> 
> What we have previously in the ArmPkg in *DSC*. We don’t need add
> ArmPkg in yaml.
> However, what you try to introduce is ArmPkg in *INF*, e.g. your
> patch v5 5/6. Then we have to add ArmPkg in yaml.
> 
> Personally, I don’t think it is a good idea to add ArmPkg to yaml,
> because it means that you have to pull ArmPkg when you build
> CryptoPkg,.
> 
> As long as what you add is industry standard, it is OK to add to
> MdePkg, like what you did in v2. I would like to suggest this
> approach.

Ultimately, all of ArmPkg needs to migrate to MdePkg.
See https://bugzilla.tianocore.org/show_bug.cgi?id=4121
But this is a BIG task.

The reason I asked Pierre to add this functionality in ArmPkg rather
than MdePkg is because that is where the existing related discovery
code lives. (Think of it as CPUID.)

For historical reasons, predating mine and Ard's involvement with
edk2, this functionality (as well as other critical Arm functionality)
lives in a library called ArmLib, under ArmPkg.
For Ia32/X64, all such support lives in BaseLib, under MdePkg.

This is why I referred to ArmPkg as an exclave of MdePkg in my
original reply to Pierre. And until someone untangles this, it's not
realistic to treat ArmPkg as anything else.

And I don't think it's fair to expect Pierre to untangle this as part
of this series. But I also don't think "Arm architectures need to
duplicate their basic support code across multiple packages" is a
solution.

Regards,

Leif

> But I would like to have ARM expert to check if those are really ARM
> standard, and also have MdePkg owner check if it is acceptable.
> 
> Thank you
> Yao, Jiewen
> 
> 
> 
> 
> > -Original Message-
> > From: Pierre Gondois 
> > Sent: Tuesday, November 21, 2023 8:59 PM
> > To: Yao, Jiewen ; devel@edk2.groups.io; Leif Lindholm
> > 
> > Cc: Li, Yi1 ; Lu, Xiaoyu1 ; Jiang, 
> > Guomin
> > ; Ard Biesheuvel ; Sami
> > Mujawar ; Gerd Hoffmann 
> > Subject: Re: [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency
> > upon ArmPkg
> > 
> > Hello Jiewen,
> > 
> > On 11/21/23 12:27, Yao, Jiewen wrote:
> > > Why CryptoPkg needs to depend on ArmPkg?
> > >
> > > Can we move content to MdePkg?
> > 
> > The OpensslLib needs to discover the native instruction supported by the
> > underlying platform before using them. This could also be done through the
> > MdePkg as you suggested. The v2 is implemented that way:
> > https://edk2.groups.io/g/devel/message/110953
> > 
> > Also, as noted by Leif, it seems there is already a dependency over ArmPkg:
> > # git grep ArmPkg CryptoPkg/
> > CryptoPkg/CryptoPkg.dsc:  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> > CryptoPkg/CryptoPkg.dsc:
> > NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > CryptoPkg/CryptoPkg.dsc:
> > ArmSoftFloatLib|ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> > CryptoPkg/CryptoPkgMbedTls.dsc:
> > NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > CryptoPkg/CryptoPkgMbedTls.dsc:
> > ArmSoftFloatLib|ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> > CryptoPkg/CryptoPkgMbedTls.dsc:
> > PeiServicesTablePointerLib|ArmPkg/Library/PeiServicesTablePointerLib/PeiServic
> > esTablePointerLib.inf
> > 
> > Both solutions suit me (discovering capabilities through ArmPkg or MdePkg),
> > I just need to know which one is preferred,
> > 
> > Regards,
> > Pierre
> > 
> > >
> > >> -Original Message-
> > >> From: Pierre Gondois 
> > >> Sent: Tuesday, November 21, 2023 4:47 PM
> > >> To: devel@edk2.groups.io
> > >> Cc: Yao, Jiewen ; Li, Yi1 ; Lu,
> > Xiaoyu1
> > >> ; Jiang, Guomin ; Leif
> > Lindholm
> > >> ; Ard Biesheuvel ;
> > >> Sami Mujawar ; Gerd Hoffmann
> > >> 
> > >> Subject: [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency 
> > >> upon
> > >> ArmPkg
> > >>
> > >> Allow dependency upon ArmPkg to pass the dependency Check.
> > >>
> > >> Signed-off-by: Pierre Gondois 
> > >> ---
> > >>   CryptoPkg/CryptoPkg.ci.yaml | 1 +
> > >>   1 file changed, 1 insertion(+)
> > >>
> > >> diff --git a/CryptoPkg/CryptoPkg.ci.yaml b/CryptoPkg/CryptoPkg.ci.yaml
> > >> index f961d85927c0..3bbb220d3224 100644

Re: [edk2-devel] [PATCH v3 22/39] ArmPkg: Remove ArmPciCpuIo2Dxe from ArmPkg

2023-11-20 Thread Leif Lindholm
Hi Chao,

Yes, correct.

So we can update the existing users of this driver in edk2-platforms
before deleting it.

Regards,

Leif

On Mon, Nov 20, 2023 at 11:24:03 +0800, Chao Li wrote:
> Hi Leif,
> 
> Do you mean that CpuIo2Dxe adds MMIO method first, then waits for this patch
> series to be merged, and finally makes a new BZ and remove the ARM version?
> 
> 
> Thanks,
> Chao
> On 2023/11/17 21:13, Leif Lindholm wrote:
> > On Fri, Nov 17, 2023 at 18:01:39 +0800, Chao Li wrote:
> > > ArmPciCpuIo2Dxe has been merged into CpuIo2Dxe, and CpuIo2Dxe is already
> > > used by all ARM virtual platforms, so remove it.
> > This does affect 15 platforms in edk2-platforms.
> > You should ping the maintainers of the affected platforms, or even
> > better write a patch yourself, so we don't end up with sudden
> > mass-breakage.
> > 
> > It might be worth splitting this patch out of the rest of the set in
> > order to permit a more graceful switchover.
> > 
> > /
> >  Leif
> > 
> > > BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=4584
> > > 
> > > Cc: Leif Lindholm
> > > Cc: Ard Biesheuvel
> > > Cc: Sami Mujawar
> > > ---
> > >   ArmPkg/ArmPkg.dsc |   1 -
> > >   .../Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.c | 556 --
> > >   .../ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf   |  47 --
> > >   3 files changed, 604 deletions(-)
> > >   delete mode 100644 ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.c
> > >   delete mode 100644 ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf
> > > 
> > > diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
> > > index 6dd91e6941..7af25a91a1 100644
> > > --- a/ArmPkg/ArmPkg.dsc
> > > +++ b/ArmPkg/ArmPkg.dsc
> > > @@ -143,7 +143,6 @@
> > > ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> > > -  ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf
> > > ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
> > > ArmPkg/Library/ArmGicArchLib/ArmGicArchLib.inf
> > > ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
> > > diff --git a/ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.c 
> > > b/ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.c
> > > deleted file mode 100644
> > > index 5a2866ccd8..00
> > > --- a/ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.c
> > > +++ /dev/null
> > > @@ -1,556 +0,0 @@
> > > -/** @file
> > > -  Produces the CPU I/O 2 Protocol.
> > > -
> > > -Copyright (c) 2009 - 2012, Intel Corporation. All rights reserved.
> > > -Copyright (c) 2016, Linaro Ltd. All rights reserved.
> > > -
> > > -SPDX-License-Identifier: BSD-2-Clause-Patent
> > > -
> > > -**/
> > > -
> > > -#include 
> > > -
> > > -#include 
> > > -
> > > -#include 
> > > -#include 
> > > -#include 
> > > -#include 
> > > -#include 
> > > -
> > > -#define MAX_IO_PORT_ADDRESS  0x
> > > -
> > > -//
> > > -// Handle for the CPU I/O 2 Protocol
> > > -//
> > > -STATIC EFI_HANDLE  mHandle = NULL;
> > > -
> > > -//
> > > -// Lookup table for increment values based on transfer widths
> > > -//
> > > -STATIC CONST UINT8  mInStride[] = {
> > > -  1, // EfiCpuIoWidthUint8
> > > -  2, // EfiCpuIoWidthUint16
> > > -  4, // EfiCpuIoWidthUint32
> > > -  8, // EfiCpuIoWidthUint64
> > > -  0, // EfiCpuIoWidthFifoUint8
> > > -  0, // EfiCpuIoWidthFifoUint16
> > > -  0, // EfiCpuIoWidthFifoUint32
> > > -  0, // EfiCpuIoWidthFifoUint64
> > > -  1, // EfiCpuIoWidthFillUint8
> > > -  2, // EfiCpuIoWidthFillUint16
> > > -  4, // EfiCpuIoWidthFillUint32
> > > -  8  // EfiCpuIoWidthFillUint64
> > > -};
> > > -
> > > -//
> > > -// Lookup table for increment values based on transfer widths
> > > -//
> > > -STATIC CONST UINT8  mOutStride[] = {
> > > -  1, // EfiCpuIoWidthUint8
> > > -  2, // EfiCpuIoWidthUint16
> > > -  4, // EfiCpuIoWidthUint32
> > > -  8, // EfiCpuIoWidthUint64
> > > -  1, // EfiCpuIoWidthFifoUint8
> > > -  2, // EfiCpuIoWidthFifoUint16
> > > -  4, // EfiCpuIoWidthFifoUint32
> > > -  8, // EfiCpuIoWidthFifoUint64
> > > -  0, // EfiCpuIoWidthFillUint8
> > > -  0, // EfiCpuIoWidthFillUint16
> > > -  0, // EfiCpuIoWidthFillUi

Re: [edk2-devel] [PATCH v4 5/6] CryptoPkg/OpensslLib: Add AArch64Cap for arch specific hooks

2023-11-20 Thread Leif Lindholm
On Mon, Nov 20, 2023 at 14:48:25 +0100, Pierre Gondois wrote:
> Add AARCH64 specific implementations of:
> - OPENSSL_cpuid_setup(), probing hardware capabilitie
>   (presence of FEAT_AES, etc.)
> - OPENSSL_rdtsc(), returning non-trusted entropy by accessing
>   system counter.
> 
> Acked-by: Gerd Hoffmann 
> Signed-off-by: Pierre Gondois 
> ---
>  .../Library/OpensslLib/OpensslLibAccel.inf|  7 ++
>  .../OpensslLib/OpensslLibFullAccel.inf|  7 ++
>  .../OpensslLib/OpensslStub/AArch64Cap.c   | 84 +++
>  3 files changed, 98 insertions(+)
>  create mode 100644 CryptoPkg/Library/OpensslLib/OpensslStub/AArch64Cap.c
> 
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf 
> b/CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf
> index 3d1a9638b1c1..08e8be6ea9e1 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLibAccel.inf
> @@ -1329,6 +1329,7 @@ [Sources.X64]
>  # Autogenerated files list ends here
>  
>  [Sources.AARCH64]
> +  OpensslStub/AArch64Cap.c
>  # Autogenerated files list starts here
>$(OPENSSL_PATH)/crypto/aes/aes_cbc.c
>$(OPENSSL_PATH)/crypto/aes/aes_cfb.c
> @@ -1955,11 +1956,17 @@ [Packages]
>MdePkg/MdePkg.dec
>CryptoPkg/CryptoPkg.dec
>  
> +[Packages.AARCH64]
> +  ArmPkg/ArmPkg.dec
> +
>  [LibraryClasses]
>BaseLib
>DebugLib
>RngLib
>  
> +[LibraryClasses.AARCH64]
> +  ArmLib
> +
>  [BuildOptions]
>#
># Disables the following Visual Studio compiler warnings brought by 
> openssl source,
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf 
> b/CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf
> index e7e83d419f4b..2a01ffe06bd7 100644
> --- a/CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf
> +++ b/CryptoPkg/Library/OpensslLib/OpensslLibFullAccel.inf
> @@ -1432,6 +1432,7 @@ [Sources.X64]
>  # Autogenerated files list ends here
>  
>  [Sources.AARCH64]
> +  OpensslStub/AArch64Cap.c
>  # Autogenerated files list starts here
>$(OPENSSL_PATH)/crypto/aes/aes_cbc.c
>$(OPENSSL_PATH)/crypto/aes/aes_cfb.c
> @@ -2107,11 +2108,17 @@ [Packages]
>MdePkg/MdePkg.dec
>CryptoPkg/CryptoPkg.dec
>  
> +[Packages.AARCH64]
> +  ArmPkg/ArmPkg.dec
> +
>  [LibraryClasses]
>BaseLib
>DebugLib
>RngLib
>  
> +[LibraryClasses.AARCH64]
> +  ArmLib
> +
>  [BuildOptions]
>#
># Disables the following Visual Studio compiler warnings brought by 
> openssl source,
> diff --git a/CryptoPkg/Library/OpensslLib/OpensslStub/AArch64Cap.c 
> b/CryptoPkg/Library/OpensslLib/OpensslStub/AArch64Cap.c
> new file mode 100644
> index ..7468ef3ab54e
> --- /dev/null
> +++ b/CryptoPkg/Library/OpensslLib/OpensslStub/AArch64Cap.c
> @@ -0,0 +1,84 @@
> +/** @file
> +  Arm capabilities probing.
> +
> +  Copyright (c) 2023, Arm Limited. All rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#include 
> +#include "crypto/arm_arch.h"
> +
> +#include 
> +
> +/** Get bits from a value.
> +
> +  Shift the input value from 'shift' bits and apply 'mask'.
> +
> +  @param   valueThe value to get the bits from.
> +  @param   shiftIndex of the bits to read.
> +  @param   mask Mask to apply to the value once shifted.
> +
> +  @return  The desired bitfield from the value.
> +**/
> +#define GET_BITFIELD(value, shift, mask)\
> +  ((value >> shift) & mask)

(This macro appears unused here now.)

> +
> +UINT32  OPENSSL_armcap_P = 0;
> +
> +void
> +OPENSSL_cpuid_setup (
> +  void
> +  )
> +{
> +  OPENSSL_armcap_P = 0;
> +
> +  /* Access to EL0 registers is possible from higher ELx. */
> +  OPENSSL_armcap_P |= ARMV8_CPUID;
> +  /* Access to Physical timer is possible. */
> +  OPENSSL_armcap_P |= ARMV7_TICK;
> +
> +  /* Neon support is not guaranteed, but it is assumed to be present.
> + Arm ARM for Armv8, sA1.5 Advanced SIMD and floating-point support
> +  */
> +  OPENSSL_armcap_P |= ARMV7_NEON;
> +
> +  if (ArmHasAes ())
> +  {

And I think that curly bracket is supposed to be on the previous line
(and similarly below), but this may be intional to align with nearby
code?

Anyway, this is a big readability improvement, thank you very much!
Acked-by: Leif Lindholm 

/
Leif

> +OPENSSL_armcap_P |= ARMV8_AES;
> +  }
> +
> +  if (ArmHasSha1 ())
> +  {
> +OPENSSL_armcap_P |= ARMV8_SHA1;
> +  }
> +
> +  if (ArmHasSha256 ())
> +  {
> +OPENSSL_armcap_P |= ARMV8_SHA256;
> +  }
> +
> +  if (ArmHasPmull ())
> +  {
> +OPENSSL_armcap_P |= ARMV8_PMULL;
>

Re: [edk2-devel] [PATCH v4 1/6] ArmPkg/ArmLib: Add macros/helper functions around AA64Isar0 register

2023-11-20 Thread Leif Lindholm
On Mon, Nov 20, 2023 at 14:48:21 +0100, Pierre Gondois wrote:
> Add macro definitions and helper functions to access AArch64
> capabilities described in the AA64Isar0 register.
> 
> Signed-off-by: Pierre Gondois 
> ---
>  ArmPkg/Include/Chipset/AArch64.h   |  60 +++-
>  ArmPkg/Include/Library/ArmLib.h| 228 -
>  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.c | 367 +
>  3 files changed, 653 insertions(+), 2 deletions(-)
> 
> diff --git a/ArmPkg/Include/Chipset/AArch64.h 
> b/ArmPkg/Include/Chipset/AArch64.h
> index 5390bf0a2774..97c20e71a811 100644
> --- a/ArmPkg/Include/Chipset/AArch64.h
> +++ b/ArmPkg/Include/Chipset/AArch64.h
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> -  Copyright (c) 2011 - 2021, Arm Limited. All rights reserved.
> +  Copyright (c) 2011 - 2023, Arm Limited. All rights reserved.
>  
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
> @@ -127,6 +127,64 @@
>  // build for ARMv8.0, we need to define the register here.
>  #define ID_AA64MMFR2_EL1  S3_0_C0_C7_2
>  
> +//
> +// Bit shifts for the ID_AA64ISAR0_EL1 register.
> +//
> +#define ARM_ID_AA64ISAR0_EL1_AES_SHIFT (4U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA1_SHIFT(8U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA2_SHIFT(12U)
> +#define ARM_ID_AA64ISAR0_EL1_CRC32_SHIFT   (16U)
> +#define ARM_ID_AA64ISAR0_EL1_ATOMIC_SHIFT  (20U)
> +#define ARM_ID_AA64ISAR0_EL1_RDM_SHIFT (28U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA3_SHIFT(32U)
> +#define ARM_ID_AA64ISAR0_EL1_SM3_SHIFT (36U)
> +#define ARM_ID_AA64ISAR0_EL1_SM4_SHIFT (40U)
> +#define ARM_ID_AA64ISAR0_EL1_DP_SHIFT  (44U)
> +#define ARM_ID_AA64ISAR0_EL1_FHM_SHIFT (48U)
> +#define ARM_ID_AA64ISAR0_EL1_TS_SHIFT  (52U)
> +#define ARM_ID_AA64ISAR0_EL1_TLB_SHIFT (56U)
> +#define ARM_ID_AA64ISAR0_EL1_RNDR_SHIFT(60U)
> +
> +//
> +// Bit masks for the ID_AA64ISAR0_EL1 fields.
> +//
> +#define ARM_ID_AA64ISAR0_EL1_AES_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SHA1_MASK(0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SHA2_MASK(0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_CRC32_MASK   (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_ATOMIC_MASK  (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_RDM_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SHA3_MASK(0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SM3_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SM4_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_DP_MASK  (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_FHM_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_TS_MASK  (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_TLB_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_RNDR_MASK(0xFU)
> +
> +//
> +// Bit masks for the ID_AA64ISAR0_EL1 field values.
> +//
> +#define ARM_ID_AA64ISAR0_EL1_AES_FEAT_AES_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_AES_FEAT_PMULL_MASK  (0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA1_FEAT_SHA1_MASK  (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA2_FEAT_SHA256_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA2_FEAT_SHA512_MASK(0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_CRC32_HAVE_CRC32_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_ATOMIC_FEAT_LSE_MASK (0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_RDM_FEAT_RDM_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA3_FEAT_SHA3_MASK  (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SM3_FEAT_SM3_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SM4_FEAT_SM4_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_DP_FEAT_DOTPROD_MASK (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_FHM_FEAT_FHM_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_TS_FEAT_FLAGM_MASK   (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_TS_FEAT_FLAGM2_MASK  (0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_TLB_FEAT_TLBIOS_MASK (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_TLB_FEAT_TLBIRANGE_MASK  (0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_RNDR_FEAT_RNG_MASK   (0x1U)
> +
>  #define VECTOR_BASE(tbl)  \
>.section .text.##tbl##,"ax";\
>.align 11;  \
> diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
> index 6aa8a48f07f3..a176fcd7bf0a 100644
> --- a/ArmPkg/Include/Library/ArmLib.h
> +++ b/ArmPkg/Include/Library/ArmLib.h
> @@ -1,7 +1,7 @@
>  /** @file
>  
>Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> -  Copyright (c) 2011 - 2016, ARM Ltd. All rights reserved.
> +  Copyright (c) 2011 - 2023, Arm Limited. All rights reserved.
>Copyright (c) 2020 - 2021, NUVIA Inc. All rights reserved.
>  
>SPDX-License-Identifier: BSD-2-Clause-Patent
> @@ -805,6 +805,232 @@ ArmHasEte (
>VOID
>);
>  
> +/** Read AA64Isar0 regis

Re: [edk2-devel] [PATCH v3 22/39] ArmPkg: Remove ArmPciCpuIo2Dxe from ArmPkg

2023-11-17 Thread Leif Lindholm
On Fri, Nov 17, 2023 at 18:01:39 +0800, Chao Li wrote:
> ArmPciCpuIo2Dxe has been merged into CpuIo2Dxe, and CpuIo2Dxe is already
> used by all ARM virtual platforms, so remove it.

This does affect 15 platforms in edk2-platforms.
You should ping the maintainers of the affected platforms, or even
better write a patch yourself, so we don't end up with sudden
mass-breakage.

It might be worth splitting this patch out of the rest of the set in
order to permit a more graceful switchover.

/
Leif

> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
> 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> ---
>  ArmPkg/ArmPkg.dsc |   1 -
>  .../Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.c | 556 --
>  .../ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf   |  47 --
>  3 files changed, 604 deletions(-)
>  delete mode 100644 ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.c
>  delete mode 100644 ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf
> 
> diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
> index 6dd91e6941..7af25a91a1 100644
> --- a/ArmPkg/ArmPkg.dsc
> +++ b/ArmPkg/ArmPkg.dsc
> @@ -143,7 +143,6 @@
>  
>ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
>  
> -  ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf
>ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
>ArmPkg/Library/ArmGicArchLib/ArmGicArchLib.inf
>ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
> diff --git a/ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.c 
> b/ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.c
> deleted file mode 100644
> index 5a2866ccd8..00
> --- a/ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.c
> +++ /dev/null
> @@ -1,556 +0,0 @@
> -/** @file
> -  Produces the CPU I/O 2 Protocol.
> -
> -Copyright (c) 2009 - 2012, Intel Corporation. All rights reserved.
> -Copyright (c) 2016, Linaro Ltd. All rights reserved.
> -
> -SPDX-License-Identifier: BSD-2-Clause-Patent
> -
> -**/
> -
> -#include 
> -
> -#include 
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#define MAX_IO_PORT_ADDRESS  0x
> -
> -//
> -// Handle for the CPU I/O 2 Protocol
> -//
> -STATIC EFI_HANDLE  mHandle = NULL;
> -
> -//
> -// Lookup table for increment values based on transfer widths
> -//
> -STATIC CONST UINT8  mInStride[] = {
> -  1, // EfiCpuIoWidthUint8
> -  2, // EfiCpuIoWidthUint16
> -  4, // EfiCpuIoWidthUint32
> -  8, // EfiCpuIoWidthUint64
> -  0, // EfiCpuIoWidthFifoUint8
> -  0, // EfiCpuIoWidthFifoUint16
> -  0, // EfiCpuIoWidthFifoUint32
> -  0, // EfiCpuIoWidthFifoUint64
> -  1, // EfiCpuIoWidthFillUint8
> -  2, // EfiCpuIoWidthFillUint16
> -  4, // EfiCpuIoWidthFillUint32
> -  8  // EfiCpuIoWidthFillUint64
> -};
> -
> -//
> -// Lookup table for increment values based on transfer widths
> -//
> -STATIC CONST UINT8  mOutStride[] = {
> -  1, // EfiCpuIoWidthUint8
> -  2, // EfiCpuIoWidthUint16
> -  4, // EfiCpuIoWidthUint32
> -  8, // EfiCpuIoWidthUint64
> -  1, // EfiCpuIoWidthFifoUint8
> -  2, // EfiCpuIoWidthFifoUint16
> -  4, // EfiCpuIoWidthFifoUint32
> -  8, // EfiCpuIoWidthFifoUint64
> -  0, // EfiCpuIoWidthFillUint8
> -  0, // EfiCpuIoWidthFillUint16
> -  0, // EfiCpuIoWidthFillUint32
> -  0  // EfiCpuIoWidthFillUint64
> -};
> -
> -/**
> -  Check parameters to a CPU I/O 2 Protocol service request.
> -
> -  The I/O operations are carried out exactly as requested. The caller is 
> responsible
> -  for satisfying any alignment and I/O width restrictions that a PI System 
> on a
> -  platform might require. For example on some platforms, width requests of
> -  EfiCpuIoWidthUint64 do not work. Misaligned buffers, on the other hand, 
> will
> -  be handled by the driver.
> -
> -  @param[in] MmioOperation  TRUE for an MMIO operation, FALSE for I/O Port 
> operation.
> -  @param[in] Width  Signifies the width of the I/O or Memory 
> operation.
> -  @param[in] AddressThe base address of the I/O operation.
> -  @param[in] Count  The number of I/O operations to perform. The 
> number of
> -bytes moved is Width size * Count, starting at 
> Address.
> -  @param[in] Buffer For read operations, the destination buffer to 
> store the results.
> -For write operations, the source buffer from 
> which to write data.
> -
> -  @retval EFI_SUCCESSThe parameters for this request pass the 
> checks.
> -  @retval EFI_INVALID_PARAMETER  Width is invalid for this PI system.
> -  @retval EFI_INVALID_PARAMETER  Buffer is NULL.
> -  @retval EFI_UNSUPPORTEDThe Buffer is not aligned

Re: [edk2-devel] [PATCH v3 09/39] MdePkg: Add a new library named PeiServicesTablePointerLibReg

2023-11-17 Thread Leif Lindholm
Not my package, just spotted a typo below:

On Fri, Nov 17, 2023 at 17:59:49 +0800, Chao Li wrote:
> Since some ARCH or platform not require execute code on memory during
> PEI phase, some values may transferred via CPU registers.
> 
> Adding PeiServcieTablePointerLibReg to allow set and get the PEI service
> table pointer depend by a CPU register, this library can accommodate lot
> of platforms who not require execte code on memory during PEI phase.
> 
> Adding PeiServiceTablePointerLibReg to allows setting and getting the
> PEI service table pointer via CPU registers, and the library can
> accommodate many platforms that do not need to execute code on memory
> during the PEI phase.
> 
> The idea of this library is derived from
> ArmPkg/Library/PeiServicesTablePointerLib/
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Leif Lindholm 
> Cc: Ard Biesheuvel 
> Cc: Sami Mujawar 
> Cc: Laszlo Ersek 
> Cc: Sunil V L 
> Signed-off-by: Chao Li 
> ---
>  .../Library/PeiServicesTablePointerLib.h  | 37 +++-
>  .../PeiServicesTablePointer.c | 86 +++
>  .../PeiServicesTablePointerLib.uni| 20 +
>  .../PeiServicesTablePointerLibReg.inf | 40 +
>  MdePkg/MdePkg.dsc |  1 +
>  5 files changed, 180 insertions(+), 4 deletions(-)
>  create mode 100644 
> MdePkg/Library/PeiServicesTablePointerLibReg/PeiServicesTablePointer.c
>  create mode 100644 
> MdePkg/Library/PeiServicesTablePointerLibReg/PeiServicesTablePointerLib.uni
>  create mode 100644 
> MdePkg/Library/PeiServicesTablePointerLibReg/PeiServicesTablePointerLibReg.inf
> 
> diff --git a/MdePkg/Include/Library/PeiServicesTablePointerLib.h 
> b/MdePkg/Include/Library/PeiServicesTablePointerLib.h
> index 61635eff00..f5c764cb13 100644
> --- a/MdePkg/Include/Library/PeiServicesTablePointerLib.h
> +++ b/MdePkg/Include/Library/PeiServicesTablePointerLib.h
> @@ -52,10 +52,11 @@ SetPeiServicesTablePointer (
>immediately preceding the Interrupt Descriptor Table (IDT) in memory.
>For X64 CPUs, the PEI Services Table pointer is stored in the 8 bytes
>immediately preceding the Interrupt Descriptor Table (IDT) in memory.
> -  For Itanium and ARM CPUs, a the PEI Services Table Pointer is stored in
> -  a dedicated CPU register.  This means that there is no memory storage
> -  associated with storing the PEI Services Table pointer, so no additional
> -  migration actions are required for Itanium or ARM CPUs.
> +  For Itanium, ARM and LoongArch CPUs, a the PEI Services Table Pointer
> +  is stored in a dedicated CPU register.  This means that there is no
> +  memory storage associated with storing the PEI Services Table pointer,
> +  so no additional migration actions are required for Itanium, ARM and
> +  LoongArch CPUs.
>  
>  **/
>  VOID
> @@ -64,4 +65,32 @@ MigratePeiServicesTablePointer (
>VOID
>);
>  
> +/**
> +  Retrieves the cached value of the PEI Services Table pointer from a CPU 
> register.
> +
> +  Returns the cached value of the PEI Services Table pointer in a CPU 
> specific manner
> +  as specified in the CPU binding section of the Platform Initialization 
> Pre-EFI
> +  Initialization Core Interface Specification.
> +
> +  @return  The pointer to PeiServices.
> +**/
> +CONST EFI_PEI_SERVICES **
> +EFIAPI
> +GetPeiServicesTablePointerFromRegister (
> +  VOID
> +  );
> +
> +/**
> +  Set the pointer PEI Service Table to a CPU register.
> +
> +  Caches the pointer to the PEI Services Table specified by 
> PeiServicesTablePointer
> +  in a platform specific manner.
> +
> +  @paramPeiServicesTablePointer   The address of PeiServices.
> +**/
> +VOID
> +EFIAPI
> +SetPeiServicesTablePointerToRegester (

SetPeiServicesTablePointerToRegester ->
SetPeiServicesTablePointerToRegister

Regester -> Register.

/
Leif

> +  IN UINTN  PeiServicesTablePointer
> +  );
>  #endif
> diff --git 
> a/MdePkg/Library/PeiServicesTablePointerLibReg/PeiServicesTablePointer.c 
> b/MdePkg/Library/PeiServicesTablePointerLibReg/PeiServicesTablePointer.c
> new file mode 100644
> index 00..0227f98871
> --- /dev/null
> +++ b/MdePkg/Library/PeiServicesTablePointerLibReg/PeiServicesTablePointer.c
> @@ -0,0 +1,86 @@
> +/** @file
> +  PEI Services Table Pointer Library For Reigseter Mechanism.
> +
> +  This library is used for PEIM which does executed from flash device 
> directly but
> +  executed in memory.
> +
> +  Copyright (c) 2006 - 2010, Intel Corporation. All rights reserved.
> +  Copyright (c) 2011 Hewlett-Packard Corporation. All rights re

Re: [edk2-devel] [PATCH 0/3] Maintainers.txt: add Laszlo Ersek as an ArmVirt, Ovmf, UefiCpu Pkg "M"

2023-11-16 Thread Leif Lindholm
For the series:
Reviewed-by: Leif Lindholm 

On Thu, Nov 16, 2023 at 22:50:55 +0100, Laszlo Ersek wrote:
> I'm offering to restore a subset of my earlier ArmVirtPkg and OvmfPkg
> maintainer responsibilities.
> 
> I'm both offering and requesting an escalation of my earlier UefiCpuPkg
> role.
> 
> The commit messages contain lists of files and directories that I intend
> to assist with.
> 
> Under ArmVirtPkg, my focus is the ArmVirtQemu platform.
> 
> Under OvmfPkg and UefiCpuPkg, my focus is the traditional three OVMF
> platforms (IA32, IA32X64, X64) and their dependencies; in particular I
> refrain from Confidential Computing technologies. Under OvmfPkg, I may
> also not be the primary reviewer of those nontrivial device drivers and
> libraries that I neither wrote nor reviewed.
> 
> Finally, I'm interested in reviewing patches for most of the edk2 core,
> and patches for the RISC-V architecture; but it's too early to formalize
> those interests even as some "R" lines.
> 
> Cc: Andrew Fish 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Rahul Kumar 
> Cc: Ray Ni 
> Cc: Sami Mujawar 
> 
> Thanks,
> Laszlo
> 
> Laszlo Ersek (3):
>   Maintainers.txt: add Laszlo Ersek as an ArmVirtPkg maintainer
>   Maintainers.txt: add Laszlo Ersek as an OvmfPkg maintainer
>   Maintainers.txt: add Laszlo Ersek as a UefiCpuPkg maintainer
> 
>  Maintainers.txt | 3 +++
>  1 file changed, 3 insertions(+)
> 
> 
> base-commit: 3db76e6476e493d3cda45b81bba99a645180cf35


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




Re: [edk2-devel] [edk2-platforms PATCH v2 0/1] Marvell package restructure

2023-11-16 Thread Leif Lindholm
Apologies, I managed to misfile this.
Reviewed-by: Leif Lindholm 

Typo in subject line fixed, pushed as ec5de71d83f3.

Thanks!

/
Leif

On Thu, Nov 02, 2023 at 09:15:51 +0530, ndhil...@marvell.com wrote:
> From: Narinder Dhillon 
> 
> Current Silicon/Marvell package structure does not allow sharing of
> components that are common to different SoC's. This restructure will
> increase shared code and better seperation.
> 
> Credit to Leif Lindholm for providing this new structure.
> 
> v2:
>  - Remove three lines for libraries that were erroneously introduced
>into MarvellSiliconPkg.dec file. These libraries are present in
>Armada7k8k.dsc.inc
>  - Removed trailing new line at the end of MarvellSiliconPkg.dec
>  - Squashed patches 2,3,4 into 1 as they don't build separately
> 
> v1:
>  - Original patch series restructuring Marvell package
> 
> 
> Narinder Dhillon (1):
>   Silicon/Marvell: Retructure package
> 
>  .../Marvell/Armada70x0Db/Armada70x0Db.dsc | 108 -
>  .../Armada70x0DbBoardDescLib.inf  |   2 +-
>  .../NonDiscoverableInitLib.inf|   2 +-
>  .../Marvell/Armada80x0Db/Armada80x0Db.dsc | 133 ++-
>  .../Armada80x0DbBoardDescLib.inf  |   2 +-
>  .../NonDiscoverableInitLib.inf|   2 +-
>  .../Cn9130DbABoardDescLib.inf |   2 +-
>  .../Cn9132DbABoardDescLib.inf |   2 +-
>  Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc   | 100 -
>  Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc   |  66 +++---
>  Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc   |  66 +++---
>  Platform/Marvell/Cn913xDb/Cn913xDbA.dsc   |   8 +-
>  .../NonDiscoverableInitLib.inf|   2 +-
>  .../Armada80x0McBin/Armada80x0McBin.dsc   | 116 +-
>  .../Armada80x0McBinBoardDescLib.inf   |   2 +-
>  .../NonDiscoverableInitLib.inf|   2 +-
>  .../BoardDescriptionLib.inf   |   2 +-
>  .../Cn913xCEx7Eval/Cn9130Eval.dsc.inc |  40 ++--
>  .../Cn913xCEx7Eval/Cn9131Eval.dsc.inc |  56 ++---
>  .../Cn913xCEx7Eval/Cn9132Eval.dsc.inc |  56 ++---
>  .../Cn913xCEx7Eval/Cn913xCEx7.dsc.inc |  60 ++---
>  .../Cn913xCEx7Eval/Cn913xCEx7Eval.dsc |   6 +-
>  .../NonDiscoverableInitLib.inf|   2 +-
>  .../Applications/EepromCmd/EepromCmd.inf  |   2 +-
>  .../Applications/FirmwareUpdate/FUpdate.inf   |   6 +-
>  .../Applications/SpiTool/SpiFlashCmd.inf  |   6 +-
>  .../Armada7k8k/AcpiTables/Armada70x0Db.inf|   2 +-
>  .../Armada7k8k/AcpiTables/Armada80x0Db.inf|   2 +-
>  .../Armada7k8k/AcpiTables/Armada80x0McBin.inf |   2 +-
>  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc |  22 +-
>  .../Armada7k8kRngDxe/Armada7k8kRngDxe.inf |   4 +-
>  .../Drivers/PlatInitDxe/PlatInitDxe.inf   |   6 +-
>  .../PlatformFlashAccessLib.inf|   6 +-
>  .../Library/Armada7k8kLib/Armada7k8kLib.inf   |   4 +-
>  .../Armada7k8kMemoryInitPeiLib.inf|  14 +-
>  .../PciHostBridgeLib.inf  |   2 +-
>  .../Armada7k8kPciSegmentLib/PciSegmentLib.inf |   2 +-
>  .../Armada7k8kSampleAtResetLib.inf|   2 +-
>  .../Armada7k8kSoCDescLib.inf  |   4 +-
>  .../RealTimeClockLib/RealTimeClockLib.inf |   4 +-
>  .../Marvell/Documentation/PortingGuide.txt| 114 +-
>  .../Drivers/BoardDesc/MvBoardDescDxe.inf  |  18 +-
>  .../Drivers/Gpio/MvGpioDxe/MvGpioDxe.inf  |   2 +-
>  .../Gpio/MvPca95xxDxe/MvPca95xxDxe.inf|   2 +-
>  .../Drivers/I2c/MvEepromDxe/MvEepromDxe.inf   |   6 +-
>  .../Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf |  14 +-
>  .../Drivers/Net/MvMdioDxe/MvMdioDxe.inf   |   2 +-
>  .../Marvell/Drivers/Net/MvPhyDxe/MvPhyDxe.inf |  12 +-
>  Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.inf |  16 +-
>  .../NonDiscoverableDxe/NonDiscoverableDxe.inf |   2 +-
>  .../Drivers/SdMmc/XenonDxe/XenonDxe.inf   |   2 +-
>  .../SmbiosPlatformDxe/SmbiosPlatformDxe.inf   |  14 +-
>  .../Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf |   8 +-
>  .../Spi/MvSpiFlashDxe/MvSpiFlashDxe.inf   |   2 +-
>  .../Spi/MvSpiOrionDxe/MvSpiOrionDxe.inf   |   8 +-
>  .../Marvell/Library/ComPhyLib/ComPhyLib.inf   |  28 +--
>  Silicon/Marvell/Library/IcuLib/IcuLib.inf |   4 +-
>  Silicon/Marvell/Library/MppLib/MppLib.inf |  94 
>  .../Marvell/Library/MvGpioLib/MvGpioLib.inf   |   2 +-
>  .../Marvell/Library/UtmiPhyLib/UtmiPhyLib.inf |   2 +-
>  Silicon/Marvell/Marvell.dec   | 208 --
>  .../Include/IndustryStandard/MvSmc.h  |   0
>  .../Include/Library/ArmadaBoardDescLib.h  |   0
>  .../Include/Library/ArmadaIcuLib.h|   0
>  .../Includ

Re: [edk2-devel] [PATCH v6 0/2] Fix and optimize the issue if IPv4 installed after RestEx

2023-11-16 Thread Leif Lindholm
On Wed, Nov 15, 2023 at 22:12:34 +, Igor Kulchytskyy via groups.io wrote:
> Igor Kulchytskyy (2):
>   RedfishPkg: RedfishDiscoverDxe: Fix issue if IPv4 installed after
> RestEx
>   RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow
> 
>  .../RedfishDiscoverDxe/RedfishDiscoverDxe.c   | 225 --
>  .../RedfishDiscoverInternal.h |   4 +
>  2 files changed, 158 insertions(+), 71 deletions(-)

Happy with this. Many thanks for the rework.

For the series:
Acked-by: Leif Lindholm 


> --
> 2.37.1.windows.1
> -The information contained in this message may be confidential and 
> proprietary to American Megatrends (AMI). This communication is intended to 
> be read only by the individual or entity to whom it is addressed or by their 
> designee. If the reader of this message is not the intended recipient, you 
> are on notice that any distribution of this message, in any form, is strictly 
> prohibited. Please promptly notify the sender by reply e-mail or by telephone 
> at 770-246-8600, and then delete or destroy all copies of the transmission.
> 
> 
> 
> 
> 


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




Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow

2023-11-16 Thread Leif Lindholm

Ah, I fell off cc.
Having a look now.

/
Leif

On 2023-11-16 12:23, Igor Kulchytskyy wrote:

Hi Leif,
Already sent it yesterday.
Thank you,
Igor

-Original Message-
From: Leif Lindholm 
Sent: Thursday, November 16, 2023 7:15 AM
To: devel@edk2.groups.io; mike.maslen...@gmail.com; Igor Kulchytskyy 

Cc: Abner Chang ; Nickle Wang 
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: 
RedfishDiscoverDxe: Optimize the Redfish Discover flow


**CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.**

On 2023-11-15 18:27, Mike Maslenkin wrote:

On Wed, Nov 15, 2023 at 4:52 PM Igor Kulchytskyy  wrote:


Hello Leif and Mike,
Let me try to explain the idea of the filtering IP.
That filtering should work only if we know exactly that IP is IPv4 or IPv6 in 
SMBIOS Type 42.

Hm. I've already composed a reply below, but then a returned to this
statement...

Is this a difference in condition between v3 and v5? I came to the
conclusion that at the place we are discussing
SMBIOS table 42h can be absent because
PlatformHostInterfaceInformationReady hasn't been called yet,
so REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN is expected.



And it just helping to reduce the work in case we know the exact type of IP, 
which supposed to be used in BIOS BMC communication.
In that case there is no need to build network interface for the unused IP Type.
On some systems IP address could be dynamic and we will not be able to know the 
version of IP from SMBIOS.
If you see I check HostIpAssignmentType in GetHiIpProtocolType function. And 
return IP type UNKNOWN if it is not static.
If we get an unknown IP type, we should not return from BuildupNetworkInterface 
function, but just proceed and build the network interface for all IPs.
So, later Redfish Discover driver can find the right one.
Based on this logic I'm going to prepare the patch v6.
Thank you,
Igor


Agree.. I was focused on edk2 implementation of
RedfishPlatformHostInterfaceLib and PlatformHostInterfaceBmcUsbNicLib
where HostIpAddressFormat is specified (hardcoded). I guess
HostIpAddressFormat  as well as SMBIOS table 42h must be available
by the time RedfishServiceAcquireService()->DiscoverRedfishHostInterface()
call, while it might be not available at the moment
RedfishDiscoverDriverBindingStart()->BuildupNetworkInterface(). So,
condition from v3 looks correct to me.

My main concern was introduction of defines. Those don't look great.
Those are huge (it even doesn't fit into the screen) and misleading a
bit.
For example:
+#define MAC_COMPARE(ThisNetworkInterface, TargetNetworkInterface)
(CompareMem ((VOID *)>MacAddress,
>MacAddress,
ThisNetworkInterface->HwAddressSize))

The proposed variant is equal to #define MAC_COMPARE(A, B)
(CompareMem ((VOID *)>MacAddress,
>MacAddress,
ThisNetworkInterface->HwAddressSize)), i.e a bit useless.

I would expect it could be declared at least as:
#define MAC_COMPARE(This, Target)  CompareMem ((VOID
*)&(This)->MacAddress, &(Target)->MacAddress, (This)->HwAddressSize)
I.e define should really replace some arguments  also reducing the line length.

BTW: there is a place in ValidateTargetNetworkInterface() where
CompareMem  can be replaced with MAC_COMPARE too.

Also, I found IP6_LINK_EQUAL(Mac1, Mac2) define, that is unused in
edk2. But according to that one, please consider moving "== 0" check
to #define declaration.
But I do not think this macro is required at all, because there are 5
MAC compares left in this module. So, it just brings some
inconsistency.

Agreed that static helper function would be the best.

Leif, do you expect something like this?
STATIC
BOOLEAN
FilterInterface (
IN NETWORK_INTERFACE_PROTOCOL_TYPE ProtocolType,
IN UINT8 HostIpAddressFormat
)
{
// This is based on v5, but according to the comments above
// v3 is correct as it allows
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN

if (ProtocolType == ProtocolTypeTcp4) {
  return IpType != REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP4;
} else if (ProtocolType == ProtocolTypeTcp6) {
  return IpType != REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP6;
}


Yes, this looks ideal.


return false;


Although this should be FALSE (upper-case).


}

and then::

// Get IP Type to filter out unnecessary network protocol if possible
IpType = GetHiIpProtocolType ();

for (Index = 0; Index < ListCount; Index++) {
// Check IP Type and skip an unnecessary network protocol if does not match
   if (FilterInterface (gRequiredProtocol[Index].ProtocolType, IpType)) {


This gives us a big but still readable chunk here, and much neater tests
in the helper than they *could* be either in place or in macros.


  continue;
}


Ship it.

/
  Leif


Regards,
Mike.







-The information contained in this message may be confidential and proprie

Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow

2023-11-16 Thread Leif Lindholm

On 2023-11-15 18:27, Mike Maslenkin wrote:

On Wed, Nov 15, 2023 at 4:52 PM Igor Kulchytskyy  wrote:


Hello Leif and Mike,
Let me try to explain the idea of the filtering IP.
That filtering should work only if we know exactly that IP is IPv4 or IPv6 in 
SMBIOS Type 42.

Hm. I've already composed a reply below, but then a returned to this
statement...

Is this a difference in condition between v3 and v5? I came to the
conclusion that at the place we are discussing
SMBIOS table 42h can be absent because
PlatformHostInterfaceInformationReady hasn't been called yet,
so REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN is expected.



And it just helping to reduce the work in case we know the exact type of IP, 
which supposed to be used in BIOS BMC communication.
In that case there is no need to build network interface for the unused IP Type.
On some systems IP address could be dynamic and we will not be able to know the 
version of IP from SMBIOS.
If you see I check HostIpAssignmentType in GetHiIpProtocolType function. And 
return IP type UNKNOWN if it is not static.
If we get an unknown IP type, we should not return from BuildupNetworkInterface 
function, but just proceed and build the network interface for all IPs.
So, later Redfish Discover driver can find the right one.
Based on this logic I'm going to prepare the patch v6.
Thank you,
Igor


Agree.. I was focused on edk2 implementation of
RedfishPlatformHostInterfaceLib and PlatformHostInterfaceBmcUsbNicLib
where HostIpAddressFormat is specified (hardcoded). I guess
HostIpAddressFormat  as well as SMBIOS table 42h must be available
by the time RedfishServiceAcquireService()->DiscoverRedfishHostInterface()
call, while it might be not available at the moment
RedfishDiscoverDriverBindingStart()->BuildupNetworkInterface(). So,
condition from v3 looks correct to me.

My main concern was introduction of defines. Those don't look great.
Those are huge (it even doesn't fit into the screen) and misleading a
bit.
For example:
+#define MAC_COMPARE(ThisNetworkInterface, TargetNetworkInterface)
(CompareMem ((VOID *)>MacAddress,
>MacAddress,
ThisNetworkInterface->HwAddressSize))

The proposed variant is equal to #define MAC_COMPARE(A, B)
(CompareMem ((VOID *)>MacAddress,
>MacAddress,
ThisNetworkInterface->HwAddressSize)), i.e a bit useless.

I would expect it could be declared at least as:
#define MAC_COMPARE(This, Target)  CompareMem ((VOID
*)&(This)->MacAddress, &(Target)->MacAddress, (This)->HwAddressSize)
I.e define should really replace some arguments  also reducing the line length.

BTW: there is a place in ValidateTargetNetworkInterface() where
CompareMem  can be replaced with MAC_COMPARE too.

Also, I found IP6_LINK_EQUAL(Mac1, Mac2) define, that is unused in
edk2. But according to that one, please consider moving "== 0" check
to #define declaration.
But I do not think this macro is required at all, because there are 5
MAC compares left in this module. So, it just brings some
inconsistency.

Agreed that static helper function would be the best.

Leif, do you expect something like this?
STATIC
BOOLEAN
FilterInterface (
   IN NETWORK_INTERFACE_PROTOCOL_TYPE ProtocolType,
   IN UINT8 HostIpAddressFormat
   )
{
   // This is based on v5, but according to the comments above
   // v3 is correct as it allows
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN

   if (ProtocolType == ProtocolTypeTcp4) {
 return IpType != REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP4;
   } else if (ProtocolType == ProtocolTypeTcp6) {
 return IpType != REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP6;
   }


Yes, this looks ideal.


   return false;


Although this should be FALSE (upper-case).


}

and then::

// Get IP Type to filter out unnecessary network protocol if possible
IpType = GetHiIpProtocolType ();

for (Index = 0; Index < ListCount; Index++) {
   // Check IP Type and skip an unnecessary network protocol if does not match
  if (FilterInterface (gRequiredProtocol[Index].ProtocolType, IpType)) {


This gives us a big but still readable chunk here, and much neater tests 
in the helper than they *could* be either in place or in macros.



 continue;
   }


Ship it.

/
Leif


Regards,
Mike.









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




Re: [edk2-devel] [PATCH v2 15/30] EmbeddedPkg: Add PcdPrePiCpuIoSize width for LOONGARCH64

2023-11-16 Thread Leif Lindholm

On 2023-11-16 08:15, Pedro Falcato wrote:

Leif,

Can you clarify the meaning of PcdPrePiCpuIoSize?


Not out of memory, so let's go exploring.

> I was thinking it's
> supposed to be the size of the port-mapped IO for the
> architecture/platform (as hinted by in X64 = IA32 = 16, and ARM=0),
> but from a quick git grep I can tell that
> 1) most platforms define it to something else (ArmVirt defines it to
> 16, real platforms have a plethora of other values)
> 2) gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize has no internal consumer
> in EmbeddedPkg, but only in ArmPlatformPkg and LoongArchQemuPkg (and
> BeagleBoardPkg's PrePi)

ArmVirtPkg reads this Pcd in
https://github.com/tianocore/edk2/blob/master/ArmVirtPkg/PrePi/PrePi.c#L87
which is in a call to BuildCpuHob, in
https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/Library/PrePiHobLib/Hob.c#L644
which uses the argument to initialize the SizeOfIoSpace in EFI_HOB_CPU
(defined in PI spec).

This eventually gets dug up in
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2559
where it is used to set up the GCD I/O Space Map.
This is also the only way to find out it describes a power of 2. Neither 
the spec nor any of the comment headers in the codebase describe what 
the size means. Tsk, tsk.


Ultimately, this ends up being used in
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c#L175
during InitializePciHostBridge ().

So I'm guessing, and I think it rings a bell, that this is needed to 
enable PCIe I/O resources to be assigned, which *can* be supported on 
Arm and probably Loongson systems through magic memory regions trapping 
accesses in the PCIe IP.



3) Platform/Loongson/LoongArchQemuPkg/Loongson.dec:
gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|0|UINT8|0x00010001 <-- ??


Yeah, it's not great that we don't seem to have a way to trap when Pcd's 
get redefined outside of their own namespace. That happens way too 
frequently. That's certainly a bug.



and FWIW, LoongArch does not seem to have port-mapped IO at all.


So I guess the setting comes down to whether that is considered to be 
the expected behaviour on Loongson platforms or not. About which I have 
no idea and am happy to trust the author on :)


/
Leif



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




Re: [edk2-devel] [PATCH v2 15/30] EmbeddedPkg: Add PcdPrePiCpuIoSize width for LOONGARCH64

2023-11-15 Thread Leif Lindholm

On 2023-11-06 03:29, Chao Li wrote:

Added LoongArch64 architecture CPU IO width.

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

Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
Cc: Abner Chang 
Cc: Daniel Schaefer 
Signed-off-by: Chao Li 


Reviewed-by: Leif Lindholm 

I note that as a result of this we are now definining this token 
individually for 5 different architectures, in order to provide two 
different default values. We should probably look at consolidating 
those, but that responsibility doesn't have to land on this set.


/
Leif


---
  EmbeddedPkg/EmbeddedPkg.dec | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
index 341ef5e6a6..241d4f3acc 100644
--- a/EmbeddedPkg/EmbeddedPkg.dec
+++ b/EmbeddedPkg/EmbeddedPkg.dec
@@ -165,6 +165,9 @@
  [PcdsFixedAtBuild.X64]
gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16|UINT8|0x0011
  
+[PcdsFixedAtBuild.LOONGARCH64]

+  gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize|16|UINT8|0x0011
+
  [PcdsFixedAtBuild.common, PcdsDynamic.common]
#
# Value to add to a host address to obtain a device address, using




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




Re: [edk2-devel] [PATCH v3 1/6] ArmPkg/ArmLib: Move ArmReadIdAA64Isar0() to ArmLib

2023-11-15 Thread Leif Lindholm
Hi Pierre,

I apologise for asking this level of rework on a v3, but I would much
prefer if we could add these definitions in
ArmPkg/Include/Chipset/AArch64.h, add helper functions in AArch64Lib*
and declare those in ArmLib.h - and then use those instead of doing
the direct ID register accesses in AArch64Cap.c in 5/6.

This follows the pattern that is used in that library already (and
that we want to expand on).

Regards,

Leif

On Fri, Nov 10, 2023 at 11:48:05 +0100, Pierre Gondois wrote:
> Add ArmReadIdAA64Isar0() to ArmLib along with macros
> to read specific register fields.
> 
> Signed-off-by: Pierre Gondois 
> ---
>  ArmPkg/Include/Library/ArmLib.h| 68 ++
>  ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h |  6 --
>  2 files changed, 68 insertions(+), 6 deletions(-)
> 
> diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
> index 6aa8a48f07f3..1edaa8d45962 100644
> --- a/ArmPkg/Include/Library/ArmLib.h
> +++ b/ArmPkg/Include/Library/ArmLib.h
> @@ -805,6 +805,74 @@ ArmHasEte (
>VOID
>);
>  
> +//
> +// Bit shifts for the ID_AA64ISAR0_EL1 register.
> +//
> +#define ARM_ID_AA64ISAR0_EL1_AES_SHIFT (4U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA1_SHIFT(8U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA2_SHIFT(12U)
> +#define ARM_ID_AA64ISAR0_EL1_CRC32_SHIFT   (16U)
> +#define ARM_ID_AA64ISAR0_EL1_ATOMIC_SHIFT  (20U)
> +#define ARM_ID_AA64ISAR0_EL1_RDM_SHIFT (28U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA3_SHIFT(32U)
> +#define ARM_ID_AA64ISAR0_EL1_SM3_SHIFT (36U)
> +#define ARM_ID_AA64ISAR0_EL1_SM4_SHIFT (40U)
> +#define ARM_ID_AA64ISAR0_EL1_DP_SHIFT  (44U)
> +#define ARM_ID_AA64ISAR0_EL1_FHM_SHIFT (48U)
> +#define ARM_ID_AA64ISAR0_EL1_TS_SHIFT  (52U)
> +#define ARM_ID_AA64ISAR0_EL1_TLB_SHIFT (56U)
> +#define ARM_ID_AA64ISAR0_EL1_RNDR_SHIFT(60U)
> +
> +//
> +// Bit masks for the ID_AA64ISAR0_EL1 fields.
> +//
> +#define ARM_ID_AA64ISAR0_EL1_AES_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SHA1_MASK(0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SHA2_MASK(0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_CRC32_MASK   (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_ATOMIC_MASK  (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_RDM_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SHA3_MASK(0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SM3_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SM4_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_DP_MASK  (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_FHM_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_TS_MASK  (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_TLB_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_RNDR_MASK(0xFU)
> +
> +//
> +// Bit masks for the ID_AA64ISAR0_EL1 field values.
> +//
> +#define ARM_ID_AA64ISAR0_EL1_AES_FEAT_AES_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_AES_FEAT_PMULL_MASK  (0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA1_FEAT_SHA1_MASK  (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA2_FEAT_SHA256_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA2_FEAT_SHA512_MASK(0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_CRC32_HAVE_CRC32_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_ATOMIC_FEAT_LSE_MASK (0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_RDM_FEAT_RDM_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA3_FEAT_SHA3_MASK  (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SM3_FEAT_SM3_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SM4_FEAT_SM4_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_DP_FEAT_DOTPROD_MASK (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_FHM_FEAT_FHM_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_TS_FEAT_FLAGM_MASK   (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_TS_FEAT_FLAGM2_MASK  (0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_TLB_FEAT_TLBIOS_MASK (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_TLB_FEAT_TLBIRANGE_MASK  (0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_RNDR_FEAT_RNG_MASK   (0x1U)
> +
> +/** Read AA64Isar0 register.
> +
> +   @return AA64Isar0's register value.
> +**/
> +UINTN
> +EFIAPI
> +ArmReadIdAA64Isar0 (
> +  VOID
> +  );
> +
>  #endif // MDE_CPU_AARCH64
>  
>  #ifdef MDE_CPU_ARM
> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h 
> b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h
> index 6380a019ddc5..07181d940bdd 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h
> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Lib.h
> @@ -50,12 +50,6 @@ ArmReadIdAA64Dfr1 (
>VOID
>);
>  
> -UINTN
> -EFIAPI
> -ArmReadIdAA64Isar0 (
> -  VOID
> -  );
> -
>  UINTN
>  EFIAPI
>  ArmReadIdAA64Isar1 (
> -- 
> 2.25.1
> 


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




Re: [edk2-devel] [PATCH] DynamicTablesPkg: Fix ETE _UID Creation

2023-11-15 Thread Leif Lindholm
On Wed, Nov 15, 2023 at 16:24:46 +, Ashish Singhal via groups.io wrote:
> On Tue, Nov 14, 2023 at 20:19:04 -0700, Ashish Singhal wrote:
> > Just like CPU _UID, ETE UID also needs to be unique so
> > use AcpiProcessorUid instead of CpuName
> >
> > Signed-off-by: Ashish Singhal 
> > ---
> >  .../Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git 
> > a/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c
> >  
> > b/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c
> > index 8228c7845a..724f33c660 100644
> > --- 
> > a/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c
> > +++ 
> > b/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c
> > @@ -359,6 +359,7 @@ CreateAmlCpcNode (
> >
> >@param [in]  GeneratorThe SSDT Cpu Topology generator.
> >@param [in]  ParentNode   Parent node to attach the Cpu node to.
> > +  @param [in]  GicCInfo CM_ARM_GICC_INFO object used to create the 
> > node.
> >@param [in]  CpuName  Value used to generate the node name.
> 
> Can that replace both uses of CpuName in the function (so it can be
> dropped), or does
> 
>   Status = WriteAslName ('E', CpuName, AslName);
> 
> have other requirements?
> 
> /
> Leif
> 
> Hello Leif,
> 
> CPU Name can be more logical, and you may have the same CPU name in
> different clusters for example. _UID however needs to be unique.

Sure, makes sense.
I just dislike functions that take too many arguments, so wanted to
make sure we weren't missing an opportunity to drop one as we were
adding this new one.
Never mind me :)

Thanks,

Leif

> Thanks
> Ashish
> 
> >@param [out] EtNodePtr   If not NULL, return the created Cpu node.
> >
> > @@ -372,6 +373,7 @@ EFIAPI
> >  CreateAmlEtd (
> >IN   ACPI_CPU_TOPOLOGY_GENERATOR  *Generator,
> >IN   AML_NODE_HANDLE  ParentNode,
> > +  IN   CM_ARM_GICC_INFO *GicCInfo,
> >IN   UINT32   CpuName,
> >OUT  AML_OBJECT_NODE_HANDLE   *EtNodePtr OPTIONAL
> >)
> > @@ -397,7 +399,7 @@ CreateAmlEtd (
> >
> >Status = AmlCodeGenNameInteger (
> >   "_UID",
> > - CpuName,
> > + GicCInfo->AcpiProcessorUid,
> >   EtNode,
> >   NULL
> >   );
> > @@ -474,6 +476,7 @@ CreateAmlEtNode (
> >Status = CreateAmlEtd (
> >   Generator,
> >   Node,
> > + GicCInfo,
> >   CpuName,
> >   NULL
> >   );
> > --
> > 2.17.1
> >
> 
> 
> 
> 
> 


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




Re: [edk2-devel] [PATCH] DynamicTablesPkg: Fix ETE _UID Creation

2023-11-15 Thread Leif Lindholm
On Tue, Nov 14, 2023 at 20:19:04 -0700, Ashish Singhal wrote:
> Just like CPU _UID, ETE UID also needs to be unique so
> use AcpiProcessorUid instead of CpuName
> 
> Signed-off-by: Ashish Singhal 
> ---
>  .../Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c
>  
> b/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c
> index 8228c7845a..724f33c660 100644
> --- 
> a/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c
> +++ 
> b/DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyGenerator.c
> @@ -359,6 +359,7 @@ CreateAmlCpcNode (
>  
>@param [in]  GeneratorThe SSDT Cpu Topology generator.
>@param [in]  ParentNode   Parent node to attach the Cpu node to.
> +  @param [in]  GicCInfo CM_ARM_GICC_INFO object used to create the node.
>@param [in]  CpuName  Value used to generate the node name.

Can that replace both uses of CpuName in the function (so it can be
dropped), or does

  Status = WriteAslName ('E', CpuName, AslName);

have other requirements?

/
Leif

>@param [out] EtNodePtr   If not NULL, return the created Cpu node.
>  
> @@ -372,6 +373,7 @@ EFIAPI
>  CreateAmlEtd (
>IN   ACPI_CPU_TOPOLOGY_GENERATOR  *Generator,
>IN   AML_NODE_HANDLE  ParentNode,
> +  IN   CM_ARM_GICC_INFO *GicCInfo,
>IN   UINT32   CpuName,
>OUT  AML_OBJECT_NODE_HANDLE   *EtNodePtr OPTIONAL
>)
> @@ -397,7 +399,7 @@ CreateAmlEtd (
>  
>Status = AmlCodeGenNameInteger (
>   "_UID",
> - CpuName,
> + GicCInfo->AcpiProcessorUid,
>   EtNode,
>   NULL
>   );
> @@ -474,6 +476,7 @@ CreateAmlEtNode (
>Status = CreateAmlEtd (
>   Generator,
>   Node,
> + GicCInfo,
>   CpuName,
>   NULL
>   );
> -- 
> 2.17.1
> 


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




Re: [edk2-devel] [PATCH 1/1] Maintainers: add myself as reviewer for sbsa-ref

2023-11-15 Thread Leif Lindholm
On Mon, May 15, 2023 at 16:33:52 +0200, Marcin Juszkiewicz wrote:
> At Linaro I work on sbsa-ref, know direction it goes.
> 
> May not get code details each time.
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 
Pushed as 4b07df2e6f38.

> ---
>  Maintainers.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 24918d1c6ede..d1d75fe6c940 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -375,6 +375,7 @@ M: Ard Biesheuvel 
>  M: Leif Lindholm 
>  R: Graeme Gregory 
>  R: Radoslaw Biernacki 
> +R: Marcin Juszkiewicz 
>  
>  Raspberry Pi platforms and silicon
>  F: Platform/RaspberryPi/
> -- 
> 2.40.1
> 


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




Re: [edk2-devel] [PATCH edk2-platforms 1/1] Maintainers: fix Phytium entry

2023-11-15 Thread Leif Lindholm
On Wed, Nov 15, 2023 at 13:48:10 +0100, Marcin Juszkiewicz wrote:
> Signed-off-by: Marcin Juszkiewicz 

Oops.
Reviewed-by: Leif Lindholm 
Pushed as eac04509004e.
Thanks!

> ---
>  Maintainers.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index affb2632e0db..7bfd3c850a30 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -407,7 +407,7 @@ M: Daniel Schaefer 
>  
>  Phytium platforms and silicon
>  F: Platform/Phytium/
> -F: Silicon/silicon/
> +F: Silicon/Phytium/
>  M: Leif Lindholm 
>  R: Peng Xie 
>  R: Ling Jia 
> -- 
> 2.41.0
> 


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




Re: [edk2-devel] [PATCH edk2-platforms 1/1] set WritePolicyValid for all cache types

2023-11-15 Thread Leif Lindholm
On Wed, Nov 15, 2023 at 13:46:08 +0100, Marcin Juszkiewicz wrote:
> acpiview complains:
> 
> ERROR: On Arm based systems, all cache properties must be provided in
> the cache type structure. Missing 'Write Policy Valid' flag.
> 
> ACPI specification says:
> 
> > Set to 1 if the write policy attribute described is valid. A value 
> > of 0 indicates that, where possible, processor architecture specific
> > discovery mechanisms should be used to ascertain the value of this
> > attribute.

Thanks for finding this. This is definitely an error (and I expect
this is a single original error that has then been copied around to
other platforms, so important to fix all of them).

But I can see how that mistake was made. The ACPI specification makes
no reference to what write policy means for instruction caches
(i.e. nothing).

However, the ACPI specification *does* make it crystal clear that "On
Arm-based systems, all cache properties must be provided in the
table.". So indicating that one of the entries is invalid is
... invalid.
So apparently all Arm instruction caches are Write-back. Lol.

> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 

I'll leave this one for a day or so before merging to allow
reviewers/maintainers to see and respond.

Regards,

Leif

> ---
>  Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h | 2 +-
>  Platform/RaspberryPi/AcpiTables/Pptt.aslc | 2 +-
>  Silicon/Marvell/Armada7k8k/AcpiTables/Pptt.aslc   | 2 +-
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Pptt.aslc | 2 +-
>  Silicon/Phytium/FT2000-4Pkg/Drivers/AcpiTables/Pptt.aslc  | 2 +-
>  Silicon/Socionext/SynQuacer/AcpiTables/Pptt.aslc  | 2 +-
>  6 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h 
> b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> index 983d17f6fa50..61d8bce8c959 100644
> --- a/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> +++ b/Silicon/Qemu/SbsaQemu/Include/IndustryStandard/SbsaQemuAcpi.h
> @@ -126,7 +126,7 @@ typedef struct {
>1,   /* AssociativityValid */  
>   \
>1,   /* AllocationTypeValid */ 
>   \
>1,   /* CacheTypeValid */  
>   \
> -  0,   /* WritePolicyValid */
>   \
> +  1,   /* WritePolicyValid */
>   \
>1,   /* LineSizeValid */   
>   \
>  },   
>   \
>  0, /* NextLevelOfCache */
>   \
> diff --git a/Platform/RaspberryPi/AcpiTables/Pptt.aslc 
> b/Platform/RaspberryPi/AcpiTables/Pptt.aslc
> index a52bc5a31adf..b80f5ff1e057 100644
> --- a/Platform/RaspberryPi/AcpiTables/Pptt.aslc
> +++ b/Platform/RaspberryPi/AcpiTables/Pptt.aslc
> @@ -114,7 +114,7 @@ typedef struct {
>1,  /* AssociativityValid */   
>   \
>1,  /* AllocationTypeValid */  
>   \
>1,  /* CacheTypeValid */   
>   \
> -  0,  /* WritePolicyValid */ 
>   \
> +  1,  /* WritePolicyValid */ 
>   \
>1,  /* LineSizeValid */
>   \
>  },   
>   \
>  0,/* NextLevelOfCache */ 
>   \
> diff --git a/Silicon/Marvell/Armada7k8k/AcpiTables/Pptt.aslc 
> b/Silicon/Marvell/Armada7k8k/AcpiTables/Pptt.aslc
> index e03bfcd6211d..f3a9b90fb564 100644
> --- a/Silicon/Marvell/Armada7k8k/AcpiTables/Pptt.aslc
> +++ b/Silicon/Marvell/Armada7k8k/AcpiTables/Pptt.aslc
> @@ -94,7 +94,7 @@ typedef struct {
>1,  /* AssociativityValid */   
>   \
>1,  /* AllocationTypeValid */  
>   \
>1,  /* CacheTypeValid */   
>   \
> -  0,  /* WritePolicyValid */ 
>   \
> +  1,  /* WritePolicyValid */ 
>   \
>1,  /* LineSizeValid */
>   \
>  },

Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow

2023-11-15 Thread Leif Lindholm

On 2023-11-14 23:52, Mike Maslenkin wrote:

On Tue, Nov 14, 2023 at 9:57 PM Igor Kulchytskyy via groups.io
 wrote:


Hi Leif,
Please see my comments below.
Thank you,
Igor


-Original Message-
From: Leif Lindholm 
Sent: Tuesday, November 14, 2023 12:26 PM
To: devel@edk2.groups.io; Igor Kulchytskyy 
Cc: Abner Chang ; Nickle Wang 
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: 
RedfishDiscoverDxe: Optimize the Redfish Discover flow


**CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.**

On 2023-11-14 14:28, Igor Kulchytskyy via groups.io wrote:

Filter out the network interfaces which are not supported by
Redfish Host Interface.

Cc: Abner Chang 
Cc: Nickle Wang 
Signed-off-by: Igor Kulchytskyy 
---
   RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c  | 163 
++--
   RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h |   6 +
   2 files changed, 120 insertions(+), 49 deletions(-)

diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
index 0f622e05a9..ae83cd3c97 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c




@@ -1601,10 +1681,22 @@ BuildupNetworkInterface (
 EFI_REDFISH_DISCOVER_REST_EX_INSTANCE_INTERNAL   *RestExInstance;
 EFI_TPL  OldTpl;
 BOOLEAN  
NewNetworkInterfaceInstalled;
+  UINT8IpType;
+  UINTNListCount;

+  ListCount= (sizeof (gRequiredProtocol) / sizeof 
(REDFISH_DISCOVER_REQUIRED_PROTOCOL));
 NewNetworkInterfaceInstalled = FALSE;
 Index= 0;
-  do {
+
+  // Get IP Type to filter out unnecessary network protocol if possible
+  IpType = GetHiIpProtocolType ();
+
+  for (Index = 0; Index < ListCount; Index++) {
+// Check IP Type and skip an unnecessary network protocol if does not match
+if (IS_TCP4_MATCH (IpType) || IS_TCP6_MATCH (IpType)) {


The logic of these macros is inverted compared to their names, though.

You want this test to read
if (!IS_TCP4_MATCH (IpType) && !IS_TCP6_MATCH (IpType)) {


+  continue;
+}
+
   Status = gBS->OpenProtocol (
   // Already in list?
   ControllerHandle,



diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
index 01454acc1d..3093eea0d5 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
@@ -39,6 +39,12 @@
   #define REDFISH_DISCOVER_VERSION0x0001
   #define EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_TPL  TPL_NOTIFY

+#define MAC_COMPARE(ThisNetworkInterface, TargetNetworkInterface)  (CompareMem ((VOID 
*)>MacAddress, >MacAddress, 
ThisNetworkInterface->HwAddressSize))
+#define VALID_TCP6(TargetNetworkInterface, ThisNetworkInterface)   
(TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface->NetworkProtocolType 
== ProtocolTypeTcp6))
+#define VALID_TCP4(TargetNetworkInterface, ThisNetworkInterface)   
(!TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface->NetworkProtocolType 
== ProtocolTypeTcp4))
+#define IS_TCP4_MATCH(IpType)  
((gRequiredProtocol[Index].ProtocolType == ProtocolTypeTcp4) && (IpType != 
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP4))
+#define IS_TCP6_MATCH(IpType)  
((gRequiredProtocol[Index].ProtocolType == ProtocolTypeTcp6) && (IpType != 
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP6))


And these macros to test for ==, not !=


Igor: First version tested "==", but we agreed that it may not work if we have 
a wrong value of IpType.

Otherwise the code reads like it does the opposite of what it does.

(You could also keep the logic and call the macros IS_TCP#_MISMATCH, but
that feels a bit convoluted.)

Igor: I would prefer to go with IS_TCP#_MISMATCH names.

Regards,

Leif


Sorry, could I add my 2 cents?


Always!


For me all newly added defines looks bad, just because those
implicitly use reference to a global variable
plus local variable state (i.e  current cycle index).


Fair. But the original test is basically line noise.
I will point out that gRequiredProtocol appears to be misnamed to start 
with. It's only used in this file, so ought to be mRequiredProtocol.

However, your point still stands.


Could we rewrite code in a simple and straight forward manner, similar to:

if (IpType == REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN) {
   // The protocol type is not specified in SMBIOS table type 42h
   return EFI_U

edk2-stable202311 Code freeze process violation Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow

2023-11-15 Thread Leif Lindholm

On 2023-11-15 03:55, Chang, Abner via groups.io wrote:

[AMD Official Use Only - General]

Just let you know I just merged this change. Igor can help to follow up the 
suggestions given by Leif and Mike.


I was under the impression merging was disabled for everyone except Mike 
and Liming during code freeze specifically to avoid this situation.

Apparently, that isn't working.

Regardless, this is a violation of the stable tag process.
Liming: can you please revert these commits?

Regards,

Leif


Thanks
Abner


-Original Message-
From: Chang, Abner
Sent: Wednesday, November 15, 2023 9:20 AM
To: Mike Maslenkin ; devel@edk2.groups.io;
ig...@ami.com
Cc: Leif Lindholm ; Nickle Wang

Subject: RE: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe:
Optimize the Redfish Discover flow

Hi Mike and Leif,
Thanks for your comments on this change. As we are rushing to get this
change to be pulled in stable release 202312 this week, I will just merge this
code to master branch and let the discussing keeps going.
I think there is no functionality difference base on your suggestions, but it's
about the coding practice and readability.

Hi Igor,
Could you please resend the V6 after stable tag is released if Mike and Leif's
comment is reasonable to you?

Thanks
Abner


-Original Message-
From: Mike Maslenkin 
Sent: Wednesday, November 15, 2023 7:53 AM
To: devel@edk2.groups.io; ig...@ami.com
Cc: Leif Lindholm ; Chang, Abner
; Nickle Wang 
Subject: Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe:
Optimize the Redfish Discover flow

Caution: This message originated from an External Source. Use proper

caution

when opening attachments, clicking links, or responding.


On Tue, Nov 14, 2023 at 9:57 PM Igor Kulchytskyy via groups.io
 wrote:


Hi Leif,
Please see my comments below.
Thank you,
Igor


-Original Message-
From: Leif Lindholm 
Sent: Tuesday, November 14, 2023 12:26 PM
To: devel@edk2.groups.io; Igor Kulchytskyy 
Cc: Abner Chang ; Nickle Wang



Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg:

RedfishDiscoverDxe: Optimize the Redfish Discover flow



**CAUTION: The e-mail below is from an external source. Please exercise

caution before opening attachments, clicking links, or following guidance.**


On 2023-11-14 14:28, Igor Kulchytskyy via groups.io wrote:

Filter out the network interfaces which are not supported by
Redfish Host Interface.

Cc: Abner Chang 
Cc: Nickle Wang 
Signed-off-by: Igor Kulchytskyy 
---
   RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c  | 163

++--

   RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h |   6 +
   2 files changed, 120 insertions(+), 49 deletions(-)

diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c

b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c

index 0f622e05a9..ae83cd3c97 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c




@@ -1601,10 +1681,22 @@ BuildupNetworkInterface (
 EFI_REDFISH_DISCOVER_REST_EX_INSTANCE_INTERNAL

*RestExInstance;

 EFI_TPL  OldTpl;
 BOOLEAN  
NewNetworkInterfaceInstalled;
+  UINT8IpType;
+  UINTNListCount;

+  ListCount= (sizeof (gRequiredProtocol) / sizeof

(REDFISH_DISCOVER_REQUIRED_PROTOCOL));

 NewNetworkInterfaceInstalled = FALSE;
 Index= 0;
-  do {
+
+  // Get IP Type to filter out unnecessary network protocol if possible
+  IpType = GetHiIpProtocolType ();
+
+  for (Index = 0; Index < ListCount; Index++) {
+// Check IP Type and skip an unnecessary network protocol if does

not

match

+if (IS_TCP4_MATCH (IpType) || IS_TCP6_MATCH (IpType)) {


The logic of these macros is inverted compared to their names, though.

You want this test to read
if (!IS_TCP4_MATCH (IpType) && !IS_TCP6_MATCH (IpType)) {


+  continue;
+}
+
   Status = gBS->OpenProtocol (
   // Already in list?
   ControllerHandle,



diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h

b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h

index 01454acc1d..3093eea0d5 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
@@ -39,6 +39,12 @@
   #define REDFISH_DISCOVER_VERSION0x0001
   #define EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_TPL

TPL_NOTIFY


+#define MAC_COMPARE(ThisNetworkInterface,

TargetNetworkInterface)

(CompareMem ((VOID *)>MacAddress,
>MacAddress, ThisNetworkInterface-

HwAddressSize))

+#define VALID_TCP6(TargetNetworkInterface, ThisNetworkInterface)

(TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface-

NetworkProtocolType == Protocol

Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow

2023-11-15 Thread Leif Lindholm

On 2023-11-15 01:19, Chang, Abner via groups.io wrote:

[AMD Official Use Only - General]

Hi Mike and Leif,
Thanks for your comments on this change. As we are rushing to get this change 
to be pulled in stable release 202312 this week, I will just merge this code to 
master branch and let the discussing keeps going.
I think there is no functionality difference base on your suggestions, but it's 
about the coding practice and readability.


Readability is not optional.
If the fix is important enough, we need to delay the stable tag, not 
ignore the process.


/
Leif



Hi Igor,
Could you please resend the V6 after stable tag is released if Mike and Leif's 
comment is reasonable to you?

Thanks
Abner


-Original Message-
From: Mike Maslenkin 
Sent: Wednesday, November 15, 2023 7:53 AM
To: devel@edk2.groups.io; ig...@ami.com
Cc: Leif Lindholm ; Chang, Abner
; Nickle Wang 
Subject: Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe:
Optimize the Redfish Discover flow

Caution: This message originated from an External Source. Use proper caution
when opening attachments, clicking links, or responding.


On Tue, Nov 14, 2023 at 9:57 PM Igor Kulchytskyy via groups.io
 wrote:


Hi Leif,
Please see my comments below.
Thank you,
Igor


-Original Message-
From: Leif Lindholm 
Sent: Tuesday, November 14, 2023 12:26 PM
To: devel@edk2.groups.io; Igor Kulchytskyy 
Cc: Abner Chang ; Nickle Wang



Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg:

RedfishDiscoverDxe: Optimize the Redfish Discover flow



**CAUTION: The e-mail below is from an external source. Please exercise

caution before opening attachments, clicking links, or following guidance.**


On 2023-11-14 14:28, Igor Kulchytskyy via groups.io wrote:

Filter out the network interfaces which are not supported by
Redfish Host Interface.

Cc: Abner Chang 
Cc: Nickle Wang 
Signed-off-by: Igor Kulchytskyy 
---
   RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c  | 163

++--

   RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h |   6 +
   2 files changed, 120 insertions(+), 49 deletions(-)

diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c

b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c

index 0f622e05a9..ae83cd3c97 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c




@@ -1601,10 +1681,22 @@ BuildupNetworkInterface (
 EFI_REDFISH_DISCOVER_REST_EX_INSTANCE_INTERNAL

*RestExInstance;

 EFI_TPL  OldTpl;
 BOOLEAN  
NewNetworkInterfaceInstalled;
+  UINT8IpType;
+  UINTNListCount;

+  ListCount= (sizeof (gRequiredProtocol) / sizeof

(REDFISH_DISCOVER_REQUIRED_PROTOCOL));

 NewNetworkInterfaceInstalled = FALSE;
 Index= 0;
-  do {
+
+  // Get IP Type to filter out unnecessary network protocol if possible
+  IpType = GetHiIpProtocolType ();
+
+  for (Index = 0; Index < ListCount; Index++) {
+// Check IP Type and skip an unnecessary network protocol if does not

match

+if (IS_TCP4_MATCH (IpType) || IS_TCP6_MATCH (IpType)) {


The logic of these macros is inverted compared to their names, though.

You want this test to read
if (!IS_TCP4_MATCH (IpType) && !IS_TCP6_MATCH (IpType)) {


+  continue;
+}
+
   Status = gBS->OpenProtocol (
   // Already in list?
   ControllerHandle,



diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h

b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h

index 01454acc1d..3093eea0d5 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
@@ -39,6 +39,12 @@
   #define REDFISH_DISCOVER_VERSION0x0001
   #define EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_TPL  TPL_NOTIFY

+#define MAC_COMPARE(ThisNetworkInterface, TargetNetworkInterface)

(CompareMem ((VOID *)>MacAddress,
>MacAddress, ThisNetworkInterface-

HwAddressSize))

+#define VALID_TCP6(TargetNetworkInterface, ThisNetworkInterface)

(TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface-

NetworkProtocolType == ProtocolTypeTcp6))

+#define VALID_TCP4(TargetNetworkInterface, ThisNetworkInterface)

(!TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface-

NetworkProtocolType == ProtocolTypeTcp4))

+#define IS_TCP4_MATCH(IpType)

((gRequiredProtocol[Index].ProtocolType == ProtocolTypeTcp4) && (IpType !=
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP4))

+#define IS_TCP6_MATCH(IpType)

((gRequiredProtocol[Index].ProtocolType == ProtocolTypeTcp6) && (IpType !=
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP6))


And these macros to test for ==, not !=


Igor: Fir

Re: [edk2-devel] [PATCH v5 2/2] RedfishPkg: RedfishDiscoverDxe: Optimize the Redfish Discover flow

2023-11-14 Thread Leif Lindholm

On 2023-11-14 14:28, Igor Kulchytskyy via groups.io wrote:

Filter out the network interfaces which are not supported by
Redfish Host Interface.

Cc: Abner Chang 
Cc: Nickle Wang 
Signed-off-by: Igor Kulchytskyy 
---
  RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c  | 163 
++--
  RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h |   6 +
  2 files changed, 120 insertions(+), 49 deletions(-)

diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
index 0f622e05a9..ae83cd3c97 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c




@@ -1601,10 +1681,22 @@ BuildupNetworkInterface (
EFI_REDFISH_DISCOVER_REST_EX_INSTANCE_INTERNAL   *RestExInstance;
EFI_TPL  OldTpl;
BOOLEAN  
NewNetworkInterfaceInstalled;
+  UINT8IpType;
+  UINTNListCount;

+  ListCount= (sizeof (gRequiredProtocol) / sizeof 
(REDFISH_DISCOVER_REQUIRED_PROTOCOL));
NewNetworkInterfaceInstalled = FALSE;
Index= 0;
-  do {
+
+  // Get IP Type to filter out unnecessary network protocol if possible
+  IpType = GetHiIpProtocolType ();
+
+  for (Index = 0; Index < ListCount; Index++) {
+// Check IP Type and skip an unnecessary network protocol if does not match
+if (IS_TCP4_MATCH (IpType) || IS_TCP6_MATCH (IpType)) {


The logic of these macros is inverted compared to their names, though.

You want this test to read
  if (!IS_TCP4_MATCH (IpType) && !IS_TCP6_MATCH (IpType)) {


+  continue;
+}
+
  Status = gBS->OpenProtocol (
  // Already in list?
  ControllerHandle,



diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
index 01454acc1d..3093eea0d5 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverInternal.h
@@ -39,6 +39,12 @@
  #define REDFISH_DISCOVER_VERSION0x0001
  #define EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_TPL  TPL_NOTIFY

+#define MAC_COMPARE(ThisNetworkInterface, TargetNetworkInterface)  (CompareMem ((VOID 
*)>MacAddress, >MacAddress, 
ThisNetworkInterface->HwAddressSize))
+#define VALID_TCP6(TargetNetworkInterface, ThisNetworkInterface)   
(TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface->NetworkProtocolType 
== ProtocolTypeTcp6))
+#define VALID_TCP4(TargetNetworkInterface, ThisNetworkInterface)   
(!TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface->NetworkProtocolType 
== ProtocolTypeTcp4))
+#define IS_TCP4_MATCH(IpType)  
((gRequiredProtocol[Index].ProtocolType == ProtocolTypeTcp4) && (IpType != 
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP4))
+#define IS_TCP6_MATCH(IpType)  
((gRequiredProtocol[Index].ProtocolType == ProtocolTypeTcp6) && (IpType != 
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP6))


And these macros to test for ==, not !=

Otherwise the code reads like it does the opposite of what it does.

(You could also keep the logic and call the macros IS_TCP#_MISMATCH, but 
that feels a bit convoluted.)


Regards,

Leif


+
  //
  // GUID definitions
  //
--
2.37.1.windows.1
-The information contained in this message may be confidential and proprietary 
to American Megatrends (AMI). This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited. Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.









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




[edk2-devel] [PATCH v3 4/5] BaseTools/Scripts/GetMaintainer: Handle reviewer only case

2023-11-10 Thread Leif Lindholm
From: Michael D Kinney 

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

If a package only has reviewers and no maintainers, then also
return the  maintainers.

In order to detect this case, get_maintainers() is updated to
return maintainers, reviews, and lists separately instead of
a single merged list.  This also allows this module to be used
by other scripts that need to distinguish between maintainers,
reviewers, and lists.

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
---
 BaseTools/Scripts/GetMaintainer.py | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Scripts/GetMaintainer.py 
b/BaseTools/Scripts/GetMaintainer.py
index cb3aadbbefb1..1361fb6c0e30 100644
--- a/BaseTools/Scripts/GetMaintainer.py
+++ b/BaseTools/Scripts/GetMaintainer.py
@@ -76,6 +76,7 @@ def get_section_maintainers(path, section):
 """Returns a list with email addresses to any M: and R: entries
matching the provided path in the provided section."""
 maintainers = []
+reviewers = []
 lists = []
 nowarn_status = ['Supported', 'Maintained']
 
@@ -83,12 +84,18 @@ def get_section_maintainers(path, section):
 for status in section['status']:
 if status not in nowarn_status:
 print('WARNING: Maintained status for "%s" is \'%s\'!' % 
(path, status))
-for address in section['maintainer'], section['reviewer']:
+for address in section['maintainer']:
 # Convert to list if necessary
 if isinstance(address, list):
 maintainers += address
 else:
 maintainers += [address]
+for address in section['reviewer']:
+# Convert to list if necessary
+if isinstance(address, list):
+reviewers += address
+else:
+reviewers += [address]
 for address in section['list']:
 # Convert to list if necessary
 if isinstance(address, list):
@@ -96,16 +103,18 @@ def get_section_maintainers(path, section):
 else:
 lists += [address]
 
-return {'maintainers': maintainers, 'lists': lists}
+return {'maintainers': maintainers, 'reviewers': reviewers, 'lists': lists}
 
 def get_maintainers(path, sections, level=0):
 """For 'path', iterates over all sections, returning maintainers
for matching ones."""
 maintainers = []
+reviewers = []
 lists = []
 for section in sections:
 recipients = get_section_maintainers(path, section)
 maintainers += recipients['maintainers']
+reviewers += recipients['reviewers']
 lists += recipients['lists']
 
 if not maintainers:
@@ -115,13 +124,14 @@ def get_maintainers(path, sections, level=0):
 if level == 0:
 recipients = get_maintainers('', sections, level=level + 
1)
 maintainers += recipients['maintainers']
+reviewers += recipients['reviewers']
 lists += recipients['lists']
 else:
 print("No  maintainers set for project.")
 if not maintainers:
 return None
 
-return {'maintainers': maintainers, 'lists': lists}
+return {'maintainers': maintainers, 'reviewers': reviewers, 'lists': lists}
 
 def parse_maintainers_line(line):
 """Parse one line of Maintainers.txt, returning any match group and its 
key."""
@@ -187,7 +197,7 @@ if __name__ == '__main__':
 for file in FILES:
 print(file)
 recipients = get_maintainers(file, SECTIONS)
-ADDRESSES += recipients['maintainers'] + recipients['lists']
+ADDRESSES += recipients['maintainers'] + recipients['reviewers'] + 
recipients['lists']
 
 for address in list(OrderedDict.fromkeys(ADDRESSES)):
 if '<' in address and '>' in address:
-- 
2.39.2



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




[edk2-devel] [PATCH v3 5/5] BaseTools/Scripts/GetMaintainer: Sort output addresses

2023-11-10 Thread Leif Lindholm
From: Michael D Kinney 

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

Sort the list of output addresses alphabetically so this
script produces the same output even if the order of patches
in a patch series is modified such that that order of files
processed by this script changes.

Use set() logic instead of OrderedDict to accumulate the
list of unique addresses that are sorted alphabetically.

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
---
 BaseTools/Scripts/GetMaintainer.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Scripts/GetMaintainer.py 
b/BaseTools/Scripts/GetMaintainer.py
index 1361fb6c0e30..8097ba4e7bd6 100644
--- a/BaseTools/Scripts/GetMaintainer.py
+++ b/BaseTools/Scripts/GetMaintainer.py
@@ -192,14 +192,16 @@ if __name__ == '__main__':
 else:
 FILES = get_modified_files(REPO, ARGS)
 
-ADDRESSES = []
-
+# Accumulate a sorted list of addresses
+ADDRESSES = set([])
 for file in FILES:
 print(file)
 recipients = get_maintainers(file, SECTIONS)
-ADDRESSES += recipients['maintainers'] + recipients['reviewers'] + 
recipients['lists']
+ADDRESSES |= set(recipients['maintainers'] + recipients['reviewers'] + 
recipients['lists'])
+ADDRESSES = list(ADDRESSES)
+ADDRESSES.sort()
 
-for address in list(OrderedDict.fromkeys(ADDRESSES)):
+for address in ADDRESSES:
 if '<' in address and '>' in address:
 address = address.split('>', 1)[0] + '>'
 print('  %s' % address)
-- 
2.39.2



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




[edk2-devel] [PATCH v3 3/5] BaseTools/Scripts/GetMaintainer: refactor internal returns as dicts

2023-11-10 Thread Leif Lindholm
To clean up interfaces, change the lookup functions to return dictionaries
rather than multiple values.

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
 BaseTools/Scripts/GetMaintainer.py | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/BaseTools/Scripts/GetMaintainer.py 
b/BaseTools/Scripts/GetMaintainer.py
index cdcdff750635..cb3aadbbefb1 100644
--- a/BaseTools/Scripts/GetMaintainer.py
+++ b/BaseTools/Scripts/GetMaintainer.py
@@ -96,7 +96,7 @@ def get_section_maintainers(path, section):
 else:
 lists += [address]
 
-return maintainers, lists
+return {'maintainers': maintainers, 'lists': lists}
 
 def get_maintainers(path, sections, level=0):
 """For 'path', iterates over all sections, returning maintainers
@@ -104,22 +104,24 @@ def get_maintainers(path, sections, level=0):
 maintainers = []
 lists = []
 for section in sections:
-tmp_maint, tmp_lists = get_section_maintainers(path, section)
-maintainers += tmp_maint
-lists += tmp_lists
+recipients = get_section_maintainers(path, section)
+maintainers += recipients['maintainers']
+lists += recipients['lists']
 
 if not maintainers:
 # If no match found, look for match for (nonexistent) file
 # REPO.working_dir/
 print('"%s": no maintainers found, looking for default' % path)
 if level == 0:
-maintainers = get_maintainers('', sections, level=level + 
1)
+recipients = get_maintainers('', sections, level=level + 
1)
+maintainers += recipients['maintainers']
+lists += recipients['lists']
 else:
 print("No  maintainers set for project.")
 if not maintainers:
 return None
 
-return maintainers + lists
+return {'maintainers': maintainers, 'lists': lists}
 
 def parse_maintainers_line(line):
 """Parse one line of Maintainers.txt, returning any match group and its 
key."""
@@ -184,9 +186,8 @@ if __name__ == '__main__':
 
 for file in FILES:
 print(file)
-addresslist = get_maintainers(file, SECTIONS)
-if addresslist:
-ADDRESSES += addresslist
+recipients = get_maintainers(file, SECTIONS)
+ADDRESSES += recipients['maintainers'] + recipients['lists']
 
 for address in list(OrderedDict.fromkeys(ADDRESSES)):
 if '<' in address and '>' in address:
-- 
2.39.2



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




[edk2-devel] [PATCH v3 2/5] BaseTools/Scripts/GetMaintainer: Simplify logic

2023-11-10 Thread Leif Lindholm
From: Michael D Kinney 

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

get_section_maintainers() either returns a list with
valid entries or an empty list.  It never returns None.
Simplify logic that accumulates maintainers and lists by
unconditionally appending lists returned from
get_section_maintainers().

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
---
 BaseTools/Scripts/GetMaintainer.py | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Scripts/GetMaintainer.py 
b/BaseTools/Scripts/GetMaintainer.py
index 2a3147c059b5..cdcdff750635 100644
--- a/BaseTools/Scripts/GetMaintainer.py
+++ b/BaseTools/Scripts/GetMaintainer.py
@@ -105,10 +105,8 @@ def get_maintainers(path, sections, level=0):
 lists = []
 for section in sections:
 tmp_maint, tmp_lists = get_section_maintainers(path, section)
-if tmp_maint:
-maintainers += tmp_maint
-if tmp_lists:
-lists += tmp_lists
+maintainers += tmp_maint
+lists += tmp_lists
 
 if not maintainers:
 # If no match found, look for match for (nonexistent) file
-- 
2.39.2



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




[edk2-devel] [PATCH v3 1/5] BaseTools/Scripts/GetMaintainer: Fix logic bug collecting maintainers

2023-11-10 Thread Leif Lindholm
From: Michael D Kinney 

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

Fix logic bug where maintainers is incorrectly added to lists.

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
---
 BaseTools/Scripts/GetMaintainer.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Scripts/GetMaintainer.py 
b/BaseTools/Scripts/GetMaintainer.py
index d1e042c0afe4..2a3147c059b5 100644
--- a/BaseTools/Scripts/GetMaintainer.py
+++ b/BaseTools/Scripts/GetMaintainer.py
@@ -88,7 +88,7 @@ def get_section_maintainers(path, section):
 if isinstance(address, list):
 maintainers += address
 else:
-lists += [address]
+maintainers += [address]
 for address in section['list']:
 # Convert to list if necessary
 if isinstance(address, list):
-- 
2.39.2



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




[edk2-devel] [PATCH v3 0/5] BaseTools/Scripts/GetMaintainer: Handle reviewer only case

2023-11-10 Thread Leif Lindholm
OK, so this a bit of a backwards review, but I figured I might as
well show how I would prefer the split. I'm adding a patch that
changes internal returns to dictionaries instead of multiple return
values.

There are no functional differences between the original submission 
and this for 1-2,4-5/5, so I'm happy to give 
Reviewed-by: Leif Lindholm 
for those. 3/5 is new and requires review by someone else.

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

Fix logic bug where maintainers was incorrectly added to lists.

If a package only has reviewers and no maintainers, then also
return the  maintainers.

In order to detect this case, get_maintainers() is updated to
return maintainers, reviews, and lists separately instead of
a single merged list.  This also allows this module to be used
by other scripts that need to distinguish between maintainers,
reviewers, and lists.

Simplify logic that accumulates maintainers, reviewers, lists.

Sort the list of output addresses alphabetically and use set()
instead of OrderedDict() to accumulate unique addresses.

Changes since v2:
- Reworked internal return logic to use dictionaries.
- Reordered cleanup before new functionality.
Changes since v1:
- Split into patch series

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Michael D Kinney 

Leif Lindholm (1):
  BaseTools/Scripts/GetMaintainer: refactor internal returns as dicts

Michael D Kinney (4):
  BaseTools/Scripts/GetMaintainer: Fix logic bug collecting maintainers
  BaseTools/Scripts/GetMaintainer: Simplify logic
  BaseTools/Scripts/GetMaintainer: Handle reviewer only case
  BaseTools/Scripts/GetMaintainer: Sort output addresses

 BaseTools/Scripts/GetMaintainer.py | 43 +++---
 1 file changed, 27 insertions(+), 16 deletions(-)

-- 
2.39.2



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




Re: [edk2-devel] [edk2-stable202311][Patch 1/1] BaseTools/Scripts: Handle reviewer only case in GetMaintainer.py

2023-11-10 Thread Leif Lindholm

On 2023-11-10 16:34, Kinney, Michael D wrote:

Hi Leif,

Agree with your points.  I was trying to make minimal changes to address
the reviewers with no maintainers case.  Returning a dictionary would make
more sense.

A couple questions:

1) Do you want to see this patch broken up into a series, with the
logic fix, reviewers with no maintainers feature, and code clean
up in separate patches?


Ideally, yes.
It will be helpful if I need to try to understand these changes again in 
future :)



2) Is this change approved for edk2-stable202311?


Yes.

Regards,

Leif


Thanks,

Mike


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Leif
Lindholm
Sent: Friday, November 10, 2023 4:44 AM
To: Kinney, Michael D 
Cc: devel@edk2.groups.io; Rebecca Cran ; Gao,
Liming ; Feng, Bob C ;
Chen, Christine 
Subject: Re: [edk2-devel] [edk2-stable202311][Patch 1/1]
BaseTools/Scripts: Handle reviewer only case in GetMaintainer.py

On Wed, Nov 08, 2023 at 12:43:23 -0800, Michael D Kinney wrote:

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

If a package only has reviewers and no maintainers, then also
return the  maintainers.

Update get_maintainers() to return maintainers, reviews, and
lists separately instead of a single merged list to allow this
module to be used by other scripts and distinguish types.

Sort the list of output addresses alphabetically.

Fix logic bug where maintainers was incorrectly added to lists.

Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Leif Lindholm 
Signed-off-by: Michael D Kinney 
---
  BaseTools/Scripts/GetMaintainer.py | 42 ++-

---

  1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/BaseTools/Scripts/GetMaintainer.py

b/BaseTools/Scripts/GetMaintainer.py

index d1e042c0afe4..b33546b10f21 100644
--- a/BaseTools/Scripts/GetMaintainer.py
+++ b/BaseTools/Scripts/GetMaintainer.py
@@ -76,6 +76,7 @@ def get_section_maintainers(path, section):
  """Returns a list with email addresses to any M: and R: entries
 matching the provided path in the provided section."""
  maintainers = []
+reviewers = []
  lists = []
  nowarn_status = ['Supported', 'Maintained']

@@ -83,12 +84,18 @@ def get_section_maintainers(path, section):
  for status in section['status']:
  if status not in nowarn_status:
  print('WARNING: Maintained status for "%s" is

\'%s\'!' % (path, status))

-for address in section['maintainer'], section['reviewer']:
+for address in section['maintainer']:
  # Convert to list if necessary
  if isinstance(address, list):
  maintainers += address
  else:
-lists += [address]
+maintainers += [address]


That's a bugfix. Ought to be separate.
(Cleverly hidden by concatentaing the results when we didn't care
about keeping them separate other than for seeing if we'd found any
humans.)


+for address in section['reviewer']:
+# Convert to list if necessary
+if isinstance(address, list):
+reviewers += address
+else:
+reviewers += [address]
  for address in section['list']:
  # Convert to list if necessary
  if isinstance(address, list):
@@ -96,32 +103,34 @@ def get_section_maintainers(path, section):
  else:
  lists += [address]

-return maintainers, lists
+return maintainers, reviewers, lists

  def get_maintainers(path, sections, level=0):
  """For 'path', iterates over all sections, returning

maintainers

 for matching ones."""
  maintainers = []
+reviewers = []
  lists = []
  for section in sections:
-tmp_maint, tmp_lists = get_section_maintainers(path,

section)

-if tmp_maint:
-maintainers += tmp_maint
-if tmp_lists:
-lists += tmp_lists
+tmp_maint, tmp_review, tmp_lists =

get_section_maintainers(path, section)

+maintainers += tmp_maint
+reviewers += tmp_review
+lists += tmp_lists


Minor niggle at coding style cleanup as part of functional rework.



  if not maintainers:
  # If no match found, look for match for (nonexistent) file
  # REPO.working_dir/
  print('"%s": no maintainers found, looking for default' %

path)

  if level == 0:
-maintainers = get_maintainers('', sections,

level=level + 1)

+maintainers, tmp_review, tmp_lists =

get_maintainers('', sections, level=level + 1)

+reviewers += tmp_review
+lists += tmp_lists
  else:
  print("No  maintainers set for project.")
  if not maintainers:
  return None

-return maintainers + lists


Apart from the niggles mentioned

Re: [edk2-devel] [PATCH v2 01/11] ArmPkg/ArmScmiDxe: Rename PERFORMANCE_PROTOCOL_VERSION

2023-11-10 Thread Leif Lindholm

On 2023-11-10 09:11, Pierre Gondois wrote:

Hello Leif,

On 11/2/23 11:20, Pierre Gondois wrote:

Hello Leif,
Thanks for the review,

On 10/26/23 12:05, Leif Lindholm wrote:

On Wed, Oct 25, 2023 at 13:25:30 +0200, pierre.gond...@arm.com wrote:

From: Pierre Gondois 

Rename PERFORMANCE_PROTOCOL_VERSION to reflect the different
versions of the protocol. The macro is neither used in edk2 nor
in edk2-platforms.


OK, so slight nitpick, but mainly because it parses a bit weirdly...
*Will* it be used after this series is merged, or is this an update
for completeness?


The 'fast channels' were added in the v2.0 SCMI specification. This 
patch-set

relies on this feature, so it is checked in:
 [PATCH v2 10/11] DynamicTablesPkg: Add ArmScmiInfoLib
that the underlying SCP is at least at this version.

```
 // FastChannels were added in SCMI v2.0 spec.
 if (Version < PERFORMANCE_PROTOCOL_VERSION_V2) {
   DEBUG ((DEBUG_ERROR, "ArmScmiInfoLib requires SCMI version > 
2.0\n"));

   return EFI_UNSUPPORTED;
 }
```




Signed-off-by: Pierre Gondois 
---
   ArmPkg/Include/Library/ArmLib.h |  1 +
   .../Include/Protocol/ArmScmiPerformanceProtocol.h   | 13 
-

   2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/ArmPkg/Include/Library/ArmLib.h 
b/ArmPkg/Include/Library/ArmLib.h

index 0169dbc1092c..7b2b2238fed9 100644
--- a/ArmPkg/Include/Library/ArmLib.h
+++ b/ArmPkg/Include/Library/ArmLib.h
@@ -780,6 +780,7 @@ EFIAPI
   ArmHasVhe (
 VOID
 );
+
   #endif // MDE_CPU_AARCH64
   #ifdef MDE_CPU_ARM
diff --git a/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h 
b/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h

index 7e548e4765c2..8e8e05d5a5f6 100644
--- a/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
+++ b/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
@@ -1,12 +1,12 @@
   /** @file
-  Copyright (c) 2017-2021, Arm Limited. All rights reserved.
+  Copyright (c) 2017-2023, Arm Limited. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
-  System Control and Management Interface V1.0
-    http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/
-    DEN0056A_System_Control_and_Management_Interface.pdf
+  System Control and Management Interface, latest version:


I see this as a pattern throughout the series.
But this statement will at some point become untrue; this
implementation is written against a specific version. I think this
version shold be reflected in the comment. (And that applies
throughout the series.)


+  - https://developer.arm.com/documentation/den0056/latest/


But I think the above is the most useful link.


I was referring to this point I'm not sure I understood.


Oh, right.

I was referring to "latest version" being a moving target.
If I go to https://developer.arm.com/documentation/den0056/latest/, that 
currently means "version 3.2". At some point in the future, that number 
will change, but this code won't automatically get updated.


So I'd prefer something like
"System Control and Management Interface v3.2,
Latest version of the specification can be downloaded from
https://developer.arm.com/documentation/den0056/latest/;

If that makes more sense?

Regards,

Leif


Regards,
Pierre



I am not sure I understand completely. Do you mean that the SCMI
structures/interfaces defined in:
 ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
and that were written against the SCMI v1.0 specification should
not be used as such for other SCMI specification version ?
I.e. the same process as for the AcpiXX.h files
(MdePkg/Include/IndustryStandard/Acpi65.h) should be used ?

Or do you mean that the _CPC object generation implies that the
SCP should comply to the v2.0 version at least and this should be
reflected in the commit messages ?

Regards,
Pierre



/
  Leif


+
   **/
   #ifndef ARM_SCMI_PERFORMANCE_PROTOCOL_H_
@@ -14,7 +14,10 @@
   #include 
-#define PERFORMANCE_PROTOCOL_VERSION  0x1
+/// Arm Scmi performance protocol versions.
+#define PERFORMANCE_PROTOCOL_VERSION_V1  0x1
+#define PERFORMANCE_PROTOCOL_VERSION_V2  0x2
+#define PERFORMANCE_PROTOCOL_VERSION_V3  0x3
   #define ARM_SCMI_PERFORMANCE_PROTOCOL_GUID  { \
 0x9b8ba84, 0x3dd3, 0x49a6, {0xa0, 0x5a, 0x31, 0x34, 0xa5, 0xf0, 
0x7b, 0xad} \

--
2.25.1





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




Re: [edk2-devel] [PATCH v3] RedfishPkg: RedfishDiscoverDxe: Fix issue if IPv4 installed after RestEx

2023-11-10 Thread Leif Lindholm
On Fri, Nov 10, 2023 at 00:39:53 +, Chang, Abner wrote:
> [AMD Official Use Only - General]
> 
> Thanks Leif, some responses are given in line.
> As we would like to have this be part of edk2-stable202312,  we
> prefer letting this change gets in stable release first and address
> the comment in another patch afterward.
>
> Hi Igor,
> Could you please check my comment and help to send another patch after 
> edk2-stable202312?
> 
> Thanks
> Abner
> 
> 
> > -Original Message-
> > From: Leif Lindholm 
> > Sent: Thursday, November 9, 2023 11:12 PM
> > To: devel@edk2.groups.io; ig...@ami.com
> > Cc: Chang, Abner ; Nickle Wang
> > ; gaolim...@byosoft.com.cn
> > Subject: Re: [edk2-devel] [PATCH v3] RedfishPkg: RedfishDiscoverDxe: Fix
> > issue if IPv4 installed after RestEx
> >
> > Caution: This message originated from an External Source. Use proper caution
> > when opening attachments, clicking links, or responding.
> >
> >
> > On 2023-11-07 12:06, Igor Kulchytskyy via groups.io wrote:
> > > Supported function of the driver changed to wait for all newtwork
> >
> > Typo:
> > newtwork ->
> > network
> >
> > > interface to be installed.
> > > Filer out the network interfaces which are not supported by
> >
> > Filer ->
> > Filter
> >
> > > Redfish Host Interface.
> >
> > These sound like two separate changes?
> This is for the same issue.

That means it should be in the same set, not in the same patch.

> > > Cc: Abner Chang 
> > > Cc: Nickle Wang 
> > > Signed-off-by: Igor Kulchytskyy 
> > > ---
> > >   RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c | 165
> > ++--
> > >   1 file changed, 117 insertions(+), 48 deletions(-)
> > >
> > > diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> > b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> > > index 23da3b968f..85e47843e4 100644
> > > --- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> > > +++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
> > > @@ -322,9 +322,16 @@ GetTargetNetworkInterfaceInternal (
> > >   {
> > > EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL
> > *ThisNetworkInterface;
> > >
> > > +  if (IsListEmpty ()) {
> > > +return NULL;
> > > +  }
> > > +
> > > ThisNetworkInterface =
> > (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL *)GetFirstNode
> > ();
> > > while (TRUE) {
> > > -if (CompareMem ((VOID *)>MacAddress,
> > >MacAddress, ThisNetworkInterface-
> > >HwAddressSize) == 0) {
> > > +if ((CompareMem ((VOID *)>MacAddress,
> > >MacAddress, ThisNetworkInterface-
> > >HwAddressSize) == 0) &&
> > > +((TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface-
> > >NetworkProtocolType == ProtocolTypeTcp6)) ||
> > > + (!TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface-
> > >NetworkProtocolType == ProtocolTypeTcp4
> > > +{
> >
> > This could really benefit from some helper macros.
> > e.g. if the test could look like
> 
> Hi Igor,
> Could we consider this suggestion after stable release?
> 
> >
> > if ((MAC_COMPARE (ThisNetworkInterface, TargetNetworkInterface) == 0) &&
> >  (VALID_TCP6 (TargetNetworkInterface, ThisNetworkInterface) ||
> >   VALID_TCP4 (TargetNetworkInterface, ThisNetworkInterface))) {
> >
> > > return ThisNetworkInterface;
> > >   }
> > >
> > > @@ -354,6 +361,10 @@ GetTargetNetworkInterfaceInternalByController (
> > >   {
> > > EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL
> > *ThisNetworkInterface;
> > >
> > > +  if (IsListEmpty ()) {
> > > +return NULL;
> > > +  }
> > > +
> > > ThisNetworkInterface =
> > (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL *)GetFirstNode
> > ();
> > > while (TRUE) {
> > >   if (ThisNetworkInterface->OpenDriverControllerHandle ==
> > ControllerHandle) {
> > > @@ -476,6 +487,42 @@ CheckIsIpVersion6 (
> > > return FALSE;
> > >   }
> > >
> > > +/**
> > > +  This function returns the  IP type supported by the Host Interface.
> > > +
> > > +  @retval 00h is Unknown
> > > +  01h is Ipv4
> > > +  02h is Ipv6
> > > +
> > > +**/
>

Re: [edk2-devel] [edk2-stable202311][Patch 1/1] BaseTools/Scripts: Handle reviewer only case in GetMaintainer.py

2023-11-10 Thread Leif Lindholm
On Wed, Nov 08, 2023 at 12:43:23 -0800, Michael D Kinney wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4593
> 
> If a package only has reviewers and no maintainers, then also
> return the  maintainers.
> 
> Update get_maintainers() to return maintainers, reviews, and
> lists separately instead of a single merged list to allow this
> module to be used by other scripts and distinguish types.
> 
> Sort the list of output addresses alphabetically.
> 
> Fix logic bug where maintainers was incorrectly added to lists.
> 
> Cc: Rebecca Cran 
> Cc: Liming Gao 
> Cc: Bob Feng 
> Cc: Yuwei Chen 
> Cc: Leif Lindholm 
> Signed-off-by: Michael D Kinney 
> ---
>  BaseTools/Scripts/GetMaintainer.py | 42 ++
>  1 file changed, 26 insertions(+), 16 deletions(-)
> 
> diff --git a/BaseTools/Scripts/GetMaintainer.py 
> b/BaseTools/Scripts/GetMaintainer.py
> index d1e042c0afe4..b33546b10f21 100644
> --- a/BaseTools/Scripts/GetMaintainer.py
> +++ b/BaseTools/Scripts/GetMaintainer.py
> @@ -76,6 +76,7 @@ def get_section_maintainers(path, section):
>  """Returns a list with email addresses to any M: and R: entries
> matching the provided path in the provided section."""
>  maintainers = []
> +reviewers = []
>  lists = []
>  nowarn_status = ['Supported', 'Maintained']
>  
> @@ -83,12 +84,18 @@ def get_section_maintainers(path, section):
>  for status in section['status']:
>  if status not in nowarn_status:
>  print('WARNING: Maintained status for "%s" is \'%s\'!' % 
> (path, status))
> -for address in section['maintainer'], section['reviewer']:
> +for address in section['maintainer']:
>  # Convert to list if necessary
>  if isinstance(address, list):
>  maintainers += address
>  else:
> -lists += [address]
> +maintainers += [address]

That's a bugfix. Ought to be separate.
(Cleverly hidden by concatentaing the results when we didn't care
about keeping them separate other than for seeing if we'd found any
humans.)

> +for address in section['reviewer']:
> +# Convert to list if necessary
> +if isinstance(address, list):
> +reviewers += address
> +else:
> +reviewers += [address]
>  for address in section['list']:
>  # Convert to list if necessary
>  if isinstance(address, list):
> @@ -96,32 +103,34 @@ def get_section_maintainers(path, section):
>  else:
>  lists += [address]
>  
> -return maintainers, lists
> +return maintainers, reviewers, lists
>  
>  def get_maintainers(path, sections, level=0):
>  """For 'path', iterates over all sections, returning maintainers
> for matching ones."""
>  maintainers = []
> +reviewers = []
>  lists = []
>  for section in sections:
> -tmp_maint, tmp_lists = get_section_maintainers(path, section)
> -if tmp_maint:
> -maintainers += tmp_maint
> -if tmp_lists:
> -lists += tmp_lists
> +tmp_maint, tmp_review, tmp_lists = get_section_maintainers(path, 
> section)
> +maintainers += tmp_maint
> +reviewers += tmp_review
> +lists += tmp_lists

Minor niggle at coding style cleanup as part of functional rework.

>  
>  if not maintainers:
>  # If no match found, look for match for (nonexistent) file
>  # REPO.working_dir/
>  print('"%s": no maintainers found, looking for default' % path)
>  if level == 0:
> -maintainers = get_maintainers('', sections, level=level 
> + 1)
> +maintainers, tmp_review, tmp_lists = 
> get_maintainers('', sections, level=level + 1)
> +reviewers += tmp_review
> +lists += tmp_lists
>  else:
>  print("No  maintainers set for project.")
>  if not maintainers:
>  return None
>  
> -return maintainers + lists

Apart from the niggles mentioned above, I agree that this is a
reasonable way of adding the required functionality without completely
rewriting the existing code. (It does make me feel there must be a
better way of writing it than I did, though.)

> +return maintainers, reviewers, lists
>  
>  def parse_maintainers_line(line):
>  """Parse one line of Maintainers.txt, returning any match group and its 
> key."""
> @@ -182,15 +191,16 @@ if __name__ == '__main__':
>

Re: [edk2-devel] [PATCH v3] RedfishPkg: RedfishDiscoverDxe: Fix issue if IPv4 installed after RestEx

2023-11-09 Thread Leif Lindholm

On 2023-11-07 12:06, Igor Kulchytskyy via groups.io wrote:

Supported function of the driver changed to wait for all newtwork


Typo:
newtwork ->
network


interface to be installed.
Filer out the network interfaces which are not supported by


Filer ->
Filter


Redfish Host Interface.


These sound like two separate changes?


Cc: Abner Chang 
Cc: Nickle Wang 
Signed-off-by: Igor Kulchytskyy 
---
  RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c | 165 ++--
  1 file changed, 117 insertions(+), 48 deletions(-)

diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c 
b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
index 23da3b968f..85e47843e4 100644
--- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
+++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c
@@ -322,9 +322,16 @@ GetTargetNetworkInterfaceInternal (
  {
EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL  *ThisNetworkInterface;

+  if (IsListEmpty ()) {
+return NULL;
+  }
+
ThisNetworkInterface = (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL 
*)GetFirstNode ();
while (TRUE) {
-if (CompareMem ((VOID *)>MacAddress, 
>MacAddress, ThisNetworkInterface->HwAddressSize) == 0) {
+if ((CompareMem ((VOID *)>MacAddress, 
>MacAddress, ThisNetworkInterface->HwAddressSize) == 0) &&
+((TargetNetworkInterface->IsIpv6 && 
(ThisNetworkInterface->NetworkProtocolType == ProtocolTypeTcp6)) ||
+ (!TargetNetworkInterface->IsIpv6 && 
(ThisNetworkInterface->NetworkProtocolType == ProtocolTypeTcp4
+{


This could really benefit from some helper macros.
e.g. if the test could look like

if ((MAC_COMPARE (ThisNetworkInterface, TargetNetworkInterface) == 0) &&
(VALID_TCP6 (TargetNetworkInterface, ThisNetworkInterface) ||
 VALID_TCP4 (TargetNetworkInterface, ThisNetworkInterface))) {


return ThisNetworkInterface;
  }

@@ -354,6 +361,10 @@ GetTargetNetworkInterfaceInternalByController (
  {
EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL  *ThisNetworkInterface;

+  if (IsListEmpty ()) {
+return NULL;
+  }
+
ThisNetworkInterface = (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL 
*)GetFirstNode ();
while (TRUE) {
  if (ThisNetworkInterface->OpenDriverControllerHandle == ControllerHandle) 
{
@@ -476,6 +487,42 @@ CheckIsIpVersion6 (
return FALSE;
  }

+/**
+  This function returns the  IP type supported by the Host Interface.
+
+  @retval 00h is Unknown
+  01h is Ipv4
+  02h is Ipv6
+
+**/
+UINT8


If this is just a local helper function, we probably want it STATIC.


+GetHiIpProtocolType (
+  VOID
+  )
+{
+  EFI_STATUS Status;
+  REDFISH_OVER_IP_PROTOCOL_DATA  *Data;
+  REDFISH_INTERFACE_DATA *DeviceDescriptor;
+
+  Data = NULL;
+  DeviceDescriptor = NULL;
+  if (mSmbios == NULL) {
+Status = gBS->LocateProtocol (, NULL, (VOID 
**));
+if (EFI_ERROR (Status)) {
+  return REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN;
+}
+  }
+
+  Status = RedfishGetHostInterfaceProtocolData (mSmbios, , 
); // Search for SMBIOS type 42h
+  if (!EFI_ERROR (Status) && (Data != NULL) &&
+  (Data->HostIpAssignmentType == RedfishHostIpAssignmentStatic))
+  {
+return Data->HostIpAddressFormat;
+  }
+
+  return REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_UNKNOWN;
+}
+
  /**
This function discover Redfish service through SMBIOS host interface.

@@ -512,6 +559,18 @@ DiscoverRedfishHostInterface (

Status = RedfishGetHostInterfaceProtocolData (mSmbios, , 
); // Search for SMBIOS type 42h
if (!EFI_ERROR (Status) && (Data != NULL) && (DeviceDescriptor != NULL)) {
+if ((Instance->NetworkInterface->NetworkProtocolType == ProtocolTypeTcp4) 
&&
+(Data->HostIpAddressFormat != 
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP4)) // IPv4 case
+{
+  DEBUG ((DEBUG_ERROR, "%a: Network Interface is IPv4, but Host Interface 
requires Ipv6\n", __func__));
+  return EFI_UNSUPPORTED;
+} else if ((Instance->NetworkInterface->NetworkProtocolType == ProtocolTypeTcp6) 
&&
+   (Data->HostIpAddressFormat != 
REDFISH_HOST_INTERFACE_HOST_IP_ADDRESS_FORMAT_IP6)) // IPv6 case
+{
+  DEBUG ((DEBUG_ERROR, "%a: Network Interface is IPv6, but Host Interface 
requires IPv4\n", __func__));
+  return EFI_UNSUPPORTED;
+}
+
  //
  // Check if we can reach out Redfish service using this network interface.
  // Check with MAC address using Device Descriptor Data Device Type 04 and 
Type 05.
@@ -1102,6 +1161,7 @@ RedfishServiceGetNetworkInterface (
OUT EFI_REDFISH_DISCOVER_NETWORK_INTERFACE  **NetworkIntfInstances
)
  {
+  EFI_STATUS   Status;
EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL  *ThisNetworkInterfaceIntn;
EFI_REDFISH_DISCOVER_NETWORK_INTERFACE   *ThisNetworkInterface;
EFI_REDFISH_DISCOVER_REST_EX_INSTANCE_INTERNAL   *RestExInstance;
@@ -1141,13 +1201,23 @@ 

Re: [edk2-devel] 回复: [edk2-stable202311] [PATCH v3] RedfishPkg: RedfishDiscoverDxe: Fix issue if IPv4 installed after RestEx

2023-11-09 Thread Leif Lindholm
(You have my old now-dysfunctional @nuviainc.com email address on cc, 
please delete that one if you can.)


I think it's fine to merge this bugfix, but I have a couple of review 
comments I will make on the v3 code itself, replying to that submission.
(I am however not the maintainer of RedFishPkg, so Nickle is free to 
ignore me and push this version.)


/
Leif


On 2023-11-09 13:49, gaoliming via groups.io wrote:

Nickle:

  This is a bug fix. Its impact is only in RedfishDiscoverDxe. I think 
it can be merged for this stable tag.


Thanks

Liming

*发件人:*devel@edk2.groups.io  *代表 *Nickle Wang 
via groups.io

*发送时间:*2023年11月8日10:44
*收件人:*Liming Gao ; Kinney, Michael D 
; devel@edk2.groups.io

*抄送:*Igor Kulchytskyy ; Chang, Abner 
*主题:*Re: [edk2-devel] [PATCH v3] RedfishPkg: RedfishDiscoverDxe: Fix 
issue if IPv4 installed after RestEx


Hi @Liming Gao , @Kinney, Michael D 




If the patch is sent before Soft Feature Freeze, and plans to catch this stable 
tag, the patch contributor need reply to his patch and notify edk2 community


We would like to include this fix to edk2-stable202311 release. Could 
you please help us to merge this patch? This patch review was started on 
November 1: https://edk2.groups.io/g/devel/message/110440 
. Anber and I gave 
reviewed-by to this patch today. We have a pull request ready for 
merging here: https://github.com/tianocore/edk2/pull/4994 



Thanks,

Nickle


-Original Message-


From: devel@edk2.groups.io  
> On Behalf Of Chang, Abner


via groups.io



Sent: Wednesday, November 8, 2023 8:14 AM


To: Igor Kulchytskyy mailto:ig...@ami.com>>; devel@edk2.groups.io 




Cc: Nickle Wang mailto:nick...@nvidia.com>>



Subject: Re: [edk2-devel] [PATCH v3] RedfishPkg: RedfishDiscoverDxe: Fix issue 
if



IPv4 installed after RestEx







External email: Use caution opening links or attachments











[AMD Official Use Only - General]







Reviewed-by: Abner Chang mailto:abner.ch...@amd.com>>







> -Original Message-



> From: Igor Kulchytskyy mailto:ig...@ami.com>>



> Sent: Tuesday, November 7, 2023 8:06 PM



> To: devel@edk2.groups.io 



> Cc: Chang, Abner mailto:abner.ch...@amd.com>>; Nickle 
Wang



> mailto:nick...@nvidia.com>>



> Subject: [PATCH v3] RedfishPkg: RedfishDiscoverDxe: Fix issue if IPv4



> installed after RestEx



>



> Caution: This message originated from an External Source. Use proper



> caution when opening attachments, clicking links, or responding.



>



>



> Supported function of the driver changed to wait for all newtwork



> interface to be installed.



> Filer out the network interfaces which are not supported by Redfish



> Host Interface.



>



> Cc: Abner Chang mailto:abner.ch...@amd.com>>



> Cc: Nickle Wang mailto:nick...@nvidia.com>>



> Signed-off-by: Igor Kulchytskyy mailto:ig...@ami.com>>



> ---



>  RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c | 165



> ++--



>  1 file changed, 117 insertions(+), 48 deletions(-)



>



> diff --git a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c



> b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c



> index 23da3b968f..85e47843e4 100644



> --- a/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c



> +++ b/RedfishPkg/RedfishDiscoverDxe/RedfishDiscoverDxe.c



> @@ -322,9 +322,16 @@ GetTargetNetworkInterfaceInternal (  {



>    EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL



> *ThisNetworkInterface;



>



> +  if (IsListEmpty ()) {



> +    return NULL;



> +  }



> +



>    ThisNetworkInterface =



> (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL *)GetFirstNode



> ();



>    while (TRUE) {



> -    if (CompareMem ((VOID *)>MacAddress,



> >MacAddress, ThisNetworkInterface-



> >HwAddressSize) == 0) {



> +    if ((CompareMem ((VOID *)>MacAddress,



> >MacAddress, ThisNetworkInterface-



> >HwAddressSize) == 0) &&



> +    ((TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface-



> >NetworkProtocolType == ProtocolTypeTcp6)) ||



> + (!TargetNetworkInterface->IsIpv6 && (ThisNetworkInterface-



> >NetworkProtocolType == ProtocolTypeTcp4



> +    {



>    return ThisNetworkInterface;



>  }



>



> @@ -354,6 +361,10 @@ GetTargetNetworkInterfaceInternalByController (



> {



>    EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL



> *ThisNetworkInterface;



>



> +  if (IsListEmpty ()) {



> +    return NULL;



> +  }



> +



>    ThisNetworkInterface =



> (EFI_REDFISH_DISCOVER_NETWORK_INTERFACE_INTERNAL *)GetFirstNode



> ();



>    while (TRUE) {



>  if (ThisNetworkInterface->OpenDriverControllerHandle ==



> ControllerHandle) {



> @@ -476,6 +487,42 @@ 

Re: 回复: [edk2-devel] [PATCH 1/1] BaseTools/tools_def: drop -mgeneral-regs-only for AArch64 CLANGDWARF

2023-11-09 Thread Leif Lindholm
Thanks!

https://github.com/tianocore/edk2/pull/5023 raised.

/
Leif

On Thu, Nov 09, 2023 at 21:42:38 +0800, gaoliming via groups.io wrote:
> Leif:
>   Sure. This patch can be merged for this stable tag. 
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Leif Lindholm
> > 发送时间: 2023年11月7日 21:13
> > 收件人: Yeping Song (QUIC) ;
> > devel@edk2.groups.io; Liming Gao 
> > 抄送: Rebecca Cran ; Bob Feng
> > ; Yuwei Chen ; Ard
> > Biesheuvel ; Sami Mujawar
> > ; Kinney, Michael D 
> > 主题: Re: [edk2-devel] [PATCH 1/1] BaseTools/tools_def: drop
> > -mgeneral-regs-only for AArch64 CLANGDWARF
> > 
> > Liming,
> > 
> > You reviewed this patch before the stable tag. Am I OK to stage a github
> > PR for this change?
> > 
> > Reviewed-by: Leif Lindholm 
> > 
> > Regards,
> > 
> > Leif
> > 
> > On 2023-11-07 13:11, Yeping Song (QUIC) wrote:
> > > Hi all,
> > > I would like for this to be include in stable tag. Please help to review 
> > > and
> > merge this patch into stable release.
> > > Thanks
> > > Yepings
> > >
> > >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of Yeping
> > Song
> > > Sent: Saturday, November 4, 2023 12:38 AM
> > > To: devel@edk2.groups.io
> > > Cc: Yeping Song (QUIC) ; Rebecca Cran
> > ; Liming Gao ; Bob Feng
> > ; Yuwei Chen ; Ard
> > Biesheuvel ; Leif Lindholm (QUIC)
> > ; Sami Mujawar 
> > > Subject: [edk2-devel] [PATCH 1/1] BaseTools/tools_def: drop
> > -mgeneral-regs-only for AArch64 CLANGDWARF
> > >
> > > WARNING: This email originated from outside of Qualcomm. Please be wary
> > of any links or attachments, and do not enable macros.
> > >
> > > Commit 0df6c8c157af9 ("BaseTools/tools_def AARCH64:
> > > avoid SIMD registers in XIP code")
> > > adds -mgeneral-regs-only to GCC_AARCH64_CC_XIPFLAGS, in order to avoid
> > a bug present in certain versions of GCC.
> > > This was never a problem for clang.
> > > That's given the history of what the problem is.
> > > Then we can describe how we fix it:
> > > Change *_CLANGDWARF_AARCH64_CC_XIPFLAGS to set the required
> > -mstrict-align option instead of importing the whole GCC variable.
> > >
> > > Signed-off-by: Yeping Song 
> > > Cc: Rebecca Cran 
> > > Cc: Liming Gao 
> > > Cc: Bob Feng 
> > > Cc: Yuwei Chen 
> > > Cc: Ard Biesheuvel 
> > > Cc: Leif Lindholm 
> > > Cc: Sami Mujawar 
> > > ---
> > >   BaseTools/Conf/tools_def.template | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/BaseTools/Conf/tools_def.template
> > b/BaseTools/Conf/tools_def.template
> > > index 5bd5283655ea..c34ecfd557c5 100755
> > > --- a/BaseTools/Conf/tools_def.template
> > > +++ b/BaseTools/Conf/tools_def.template
> > > @@ -2015,7 +2015,7 @@ DEFINE CLANGDWARF_AARCH64_DLINK_FLAGS
> > = DEF(CLANGDWARF_AARCH64_TARGET) DEF(GCC_
> > >   *_CLANGDWARF_AARCH64_RC_FLAGS   =
> > DEF(GCC_AARCH64_RC_FLAGS) DEF(GCC_AARCH64_RC_BTI_FLAGS)
> > >   *_CLANGDWARF_AARCH64_VFRPP_FLAGS=
> > DEF(GCC_VFRPP_FLAGS) DEF(CLANGDWARF_AARCH64_TARGET)
> > $(PLATFORM_FLAGS)
> > >   *_CLANGDWARF_AARCH64_ASLPP_FLAGS=
> > DEF(GCC_ASLPP_FLAGS) DEF(CLANGDWARF_AARCH64_TARGET)
> > > -*_CLANGDWARF_AARCH64_CC_XIPFLAGS=
> > DEF(GCC_AARCH64_CC_XIPFLAGS)
> > > +*_CLANGDWARF_AARCH64_CC_XIPFLAGS= -mstrict-align
> > >
> > > DEBUG_CLANGDWARF_AARCH64_CC_FLAGS=
> > DEF(CLANGDWARF_AARCH64_CC_FLAGS) $(PLATFORM_FLAGS) -flto -O1
> > > DEBUG_CLANGDWARF_AARCH64_DLINK_FLAGS =
> > DEF(CLANGDWARF_AARCH64_DLINK_FLAGS) -flto -Wl,-O1 -fuse-ld=lld
> > -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64
> > -Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wl,--no-pie,--no-relax
> > > --
> > > 2.25.1
> > >
> > >
> > >
> > >
> > >
> > >
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
> 
> 
> 
> 


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




Re: [edk2-devel] [PATCH v2 2/7] MdePkg/BaseLib: AARCH64: Add ArmReadIdAA64Isar0Reg()

2023-11-09 Thread Leif Lindholm
On Thu, Nov 09, 2023 at 10:23:02 +0100, Pierre Gondois wrote:
> To enable AARCH64 native instruction support for Openssl,
> some interfaces must be implemented. OPENSSL_cpuid_setup()
> allows to probe the supported features of the platform.
> 
> Add ArmReadIdAA64Isar0Reg() to read the AA64Isar0, containing
> Arm64 instruction capabilities.
> A similar ArmReadIdAA64Isar0() function is available in the ArmPkg,
> but the CryptoPkg where OPENSSL_cpuid_setup will reside cannot rely
> on the ArmPkg.

The word "similar" here does an exemplary job of explaining why this
is problematic.

/
Leif

> Signed-off-by: Pierre Gondois 
> ---
>  MdePkg/Include/Library/BaseLib.h  | 72 +++
>  .../BaseLib/AArch64/ArmReadIdAA64Isar0Reg.S   | 30 
>  .../BaseLib/AArch64/ArmReadIdAA64Isar0Reg.asm | 30 
>  MdePkg/Library/BaseLib/BaseLib.inf|  2 +
>  4 files changed, 134 insertions(+)
>  create mode 100644 MdePkg/Library/BaseLib/AArch64/ArmReadIdAA64Isar0Reg.S
>  create mode 100644 MdePkg/Library/BaseLib/AArch64/ArmReadIdAA64Isar0Reg.asm
> 
> diff --git a/MdePkg/Include/Library/BaseLib.h 
> b/MdePkg/Include/Library/BaseLib.h
> index b81c9dd83508..365d50cfb1b8 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -140,6 +140,78 @@ ArmReadCntPctReg (
>VOID
>);
>  
> +//
> +// Bit shifts for the ID_AA64ISAR0_EL1 register.
> +//
> +#define ARM_ID_AA64ISAR0_EL1_AES_SHIFT (4U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA1_SHIFT(8U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA2_SHIFT(12U)
> +#define ARM_ID_AA64ISAR0_EL1_CRC32_SHIFT   (16U)
> +#define ARM_ID_AA64ISAR0_EL1_ATOMIC_SHIFT  (20U)
> +#define ARM_ID_AA64ISAR0_EL1_RDM_SHIFT (28U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA3_SHIFT(32U)
> +#define ARM_ID_AA64ISAR0_EL1_SM3_SHIFT (36U)
> +#define ARM_ID_AA64ISAR0_EL1_SM4_SHIFT (40U)
> +#define ARM_ID_AA64ISAR0_EL1_DP_SHIFT  (44U)
> +#define ARM_ID_AA64ISAR0_EL1_FHM_SHIFT (48U)
> +#define ARM_ID_AA64ISAR0_EL1_TS_SHIFT  (52U)
> +#define ARM_ID_AA64ISAR0_EL1_TLB_SHIFT (56U)
> +#define ARM_ID_AA64ISAR0_EL1_RNDR_SHIFT(60U)
> +
> +//
> +// Bit masks for the ID_AA64ISAR0_EL1 fields.
> +//
> +#define ARM_ID_AA64ISAR0_EL1_AES_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SHA1_MASK(0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SHA2_MASK(0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_CRC32_MASK   (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_ATOMIC_MASK  (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_RDM_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SHA3_MASK(0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SM3_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_SM4_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_DP_MASK  (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_FHM_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_TS_MASK  (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_TLB_MASK (0xFU)
> +#define ARM_ID_AA64ISAR0_EL1_RNDR_MASK(0xFU)
> +
> +//
> +// Bit masks for the ID_AA64ISAR0_EL1 field values.
> +//
> +#define ARM_ID_AA64ISAR0_EL1_AES_FEAT_AES_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_AES_FEAT_PMULL_MASK  (0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA1_FEAT_SHA1_MASK  (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA2_FEAT_SHA256_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA2_FEAT_SHA512_MASK(0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_CRC32_HAVE_CRC32_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_ATOMIC_FEAT_LSE_MASK (0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_RDM_FEAT_RDM_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SHA3_FEAT_SHA3_MASK  (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SM3_FEAT_SM3_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_SM4_FEAT_SM4_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_DP_FEAT_DOTPROD_MASK (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_FHM_FEAT_FHM_MASK(0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_TS_FEAT_FLAGM_MASK   (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_TS_FEAT_FLAGM2_MASK  (0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_TLB_FEAT_TLBIOS_MASK (0x1U)
> +#define ARM_ID_AA64ISAR0_EL1_TLB_FEAT_TLBIRANGE_MASK  (0x2U)
> +#define ARM_ID_AA64ISAR0_EL1_RNDR_FEAT_RNG_MASK   (0x1U)
> +
> +/**
> +  Reads the current value of ID_AA64ISAR0_EL1 register.
> +
> +  Reads and returns the current value of ID_AA64ISAR0_EL1.
> +  This function is only available on AARCH64.
> +
> +  @return The current value of ID_AA64ISAR0_EL1
> +**/
> +UINT64
> +EFIAPI
> +ArmReadIdAA64Isar0Reg (
> +  VOID
> +  );
> +
>  #endif // defined (MDE_CPU_AARCH64)
>  
>  #if defined (MDE_CPU_RISCV64)
> diff --git a/MdePkg/Library/BaseLib/AArch64/ArmReadIdAA64Isar0Reg.S 
> b/MdePkg/Library/BaseLib/AArch64/ArmReadIdAA64Isar0Reg.S
> new file mode 100644
> index ..4e61b869a401
> --- /dev/null
> +++ b/MdePkg/Library/BaseLib/AArch64/ArmReadIdAA64Isar0Reg.S
> @@ -0,0 +1,30 @@
> +#--
> +#
> +# ArmReadIdAA64Isar0Reg() for AArch64
> +#
> +# Copyright 

Re: [edk2-devel] [PATCH v2 1/7] MdePkg/BaseLib: AARCH64: Add ArmReadCntPctReg()

2023-11-09 Thread Leif Lindholm
On Thu, Nov 09, 2023 at 10:23:01 +0100, Pierre Gondois wrote:
> To enable AARCH64 native instruction support for Openssl,
> some interfaces must be implemented. OPENSSL_rdtsc() requests
> an access to a counter to get some non-trusted entropy.
> 
> Add ArmReadCntPctReg() to read system count.
> A similar ArmReadCntPct() function is available in the ArmPkg,
> but the CryptoPkg where OPENSSL_rdtsc will reside cannot rely
> on the ArmPkg.

This is patently untrue, as can be discovered by grepping for ArmPkg
under CryptoPkg already.

Yes, we have a problematic history around how architectures that
weren't already in tree when edk2 was first published got
introduced at a later date. But this bit of contortionism helps no one.
Please move this to ArmPkg, which is effectively an exclave of MdePkg
anyway.

(Yes, there is an argument for moving ArmLib into MdePkg, but that
quickly escalates through dependencies to moving all of ArmPkg into
MdePkg, and that's a fairly big task.)

/
Leif

> Signed-off-by: Pierre Gondois 
> ---
>  MdePkg/Include/Library/BaseLib.h  | 14 +
>  .../BaseLib/AArch64/ArmReadCntPctReg.S| 30 +++
>  .../BaseLib/AArch64/ArmReadCntPctReg.asm  | 30 +++
>  MdePkg/Library/BaseLib/BaseLib.inf|  4 ++-
>  4 files changed, 77 insertions(+), 1 deletion(-)
>  create mode 100644 MdePkg/Library/BaseLib/AArch64/ArmReadCntPctReg.S
>  create mode 100644 MdePkg/Library/BaseLib/AArch64/ArmReadCntPctReg.asm
> 
> diff --git a/MdePkg/Include/Library/BaseLib.h 
> b/MdePkg/Include/Library/BaseLib.h
> index 5d7067ee854e..b81c9dd83508 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -126,6 +126,20 @@ typedef struct {
>  
>  #define BASE_LIBRARY_JUMP_BUFFER_ALIGNMENT  8
>  
> +/**
> +  Reads the current value of CNTPCT_EL0 register.
> +
> +  Reads and returns the current value of CNTPCT_EL0.
> +  This function is only available on AARCH64.
> +
> +  @return The current value of CNTPCT_EL0
> +**/
> +UINT64
> +EFIAPI
> +ArmReadCntPctReg (
> +  VOID
> +  );
> +
>  #endif // defined (MDE_CPU_AARCH64)
>  
>  #if defined (MDE_CPU_RISCV64)
> diff --git a/MdePkg/Library/BaseLib/AArch64/ArmReadCntPctReg.S 
> b/MdePkg/Library/BaseLib/AArch64/ArmReadCntPctReg.S
> new file mode 100644
> index ..d5f3a0082a99
> --- /dev/null
> +++ b/MdePkg/Library/BaseLib/AArch64/ArmReadCntPctReg.S
> @@ -0,0 +1,30 @@
> +#--
> +#
> +# ArmReadCntPctReg() for AArch64
> +#
> +# Copyright (c) 2023, Arm Limited. All rights reserved.
> +#
> +# SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +#--
> +
> +.text
> +.p2align 2
> +GCC_ASM_EXPORT(ArmReadCntPctReg)
> +
> +#/**
> +#  Reads the CNTPCT_EL0 Register.
> +#
> +#  @return The contents of the CNTPCT_EL0 register.
> +#
> +#**/
> +#UINT64
> +#EFIAPI
> +#ArmReadCntPctReg (
> +#  VOID
> +#  );
> +#
> +ASM_PFX(ArmReadCntPctReg):
> +  AARCH64_BTI(c)
> +  mrs   x0, cntpct_el0
> +  ret
> diff --git a/MdePkg/Library/BaseLib/AArch64/ArmReadCntPctReg.asm 
> b/MdePkg/Library/BaseLib/AArch64/ArmReadCntPctReg.asm
> new file mode 100644
> index ..cfdfe4cea4eb
> --- /dev/null
> +++ b/MdePkg/Library/BaseLib/AArch64/ArmReadCntPctReg.asm
> @@ -0,0 +1,30 @@
> +;--
> +;
> +; ArmReadCntPctReg() for AArch64
> +;
> +; Copyright (c) 2023, Arm Limited. All rights reserved.
> +;
> +; SPDX-License-Identifier: BSD-2-Clause-Patent
> +;
> +;--
> +
> +  EXPORT ArmReadCntPctReg
> +  AREA BaseLib_LowLevel, CODE, READONLY
> +
> +;/**
> +;  Reads the CNTPCT_EL0 Register.
> +;
> +; @return The contents of the CNTPCT_EL0 register.
> +;
> +;**/
> +;UINT64
> +;EFIAPI
> +;ArmReadCntPctReg (
> +;  VOID
> +;  );
> +;
> +ArmReadCntPctReg
> +  mrs   x0, cntpct_el0
> +  ret
> +
> +  END
> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
> b/MdePkg/Library/BaseLib/BaseLib.inf
> index 03c7b02e828b..24e5e6c3ecb5 100644
> --- a/MdePkg/Library/BaseLib/BaseLib.inf
> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> @@ -3,7 +3,7 @@
>  #
>  #  Copyright (c) 2007 - 2021, Intel Corporation. All rights reserved.
>  #  Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
> -#  Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved.
> +#  Portions copyright (c) 2011 - 2023, Arm Limited. All rights reserved.
>  #  Copyright (c) 2020 - 2021, Hewlett Packard Enterprise Development LP. All 
> rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
> @@ -376,6 +376,7 @@ [Sources.AARCH64]
>AArch64/SetJumpLongJump.S | GCC
>AArch64/CpuBreakpoint.S   | GCC
>AArch64/SpeculationBarrier.S  | GCC
> +  AArch64/ArmReadCntPctReg.S| GCC
>  
>

Re: [edk2-devel] Soft Feature Freeze starts now for edk2-stable202311

2023-11-09 Thread Leif Lindholm

-announce, +discuss

On 2023-11-09 12:02, Marcin Juszkiewicz wrote:

W dniu 7.11.2023 o 01:59, gaoliming via groups.io pisze:


Below is edk2-stable202311 tag planning Proposed Schedule

Date (00:00:00 UTC-8) Description

2023-08-25 Beginning of development
2023-11-06 Soft Feature Freeze
2023-11-10 Hard Feature Freeze
2023-11-24 Release


Can edk2-platforms and edk2-non-osi be tagged at same time as edk2? 
There are projects outside which use both repositories to build firmware 
for their use.


I was contacted with one of them as they had problem with SBSA Reference 
Platform (sbsa-ref in QEMU, qemu-sbsa in TF-A, SbsaQemu in EDK2). Turned 
out that their set of git repositories was far too much out of sync with 
each other.


Having edk2-stable202311 tag in those 3 repositories show them exactly 
which versions to use and make their life easier.


TL;DR: yes.

That is the long-term plan.
Perhaps approaching medium-term now.

But that requires pruning of platforms that are no longer actively 
maintained, and ongoing validation efforts on all platforms in 
edk2-platforms.


On the whole, tagging edk2-platforms at the same time as we tag the main 
repo is unlikely to be beneficial. We'll need to introduce a freeze of 
the platforms tree once the main repo stable tag is made and then wait 
for reports/updates from maintainers.
And implement a deprecation/archiving process for platforms where this 
does not happen in a timely fashion.
And I guess also tag the edk2-non-osi repo at the same time as the 
platforms repo.


And there's not a whole lot of us to work on this. And currently we're 
focusing on migrating to the copilot^Wgithub PR system for 
submissions/review.


/
Leif



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




Re: [edk2-devel] [PATCH v2 10/11] DynamicTablesPkg: Add ArmScmiInfoLib

2023-11-09 Thread Leif Lindholm
On Thu, Nov 09, 2023 at 10:58:58 +0100, Pierre Gondois wrote:
> Hello Leif,
> 
> On 11/2/23 11:20, Pierre Gondois wrote:
> > 
> > 
> > On 10/26/23 13:03, Leif Lindholm wrote:
> > > On Wed, Oct 25, 2023 at 13:25:39 +0200, PierreGondois wrote:
> > > > From: Pierre Gondois 
> > > > 
> > > > The SCP holds some power information that could be advertised
> > > > through the _CPC object. The communication with the SCP is done
> > > > through SCMI protocols (c.f. ArmScmiDxe).
> > > > 
> > > > Use the SCMI protocols to query information and feed it to
> > > > the DynamicTablesPkg.
> > > 
> > > Couple of questions:
> > > With a generic name like ArmScmiInfoLib, does is belong in ArmPkg or
> > > MdeModulePkg?
> > > 
> > > Or if it's more tightly integrated with DynamicTablesPkg (not
> > > blatantly obvious from a quick skim below), should that be reflected
> > > by the library name?
> > 
> > The library is tight to the DynamicTablesPkg as it produces DynamicTablesPkg
> > specific objects. It uses the SCMI interface to fetch information from the 
> > SCP.
> > The ScmiProtocol resides in the ArmPkg, thus the name.
> > Does the name 'ScmiInfoLib' sound better ?
> 
> Should I keep ArmScmiInfoLib / ScmiInfoLib ?

I know it gets tedious with the long names, but if it's fully
integrated with DynamicTablesPkg, then it's kind of important that the
name does not imply it's generic; i.e., the name should be DynamicTable*.

If it helps clarify my thinking, my litmus test for this is I
don't want to have to go searching through code to determine whether

#include 

imports an Arm-specification header or a package-local helper.

> Also I'm not sure if there is a change required to:
>   [PATCH v2 01/11] ArmPkg/ArmScmiDxe: Rename PERFORMANCE_PROTOCOL_VERSION
> regarding the spec. reference, cf. 
> https://edk2.groups.io/g/devel/message/110515

I'm not sure I follow? A change in what way?

I agree the name is too generic. I didn't flag it because it replaces
a non-ideal thing with something that isn't any worse, and I'm trying
to cut down on asking people to fix existing quirks when adding new
features.

If you're happy to rename it while you're at it, I'm happy to take it.

Regards,

Leif

> Regards
> Pierre
> 
> > 
> > > 
> > > /
> > >   Leif
> > > 
> > > > Signed-off-by: Pierre Gondois 
> > > > ---
> > > >DynamicTablesPkg/DynamicTables.dsc.inc|   1 +
> > > >DynamicTablesPkg/DynamicTablesPkg.dec |   3 +
> > > >DynamicTablesPkg/DynamicTablesPkg.dsc |   1 +
> > > >.../Include/Library/ArmScmiInfoLib.h  |  33 ++
> > > >.../Library/ArmScmiInfoLib/ArmScmiInfoLib.c   | 294 
> > > > ++
> > > >.../Library/ArmScmiInfoLib/ArmScmiInfoLib.inf |  31 ++
> > > >6 files changed, 363 insertions(+)
> > > >create mode 100644 DynamicTablesPkg/Include/Library/ArmScmiInfoLib.h
> > > >create mode 100644 
> > > > DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.c
> > > >create mode 100644 
> > > > DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.inf
> > > > 
> > > > diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
> > > > b/DynamicTablesPkg/DynamicTables.dsc.inc
> > > > index 9d4312c4e87d..be40ebc4b472 100644
> > > > --- a/DynamicTablesPkg/DynamicTables.dsc.inc
> > > > +++ b/DynamicTablesPkg/DynamicTables.dsc.inc
> > > > @@ -15,6 +15,7 @@ [BuildOptions]
> > > >[LibraryClasses.common]
> > > >  
> > > > AcpiHelperLib|DynamicTablesPkg/Library/Common/AcpiHelperLib/AcpiHelperLib.inf
> > > >  AmlLib|DynamicTablesPkg/Library/Common/AmlLib/AmlLib.inf
> > > > +  
> > > > ArmScmiInfoLib|DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.inf
> > > >  
> > > > SsdtPcieSupportLib|DynamicTablesPkg/Library/Common/SsdtPcieSupportLib/SsdtPcieSupportLib.inf
> > > >  
> > > > SsdtSerialPortFixupLib|DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.inf
> > > >  
> > > > TableHelperLib|DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
> > > > diff --git a/DynamicTablesPkg/DynamicTablesPkg.dec 
> > > > b/DynamicTablesPkg/DynamicTablesPkg.dec
> > > > index cfbcbb9569f1..26498e5fec53 100644
> > > > --- a/DynamicTablesPkg/DynamicTablesPkg.dec
> >

Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Remove unused OvmfPkg Confidential Computing path

2023-11-09 Thread Leif Lindholm

Reviewed-by: Leif Lindholm 

I see no issues with this going in during soft freeze.

/
Leif

On 2023-11-08 03:49, Michael D Kinney wrote:

The following commit removed PlatformBootManagerLibGub from
OvmfPkg.  Update Maintainers.txt to remove reference to
deleted directory.

https://github.com/tianocore/edk2/commit/6fb2760dc8939b16a906b8e6bb224764907168f3

Cc: Andrew Fish 
Cc: Leif Lindholm 
Cc: Erdem Aktas 
Cc: Jiewen Yao 
Cc: Min Xu 
Cc: Tom Lendacky 
Cc: Michael Roth 
Signed-off-by: Michael D Kinney 
---
  Maintainers.txt | 1 -
  1 file changed, 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index cfbde42f2e04..7c0b4cb58cfd 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -497,7 +497,6 @@ F: OvmfPkg/Include/Guid/ConfidentialComputingSecret.h
  F: OvmfPkg/Include/Library/MemEncryptSevLib.h
  F: OvmfPkg/IoMmuDxe/CcIoMmu.*
  F: OvmfPkg/Library/BaseMemEncryptSevLib/
-F: OvmfPkg/Library/PlatformBootManagerLibGrub/
  F: OvmfPkg/Library/CcExitLib/
  F: OvmfPkg/PlatformPei/AmdSev.c
  F: OvmfPkg/ResetVector/




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




Re: [edk2-devel] [Patch v2 1/1] Maintainers.txt: Remove Orphan status option

2023-11-07 Thread Leif Lindholm

On 2023-11-05 20:04, Michael D Kinney wrote:

We would like any proposed change in the edk2 codebase to be
assignable to a human maintainer/reviewer. If there is a feature
for which there is no longer any support, we should find a way
to remove it from the head of the repository. For critical
features, we must find community members that are willing to
own it.

Cc: Andrew Fish 
Cc: Leif Lindholm 
Cc: Laszlo Ersek 
Signed-off-by: Michael D Kinney 
Reviewed-by: Laszlo Ersek 


Reviewed-by: Leif Lindholm 


---
  Maintainers.txt | 2 --
  1 file changed, 2 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 2b03ccbe54aa..cfbde42f2e04 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -31,8 +31,6 @@ Descriptions of section entries:
   Maintained: Someone actually looks after it.
   Odd Fixes:  It has a maintainer but they don't have time to do
   much other than throw the odd patch in. See below.
- Orphan: No current maintainer [but maybe you could take the
- role as you write your new code].
   Obsolete:   Old code. Something tagged obsolete generally means
   it has been replaced by a better system and you
   should be using that.




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




Re: [edk2-devel] [PATCH 1/1] BaseTools/tools_def: drop -mgeneral-regs-only for AArch64 CLANGDWARF

2023-11-07 Thread Leif Lindholm

Liming,

You reviewed this patch before the stable tag. Am I OK to stage a github 
PR for this change?


Reviewed-by: Leif Lindholm 

Regards,

Leif

On 2023-11-07 13:11, Yeping Song (QUIC) wrote:

Hi all,
I would like for this to be include in stable tag. Please help to review and 
merge this patch into stable release.
Thanks
Yepings


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Yeping Song
Sent: Saturday, November 4, 2023 12:38 AM
To: devel@edk2.groups.io
Cc: Yeping Song (QUIC) ; Rebecca Cran ; Liming Gao 
; Bob Feng ; Yuwei Chen ; Ard 
Biesheuvel ; Leif Lindholm (QUIC) ; Sami Mujawar 

Subject: [edk2-devel] [PATCH 1/1] BaseTools/tools_def: drop -mgeneral-regs-only 
for AArch64 CLANGDWARF

WARNING: This email originated from outside of Qualcomm. Please be wary of any 
links or attachments, and do not enable macros.

Commit 0df6c8c157af9 ("BaseTools/tools_def AARCH64:
avoid SIMD registers in XIP code")
adds -mgeneral-regs-only to GCC_AARCH64_CC_XIPFLAGS, in order to avoid a bug 
present in certain versions of GCC.
This was never a problem for clang.
That's given the history of what the problem is.
Then we can describe how we fix it:
Change *_CLANGDWARF_AARCH64_CC_XIPFLAGS to set the required -mstrict-align 
option instead of importing the whole GCC variable.

Signed-off-by: Yeping Song 
Cc: Rebecca Cran 
Cc: Liming Gao 
Cc: Bob Feng 
Cc: Yuwei Chen 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Sami Mujawar 
---
  BaseTools/Conf/tools_def.template | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 5bd5283655ea..c34ecfd557c5 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -2015,7 +2015,7 @@ DEFINE CLANGDWARF_AARCH64_DLINK_FLAGS  = 
DEF(CLANGDWARF_AARCH64_TARGET) DEF(GCC_
  *_CLANGDWARF_AARCH64_RC_FLAGS   = DEF(GCC_AARCH64_RC_FLAGS) 
DEF(GCC_AARCH64_RC_BTI_FLAGS)
  *_CLANGDWARF_AARCH64_VFRPP_FLAGS= DEF(GCC_VFRPP_FLAGS) 
DEF(CLANGDWARF_AARCH64_TARGET) $(PLATFORM_FLAGS)
  *_CLANGDWARF_AARCH64_ASLPP_FLAGS= DEF(GCC_ASLPP_FLAGS) 
DEF(CLANGDWARF_AARCH64_TARGET)
-*_CLANGDWARF_AARCH64_CC_XIPFLAGS= DEF(GCC_AARCH64_CC_XIPFLAGS)
+*_CLANGDWARF_AARCH64_CC_XIPFLAGS= -mstrict-align

DEBUG_CLANGDWARF_AARCH64_CC_FLAGS= DEF(CLANGDWARF_AARCH64_CC_FLAGS) 
$(PLATFORM_FLAGS) -flto -O1
DEBUG_CLANGDWARF_AARCH64_DLINK_FLAGS = DEF(CLANGDWARF_AARCH64_DLINK_FLAGS) 
-flto -Wl,-O1 -fuse-ld=lld -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64 
-Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wl,--no-pie,--no-relax
--
2.25.1










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




Re: [edk2-devel] [PATCH v2 02/11] ArmPkg/ArmScmiDxe: Add PERFORMANCE_DESCRIBE_FASTCHANNEL support

2023-11-02 Thread Leif Lindholm

On 2023-11-02 10:19, PierreGondois wrote:


+/// SCMI Message Ids for the Performance Protocol.
+typedef enum {
+  ScmiMessageIdPerformanceDomainAttributes    = 0x3,
+  ScmiMessageIdPerformanceDescribeLevels  = 0x4,
+  ScmiMessageIdPerformanceLimitsSet   = 0x5,
+  ScmiMessageIdPerformanceLimitsGet   = 0x6,
+  ScmiMessageIdPerformanceLevelSet    = 0x7,
+  ScmiMessageIdPerformanceLevelGet    = 0x8,
+  ScmiMessageIdPerformanceDescribeFastchannel = 0xB,
+} SCMI_MESSAGE_ID_PERFORMANCE;


This struct appears to move in the code at the same time as having an
entry added to it. This seems superficially unmotivated.
However it is also moved to inside the pack(1) block, which makes no
sense for an enum.


Yes right, I will move it out of the pack(1) section.


Thx, with that change:
Reviewed-by: Leif Lindholm 

The reason to move the SCMI_MESSAGE_ID_PERFORMANCE definition up in the 
file

was that the SCMI_PERFORMANCE_DESCRIBE_FASTCHANNEL interface added in this
patch takes a SCMI_MESSAGE_ID_PERFORMANCE parameter as an argument, so the
enum needs to be defined before.
I can add a comment about this in the commit message.


It doesn't really need to be in the commit message, but it's the kind of 
thing that can be helpful to point out below ---.


Regards,

Leif



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




Re: [edk2-devel] CodeQL and Apache Licensed Files

2023-11-01 Thread Leif Lindholm

On 2023-10-31 19:49, Pedro Falcato wrote:

On Tue, Oct 31, 2023 at 7:43 PM Kinney, Michael D
 wrote:


Hi Pedro,

SPDX is only for licenses, not copyrights.


IANAL, but several FOSS projects (including Linux) have generally
replaced the "Copyright (c) ..." verbiage with SPDX.


They may have decided to get rid of the copyright statements at the same 
time as they switched to SPDX instead of full boilerplate licenses, but 
that is not the same thing.


/
Leif


I assume there has to be some legal basis for this, although I don't
know if it depends on the license, etc
(IIRC I /think/ one could state that copyright holders are stored in
git information, but, again, I'm not a lawyer)





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




Re: [edk2-devel] [Patch 1/1] Maintainers.txt: Update based on active community members

2023-10-31 Thread Leif Lindholm
On Sat, Oct 28, 2023 at 12:23:30 -0700, Michael D Kinney wrote:
> Over the past few months, all the of the Maintainers and
> Reviewers listed in Maintainers.txt have been contacted to make
> sure Maintainers.txt accurately represents the TianoCore
> community members that are actively participating in their
> roles.  Based on specific feedback, bounced emails, and no
> responses, updates have been made.
> 
> * RISCV64: Daniel Schaefer replaced with Andrei Warkentin
> * ArmVirtPkg Xen has no remaining reviewers and review
>   responsibility defaults to ArmVirtPkg Maintainers/Reviewers.
> * ACPI modules related to S3 has no remaining reviewers and
>   review responsibility defaults to MdeModulePkg Maintainers/
>   Reviewers.
> * OVMF CSM modules has no remaining reviewers and review
>   responsibility defaults to OvmfPkg Maintainers/Reviewers.
> * Bounce: Chan Laura 
> * Many smaller updates removing individuals that are no
>   longer involved or have replacement coverage.
> 
> Cc: Andrew Fish 
> Cc: Leif Lindholm 
> Cc: Andrei Warkentin 
> Cc: Catharine West 
> Cc: Dandan Bi 
> Cc: Daniel Schaefer 
> Cc: David Woodhouse 
> Cc: Debkumar De 
> Cc: Eric Dong 
> Cc: Guomin Jiang 
> Cc: Hao A Wu 
> Cc: James Bottomley 
> Cc: Jian J Wang 
> Cc: Jordan Justen 
> Cc: Julien Grall 
> Cc: Peter Grehan 
> Cc: Qi Zhang 
> Cc: Ray Han Lim Ng 
> Cc: Stefan Berger 
> Cc: Wenxing Hou 
> Cc: Xiaoyu Lu 
> Signed-off-by: Michael D Kinney 

Reviewed-by: Leif Lindholm 

(I have some comments for later in the thread, but they do not affect
this patch.)

/
Leif

> ---
>  Maintainers.txt | 53 ++---
>  1 file changed, 2 insertions(+), 51 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 3f40cdeb5554..2b03ccbe54aa 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -93,7 +93,7 @@ M: Sami Mujawar  [samimujawar]
>  RISCV64
>  F: */RiscV64/
>  M: Sunil V L  [vlsunil]
> -R: Daniel Schaefer  [JohnAZoidberg]
> +R: Andrei Warkentin  [andreiw]
>  
>  LOONGARCH64
>  F: */LoongArch64/
> @@ -157,16 +157,6 @@ R: Leif Lindholm  
> [leiflindholm]
>  R: Sami Mujawar  [samimujawar]
>  R: Gerd Hoffmann  [kraxel]
>  
> -ArmVirtPkg: modules used on Xen
> -F: ArmVirtPkg/ArmVirtXen.*
> -F: ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/
> -F: ArmVirtPkg/Library/XenVirtMemInfoLib/
> -F: ArmVirtPkg/PrePi/
> -F: ArmVirtPkg/XenAcpiPlatformDxe/
> -F: ArmVirtPkg/XenPlatformHasAcpiDtDxe/
> -F: ArmVirtPkg/XenioFdtDxe/
> -R: Julien Grall  [jgrall]
> -
>  BaseTools
>  F: BaseTools/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools
> @@ -187,8 +177,7 @@ F: CryptoPkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/CryptoPkg
>  M: Jiewen Yao  [jyao1]
>  M: Yi Li  [liyi77]
> -R: Xiaoyu Lu  [xiaoyuxlu]
> -R: Guomin Jiang  [guominjia]
> +R: Wenxing Hou  [Wenxing-hou]
>  
>  DynamicTablesPkg
>  F: DynamicTablesPkg/
> @@ -202,7 +191,6 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/EmbeddedPkg
>  M: Leif Lindholm  [leiflindholm]
>  M: Ard Biesheuvel  [ardbiesheuvel]
>  M: Abner Chang  [changab]
> -R: Daniel Schaefer  [JohnAZoidberg]
>  
>  EmulatorPkg
>  F: EmulatorPkg/
> @@ -228,7 +216,6 @@ F: FmpDevicePkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg
>  M: Liming Gao  [lgao4]
>  M: Michael D Kinney  [mdkinney]
> -R: Guomin Jiang  [guominjia]
>  R: Wei6 Xu  [xuweiintel]
>  
>  IntelFsp2Pkg
> @@ -237,7 +224,6 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/IntelFsp2Pkg
>  M: Chasel Chiu  [ChaselChiu]
>  M: Nate DeSimone  [nate-desimone]
>  M: Duggapu Chinni B  [cbduggap]
> -M: Ray Han Lim Ng  [rayhanlimng]
>  R: Star Zeng  [lzeng14]
>  R: Ted Kuo  [tedkuo1]
>  R: Ashraf Ali S  [AshrafAliS]
> @@ -258,7 +244,6 @@ R: Susovan Mohapatra  
> [susovanmohapatra]
>  MdeModulePkg
>  F: MdeModulePkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/MdeModulePkg
> -M: Jian J Wang  [jwang36]
>  M: Liming Gao  [lgao4]
>  
>  MdeModulePkg: ACPI modules
> @@ -268,15 +253,6 @@ R: Zhiguang Liu  [LiuZhiguang001]
>  R: Dandan Bi  [dandanbi]
>  R: Liming Gao  [lgao4]
>  
> -MdeModulePkg: ACPI modules related to S3
> -F: MdeModulePkg/*LockBox*/
> -F: MdeModulePkg/Include/*BootScript*.h
> -F: MdeModulePkg/Include/*LockBox*.h
> -F: MdeModulePkg/Include/*S3*.h
> -F: MdeModulePkg/Library/*S3*/
> -R: Hao A Wu  [hwu25]
> -R: Eric Dong  [ydong10]
> -
>  MdeModulePkg: BDS modules
>  F: MdeModulePkg/*BootManager*/
>  F: MdeModulePkg/Include/Library/UefiBootManagerLib.h
> @@ -326,7 +302,6 @@ F: MdeModulePkg/L

Re: [edk2-devel] [PATCH edk2-platforms v6 4/4] SbsaQemu: disable XHCI in DSDT if not present

2023-10-26 Thread Leif Lindholm
(
>  DEBUG ((DEBUG_ERROR, "Failed to add GTDT table\n"));
>}
>  
> -  return EFI_SUCCESS;
> +  Status = DisableXhciOnOlderPlatVer ();
> +  if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_ERROR, "Failed to handle XHCI enablement\n"));
> +  }
> +
> +  return Status;

Right, this isn't what I asked for though.
There is nothing valid about returning a bad status here - it is the
entry point of the module. If we wanted some sort of error handling,
we would need to plumb that in manually.

Anyway, no point in you spinning another version, I'll change this
back to the original return statement.

For the series:
Reviewed-by: Leif Lindholm 
Pushed as 74b9eacfd453..d61836283a4c.

Thanks!


>  }
> diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
> b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> index 6661bc8195ee..b55ad6c5cc07 100644
> --- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> +++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> @@ -73,8 +73,9 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
>  Name (_HID, "PNP0D10")  // _HID: Hardware ID
>  Name (_UID, 0x00)// _UID: Unique ID
>  Name (_CCA, 0x01)// _CCA: Cache Coherency Attribute
> +Name (XHCI, 0xF)// will be set using AcpiLib
>  Method (_STA) {
> -  Return (0xF)
> +  Return (XHCI)
>  }
>  Method (_CRS, 0x0, Serialized) {
>  Name (RBUF, ResourceTemplate() {
> 
> -- 
> 2.41.0
> 


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




Re: [edk2-devel] [PATCH edk2-platforms 1/1] SbsaQemu: PCI node in DSDT does not need _ADR

2023-10-26 Thread Leif Lindholm
On Wed, Oct 18, 2023 at 14:38:26 +0200, Marcin Juszkiewicz wrote:
> 190: Device (PCI0) Warning  3073 -
> Multiple types ^  (Device object requires either a _HID or _ADR, but not both)
> 
> PCI Firmware specification does not require _ADR for Host bridges.
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 
Pushed as 74b9eacfd453.

Thanks!

> ---
>  Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
> b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> index ba3eefc975a5..b55ad6c5cc07 100644
> --- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> +++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> @@ -191,7 +191,6 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
>Name (_CID, EISAID ("PNP0A03")) // Compatible PCI Root Bridge
>Name (_SEG, Zero) // PCI Segment Group number
>Name (_BBN, Zero) // PCI Base Bus Number
> -  Name (_ADR, Zero)
>Name (_UID, "PCI0")
>Name (_CCA, One)// Initially mark the PCI coherent (for JunoR1)
>  
> -- 
> 2.41.0
> 


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




Re: [edk2-devel] [PATCH edk2-platforms v5 4/4] SbsaQemu: disable XHCI in DSDT if not present

2023-10-26 Thread Leif Lindholm
Couple of minor comments on this patch, rest of set good to go:

On Wed, Oct 18, 2023 at 13:55:41 +0200, Marcin Juszkiewicz wrote:
> We need platform version to be at least 0.3 to have XHCI
> in virtual hardware. On older platforms there is non-working
> EHCI which we ignore.
> 
> Set DSDT node to be disabled so operating system will not try
> to initialize not-existing hardware.
> 
> Signed-off-by: Marcin Juszkiewicz 
> ---
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf  |  4 ++
>  .../Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c| 68 
> +++-
>  Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl|  3 +-
>  3 files changed, 73 insertions(+), 2 deletions(-)
> 

> diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c 
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> index fd849ca1594b..464119de1457 100644
> --- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> +++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -682,6 +683,71 @@ AddGtdtTable (
>return Status;
>  }
>  
> +/*
> + * A function to disable XHCI node on Platform Version lower than 0.3
> + */

STATIC

> +EFI_STATUS
> +DisableXhciOnOlderPlatVer (
> +  VOID
> +  )
> +{
> +  EFI_STATUS   Status;
> +  EFI_ACPI_SDT_PROTOCOL*AcpiSdtProtocol;
> +  EFI_ACPI_DESCRIPTION_HEADER  *Table;
> +  UINTNTableKey;
> +  UINTNTableIndex;
> +  EFI_ACPI_HANDLE  TableHandle;
> +
> +  Status = EFI_SUCCESS;
> +
> +  if ( PLATFORM_VERSION_LESS_THAN (0, 3)) {
> +DEBUG ((DEBUG_ERROR, "Platform Version < 0.3 - disabling XHCI\n"));
> +Status = gBS->LocateProtocol (
> +  ,
> +  NULL,
> +  (VOID **)
> +  );
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "Unable to locate ACPI table protocol\n"));
> +  return Status;
> +}
> +
> +Status = AcpiLocateTableBySignature (
> + AcpiSdtProtocol,
> + 
> EFI_ACPI_6_3_DIFFERENTIATED_SYSTEM_DESCRIPTION_TABLE_SIGNATURE,
> + ,
> + ,
> + 
> + );
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "ACPI DSDT table not found!\n"));
> +  ASSERT_EFI_ERROR (Status);
> +  return Status;
> +}
> +
> +Status = AcpiSdtProtocol->OpenSdt (TableKey, );
> +if (EFI_ERROR (Status)) {
> +  ASSERT_EFI_ERROR (Status);
> +  AcpiSdtProtocol->Close (TableHandle);
> +  return Status;
> +}
> +
> +Status = AcpiAmlObjectUpdateInteger (AcpiSdtProtocol, TableHandle, 
> "\\_SB.USB0.XHCI", 0x0);
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "Failed to disable XHCI!\n"));
> +  ASSERT_EFI_ERROR (Status);
> +  AcpiSdtProtocol->Close (TableHandle);
> +  return Status;
> +}
> +
> +AcpiSdtProtocol->Close (TableHandle);
> +AcpiUpdateChecksum ((UINT8 *)Table, Table->Length);
> +  }
> +
> +  return Status;
> +}
> +
> +
>  EFI_STATUS
>  EFIAPI
>  InitializeSbsaQemuAcpiDxe (
> @@ -738,5 +804,5 @@ InitializeSbsaQemuAcpiDxe (
>  DEBUG ((DEBUG_ERROR, "Failed to add GTDT table\n"));
>}
>  
> -  return EFI_SUCCESS;
> +  return DisableXhciOnOlderPlatVer ();

Replacing the normal exit path like this unnecessarily ties this call
to the end of the function.

Please add another boring "if (EFI_ERROR ..." stanza instead.

/
Leif

>  }
> diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl 
> b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> index 543b5782580a..ba3eefc975a5 100644
> --- a/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> +++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Dsdt.asl
> @@ -73,8 +73,9 @@ DefinitionBlock ("DsdtTable.aml", "DSDT",
>  Name (_HID, "PNP0D10")  // _HID: Hardware ID
>  Name (_UID, 0x00)// _UID: Unique ID
>  Name (_CCA, 0x01)// _CCA: Cache Coherency Attribute
> +Name (XHCI, 0xF)// will be set using AcpiLib
>  Method (_STA) {
> -  Return (0xF)
> +  Return (XHCI)
>  }
>  Method (_CRS, 0x0, Serialized) {
>  Name (RBUF, ResourceTemplate() {
> 
> -- 
> 2.41.0
> 


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




Re: [edk2-devel] [edk2-platforms PATCH v1 1/4] Silicon/Marvell: Retructure package

2023-10-26 Thread Leif Lindholm
On Thu, Oct 26, 2023 at 16:35:52 +0100, Leif Lindholm wrote:
> On Wed, Oct 11, 2023 at 10:53:20 -0700, ndhil...@marvell.com wrote:
> > From: Narinder Dhillon 
> > 
> > Current Marvell package structure makes it difficult to add new silicon
> > packages that reuse common elements without creating nested DEC files.
> > 
> > This patch creates a new MarvellSiliconPkg folder and moves the current
> > common elements inside it.
> > 
> > Also gMarvellTokenSpaceGuid has been renamed to
> > gMarvellSiliconTokenSpaceGuid to align with new package name.
> 
> Ah, I also note this patch breaks bisect since it does not change the
> path in the affected .inf files:
> Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.inf:
> Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
> Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.inf:
> Platform/Marvell/Armada80x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
> Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.inf:
> Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.inf:
> Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
> Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.inf:
> Platform/SolidRun/Armada80x0McBin/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
> Platform/SolidRun/Cn913xCEx7Eval/BoardDescriptionLib/BoardDescriptionLib.inf:
> Platform/SolidRun/Cn913xCEx7Eval/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
> 
> That change needs to be squashed into this patch instead of introduced
> in 3/4.

Actually, belay that.
2, 3, 4 all need to be squashed into 1.
One of these years I'll learn to read through an entire set before
responding.

/
Leif

> /
> Leif
> 
> > Signed-off-by: Narinder Dhillon 
> > ---
> >  Silicon/Marvell/Marvell.dec   | 208 -
> >  .../Include/IndustryStandard/MvSmc.h  |   0
> >  .../Include/Library/ArmadaBoardDescLib.h  |   0
> >  .../Include/Library/ArmadaIcuLib.h|   0
> >  .../Include/Library/ArmadaSoCDescLib.h|   0
> >  .../Include/Library/MppLib.h  |   0
> >  .../Include/Library/MvComPhyLib.h |   0
> >  .../Include/Library/MvGpioLib.h   |   0
> >  .../Include/Library/NonDiscoverableInitLib.h  |   0
> >  .../Include/Library/SampleAtResetLib.h|   0
> >  .../Include/Library/UtmiPhyLib.h  |   0
> >  .../Include/Protocol/BoardDesc.h  |   0
> >  .../Include/Protocol/Eeprom.h |   0
> >  .../Include/Protocol/Mdio.h   |   0
> >  .../Include/Protocol/MvI2c.h  |   0
> >  .../Include/Protocol/MvPhy.h  |   0
> >  .../Include/Protocol/Spi.h|   0
> >  .../Include/Protocol/SpiFlash.h   |   0
> >  .../MarvellSiliconPkg/MarvellSiliconPkg.dec   | 211 ++
> >  19 files changed, 211 insertions(+), 208 deletions(-)
> >  delete mode 100644 Silicon/Marvell/Marvell.dec
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/IndustryStandard/MvSmc.h (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/ArmadaBoardDescLib.h (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/ArmadaIcuLib.h (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/ArmadaSoCDescLib.h (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MppLib.h 
> > (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/MvComPhyLib.h (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MvGpioLib.h 
> > (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/NonDiscoverableInitLib.h (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/SampleAtResetLib.h (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Library/UtmiPhyLib.h (100%)
> >  rename Silicon/Marvell/{ => 
> > MarvellSiliconPkg}/Include/Protocol/BoardDesc.h (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Eeprom.h 
> > (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Mdio.h 
> > (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/MvI2c.h 
> > (100%)
> >  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/MvPhy.h 
&

Re: [edk2-devel] [edk2-platforms PATCH v1 1/4] Silicon/Marvell: Retructure package

2023-10-26 Thread Leif Lindholm
On Wed, Oct 11, 2023 at 10:53:20 -0700, ndhil...@marvell.com wrote:
> From: Narinder Dhillon 
> 
> Current Marvell package structure makes it difficult to add new silicon
> packages that reuse common elements without creating nested DEC files.
> 
> This patch creates a new MarvellSiliconPkg folder and moves the current
> common elements inside it.
> 
> Also gMarvellTokenSpaceGuid has been renamed to
> gMarvellSiliconTokenSpaceGuid to align with new package name.

Ah, I also note this patch breaks bisect since it does not change the
path in the affected .inf files:
Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.inf:
Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.inf:
Platform/Marvell/Armada80x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.inf:
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.inf:
Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
Platform/SolidRun/Armada80x0McBin/Armada80x0McBinBoardDescLib/Armada80x0McBinBoardDescLib.inf:
Platform/SolidRun/Armada80x0McBin/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:
Platform/SolidRun/Cn913xCEx7Eval/BoardDescriptionLib/BoardDescriptionLib.inf:
Platform/SolidRun/Cn913xCEx7Eval/NonDiscoverableInitLib/NonDiscoverableInitLib.inf:

That change needs to be squashed into this patch instead of introduced
in 3/4.

/
Leif

> Signed-off-by: Narinder Dhillon 
> ---
>  Silicon/Marvell/Marvell.dec   | 208 -
>  .../Include/IndustryStandard/MvSmc.h  |   0
>  .../Include/Library/ArmadaBoardDescLib.h  |   0
>  .../Include/Library/ArmadaIcuLib.h|   0
>  .../Include/Library/ArmadaSoCDescLib.h|   0
>  .../Include/Library/MppLib.h  |   0
>  .../Include/Library/MvComPhyLib.h |   0
>  .../Include/Library/MvGpioLib.h   |   0
>  .../Include/Library/NonDiscoverableInitLib.h  |   0
>  .../Include/Library/SampleAtResetLib.h|   0
>  .../Include/Library/UtmiPhyLib.h  |   0
>  .../Include/Protocol/BoardDesc.h  |   0
>  .../Include/Protocol/Eeprom.h |   0
>  .../Include/Protocol/Mdio.h   |   0
>  .../Include/Protocol/MvI2c.h  |   0
>  .../Include/Protocol/MvPhy.h  |   0
>  .../Include/Protocol/Spi.h|   0
>  .../Include/Protocol/SpiFlash.h   |   0
>  .../MarvellSiliconPkg/MarvellSiliconPkg.dec   | 211 ++
>  19 files changed, 211 insertions(+), 208 deletions(-)
>  delete mode 100644 Silicon/Marvell/Marvell.dec
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/IndustryStandard/MvSmc.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/ArmadaBoardDescLib.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/ArmadaIcuLib.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/ArmadaSoCDescLib.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MppLib.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MvComPhyLib.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MvGpioLib.h 
> (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/NonDiscoverableInitLib.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/SampleAtResetLib.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/UtmiPhyLib.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/BoardDesc.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Eeprom.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Mdio.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/MvI2c.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/MvPhy.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Spi.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/SpiFlash.h 
> (100%)
>  create mode 100644 Silicon/Marvell/MarvellSiliconPkg/MarvellSiliconPkg.dec
> 
> diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
> deleted file mode 100644
> index 482a90da25..00
> --- a/Silicon/Marvell/Marvell.dec
> +++ /dev/null
> @@ -1,208 +0,0 @@
> -# Copyright (C) 2016 Marvell International Ltd.
> -#
> -# SPDX-License-Identifier: BSD-2-Clause-Patent
> -#
> -
> -[Defines]
> -  DEC_SPECIFICATION  = 0x00010005
> -  PACKAGE_NAME   = OpenPlatformMarvellPkg
> -  PACKAGE_GUID   = c372916e-83ad-4b2a-8410-bbc31bd9e68f
> -  PACKAGE_VERSION= 0.1
> -
> 

Re: [edk2-devel] [edk2-platforms PATCH v1 1/4] Silicon/Marvell: Retructure package

2023-10-26 Thread Leif Lindholm
Hi Nharinder,

Apologies for delay in responding - this was sent out during UEFI
plugfest, and then I brought home a cold from there.

On Wed, Oct 11, 2023 at 10:53:20 -0700, ndhil...@marvell.com wrote:
> From: Narinder Dhillon 
> 
> Current Marvell package structure makes it difficult to add new silicon
> packages that reuse common elements without creating nested DEC files.
> 
> This patch creates a new MarvellSiliconPkg folder and moves the current
> common elements inside it.
> 
> Also gMarvellTokenSpaceGuid has been renamed to
> gMarvellSiliconTokenSpaceGuid to align with new package name.
> 
> Signed-off-by: Narinder Dhillon 
> ---
>  Silicon/Marvell/Marvell.dec   | 208 -
>  .../Include/IndustryStandard/MvSmc.h  |   0
>  .../Include/Library/ArmadaBoardDescLib.h  |   0
>  .../Include/Library/ArmadaIcuLib.h|   0
>  .../Include/Library/ArmadaSoCDescLib.h|   0
>  .../Include/Library/MppLib.h  |   0
>  .../Include/Library/MvComPhyLib.h |   0
>  .../Include/Library/MvGpioLib.h   |   0
>  .../Include/Library/NonDiscoverableInitLib.h  |   0
>  .../Include/Library/SampleAtResetLib.h|   0
>  .../Include/Library/UtmiPhyLib.h  |   0
>  .../Include/Protocol/BoardDesc.h  |   0
>  .../Include/Protocol/Eeprom.h |   0
>  .../Include/Protocol/Mdio.h   |   0
>  .../Include/Protocol/MvI2c.h  |   0
>  .../Include/Protocol/MvPhy.h  |   0
>  .../Include/Protocol/Spi.h|   0
>  .../Include/Protocol/SpiFlash.h   |   0
>  .../MarvellSiliconPkg/MarvellSiliconPkg.dec   | 211 ++

I was curious as to what caused 208 lines to be deleted and 211 added.
A diff shows the below:

+  UtmiPhyLib|Include/Library/UtmiPhyLib.h
+  MppLib|Include/Library/MppLib.h
+  MvComPhyLib|Include/Library/MvComPhyLib.h

While it was clearly a bug that these were previously unlisted, I
think that should be changed by a separate patch, preceding this,
rather than as part of a rename operation.
There is also a trailing newline at the end of the.dec that would be
nice to get rid of. (Could be addressed in the same ".dec cleanup" patch.)

/
Leif

>  19 files changed, 211 insertions(+), 208 deletions(-)
>  delete mode 100644 Silicon/Marvell/Marvell.dec
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/IndustryStandard/MvSmc.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/ArmadaBoardDescLib.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/ArmadaIcuLib.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/ArmadaSoCDescLib.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MppLib.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MvComPhyLib.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/MvGpioLib.h 
> (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/NonDiscoverableInitLib.h (100%)
>  rename Silicon/Marvell/{ => 
> MarvellSiliconPkg}/Include/Library/SampleAtResetLib.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Library/UtmiPhyLib.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/BoardDesc.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Eeprom.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Mdio.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/MvI2c.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/MvPhy.h 
> (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/Spi.h (100%)
>  rename Silicon/Marvell/{ => MarvellSiliconPkg}/Include/Protocol/SpiFlash.h 
> (100%)
>  create mode 100644 Silicon/Marvell/MarvellSiliconPkg/MarvellSiliconPkg.dec
> 
> diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
> deleted file mode 100644
> index 482a90da25..00
> --- a/Silicon/Marvell/Marvell.dec
> +++ /dev/null
> @@ -1,208 +0,0 @@
> -# Copyright (C) 2016 Marvell International Ltd.
> -#
> -# SPDX-License-Identifier: BSD-2-Clause-Patent
> -#
> -
> -[Defines]
> -  DEC_SPECIFICATION  = 0x00010005
> -  PACKAGE_NAME   = OpenPlatformMarvellPkg
> -  PACKAGE_GUID   = c372916e-83ad-4b2a-8410-bbc31bd9e68f
> -  PACKAGE_VERSION= 0.1
> -
> -
> -#
> -# Include Section - list of Include Paths that are provided by this package.
> -#   Comments are used for Keywords and Module Types.
> -#
> -# Supported Module Types:
> -#  BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER 
> DXE_SMM_DRIVER DXE_SAL_DRIVER UEFI_DRIVER UEFI_APPLICATION
> -#
> 

Re: [edk2-devel] [PATCH edk2-platforms 1/1] Platform/SbsaQemu: use non-deprecated BaseRngLibTimerLib

2023-10-26 Thread Leif Lindholm
On Mon, Oct 09, 2023 at 09:36:58 +0200, Marcin Juszkiewicz wrote:
> During boot of debug build I noticed this message:
> 
> Warning: This BaseRngTimerLib implementation will be deprecated.
> Please use the MdeModulePkg implementation equivalent.
> 
> Signed-off-by: Marcin Juszkiewicz 

Reviewed-by: Leif Lindholm 
Pushed as 865a31472475.

Thanks!

> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc 
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 36723e21d7b5..806651fc55a0 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -148,7 +148,7 @@ [LibraryClasses.common]
>#
>IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
>OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> -  RngLib|MdePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf
> +  RngLib|MdeModulePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf
>BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
>  
>#
> -- 
> 2.41.0
> 


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




Re: [edk2-devel] [PATCH v2 11/11] DynamicTablesPkg: Remove check for _CPC field

2023-10-26 Thread Leif Lindholm
On Wed, Oct 25, 2023 at 13:25:40 +0200, pierre.gond...@arm.com wrote:
> From: Pierre Gondois 
> 
> When generating _CPC objects, some fields are mandatory.

Mandatory by spec or mandatory by current API?
If the former, could we either warn or add a Pcd to enable the more
lenient behaviour?

/
Leif

> Some fields cannot be supported by a the Juno platform, which is used
> to test the _CPC generation. Therefore, don't prevent from generating
> _CPC objects if the fields below are missing, and let the OS handle
> the missing information.
> 
> _CPC fields that are exempted from checks:
> - PerformanceLimitedRegister
> - ReferencePerformanceCounterRegister
> - DeliveredPerformanceCounterRegister
> 
> Signed-off-by: Pierre Gondois 
> ---
>  .../Common/AmlLib/CodeGen/AmlCodeGen.c| 19 +++
>  1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c 
> b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
> index f350083b148c..423e64f12606 100644
> --- a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
> +++ b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
> @@ -3531,6 +3531,11 @@ AmlCreateCpcNode (
>  return EFI_INVALID_PARAMETER;
>}
>  
> +  // The following fields are theoretically mandatory, but not supported
> +  // by some platforms. Don't check them:
> +  // - PerformanceLimitedRegister
> +  // - ReferencePerformanceCounterRegister
> +  // - DeliveredPerformanceCounterRegister
>if ((IsNullGenericAddress (>HighestPerformanceBuffer) &&
> (CpcInfo->HighestPerformanceInteger == 0)) ||
>(IsNullGenericAddress (>NominalPerformanceBuffer) &&
> @@ -3539,13 +3544,19 @@ AmlCreateCpcNode (
> (CpcInfo->LowestNonlinearPerformanceInteger == 0)) ||
>(IsNullGenericAddress (>LowestPerformanceBuffer) &&
> (CpcInfo->LowestPerformanceInteger == 0)) ||
> -  IsNullGenericAddress (>DesiredPerformanceRegister) ||
> -  IsNullGenericAddress (>ReferencePerformanceCounterRegister) ||
> -  IsNullGenericAddress (>DeliveredPerformanceCounterRegister) ||
> -  IsNullGenericAddress (>PerformanceLimitedRegister))
> +  IsNullGenericAddress (>DesiredPerformanceRegister))
>{
>  ASSERT (0);
>  return EFI_INVALID_PARAMETER;
> +  } else if ((IsNullGenericAddress (>HighestPerformanceBuffer) &&
> +  (CpcInfo->HighestPerformanceInteger == 0)) ||
> + (IsNullGenericAddress (>NominalPerformanceBuffer) &&
> +  (CpcInfo->NominalPerformanceInteger == 0)))
> +  {
> +DEBUG ((
> +  DEBUG_WARN,
> +  "Missing Reference|Delivered performance field in _CPC object\n"
> +  ));
>}
>  
>CpcPackage = NULL;
> -- 
> 2.25.1
> 


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




Re: [edk2-devel] [PATCH v2 10/11] DynamicTablesPkg: Add ArmScmiInfoLib

2023-10-26 Thread Leif Lindholm
On Wed, Oct 25, 2023 at 13:25:39 +0200, PierreGondois wrote:
> From: Pierre Gondois 
> 
> The SCP holds some power information that could be advertised
> through the _CPC object. The communication with the SCP is done
> through SCMI protocols (c.f. ArmScmiDxe).
> 
> Use the SCMI protocols to query information and feed it to
> the DynamicTablesPkg.

Couple of questions:
With a generic name like ArmScmiInfoLib, does is belong in ArmPkg or
MdeModulePkg?

Or if it's more tightly integrated with DynamicTablesPkg (not
blatantly obvious from a quick skim below), should that be reflected
by the library name?

/
Leif

> Signed-off-by: Pierre Gondois 
> ---
>  DynamicTablesPkg/DynamicTables.dsc.inc|   1 +
>  DynamicTablesPkg/DynamicTablesPkg.dec |   3 +
>  DynamicTablesPkg/DynamicTablesPkg.dsc |   1 +
>  .../Include/Library/ArmScmiInfoLib.h  |  33 ++
>  .../Library/ArmScmiInfoLib/ArmScmiInfoLib.c   | 294 ++
>  .../Library/ArmScmiInfoLib/ArmScmiInfoLib.inf |  31 ++
>  6 files changed, 363 insertions(+)
>  create mode 100644 DynamicTablesPkg/Include/Library/ArmScmiInfoLib.h
>  create mode 100644 DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.c
>  create mode 100644 DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.inf
> 
> diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc 
> b/DynamicTablesPkg/DynamicTables.dsc.inc
> index 9d4312c4e87d..be40ebc4b472 100644
> --- a/DynamicTablesPkg/DynamicTables.dsc.inc
> +++ b/DynamicTablesPkg/DynamicTables.dsc.inc
> @@ -15,6 +15,7 @@ [BuildOptions]
>  [LibraryClasses.common]
>
> AcpiHelperLib|DynamicTablesPkg/Library/Common/AcpiHelperLib/AcpiHelperLib.inf
>AmlLib|DynamicTablesPkg/Library/Common/AmlLib/AmlLib.inf
> +  ArmScmiInfoLib|DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.inf
>
> SsdtPcieSupportLib|DynamicTablesPkg/Library/Common/SsdtPcieSupportLib/SsdtPcieSupportLib.inf
>
> SsdtSerialPortFixupLib|DynamicTablesPkg/Library/Common/SsdtSerialPortFixupLib/SsdtSerialPortFixupLib.inf
>
> TableHelperLib|DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
> diff --git a/DynamicTablesPkg/DynamicTablesPkg.dec 
> b/DynamicTablesPkg/DynamicTablesPkg.dec
> index cfbcbb9569f1..26498e5fec53 100644
> --- a/DynamicTablesPkg/DynamicTablesPkg.dec
> +++ b/DynamicTablesPkg/DynamicTablesPkg.dec
> @@ -42,6 +42,9 @@ [LibraryClasses]
>##  @libraryclass  Defines a set of SMBIOS string helper methods.
>SmbiosStringTableLib|Include/Library/SmbiosStringTableLib.h
>  
> +  ##  @libraryclass  Defines a set of APIs to populate CmObj using SCMI.
> +  ArmScmiInfoLib|Include/Library/ArmScmiInfoLib.h
> +
>  [Protocols]
># Configuration Manager Protocol GUID
>gEdkiiConfigurationManagerProtocolGuid = { 0xd85a4835, 0x5a82, 0x4894, { 
> 0xac, 0x2, 0x70, 0x6f, 0x43, 0xd5, 0x97, 0x8e } }
> diff --git a/DynamicTablesPkg/DynamicTablesPkg.dsc 
> b/DynamicTablesPkg/DynamicTablesPkg.dsc
> index bd5084a9008f..6ea86c9efdb0 100644
> --- a/DynamicTablesPkg/DynamicTablesPkg.dsc
> +++ b/DynamicTablesPkg/DynamicTablesPkg.dsc
> @@ -39,6 +39,7 @@ [LibraryClasses.ARM, LibraryClasses.AARCH64]
>PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
>  
>  [Components.common]
> +  DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.inf
>DynamicTablesPkg/Library/Common/AcpiHelperLib/AcpiHelperLib.inf
>DynamicTablesPkg/Library/Common/AmlLib/AmlLib.inf
>DynamicTablesPkg/Library/Common/SsdtPcieSupportLib/SsdtPcieSupportLib.inf
> diff --git a/DynamicTablesPkg/Include/Library/ArmScmiInfoLib.h 
> b/DynamicTablesPkg/Include/Library/ArmScmiInfoLib.h
> new file mode 100644
> index ..8d3fb31df13c
> --- /dev/null
> +++ b/DynamicTablesPkg/Include/Library/ArmScmiInfoLib.h
> @@ -0,0 +1,33 @@
> +/** @file
> +  Arm SCMI Info Library.
> +
> +  Copyright (c) 2022 - 2023, Arm Limited. All rights reserved.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#ifndef ARM_SCMI_INFO_LIB_H_
> +#define ARM_SCMI_INFO_LIB_H_
> +
> +#include 
> +
> +/** Populate a AML_CPC_INFO object based on SCMI information.
> +
> +  @param[in]  DomainIdIdentifier for the performance domain.
> +  @param[out] CpcInfo If success, this structure was populated from
> +  information queried to the SCP.
> +
> +  @retval EFI_SUCCESS Success.
> +  @retval EFI_DEVICE_ERRORDevice error.
> +  @retval EFI_INVALID_PARAMETER   Invalid parameter.
> +  @retval EFI_TIMEOUT Time out.
> +  @retval EFI_UNSUPPORTED Unsupported.
> +**/
> +EFI_STATUS
> +EFIAPI
> +ArmScmiInfoGetFastChannel (
> +  IN  UINT32DomainId,
> +  OUT AML_CPC_INFO  *CpcInfo
> +  );
> +
> +#endif // ARM_SCMI_INFO_LIB_H_
> diff --git a/DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.c 
> b/DynamicTablesPkg/Library/ArmScmiInfoLib/ArmScmiInfoLib.c
> new file mode 100644
> index ..c23bff63bb6f
> --- /dev/null
> +++ 

Re: [edk2-devel] [PATCH v2 07/11] DynamicTablesPkg: Add PsdToken field to CM_ARM_GICC_INFO object

2023-10-26 Thread Leif Lindholm
On Wed, Oct 25, 2023 at 13:25:36 +0200, pierre.gond...@arm.com wrote:
> From: Pierre Gondois 
> 
> The _PSD object (cf. ACPI 6.4, s8.4.5.5 _PSD (P-State Dependency)
> allows to describe CPU's power state dependencies. Add a PsdToken
> field to the CM_ARM_GICC_INFO object so that interdependent CPUs
> can reference the same CM_ARM_PSD_INFO object.
> 
> Signed-off-by: Pierre Gondois 
> ---
>  DynamicTablesPkg/Include/ArmNameSpaceObjects.h   | 5 +
>  .../Common/TableHelperLib/ConfigurationManagerObjectParser.c | 5 +++--
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h 
> b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
> index ddd17fa45b1e..2a0ebe24bd04 100644
> --- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
> +++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h
> @@ -204,6 +204,11 @@ typedef struct CmArmGicCInfo {
>i.e. a token referencing a CM_ARM_CPC_INFO object.
>*/
>CM_OBJECT_TOKENCpcToken;
> +
> +  /** Optional field: Reference Token for the Psd info of this processor.
> +  i.e. a token referencing a CM_ARM_PSD_INFO object.
> +  */
> +  CM_OBJECT_TOKENPsdToken;
>  } CM_ARM_GICC_INFO;
>  
>  /** A structure that describes the
> diff --git 
> a/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
>  
> b/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
> index b3ee12da8c4f..a9f5c95c1039 100644
> --- 
> a/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
> +++ 
> b/DynamicTablesPkg/Library/Common/TableHelperLib/ConfigurationManagerObjectParser.c
> @@ -83,7 +83,8 @@ STATIC CONST CM_OBJ_PARSER  CmArmGicCInfoParser[] = {
>{ "ProximityDomain",   4,"0x%x",   
> NULL },
>{ "ClockDomain",   4,"0x%x",   
> NULL },
>{ "AffinityFlags", 4,"0x%x",   
> NULL },
> -  { "CpcToken",  sizeof (CM_OBJECT_TOKEN), "0x%p",   
> NULL }
> +  { "CpcToken",  sizeof (CM_OBJECT_TOKEN), "0x%p",   
> NULL },
> +  { "PsdToken",  sizeof (CM_OBJECT_TOKEN), "0x%p",   
> NULL },
>  };
>  
>  /** A parser for EArmObjGicDInfo.
> @@ -766,7 +767,7 @@ STATIC CONST CM_OBJ_PARSER_ARRAY  
> ArmNamespaceObjectParser[] = {
>  ARRAY_SIZE (CmArmPccSubspaceType34InfoParser) },
>{ "EArmObjPccSubspaceType5Info", CmArmPccSubspaceType5InfoParser,
>  ARRAY_SIZE (CmArmPccSubspaceType5InfoParser) },
> -  { "EArmObjCpcInfo",  CmArmPsdInfoParser,
> +  { "EArmObjPsdInfo",  CmArmPsdInfoParser,

Can you add something to the commit message about this bit?

/
Leif

>  ARRAY_SIZE (CmArmPsdInfoParser) },
>{ "EArmObjMax",  NULL, 
>  0},
>  };
> -- 
> 2.25.1
> 


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




Re: [edk2-devel] [PATCH v2 02/11] ArmPkg/ArmScmiDxe: Add PERFORMANCE_DESCRIBE_FASTCHANNEL support

2023-10-26 Thread Leif Lindholm
On Wed, Oct 25, 2023 at 13:25:31 +0200, PierreGondois wrote:
> From: Pierre Gondois 

Sidebar: I think if you correct your name in your git config, the
above tag will drop out.

> The PERFORMANCE_DESCRIBE_FASTCHANNEL Scmi command is available
> since SCMI v2.0 and allows to query information about the supported
> fast-channels of the Scmi performance protocol.
> Add support for this command.
> 
> Signed-off-by: Pierre Gondois 
> ---
>  .../ArmScmiDxe/ScmiPerformanceProtocol.c  | 80 +++--
>  .../Protocol/ArmScmiPerformanceProtocol.h | 90 ---
>  2 files changed, 155 insertions(+), 15 deletions(-)
> 
> diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c 
> b/ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c
> index 0f89808fbdf9..1d87339209fd 100644
> --- a/ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c
> +++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c
> @@ -1,12 +1,12 @@
>  /** @file
>  
> -  Copyright (c) 2017-2021, Arm Limited. All rights reserved.
> +  Copyright (c) 2017-2023, Arm Limited. All rights reserved.
>  
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
> -  System Control and Management Interface V1.0
> -http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/
> -DEN0056A_System_Control_and_Management_Interface.pdf
> +  System Control and Management Interface, latest version:
> +  - https://developer.arm.com/documentation/den0056/latest/
> +
>  **/
>  
>  #include 
> @@ -416,6 +416,75 @@ PerformanceLevelGet (
>return EFI_SUCCESS;
>  }
>  
> +/** Discover the attributes of the FastChannel for the specified
> +performance domain and the specified message.
> +
> +  @param[in]  ThisA Pointer to SCMI_PERFORMANCE_PROTOCOL Instance.
> +  @param[in]  DomainIdIdentifier for the performance domain.
> +  @param[in]  MessageId   Message Id of the FastChannel to discover.
> +  Must be one of:
> +   - PERFORMANCE_LIMITS_SET
> +   - PERFORMANCE_LIMITS_GET
> +   - PERFORMANCE_LEVEL_SET
> +   - PERFORMANCE_LEVEL_GET
> +  @param[out] FastChannel If success, contains the FastChannel description.
> +
> +  @retval EFI_SUCCESS Performance level got successfully.
> +  @retval EFI_DEVICE_ERRORSCP returns an SCMI error.
> +  @retval EFI_INVALID_PARAMETER   Invalid parameter.
> +  @retval EFI_TIMEOUT Time out.
> +  @retval EFI_UNSUPPORTED Unsupported.
> +**/
> +EFI_STATUS
> +DescribeFastchannel (
> +  IN  SCMI_PERFORMANCE_PROTOCOL *This,
> +  IN  UINT32DomainId,
> +  IN  SCMI_MESSAGE_ID_PERFORMANCE   MessageId,
> +  OUT SCMI_PERFORMANCE_FASTCHANNEL  *FastChannel
> +  )
> +{
> +  EFI_STATUSStatus;
> +  SCMI_COMMAND  Cmd;
> +  UINT32PayloadLength;
> +  UINT32*ReturnValues;
> +  UINT32*MessageParams;
> +
> +  if ((This == NULL)  ||
> +  (FastChannel == NULL))
> +  {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  Status = ScmiCommandGetPayload ();
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +
> +  *MessageParams++ = DomainId;
> +  *MessageParams   = MessageId;
> +
> +  Cmd.ProtocolId = ScmiProtocolIdPerformance;
> +  Cmd.MessageId  = ScmiMessageIdPerformanceDescribeFastchannel;
> +  PayloadLength  = sizeof (DomainId) + sizeof (MessageId);
> +
> +  Status = ScmiCommandExecute (
> + ,
> + ,
> + 
> + );
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
> +
> +  CopyMem (
> +FastChannel,
> +ReturnValues,
> +sizeof (SCMI_PERFORMANCE_FASTCHANNEL)
> +);
> +
> +  return Status;
> +}
> +
>  // Instance of the SCMI performance management protocol.
>  STATIC CONST SCMI_PERFORMANCE_PROTOCOL  PerformanceProtocol = {
>PerformanceGetVersion,
> @@ -425,7 +494,8 @@ STATIC CONST SCMI_PERFORMANCE_PROTOCOL  
> PerformanceProtocol = {
>PerformanceLimitsSet,
>PerformanceLimitsGet,
>PerformanceLevelSet,
> -  PerformanceLevelGet
> +  PerformanceLevelGet,
> +  DescribeFastchannel,
>  };
>  
>  /** Initialize performance management protocol and install on a given Handle.
> diff --git a/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h 
> b/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
> index 8e8e05d5a5f6..088182945a06 100644
> --- a/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
> +++ b/ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h
> @@ -14,7 +14,7 @@
>  
>  #include 
>  
> -/// Arm Scmi performance protocol versions.
> +/// Arm SCMI performance protocol versions.
>  #define PERFORMANCE_PROTOCOL_VERSION_V1  0x1
>  #define PERFORMANCE_PROTOCOL_VERSION_V2  0x2
>  #define PERFORMANCE_PROTOCOL_VERSION_V3  0x3
> @@ -79,6 +79,56 @@ typedef struct {
>UINT32RangeMin;
>  } SCMI_PERFORMANCE_LIMITS;
>  
> +/// Doorbell Support bit.
> +#define SCMI_PERF_FC_ATTRIB_HAS_DOORBELL  BIT0
> +
> +/// 

  1   2   3   4   5   6   7   8   9   10   >