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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B505C433EF for ; Thu, 28 Oct 2021 09:49:26 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 19FF460F9B for ; Thu, 28 Oct 2021 09:49:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 19FF460F9B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 52DFB82F03; Thu, 28 Oct 2021 11:49:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id DE7BB82F03; Thu, 28 Oct 2021 11:49:20 +0200 (CEST) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 5BBC782F03 for ; Thu, 28 Oct 2021 11:49:17 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=maz@kernel.org Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3415B60FC0; Thu, 28 Oct 2021 09:49:14 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mg223-002AwH-U9; Thu, 28 Oct 2021 10:49:12 +0100 Date: Thu, 28 Oct 2021 10:49:11 +0100 Message-ID: <87y26da38o.wl-maz@kernel.org> From: Marc Zyngier To: Bharat Gooty Cc: Michael Walle , U-Boot Mailing List , Vladimir Oltean , Hou Zhiqiang , Rayagonda Kokatanur , Simon Glass , Priyanka Jain , Tom Rini , Roman Bacik Subject: Re: [PATCH 0/2] arch: arm: gic-v3-its: stop abusing the device tree In-Reply-To: References: <20211027165454.1501398-1-michael@walle.cc> <871r45bk0h.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: bharat.gooty@broadcom.com, michael@walle.cc, u-boot@lists.denx.de, vladimir.oltean@nxp.com, Zhiqiang.Hou@nxp.com, rayagonda.kokatanur@broadcom.com, sjg@chromium.org, priyanka.jain@nxp.com, trini@konsulko.com, roman.bacik@broadcom.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On Thu, 28 Oct 2021 10:20:53 +0100, Bharat Gooty wrote: > > For GIC V3, once the LPI tables are programmed, we can not update it, > unless we do a reset. Please tell me something I don't know... > For the kexec kernel, where the reboot does not happen, in this case, > during the new kernel boot, the new LPI tables address will not be updated. Since July 2018, the Linux kernel is perfectly able to deal with this without any extra support. It will communicate the reservation to the secondary kernel, and the secondary kernel will happily use this. > For these reasons, We allocate the LPI table memory in u-boot and > reserve that memory. What sort of antiquated kernel are you using? And even if you are running something that predates the kernel changes, reserving the memory in the DT serves the same purpose. Why the custom node declaring the allocation? And since your kernel is able to kexec, it obviously knows about the reservation/pre-programming trick. This hardly makes any sense. M. -- Without deviation from the norm, progress is not possible.