[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200113112105.GB2337@willie-the-truck>
Date: Mon, 13 Jan 2020 11:21:06 +0000
From: Will Deacon <will@...nel.org>
To: Pavel Tatashin <pasha.tatashin@...een.com>
Cc: AKASHI Takahiro <takahiro.akashi@...aro.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>, robh+dt@...nel.org,
frowand.list@...il.com, Bhupesh Sharma <bhsharma@...hat.com>,
kexec mailing list <kexec@...ts.infradead.org>,
LKML <linux-kernel@...r.kernel.org>,
James Morse <james.morse@....com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v4 2/2] arm64: kexec_file: add crash dump support
On Fri, Jan 10, 2020 at 11:19:16AM -0500, Pavel Tatashin wrote:
> On Fri, Jan 10, 2020 at 11:05 AM Will Deacon <will@...nel.org> wrote:
> >
> > On Thu, Jan 09, 2020 at 08:32:54AM +0000, Will Deacon wrote:
> > > On Thu, Jan 09, 2020 at 09:46:55AM +0900, AKASHI Takahiro wrote:
> > > > On Wed, Jan 08, 2020 at 05:48:39PM +0000, Will Deacon wrote:
> > > > > On Mon, Dec 16, 2019 at 11:12:47AM +0900, AKASHI Takahiro wrote:
> > > > > > diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> > > > > > index 12a561a54128..d24b527e8c00 100644
> > > > > > --- a/arch/arm64/include/asm/kexec.h
> > > > > > +++ b/arch/arm64/include/asm/kexec.h
> > > > > > @@ -96,6 +96,10 @@ static inline void crash_post_resume(void) {}
> > > > > > struct kimage_arch {
> > > > > > void *dtb;
> > > > > > unsigned long dtb_mem;
> > > > > > + /* Core ELF header buffer */
> > > > > > + void *elf_headers;
> > > > > > + unsigned long elf_headers_mem;
> > > > > > + unsigned long elf_headers_sz;
> > > > > > };
> > > > >
> > > > > This conflicts with the cleanup work from Pavel. Please can you check my
> > > > > resolution? [1]
> > > >
> > > > I don't know why we need to change a type of dtb_mem,
> > > > otherwise it looks good.
> > > >
> > > > (I also assume that you notice that kimage_arch is of no use for kexec.)
> > >
> > > Yes, that's why I'd like the resolution checked. If you reckon it's cleaner
> > > to drop Pavel's patch altogether in light of your changes, we can do that
> > > instead.
> > >
> > > Thoughts?
> >
> > Well, I've reverted the cleanup patch so please shout if you'd prefer
> > something else.
>
> As I understand, the only concern was the type change for dtb_mem.
> This was one of the review comments for my patch
> https://lore.kernel.org/lkml/20191204155938.2279686-21-pasha.tatashin@soleen.com/
>
> (I believe it was from Marc Zyngier), I add a number of new fields,
> and they all should be phys_addr_t, this is why I change dtb_mem to
> phys_addr_t to be consistent.
Sure, but I've only queued the first part of your series and that cleanup
patch doesn't make a lot of sense when applied against Akashi's work. I'm
happy to take stuff on top if you both agree to it, but having half of the
struct use unsigned long and the other half use phys_addr_t is messy.
Will
Powered by blists - more mailing lists