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 AEABCCD98ED for ; Thu, 18 Jun 2026 08:38:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BghaV0XJnds55dF2dgFuuXXCRlRZxRm1R2JFiOWPEcY=; b=Lb1KpOzXuHtrLqOc+4YBUMEPUw v2s3xy5nRYX+3sNBhjJijBd2kJkJUxFHy9iYf+lLNQAyt+ajaRZAFmTvFF4GwFWPmNg5pICBukmwq /56rKhmjO+Lr1azmN7C1e5UtY6i426ko+13tvVtnHQw+dkjOxfDzziyaXnMUvOEuI5oCAlkOA6C6x qYzQNPhJQQPmToDciPRcH/DerjzlLLCBBRUygh9g0C3rTFof4Ycj2SyuqMCZQxdtQZt+R97obuuK2 Z/IB8+NvB2SUyvOePb7gFCchUTZtAC6iqus9Nxw2I2LCq1XZ3GsoG1xcjHiGxVgLTWCA4J5+rmyEH XgYK9Iag==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wa8Gn-00000000rKe-2kRd; Thu, 18 Jun 2026 08:38:41 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wa8Gm-00000000rKY-3n0g for linux-arm-kernel@lists.infradead.org; Thu, 18 Jun 2026 08:38:41 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id B41F66012A; Thu, 18 Jun 2026 08:38:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63ADC1F000E9; Thu, 18 Jun 2026 08:38:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781771919; bh=BghaV0XJnds55dF2dgFuuXXCRlRZxRm1R2JFiOWPEcY=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=nXhelwwdHIkf/sbE8QwEOS03rLt8fBTdIbsCZe07coYKQs4UXoUTDq6Bje6m8uGcu Dr5MQ0TVj1Uq22/CL5bZi9uGamNGVyuBE4uwrVOqxcsPlGhLbA8QEBhkZmWInPyMJ0 o21G3I2bxvKtL/8BbxKnwjcZpGWTdpx4Egxa9y2kJpMJ0Zargl930VFJWaalzVrn6s aasDnOM0EZTrvAPxjCdPlJaFr7RqjMSZU0dBX35bXjzedGX+hbz6n808Af92WmSRFu Jd70COqSStxnjEVjQp7iIs9O/8kmUyPZ1VotsyFi+i48LOEwR+SpqD84Aw2cnWxJU6 RW+fUzBeRRDAQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wa8Gj-0000000DvgM-0yNK; Thu, 18 Jun 2026 08:38:37 +0000 Date: Thu, 18 Jun 2026 09:38:36 +0100 Message-ID: <86ldccs0oj.wl-maz@kernel.org> From: Marc Zyngier To: Marek Vasut Cc: Marek Vasut , linux-pci@vger.kernel.org, Yoshihiro Shimoda , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , Bjorn Helgaas , Catalin Marinas , Conor Dooley , Geert Uytterhoeven , Krzysztof Kozlowski , Lorenzo Pieralisi , Manivannan Sadhasivam , Rob Herring , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround In-Reply-To: <0935eb67-83d2-49ea-89ab-0d0aa51ead8a@mailbox.org> References: <20260617030008.154449-1-marek.vasut+renesas@mailbox.org> <20260617030008.154449-2-marek.vasut+renesas@mailbox.org> <864ij1tyrj.wl-maz@kernel.org> <0935eb67-83d2-49ea-89ab-0d0aa51ead8a@mailbox.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/30.1 (aarch64-unknown-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: marek.vasut@mailbox.org, marek.vasut+renesas@mailbox.org, linux-pci@vger.kernel.org, yoshihiro.shimoda.uh@renesas.com, kwilczynski@kernel.org, bhelgaas@google.com, catalin.marinas@arm.com, conor+dt@kernel.org, geert+renesas@glider.be, krzk+dt@kernel.org, lpieralisi@kernel.org, mani@kernel.org, robh@kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 18 Jun 2026 03:50:29 +0100, Marek Vasut wrote: > > On 6/17/26 9:24 AM, Marc Zyngier wrote: > > Hello Marc, > > >> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI > >> or APB interface configured to 32 bit, it can therefore access only > >> the first 4 GiB of physical address space. This information comes from > >> R-Car V4H Interface Specification sheet, there is currently no technical > >> update number assigned to this limitation. Further input from hardware > >> engineer indicates that this limitation also applies to R-Car S4 and V4M. > >> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this > >> limitation. > > My concern is this ^ , I do not have an erratum number, because there > isn't one. I am in touch with the hardware engineer and I did get a > glimpse at internal details of the three SoC, which confirm the > limitations. Is this sufficient ? To be honest, this is between you and the SoC vendor. I'll take whatever symbol you come up with at face value, and will assume that the vendor agrees with it. After all, they are on Cc and have their SoB on the patch. > > >> Note that the 0x0201743b GIC600 ID is not Renesas-specific, it is > >> common for many ARM GICv3 implementations. Therefore, add an extra > > > > Not quite. It designates GIC600 unambiguously. > > What I am trying to communicate is, that the 0x0201743b ID is not ID > of the Renesas GIC implementation, but it is a generic ARM GIC600 > ID. That is why we cannot match the quirk on the ID (it is generic ARM > GIC600 ID), and instead we have to match the quirk on the [ ID > combined with of_machine_is_compatible("renesas,...") ]. This is understood, and is no different from the other broken platforms in the tree. > > > It is just that GIC600 > > is integrated in zillions of SoCs, most of which don't have this > > problem (the machine I'm typing this from has a GIC600 *and* 96GB of > > RAM). > > Right. > > Shall I reword this paragraph somehow to make it clearer ? I'd simply say that the workaround is keyed on the combination of the GIC implementation and the platform identification in the device tree. > > >> of_machine_is_compatible() check. > >> > >> The GIC600 implementation in R-Car S4/V4H/V4M is r1p6. > > > > Is this relevant? > > I included it for the sake of completeness and to provide all relevant > information, based on previous discussions about similar limitations > that I could find on lore.k.o This information is already contained in the ID you quote (bits [19:12]), and can be decoded using the public TRM [1]. Thanks, M. [1] https://documentation-service.arm.com/static/5e7ddddacbfe76649ba53034 -- Without deviation from the norm, progress is not possible.