Messages in this thread | | | Date | Mon, 19 Oct 2020 14:30:18 -0700 (PDT) | Subject | Re: [GIT PULL] RISC-V Patches for the 5.10 Merge Window, Part 1 | From | Palmer Dabbelt <> |
| |
On Mon, 19 Oct 2020 14:21:33 PDT (-0700), ardb@kernel.org wrote: > On Mon, 19 Oct 2020 at 23:00, Palmer Dabbelt <palmer@dabbelt.com> wrote: >> >> On Mon, 19 Oct 2020 13:43:27 PDT (-0700), atishp@atishpatra.org wrote: >> > On Mon, Oct 19, 2020 at 12:08 PM Palmer Dabbelt <palmer@dabbelt.com> wrote: >> >> >> >> The following changes since commit d012a7190fc1fd72ed48911e77ca97ba4521bccd: >> >> >> >> Linux 5.9-rc2 (2020-08-23 14:08:43 -0700) >> >> >> >> are available in the Git repository at: >> >> >> >> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git tags/riscv-for-linus-5.10-mw0 >> >> >> >> for you to fetch changes up to de22d2107ced3cc5355cc9dbbd85e44183546bd5: >> >> >> >> RISC-V: Add page table dump support for uefi (2020-10-02 14:31:33 -0700) >> >> >> >> ---------------------------------------------------------------- >> >> RISC-V Patches for the 5.10 Merge Window, Part 1 >> >> >> >> This contains a handful of cleanups and new features, including: >> >> >> >> * A handful of cleanups for our page fault handling. >> >> * Improvements to how we fill out cacheinfo. >> >> * Support for EFI-based systems. >> >> >> >> --- >> >> >> >> This contains a merge from the EFI tree that was necessary as some of the EFI >> >> support landed over there. It's my first time doing something like this, >> >> >> >> I haven't included the set_fs stuff because the base branch it depends on >> >> hasn't been merged yet. I'll probably have another merge window PR, as >> >> there's more in flight (most notably the fix for new binutils I just sent out), >> >> but I figured there was no reason to delay this any longer. >> >> >> >> There is one merge conflict, which is between my fixes and for-next branches: >> >> >> >> diff --cc arch/riscv/kernel/vmlinux.lds.S >> >> index 67db80e12d1f,9795359cb9da..ffaa3da375c2 >> >> --- a/arch/riscv/kernel/vmlinux.lds.S >> >> +++ b/arch/riscv/kernel/vmlinux.lds.S >> >> @@@ -66,8 -71,11 +70,13 @@@ SECTION >> >> _etext = .; >> >> } >> >> >> >> + INIT_DATA_SECTION(16) >> >> + >> >> + #ifdef CONFIG_EFI >> >> + . = ALIGN(PECOFF_SECTION_ALIGNMENT); >> >> + __pecoff_text_end = .; >> >> + #endif >> >> + >> >> /* Start of data section */ >> >> _sdata = .; >> >> RO_DATA(SECTION_ALIGN) >> >> >> >> ---------------------------------------------------------------- >> >> Anup Patel (1): >> >> RISC-V: Move DT mapping outof fixmap >> >> >> >> Ard Biesheuvel (3): >> >> efi/libstub: arm32: Base FDT and initrd placement on image address >> >> efi/libstub: Export efi_low_alloc_above() to other units >> >> efi/libstub: arm32: Use low allocation for the uncompressed kernel >> >> >> > >> > I thought these 3 were being taken through the EFI tree. I already see >> > them in the master branch. >> > >> > 762cd288fc4a efi/libstub: arm32: Use low allocation for the uncompressed kernel >> > 1a895dbf4b66 efi/libstub: Export efi_low_alloc_above() to other units >> > 6208857b8f7e efi/libstub: arm32: Base FDT and initrd placement on image address >> >> I see them in Linus' master with those exact hashes, so IIUC this is all OK? I >> guess I just assumed they were supposed to show up in the shortlog, but it's my >> first time trying one of these multi-tree merges so maybe I screwed something >> up? >> >> I obtained these by merging a tag from the EFI tree (that's already been >> merged) into my tree, which looks OK to me: >> >> commit 8a3f30c4319dc70547f11c18da2e7b5987543aa1 >> gpg: Signature made Fri 02 Oct 2020 02:30:05 PM PDT >> gpg: using RSA key 2B3C3747446843B24A943A7A2E1319F35FBB1889 >> gpg: issuer "palmer@dabbelt.com" >> gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [ultimate] >> gpg: aka "Palmer Dabbelt <palmerdabbelt@google.com>" [ultimate] >> merged tag 'efi-riscv-shared-for-v5.10' >> gpg: Signature made Wed 16 Sep 2020 08:57:07 AM PDT >> gpg: using RSA key 9CD2A0DA6AD8F7330175E2BBC237207E9574FA7D >> gpg: Good signature from "Adriaan (Ard) Biesheuvel <ard.biesheuvel@linaro.org>" [unknown] >> gpg: aka "Adriaan (Ard) Biesheuvel <ard.biesheuvel@gmail.com>" [unknown] >> gpg: aka "Adriaan (Ard) Biesheuvel <ardb@kernel.org>" [unknown] >> gpg: aka "Adriaan (Ard) Biesheuvel <ard.biesheuvel@arm.com>" [unknown] >> gpg: WARNING: This key is not certified with a trusted signature! >> gpg: There is no indication that the signature belongs to the owner. >> Primary key fingerprint: F43D 0332 8115 A198 C900 1688 3D20 0E9C A632 9909 >> Subkey fingerprint: 9CD2 A0DA 6AD8 F733 0175 E2BB C237 207E 9574 FA7D >> Merge: 54701a0d12e2 762cd288fc4a >> Author: Palmer Dabbelt <palmerdabbelt@google.com> >> Date: Fri Oct 2 14:29:51 2020 -0700 >> >> Merge tag 'efi-riscv-shared-for-v5.10' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/efi/efi into for-next >> >> Stable branch for v5.10 shared between the EFI and RISC-V trees >> >> The RISC-V EFI boot and runtime support will be merged for v5.10 via >> the RISC-V tree. However, it incorporates some changes that conflict >> with other EFI changes that are in flight, so this tag serves as a >> shared base that allows those conflicts to be resolved beforehand. >> >> * tag 'efi-riscv-shared-for-v5.10' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/efi/efi: >> efi/libstub: arm32: Use low allocation for the uncompressed kernel >> efi/libstub: Export efi_low_alloc_above() to other units >> efi/libstub: arm32: Base FDT and initrd placement on image address >> efi: Rename arm-init to efi-init common for all arch >> include: pe.h: Add RISC-V related PE definition >> >> I think the actual issue here is just that whatever I pointed git to when >> generating the PR didn't contain the merge of the shared code yet, so >> git-shortlog included it? >> > > This all looks fine. Usually in such cases, you don't know which > branch will gets pulled first, so it makes sense for each PR to > describe the shared changes.
OK, good to know -- I'd just been pointing my PRs at Linus' latest tag, rather than directly at master, as it's less of a moving target. Sounds like that's a reasonable thing to do, so I'll probably keep doing it (unless I forget ;))
Linus: Looks like this was all actually fine, but LMK if you have any issues.
| |