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 7D30BC433F5 for ; Thu, 28 Oct 2021 10:28:07 +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 9CFFF61040 for ; Thu, 28 Oct 2021 10:28:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9CFFF61040 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=broadcom.com 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 EA55A80D28; Thu, 28 Oct 2021 12:28:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=quarantine dis=none) header.from=broadcom.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=broadcom.com header.i=@broadcom.com header.b="JvTOzIJZ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 12D4382D6F; Thu, 28 Oct 2021 12:28:03 +0200 (CEST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id AFE8F80516 for ; Thu, 28 Oct 2021 12:27:58 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=quarantine dis=none) header.from=broadcom.com Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=bharat.gooty@broadcom.com Received: by mail-lf1-x12d.google.com with SMTP id c28so12425410lfv.13 for ; Thu, 28 Oct 2021 03:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AS5qi+7xBQ8OzB5JLdp77uEZgOhhyth7VKqm+a7okkc=; b=JvTOzIJZt93Zhe6roRcU8lzAtiOFMdO3qFZM5s2x+5FXueSqPfv9oilbys5vVu2vqq 2BzUBdfRQH3WvSqkOvaOwtace2fcCN+M4PYCDaKUcgJyKnah0NY3oswnZgG+AFKkUvl5 X7gSawlI/AnnpayVOvb2NqYAewRb7mtgLe8B8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AS5qi+7xBQ8OzB5JLdp77uEZgOhhyth7VKqm+a7okkc=; b=GjYNQd4pShp62VbqNLEWbHnzb2khFpY5A1aaP/DIoYjpEGwbI+Af5NCiaNWE1QLWqu NyBdf0SMy+nB1EWMV3sI2M70zOtyfBZjm2qtCw8JlJ8xzHzqXdR/5L/odn+Do3efsv1D cz+Web3r118VAdvVnGgtylubGaGrpVd+pIbUBCryY5RJ1VhZHtNdakkG6xgM9QdT8873 9Xa2Nnq6FkDk2x2bzWEAfmIuw9f0FWMcMizu+tYHz88edfVKXI3nVOSybAoJEBoaYCjG 3/iEBfqgvtTRHWWh6f+Nm939QcPxGb6nGCKQf4CugL50Xl5zJgIqorkIZMmppz7yJjW8 XJpQ== X-Gm-Message-State: AOAM530C8sXD2Fa/hxlk4x7U7LN629OHDcHeys2rSGh9+FAwZfVo95+s kuOV75ncp1YKHSXK9q0Dbk7erD+0XH4uBGilgLqP4wDjX+vJr0U0D1Cf0U8pThzMD7DKEvcENhw pHOnS5nnbrxzAXvMydyUa X-Google-Smtp-Source: ABdhPJzmx8lnMLd26hCzOgOS1MDBAx1bFaXY+OyNACnwqTsLs4LTkBqMCV5UcDGYW3IKPtTzr288AJnq5n6+1BStR5g= X-Received: by 2002:a05:6512:3b85:: with SMTP id g5mr3433836lfv.216.1635416876162; Thu, 28 Oct 2021 03:27:56 -0700 (PDT) MIME-Version: 1.0 References: <20211027165454.1501398-1-michael@walle.cc> <871r45bk0h.wl-maz@kernel.org> <87y26da38o.wl-maz@kernel.org> In-Reply-To: <87y26da38o.wl-maz@kernel.org> From: Bharat Gooty Date: Thu, 28 Oct 2021 15:57:44 +0530 Message-ID: Subject: Re: [PATCH 0/2] arch: arm: gic-v3-its: stop abusing the device tree To: Marc Zyngier Cc: Michael Walle , U-Boot Mailing List , Vladimir Oltean , Hou Zhiqiang , Rayagonda Kokatanur , Simon Glass , Priyanka Jain , Tom Rini , Roman Bacik , Bharat Gooty Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 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, Oct 28, 2021 at 3:19 PM Marc Zyngier wrote: > 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 GIC V3 , once the Locality specific peripheral interrupts (LPI) table is programmed and enabled, unless the GIC is reset, we can not re-program the LPI tables. For these reasons, reserve the memory and program the GIC redistributor PROPBASER and LPI_PENDBASE registers. If we do not program the LPI table in the bootloader, during the Linux boot, Linux will allocate the LPI table memory. Assume you want to boot a new kernel and do the kexec kernel. For the kexec kernel boot, Linux will again allocate the LPI table memory. But writing to the GIC registers will fail. As the LPI for the redistributors is already enabled by the previous Linux kernel, unless we do GIC reset, we can not update the LPI tables. > > 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. > > Can you specify the kernel version and the GIC versions which were used? > > 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? > > Tried using LTS 5.4 and 5.9 Linux kernels. Problem is updating the GIC V3 registers with the new LPI table memory after enabling the LPI for the redistributors. 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. > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.