Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAMj1kXEXTq8RhD-AM4i3ZmXRcLDTW8waNDbWNa0V8V1nz4zb_A@mail.gmail.com>
 <mhng-2320bbe6-c880-40f4-914e-a6209d0f2f95@palmerdabbelt-glaptop1>
In-Reply-To: <mhng-2320bbe6-c880-40f4-914e-a6209d0f2f95@palmerdabbelt-glaptop1>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Wed, 22 Apr 2020 18:39:17 +0200
Message-ID: <CAMj1kXG6KG7L5kopUMyY-DCkURfRZYDvOVU9+U=+eiktXfhrvg@mail.gmail.com>
Subject: Re: [v4 PATCH 0/3] Add UEFI support for RISC-V
To:     Palmer Dabbelt <palmer@dabbelt.com>
Cc:     Atish Patra <Atish.Patra@wdc.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-efi <linux-efi@vger.kernel.org>,
        linux-riscv <linux-riscv@lists.infradead.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Heinrich Schuchardt <xypron.glpk@gmx.de>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 21 Apr 2020 at 22:59, Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Tue, 21 Apr 2020 00:24:04 PDT (-0700), ardb@kernel.org wrote:
> > On Tue, 21 Apr 2020 at 05:34, Atish Patra <atish.patra@wdc.com> wrote:
> >>
> >> This series adds UEFI support for RISC-V. Currently, only boot time
> >> services have been added. Runtime services will be added in a separate
> >> series. This series depends on some core EFI patches
> >> present in current in efi-next and following other patches.
> >>
> >> U-Boot: Adds the boot hartid under chosen node.
> >> https://lists.denx.de/pipermail/u-boot/2020-April/405726.html
> >>
> >> Linux kernel: 5.7-rc1
> >>
> >> OpenSBI: master
> >>
> >> Patch 1 just moves arm-stub code to a generic code so that it can be used
> >> across different architecture.
> >>
> >> Patch 3 adds fixmap bindings so that CONFIG_EFI can be compiled and we do not
> >> have create separate config to enable boot time services.
> >> As runtime services are not enabled at this time, full generic early ioremap
> >> support is also not added in this series.
> >>
> >> Patch 4 and 5 adds the PE/COFF header and EFI stub code support for RISC-V
> >> respectively.
> >>
> >> The patches can also be found in following git repo.
> >>
> >> https://github.com/atishp04/linux/tree/wip_uefi_riscv_v4
> >>
> >> The patches have been verified on Qemu using bootefi command in U-Boot.
> >>
> >> Changes from v3->v4:
> >> 1. Rebased on top of efi-next.
> >> 2. Dropped patch 1 & 2 from this series as it is already queued in efi-next.
> >> Changes from v2->v3:
> >> 3. Improved handle_kernel_image() for RISC-V.
> >>
> >
> > Thanks Atish. This looks nice and simple now.
> >
> > I will need an ack from the RISC-V maintainers on these, and it is up
> > to them to consider whether the changes to core kconfigs and makefiles
> > are likely to cause trouble or not. If so, I am happy to work out a
> > way to merge this via a shared stable branch.
>
> Sorry it took me a while to get around to these, but they're essentially good
> with me.  There's some comments about needing ISA_C/c.li, but that's pretty
> trivial.  In terms of mechanics: I don't really ever understand how to do these
> multi-tree merges.  In an ideal world I'd like to have the arch/riscv/ stuff
> stay in riscv/for-next, both because I don't want to deal with merge conflicts
> and because that's where the RISC-V autobuilders look.
>
> The best I can come up with is to split #3 up such that drivers/firmware/efi/
> is its own patch and then send that up along with the PE header definitions
> into an RC.  It'd be unused code at that point, but at least it'd break the
> dependency between the trees and it'll be getting tested in riscv/for-next so
> it won't rot.  We can ARMSTUB->GENERIC_STUB by just having the RISC-V support
> select woth ARMSTUB and GENERIC_STUB, with a cleanup going in after everything
> is merged.
>
> That said, I'm happy if there's a better way to do this...
>

I'll reshuffle the code a bit, and send out an updated series. If we
are all happy with that, I will stick the first 2 patches on a shared
tag that you can pull into your branch, and you can apply the
remaining 4 patches on top of that. Are you ok with a tag based on
v5.7-rc2?