Thread (25 messages) 25 messages, 6 authors, 2021-12-13

Re: [PATCH v16 00/11] support reserving crashkernel above 4G on arm64 kdump

From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2021-12-13 10:21:34
Also in: kexec, linux-devicetree, linux-doc, lkml

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:
quoted
On Tue, Nov 23, 2021 at 08:46:35PM +0800, Zhen Lei wrote:
quoted
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 (local)
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 (local)

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help