devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: john.p.donnelly@oracle.com
Cc: Zhen Lei <thunder.leizhen@huawei.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>,
	linux-kernel@vger.kernel.org, Dave Young <dyoung@redhat.com>,
	Baoquan He <bhe@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
	Eric Biederman <ebiederm@xmission.com>,
	kexec@lists.infradead.org, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	devicetree@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org, Randy Dunlap <rdunlap@infradead.org>,
	Feng Zhou <zhoufeng.zf@bytedance.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Chen Zhou <dingguo.cz@antgroup.com>
Subject: Re: [PATCH v16 00/11] support reserving crashkernel above 4G on arm64 kdump
Date: Mon, 13 Dec 2021 10:18:06 +0000	[thread overview]
Message-ID: <Ybcd3r9AeV9vzuG4@arm.com> (raw)
In-Reply-To: <db65cd76-e2c0-4d35-0dcc-d9f8c164f77e@oracle.com>

On Fri, Dec 10, 2021 at 01:53:59PM -0600, john.p.donnelly@oracle.com wrote:
> On 12/8/21 11:13 AM, Catalin Marinas wrote:
> > On Tue, Nov 23, 2021 at 08:46:35PM +0800, Zhen Lei wrote:
> > > Chen Zhou (10):
> > >    x86: kdump: replace the hard-coded alignment with macro CRASH_ALIGN
> > >    x86: kdump: make the lower bound of crash kernel reservation
> > >      consistent
> > >    x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions
> > >      reserve_crashkernel()
> > >    x86: kdump: move xen_pv_domain() check and insert_resource() to
> > >      setup_arch()
> > >    x86: kdump: move reserve_crashkernel[_low]() into crash_core.c
> > >    arm64: kdump: introduce some macros for crash kernel reservation
> > >    arm64: kdump: reimplement crashkernel=X
> > >    x86, arm64: Add ARCH_WANT_RESERVE_CRASH_KERNEL config
> > >    of: fdt: Add memory for devices by DT property
> > >      "linux,usable-memory-range"
> > >    kdump: update Documentation about crashkernel
> > > 
> > > Zhen Lei (1):
> > >    of: fdt: Aggregate the processing of "linux,usable-memory-range"
> > 
> > Apart from a minor comment I made on patch 8 and some comments from Rob
> > that need addressing, the rest looks fine to me.
> > 
> > Ingo stated in the past that he's happy to ack the x86 changes as long
> > as there's no functional change (and that's the case AFAICT). Ingo, does
> > your conditional ack still stand?
> > 
> > In terms of merging, I'm happy to take it all through the arm64 tree
> > with acks from the x86 maintainers. Alternatively, with the change I
> > mentioned for patch 8, the first 5 patches could be queued via the tip
> > tree on a stable branch and I can base the rest of the arm64 on top.
> > 
> > Thomas, Ingo, Peter, any preference?
> > 
> > Thanks.
> 
> If you notice the trend over the past year , some of additional review
> requests are because the submitter had to rebase to the next version.

Normally the reviews stand even if the series is rebased. You only drop
them if there were non-trivial changes to the patches, not just because
of a rebase.

Ingo acked the x86 changes in the past but there were some functional
changes to the minimum alignment, so the series had to be reworked and
the ack not applied.

https://lore.kernel.org/r/20200806133627.GB2077191@gmail.com

> Can we get this acked and placed in a build so others can test and start
> using it ?

If Ingo's conditional ack (no functional changes, just a move) still
stands over the five x86 patches now, I'm happy to queue them all via
the arm64 tree. The latest series here:

https://lore.kernel.org/r/20211210065533.2023-1-thunder.leizhen@huawei.com

-- 
Catalin

      reply	other threads:[~2021-12-13 10:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-23 12:46 [PATCH v16 00/11] support reserving crashkernel above 4G on arm64 kdump Zhen Lei
2021-11-23 12:46 ` [PATCH v16 01/11] x86: kdump: replace the hard-coded alignment with macro CRASH_ALIGN Zhen Lei
2021-11-23 12:46 ` [PATCH v16 02/11] x86: kdump: make the lower bound of crash kernel reservation consistent Zhen Lei
2021-11-23 12:46 ` [PATCH v16 03/11] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel() Zhen Lei
2021-11-23 12:46 ` [PATCH v16 04/11] x86: kdump: move xen_pv_domain() check and insert_resource() to setup_arch() Zhen Lei
2021-11-23 12:46 ` [PATCH v16 05/11] x86: kdump: move reserve_crashkernel[_low]() into crash_core.c Zhen Lei
2021-11-23 12:46 ` [PATCH v16 06/11] arm64: kdump: introduce some macros for crash kernel reservation Zhen Lei
2021-11-23 12:46 ` [PATCH v16 07/11] arm64: kdump: reimplement crashkernel=X Zhen Lei
2021-11-23 12:46 ` [PATCH v16 08/11] x86, arm64: Add ARCH_WANT_RESERVE_CRASH_KERNEL config Zhen Lei
2021-12-08 17:09   ` Catalin Marinas
2021-12-09  2:06     ` Leizhen (ThunderTown)
2021-11-23 12:46 ` [PATCH v16 09/11] of: fdt: Aggregate the processing of "linux,usable-memory-range" Zhen Lei
2021-11-30 22:05   ` Rob Herring
2021-11-23 12:46 ` [PATCH v16 10/11] of: fdt: Add memory for devices by DT property "linux,usable-memory-range" Zhen Lei
2021-11-30 22:16   ` Rob Herring
2021-12-01  2:55     ` Leizhen (ThunderTown)
2021-12-09  1:59       ` Leizhen (ThunderTown)
2021-12-09 17:40         ` Rob Herring
2021-11-23 12:46 ` [PATCH v16 11/11] kdump: update Documentation about crashkernel Zhen Lei
2021-11-29 20:25 ` [PATCH v16 00/11] support reserving crashkernel above 4G on arm64 kdump Dave Kleikamp
2021-11-30  2:12 ` Baoquan He
2021-12-06  3:51 ` john.p.donnelly
2021-12-08 17:13 ` Catalin Marinas
2021-12-10 19:53   ` john.p.donnelly
2021-12-13 10:18     ` Catalin Marinas [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ybcd3r9AeV9vzuG4@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=bhe@redhat.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=dingguo.cz@antgroup.com \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=frowand.list@gmail.com \
    --cc=hpa@zytor.com \
    --cc=john.p.donnelly@oracle.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=thunder.leizhen@huawei.com \
    --cc=vgoyal@redhat.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=zhoufeng.zf@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).