On Mon, Oct 07, 2019 at 10:23:32PM +0800, Bin Meng wrote:

Hi Tom,

On Mon, Oct 7, 2019 at 10:15 PM Tom Rini trini@konsulko.com wrote:

...

On Sun, Oct 06, 2019 at 11:13:21PM +0200, Heinrich Schuchardt wrote:

...

The following changes since commit dac51e9aaf6fd38298007b266feb6a80e9ec91ee:

Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-10-05 20:06:58 -0400)

are available in the Git repository at:

https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2020-01-rc1

for you to fetch changes up to 3b728f8728fa7c596d30ecd27ebb64d37a54a12e:

cmd: disable CMD_NVEDIT_EFI by default (2019-10-06 16:02:37 +0200)

---

Pull request for UEFI sub-system for efi-2020-01-rc1

The major corrections in this pull request are:

Fixes for the SetVariable() boot service. Device path node for NVMe drives. Disable CONFIG_CMD_NVEDIT by default.

Gitlab CI and Travis CI showed no problems: https://gitlab.denx.de/u-boot/custodians/u-boot-efi/pipelines/845 https://travis-ci.org/xypron2/u-boot/builds/594214233

---

AKASHI Takahiro (1): cmd: env: fix a typo in a comment of do_env_set_efi()

Heinrich Schuchardt (4): efi_loader: appending to non-existent variable efi_selftest: correct SetVariable() test efi_selftest: testing read-only variables cmd: disable CMD_NVEDIT_EFI by default

Mian Yousaf Kaukab (1): Revert "ARM: tegra: reserve unmapped RAM so EFI doesn't use it"

Patrick Wildt (2): nvme: add accessor to namespace id and eui64 efi: device path for nvme

arch/arm/mach-tegra/board2.c | 14 ----------- cmd/Kconfig | 1 - cmd/nvedit_efi.c | 2 +- drivers/nvme/nvme.c | 13 ++++++++++ drivers/nvme/nvme.h | 1 + include/efi_api.h | 7 ++++++ include/nvme.h | 12 +++++++++ lib/efi_loader/efi_device_path.c | 20 +++++++++++++++ lib/efi_loader/efi_device_path_to_text.c | 15 +++++++++++ lib/efi_loader/efi_variable.c | 10 +++++--- lib/efi_selftest/efi_selftest_variables.c | 41 ++++++++++++------------------- 11 files changed, 91 insertions(+), 45 deletions(-)

Is this really release-day regression fix level of changes or can they wait? Thanks!

The title says it's for release v2020.01-rc1.

Actually I was wondering if maintainers can send PR ahead of a release time, as I have about 100 patch in my queue which I definitely want to get it merged as soon as possible when the release is out :)

Ah, well, whoops. Yes, I suppose the answer is prepare yes, send, only if you're willing to have me not see the full subject :)