lkml.org 
[lkml]   [2016]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI
On Thu, 12 May 2016, Matt Fleming wrote:
> On Thu, 12 May, at 10:22:07AM, Shannon Zhao wrote:
> >
> > As said above, I will rebase this patch on top of the EFI next branch.
>
> OK thanks.
>
> Note that it is not possible to escape merge conflicts, since there
> are changes in the xen tip tree that are not in the EFI next branch
> and vice versa.
>
> For example these commits from xen/linux-next look relevant,
>
> 8e147fcc3ffa ("FDT: Add a helper to get the subnode by given name")
> 37060935dc04 ("ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services")
> acb2c923a860 ("XEN: EFI: Move x86 specific codes to architecture directory")
> 055be2d42408 ("ARM: Xen: Document UEFI support on Xen ARM virtual platforms")
> 3915fea959b6 ("ARM: XEN: Move xen_early_init() before efi_init()")

From a diffstat perspective, the changes introduced by these commits
affect drivers/of/fdt.c, arch/arm/xen, arch/x86/xen, drivers/xen and
little else. I don't think they should cause merge troubles.


> Linus, Stefano, tip-folks: I'm soliciting opinions on the correct way
> to handle this inter-tree dependency where we've got changes to EFI
> code in two separate trees and Shannon wants to write patches on top
> of both.
>
> I'm guessing the best solution is to merge xen/linux-next and efi/next
> into a topic branch either in the EFI tree or Xen tree, but I want to
> be cautious of the branch history that will create.

I am OK with that. You and I will have to be careful with the pull
requests.


> (In hindsight all of these change should have probably gone via the
> EFI tree.)

That is still possible if deemed best.

\
 
 \ /
  Last update: 2016-05-12 13:21    [W:0.194 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site