From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8D3E0C433FE for ; Wed, 8 Dec 2021 17:15:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=IGyAqam4IDEeDcIYxXqEiEhs0fU8CLYq3Ghoik+j3nU=; b=ZVlfsjFnPTGtNo 6H92zq1k9dBY3OgaRnC19cvy7JqaNvk31r8GlKcySaTKxDxJs8BAhCCW3WUWSDvzZ9reQR1W59T6W WGCiPo3nvGIjoYm68s9VLyq1D92PIphssgdqiBUhq7EigfiNLxzmjGLVi+NOJAlTr8pjuzzsTa7TV 4TJeMYCv+nBljqCDm9bse9mQFhPVnmM1JB5xZ/HmBLhIAb1eBDQrFSYlnCKO5pTE3/nbNmtkGmXk7 DLRyXF205/rNoQeO47eHmwWWv9uuZBCR6Kr2HOEGENA4NbbL9UZs23cNQENh6TvdQUgTRmdohYllA i1DkccRpuBecW3bbDlDQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mv0Vt-00DgXI-SW; Wed, 08 Dec 2021 17:13:54 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mv0Vo-00DgUj-PB; Wed, 08 Dec 2021 17:13:50 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 05169CE1EC7; Wed, 8 Dec 2021 17:13:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63ACAC00446; Wed, 8 Dec 2021 17:13:41 +0000 (UTC) Date: Wed, 8 Dec 2021 17:13:38 +0000 From: Catalin Marinas To: Zhen Lei Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , linux-kernel@vger.kernel.org, Dave Young , Baoquan He , Vivek Goyal , Eric Biederman , kexec@lists.infradead.org, Will Deacon , linux-arm-kernel@lists.infradead.org, Rob Herring , Frank Rowand , devicetree@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, Randy Dunlap , Feng Zhou , Kefeng Wang , Chen Zhou Subject: Re: [PATCH v16 00/11] support reserving crashkernel above 4G on arm64 kdump Message-ID: References: <20211123124646.1995-1-thunder.leizhen@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20211123124646.1995-1-thunder.leizhen@huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211208_091349_019134_2A0E305F X-CRM114-Status: GOOD ( 16.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel