Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround

[Marc Zyngier <maz@kernel.org>]

On Thu, 18 Jun 2026 03:50:29 +0100,
Marek Vasut <marek.vasut@mailbox.org> 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.