lkml.org 
[lkml]   [2020]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [GIT PULL] RISC-V Patches for the 5.10 Merge Window, Part 1
From
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.

\
 
 \ /
  Last update: 2020-10-19 23:30    [W:0.050 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site