From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 43945DDC5 for ; Thu, 28 May 2026 01:01:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779930083; cv=none; b=CKUXUfwU4wfotHCIjJJbIajBy+OcjbrmHWoEjAcJ6uH6e6PNguFgDNa5fBvpiMb6oDTNAZOU0lz5GWHCiyI+r7sPny5wPk5jkR3D0lPIRC25xTDmJ0CA1cOrz0BMg5bRPtay+822R34gnOPpRV/IclvrBkQQNqCc+OnsMS1ZenE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779930083; c=relaxed/simple; bh=GmAv0DlRksrQd9uDGf25+LrxxkZmRpmOl+LkQNvCiX0=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=po4xr/YGSn853jIly1oH7wy4MRLhPxYBMOrF4kvE4xcPflLheI1hOp9305WszlitAzNZHyUrLspUkkxubBLv2TIEf8Gbxbm4XWagMrJHYYUrP4D7BCyqowYIhKJABR7F0Xibi14Asi1if+dyHxsKOFwzzWRWd+S/rTu7Hzqk26c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Pqjg3drR; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Pqjg3drR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 950B41F000E9; Thu, 28 May 2026 01:01:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779930081; bh=YH83iQyDpBtRJ7bFt3JrD5dC4uBBtq6U9iEcWdvtN70=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Pqjg3drRTJJ09KHbUlj28R3m536nA1zFBPbJelT5w6ptR7hgpkna8GIKErjdE834v YzUMlXIh+4r4S6J7OnbSQ2WIOhDGksP8teYv5DLdyeWbBp+6d9/fUkvA7vqpx2yfi7 VNDbLpy+zc+lB+T8EkKXok9zlsAb4zvI9NrEhOuiGxKbdTLPyZ/a1uLWpDRh86eV21 bvPcLcwXsBfzLUj4LcnohesTjcadxIwSXnOxvMpmJ2pX7AgS+oHoHQWwUgwSkzrah1 qXfgcqzt87HRWDLNurNwVVnQ4qpAxGKXKk3VlYfGQkCCP5b5EUAeReCE1QvBcjklT1 qMhGoRq8g+XXA== Date: Wed, 27 May 2026 19:01:19 -0600 (MDT) From: Paul Walmsley To: Han Gao cc: Paul Walmsley , Han Gao , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Vivian Wang Subject: Re: [PATCH] riscv: unconditionally select ARCH_KEEP_MEMBLOCK In-Reply-To: Message-ID: <774098ca-165a-f739-6331-affb0c8af1e1@kernel.org> References: <20260519165546.123105-1-gaohan@iscas.ac.cn> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-1904663008-1779929769=:198859" Content-ID: <587d9d0a-e62e-d1b7-c42f-d534a3c9abe3@kernel.org> This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1904663008-1779929769=:198859 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: <6176f9bc-6d33-1f9f-e21a-ab6c0b8c4c64@kernel.org> On Mon, 25 May 2026, Han Gao wrote: > On Fri, May 22, 2026 at 6:04 AM Paul Walmsley wrote: > > > > On Wed, 20 May 2026, Han Gao wrote: > > > > > Select ARCH_KEEP_MEMBLOCK unconditionally. kexec requires memblock > > > to be kept after boot to initialize the secondary kernel. Device > > > Tree platforms also need this for kexec support. > > > > > > Signed-off-by: Han Gao > > > > Thanks for the patch. If this patch is just about kexec, shouldn't > > ARCH_SELECTS_KEXEC just be changed to select ARCH_KEEP_MEMBLOCK? > It's currently aligned with the arm64 architecture. If so, should we > modify it accordingly? If the motivation for adding it this way is to match arm64, then the patch description would need to be updated accordingly; it doesn't say anything about that. I'm not sure that's a sufficient rationale, on its own. On the other hand, if the rationale for this change is that it fixes an issue when kexec is used, then I guess I don't understand why we wouldn't make it dependent on ARCH_SELECTS_KEXEC? It can always be patched again if more use cases are discovered, right? - Paul --8323329-1904663008-1779929769=:198859--