colin/u-boot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge tag 'efi-2023-01-rc4' of https://source.denx.de/u-boot/custodians/u-boot-efi

Browse Source 
Pull request for efi-2023-01-rc4

Documentation:

* Fix htmldoc build dependency

UEFI:

* Adjust EBBR version for compatibility table
This commit is contained in:
Tom Rini
2022-12-18 08:10:09 -05:00
parent 55e374f508 5b5f6e0d61
commit 255cebbfa3
9 changed files with 33 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
doc/develop/process.rst
View File

@@ -165,8 +165,8 @@ document.
<https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`_
and similar additional tags.
* Reviewed-by: The patch has been reviewed and found acceptible according to
the `Reveiwer's statement of oversight
* Reviewed-by: The patch has been reviewed and found acceptable according to
the `Reviewer's statement of oversight
<https://www.kernel.org/doc/html/latest/process/submitting-patches.html#reviewer-s-statement-of-oversight>`_.
A *Reviewed-by:* tag is a statement of opinion that the patch is an
appropriate modification of the code without any remaining serious technical
@@ -193,8 +193,8 @@ document.
* Cc: If a person should have the opportunity to comment on a patch, you may
optionally add a *Cc:* tag to the patch. Git tools (git send-email) will then
automatically arrange that they receives a copy of the patch when you submit it
to the mainling list. This is the only tag which might be added without an
automatically arrange that they receives a copy of the patch when you submit
it to the mailing list. This is the only tag which might be added without an
explicit action by the person it names. This tag documents that potentially
interested parties have been included in the discussion.
For example, when your change affects a specific board or driver, then makes
@@ -209,7 +209,7 @@ like this:
#. The responsible custodian inspects this patch, especially for:
#. The commit message is useful, descriptive and makes correct and
appropraite usage of required *git tags*.
appropriate usage of required *git tags*.
#. :doc:`codingstyle`
@@ -251,7 +251,7 @@ like this:
workflows and environments however.
#. Although a custodian is supposed to perform their own tests it is a
well-known and accepted fact that they needs help from other developers who
well-known and accepted fact that they need help from other developers who
- for example - have access to the required hardware or other relevant
environments. Custodians are expected to ask for assistance with testing
when required.

10
doc/develop/sending_patches.rst
View File

@@ -20,8 +20,8 @@ LWN article `How to Get Your Change Into the Linux Kernel
Using patman
------------
You can use a tool called patman to prepare, check and sent patches. It creates
change logs, cover letters and patch notes. It also simplified the process of
You can use a tool called patman to prepare, check and send patches. It creates
change logs, cover letters and patch notes. It also simplifies the process of
sending multiple versions of a series.
See more details at :doc:`patman`.
@@ -93,7 +93,7 @@ General Patch Submission Rules
visible as headline of your commit message. Make sure the subject does not
exceed 60 characters or so.
* The start of the subject should be a meaningfull tag (arm:, ppc:, tegra:,
* The start of the subject should be a meaningful tag (arm:, ppc:, tegra:,
net:, ext2:, etc)
* Include the string "PATCH" in the Subject: line of your message, e. g.
@@ -247,7 +247,7 @@ When re-posting such a new version of your patch(es), please always make sure
to observe the following rules.
* Make an appropriate note that this is a re-submission in the subject line,
eg. "[PATCH v2] Add support for feature X". ``git format-patch
e.g. "[PATCH v2] Add support for feature X". ``git format-patch
--subject-prefix="PATCH v2"`` can be used in this case (see the example
below).
@@ -312,7 +312,7 @@ Notes
2. All code must follow the :doc:`codingstyle` requirements.
3. Before sending the patch, you *must* run some form of local testing.
Submitting a patch that does not build or function correct is a mistake. For
Submitting a patch that does not build or function correctly is a mistake. For
non-trivial patches, either building a number of platforms locally or making
use of :doc:`ci_testing` is strongly encouraged in order to avoid problems
that can be found when attempting to merge the patch.

6
doc/develop/system_configuration.rst
View File

@@ -86,12 +86,12 @@ When to use each mechanism
^^^^^^^^^^^^^^^^^^^^^^^^^^
While there are some cases where it should be fairly obvious where to use each
mechanism, as for example a command would done via Kconfig, a new I2C driver
mechanism, as for example a command would be done via Kconfig, a new I2C driver
should use Kconfig and be configured via driver model and a header of values
generated by an external tool should be ``CFG``, there will be cases where it's
less clear and one needs to take care when implementing it. In general,
configuration *options* should be done in Kconfig and configuration *settings*
should done in driver model or ``CFG``. Let us discuss things to keep in mind
should be done in driver model or ``CFG``. Let us discuss things to keep in mind
when picking the appropriate mechanism.
A thing to keep in mind is that we have a strong preference for using Kconfig as
@@ -122,7 +122,7 @@ to use Kconfig in this case, it would result in using calculated rather than
constructed values, resulting in less clear code. Consider the example of a set
of register values for a memory controller. Defining this as a series of logical
ORs and shifts based on other defines is more clear than the Kconfig entry that
set the calculated value alone.
sets the calculated value alone.
When it has been determined that the practical solution is to utilize the
``CFG`` mechanism, the next decision is where to place these settings. It is

6
doc/develop/uefi/uefi.rst
View File

@@ -14,7 +14,7 @@ Development target
------------------
The implementation of UEFI in U-Boot strives to reach the requirements described
in the "Embedded Base Boot Requirements (EBBR) Specification - Release v1.0"
in the "Embedded Base Boot Requirements (EBBR) Specification - Release v2.1.0"
[2]. The "Server Base Boot Requirements System Software on ARM Platforms" [3]
describes a superset of the EBBR specification and may be used as further
reference.
@@ -799,8 +799,8 @@ Links
-----
* [1] http://uefi.org/specifications - UEFI specifications
* [2] https://github.com/ARM-software/ebbr/releases/download/v1.0/ebbr-v1.0.pdf -
Embedded Base Boot Requirements (EBBR) Specification - Release v1.0
* [2] https://github.com/ARM-software/ebbr/releases/download/v2.1.0/ebbr-v2.1.0.pdf -
Embedded Base Boot Requirements (EBBR) Specification - Release v2.1.0
* [3] https://developer.arm.com/docs/den0044/latest/server-base-boot-requirements-system-software-on-arm-platforms-version-11 -
Server Base Boot Requirements System Software on ARM Platforms - Version 1.1
* [4] :doc:`iscsi`

2
doc/sphinx/requirements.txt
View File

@@ -1,6 +1,6 @@
alabaster==0.7.12
Babel==2.9.1
certifi==2021.10.8
certifi==2022.12.7
charset-normalizer==2.0.12
docutils==0.16
idna==3.3

2
include/efi_api.h
View File

@@ -232,7 +232,7 @@ enum efi_reset_type {
#define EFI_CONFORMANCE_PROFILES_TABLE_VERSION 1
#define EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID \
#define EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID \
EFI_GUID(0xcce33c35, 0x74ac, 0x4087, 0xbc, 0xe7, \
0x8b, 0x29, 0xb0, 0x2e, 0xeb, 0x27)

6
lib/efi_loader/Kconfig
View File

@@ -384,8 +384,8 @@ config EFI_ECPT
help
Enabling this option created the ECPT UEFI table.
config EFI_EBBR_2_0_CONFORMANCE
bool "Add the EBBRv2.0 conformance entry to the ECPT table"
config EFI_EBBR_2_1_CONFORMANCE
bool "Add the EBBRv2.1 conformance entry to the ECPT table"
depends on EFI_ECPT
depends on EFI_LOADER_HII
depends on EFI_RISCV_BOOT_PROTOCOL || !RISCV
@@ -393,7 +393,7 @@ config EFI_EBBR_2_0_CONFORMANCE
depends on EFI_UNICODE_COLLATION_PROTOCOL2
default y
help
Enabling this option adds the EBBRv2.0 conformance entry to the ECPT UEFI table.
Enabling this option adds the EBBRv2.1 conformance entry to the ECPT UEFI table.
config EFI_RISCV_BOOT_PROTOCOL
bool "RISCV_EFI_BOOT_PROTOCOL support"

8
lib/efi_loader/efi_conformance.c
View File

@@ -12,8 +12,8 @@
#include <malloc.h>
static const efi_guid_t efi_ecpt_guid = EFI_CONFORMANCE_PROFILES_TABLE_GUID;
static const efi_guid_t efi_ebbr_2_0_guid =
EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID;
static const efi_guid_t efi_ebbr_2_1_guid =
EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID;
/**
* efi_ecpt_register() - Install the ECPT system table.
@@ -38,9 +38,9 @@ efi_status_t efi_ecpt_register(void)
return ret;
}
if (CONFIG_IS_ENABLED(EFI_EBBR_2_0_CONFORMANCE))
if (CONFIG_IS_ENABLED(EFI_EBBR_2_1_CONFORMANCE))
guidcpy(&ecpt->conformance_profiles[num_entries++],
&efi_ebbr_2_0_guid);
&efi_ebbr_2_1_guid);
ecpt->version = EFI_CONFORMANCE_PROFILES_TABLE_VERSION;
ecpt->number_of_profiles = num_entries;

6
lib/efi_selftest/efi_selftest_ecpt.c
View File

@@ -10,7 +10,7 @@
#include <efi_selftest.h>
static const efi_guid_t guid_ecpt = EFI_CONFORMANCE_PROFILES_TABLE_GUID;
static const efi_guid_t guid_ebbr_2_0 = EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID;
static const efi_guid_t guid_ebbr_2_1 = EFI_CONFORMANCE_PROFILE_EBBR_2_1_GUID;
/*
* ecpt_find_guid() - find GUID in EFI Conformance Profile Table
@@ -53,9 +53,9 @@ static int execute(void)
return EFI_ST_FAILURE;
}
if (CONFIG_IS_ENABLED(EFI_EBBR_2_0_CONFORMANCE)) {
if (CONFIG_IS_ENABLED(EFI_EBBR_2_1_CONFORMANCE)) {
++expected_entries;
if (ecpt_find_guid(ecpt, &guid_ebbr_2_0))
if (ecpt_find_guid(ecpt, &guid_ebbr_2_1))
return EFI_ST_FAILURE;
}