[PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro

[PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro

[Marek Vasut]

Instead of pulling in the whole linux/irqchip/arm-gic-v3.h , copy the
one GITS_TRANSLATER register offset macro directly into the driver.
This repairs the ability to build the driver on non-ARM non-GIC targets
the way it was possible until now, which retains good build test coverage.

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202607100310.iQw5m9Uo-lkp@intel.com/
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
---
Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
---
Note: The alternative I could think of would be ifdeffery which
      is not nice and thwarts the build coverage, or limit the
      driver to ARM/ARM64 in Kconfig which also thwarts the build
      coverage. I could also split off the register macros in
      linux/irqchip/arm-gic-v3.h into some separate header
      linux/irqchip/arm-gic-v3-regs.h and include that which
      might be OKish and avoids duplication. Thoughts ?
---
 drivers/pci/controller/dwc/pcie-rcar-gen4.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
index 5f7211b91ee5b..4b75615c516f0 100644
--- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
+++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
@@ -13,7 +13,6 @@
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/iopoll.h>
-#include <linux/irqchip/arm-gic-v3.h>
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_address.h>
@@ -26,6 +25,9 @@
 #include "../../pci.h"
 #include "pcie-designware.h"
 
+/* GIC ITS TRANSLATER register offset in GIC ITS space */
+#define GITS_TRANSLATER		0x10040
+
 /* Renesas-specific */
 /* PCIe Mode Setting Register 0 */
 #define PCIEMSR0		0x0000
-- 
2.53.0

Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro

[Marc Zyngier]

On Thu, 09 Jul 2026 21:10:03 +0100,
Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
> 
> Instead of pulling in the whole linux/irqchip/arm-gic-v3.h , copy the
> one GITS_TRANSLATER register offset macro directly into the driver.
> This repairs the ability to build the driver on non-ARM non-GIC targets
> the way it was possible until now, which retains good build test coverage.
> 
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202607100310.iQw5m9Uo-lkp@intel.com/
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> Note: The alternative I could think of would be ifdeffery which
>       is not nice and thwarts the build coverage, or limit the
>       driver to ARM/ARM64 in Kconfig which also thwarts the build
>       coverage. I could also split off the register macros in
>       linux/irqchip/arm-gic-v3.h into some separate header
>       linux/irqchip/arm-gic-v3-regs.h and include that which
>       might be OKish and avoids duplication. Thoughts ?

No, I'm not hacking something that is purely architecture specific for
the purpose of a bizarre integration quirk that should be handled by
the boot firmware, and not Linux.

Add whatever you want to the PCI glue code, limit this to arm64 (which
is the only architecture this can ever be used on, and the build
coverage argument really doesn't hold), but please leave the GIC code
alone.

	M.

-- 
Jazz isn't dead. It just smells funny.

Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro

[Marek Vasut]

On 7/10/26 10:30 AM, Marc Zyngier wrote:
> On Thu, 09 Jul 2026 21:10:03 +0100,
> Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>>
>> Instead of pulling in the whole linux/irqchip/arm-gic-v3.h , copy the
>> one GITS_TRANSLATER register offset macro directly into the driver.
>> This repairs the ability to build the driver on non-ARM non-GIC targets
>> the way it was possible until now, which retains good build test coverage.
>>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes: https://lore.kernel.org/oe-kbuild-all/202607100310.iQw5m9Uo-lkp@intel.com/
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>> ---
>> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
>> Cc: Bjorn Helgaas <bhelgaas@google.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Conor Dooley <conor+dt@kernel.org>
>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
>> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
>> Cc: Manivannan Sadhasivam <mani@kernel.org>
>> Cc: Marc Zyngier <maz@kernel.org>
>> Cc: Rob Herring <robh@kernel.org>
>> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>> Cc: devicetree@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-doc@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-pci@vger.kernel.org
>> Cc: linux-renesas-soc@vger.kernel.org
>> ---
>> Note: The alternative I could think of would be ifdeffery which
>>        is not nice and thwarts the build coverage, or limit the
>>        driver to ARM/ARM64 in Kconfig which also thwarts the build
>>        coverage. I could also split off the register macros in
>>        linux/irqchip/arm-gic-v3.h into some separate header
>>        linux/irqchip/arm-gic-v3-regs.h and include that which
>>        might be OKish and avoids duplication. Thoughts ?
> 
> No, I'm not hacking something that is purely architecture specific for
> the purpose of a bizarre integration quirk that should be handled by
> the boot firmware, and not Linux.

The PCIe controller is fully controlled by Linux. I don't think this can 
be handled by the boot firmware. The GIC ITS TRANSLATER address could be 
derived from the DT compatible string of the PCIe controller (I had that 
implemented before), but that is the less generic option.

> Add whatever you want to the PCI glue code, limit this to arm64 (which
> is the only architecture this can ever be used on, and the build
> coverage argument really doesn't hold), but please leave the GIC code
> alone.
So in the end, it is either this patch or limit the build to arm/arm64 . 
At least this patch still allows building this driver with more 
compilers on the various build bots, so I would opt for this patch here.

Thank you for your help !

Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro

[Marc Zyngier]

On Fri, 10 Jul 2026 14:35:10 +0100,
Marek Vasut <marek.vasut@mailbox.org> wrote:
> 
> On 7/10/26 10:30 AM, Marc Zyngier wrote:
> > On Thu, 09 Jul 2026 21:10:03 +0100,
> > Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
> >> 
> >> Instead of pulling in the whole linux/irqchip/arm-gic-v3.h , copy the
> >> one GITS_TRANSLATER register offset macro directly into the driver.
> >> This repairs the ability to build the driver on non-ARM non-GIC targets
> >> the way it was possible until now, which retains good build test coverage.
> >> 
> >> Reported-by: kernel test robot <lkp@intel.com>
> >> Closes: https://lore.kernel.org/oe-kbuild-all/202607100310.iQw5m9Uo-lkp@intel.com/
> >> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> >> ---
> >> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> >> Cc: Bjorn Helgaas <bhelgaas@google.com>
> >> Cc: Catalin Marinas <catalin.marinas@arm.com>
> >> Cc: Conor Dooley <conor+dt@kernel.org>
> >> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> >> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> >> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> >> Cc: Manivannan Sadhasivam <mani@kernel.org>
> >> Cc: Marc Zyngier <maz@kernel.org>
> >> Cc: Rob Herring <robh@kernel.org>
> >> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> >> Cc: devicetree@vger.kernel.org
> >> Cc: linux-arm-kernel@lists.infradead.org
> >> Cc: linux-doc@vger.kernel.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Cc: linux-pci@vger.kernel.org
> >> Cc: linux-renesas-soc@vger.kernel.org
> >> ---
> >> Note: The alternative I could think of would be ifdeffery which
> >>        is not nice and thwarts the build coverage, or limit the
> >>        driver to ARM/ARM64 in Kconfig which also thwarts the build
> >>        coverage. I could also split off the register macros in
> >>        linux/irqchip/arm-gic-v3.h into some separate header
> >>        linux/irqchip/arm-gic-v3-regs.h and include that which
> >>        might be OKish and avoids duplication. Thoughts ?
> > 
> > No, I'm not hacking something that is purely architecture specific for
> > the purpose of a bizarre integration quirk that should be handled by
> > the boot firmware, and not Linux.
> 
> The PCIe controller is fully controlled by Linux.

And it shouldn't. Why can't your favourite boot-loader use it, like on
any reasonable machine?

	M.

-- 
Jazz isn't dead. It just smells funny.

Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro

[Marek Vasut]

On 7/13/26 5:20 PM, Marc Zyngier wrote:
> On Fri, 10 Jul 2026 14:35:10 +0100,
> Marek Vasut <marek.vasut@mailbox.org> wrote:
>>
>> On 7/10/26 10:30 AM, Marc Zyngier wrote:
>>> On Thu, 09 Jul 2026 21:10:03 +0100,
>>> Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>>>>
>>>> Instead of pulling in the whole linux/irqchip/arm-gic-v3.h , copy the
>>>> one GITS_TRANSLATER register offset macro directly into the driver.
>>>> This repairs the ability to build the driver on non-ARM non-GIC targets
>>>> the way it was possible until now, which retains good build test coverage.
>>>>
>>>> Reported-by: kernel test robot <lkp@intel.com>
>>>> Closes: https://lore.kernel.org/oe-kbuild-all/202607100310.iQw5m9Uo-lkp@intel.com/
>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>>>> ---
>>>> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
>>>> Cc: Bjorn Helgaas <bhelgaas@google.com>
>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>> Cc: Conor Dooley <conor+dt@kernel.org>
>>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>>> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
>>>> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
>>>> Cc: Manivannan Sadhasivam <mani@kernel.org>
>>>> Cc: Marc Zyngier <maz@kernel.org>
>>>> Cc: Rob Herring <robh@kernel.org>
>>>> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>>>> Cc: devicetree@vger.kernel.org
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: linux-doc@vger.kernel.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Cc: linux-pci@vger.kernel.org
>>>> Cc: linux-renesas-soc@vger.kernel.org
>>>> ---
>>>> Note: The alternative I could think of would be ifdeffery which
>>>>         is not nice and thwarts the build coverage, or limit the
>>>>         driver to ARM/ARM64 in Kconfig which also thwarts the build
>>>>         coverage. I could also split off the register macros in
>>>>         linux/irqchip/arm-gic-v3.h into some separate header
>>>>         linux/irqchip/arm-gic-v3-regs.h and include that which
>>>>         might be OKish and avoids duplication. Thoughts ?
>>>
>>> No, I'm not hacking something that is purely architecture specific for
>>> the purpose of a bizarre integration quirk that should be handled by
>>> the boot firmware, and not Linux.
>>
>> The PCIe controller is fully controlled by Linux.
> 
> And it shouldn't. Why can't your favourite boot-loader use it, like on
> any reasonable machine?
Because U-Boot is designed to boot as quickly as possible and get out of 
the way, which means lazy initialization of any and all resources, which 
means skip initialization of any and all hardware that is not needed to 
boot the machine. It is one of the core design decisions behind the 
U-Boot driver model [1].

The R-Car V4H using mainline U-Boot can boot from PCIe/NVMe SSD, but 
that is purely optional and some users might instead boot from SD cards 
or eMMCs, and even then the PCIe hardware is shut down before booting 
the OS to prevent any issues during OS boot or reinitialization by the OS.

[1] 
https://git.u-boot-project.org/u-boot/u-boot/-/blob/main/doc/develop/driver-model/design.rst?ref_type=heads&plain=1#L794

Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro

[Bjorn Helgaas]

On Fri, Jul 10, 2026 at 03:35:10PM +0200, Marek Vasut wrote:
> On 7/10/26 10:30 AM, Marc Zyngier wrote:
> > On Thu, 09 Jul 2026 21:10:03 +0100,
> > Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
> > > 
> > > Instead of pulling in the whole linux/irqchip/arm-gic-v3.h ,
> > > copy the one GITS_TRANSLATER register offset macro directly into
> > > the driver.  This repairs the ability to build the driver on
> > > non-ARM non-GIC targets the way it was possible until now, which
> > > retains good build test coverage.
> ...

> So in the end, it is either this patch or limit the build to
> arm/arm64 . At least this patch still allows building this driver
> with more compilers on the various build bots, so I would opt for
> this patch here.

I like the build coverage, but duplicating the #define doesn't really
seem good to me.  It makes readability worse because cscope/tags now
sees two definitions without an obvious reason.

Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro

[Marek Vasut]

On 7/13/26 7:54 PM, Bjorn Helgaas wrote:
> On Fri, Jul 10, 2026 at 03:35:10PM +0200, Marek Vasut wrote:
>> On 7/10/26 10:30 AM, Marc Zyngier wrote:
>>> On Thu, 09 Jul 2026 21:10:03 +0100,
>>> Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>>>>
>>>> Instead of pulling in the whole linux/irqchip/arm-gic-v3.h ,
>>>> copy the one GITS_TRANSLATER register offset macro directly into
>>>> the driver.  This repairs the ability to build the driver on
>>>> non-ARM non-GIC targets the way it was possible until now, which
>>>> retains good build test coverage.
>> ...
> 
>> So in the end, it is either this patch or limit the build to
>> arm/arm64 . At least this patch still allows building this driver
>> with more compilers on the various build bots, so I would opt for
>> this patch here.
> 
> I like the build coverage, but duplicating the #define doesn't really
> seem good to me.  It makes readability worse because cscope/tags now
> sees two definitions without an obvious reason.

I can rename the macro, or ... sigh ... I can reduce the driver to build 
only on ARM/ARM64. Which one do you prefer ?

Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro

[Geert Uytterhoeven]

Hi Marek,

On Tue, 14 Jul 2026 at 01:27, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 7/13/26 7:54 PM, Bjorn Helgaas wrote:
> > On Fri, Jul 10, 2026 at 03:35:10PM +0200, Marek Vasut wrote:
> >> On 7/10/26 10:30 AM, Marc Zyngier wrote:
> >>> On Thu, 09 Jul 2026 21:10:03 +0100,
> >>> Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
> >>>>
> >>>> Instead of pulling in the whole linux/irqchip/arm-gic-v3.h ,
> >>>> copy the one GITS_TRANSLATER register offset macro directly into
> >>>> the driver.  This repairs the ability to build the driver on
> >>>> non-ARM non-GIC targets the way it was possible until now, which
> >>>> retains good build test coverage.
> >> ...
> >
> >> So in the end, it is either this patch or limit the build to
> >> arm/arm64 . At least this patch still allows building this driver
> >> with more compilers on the various build bots, so I would opt for
> >> this patch here.
> >
> > I like the build coverage, but duplicating the #define doesn't really
> > seem good to me.  It makes readability worse because cscope/tags now
> > sees two definitions without an obvious reason.
>
> I can rename the macro, or ... sigh ... I can reduce the driver to build

That would obfuscate the code?

> only on ARM/ARM64. Which one do you prefer ?

Just add the dependency for compile-testing, just like
PCIE_IPROC_PLATFORM does.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro

[Bjorn Helgaas]

On Mon, Jul 13, 2026 at 08:05:38PM +0200, Marek Vasut wrote:
> On 7/13/26 7:54 PM, Bjorn Helgaas wrote:
> > On Fri, Jul 10, 2026 at 03:35:10PM +0200, Marek Vasut wrote:
> > > On 7/10/26 10:30 AM, Marc Zyngier wrote:
> > > > On Thu, 09 Jul 2026 21:10:03 +0100,
> > > > Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
> > > > > 
> > > > > Instead of pulling in the whole linux/irqchip/arm-gic-v3.h ,
> > > > > copy the one GITS_TRANSLATER register offset macro directly into
> > > > > the driver.  This repairs the ability to build the driver on
> > > > > non-ARM non-GIC targets the way it was possible until now, which
> > > > > retains good build test coverage.
> > > ...
> > 
> > > So in the end, it is either this patch or limit the build to
> > > arm/arm64 . At least this patch still allows building this driver
> > > with more compilers on the various build bots, so I would opt for
> > > this patch here.
> > 
> > I like the build coverage, but duplicating the #define doesn't really
> > seem good to me.  It makes readability worse because cscope/tags now
> > sees two definitions without an obvious reason.
> 
> I can rename the macro, or ... sigh ... I can reduce the driver to build
> only on ARM/ARM64. Which one do you prefer ?

I think a dependency on ARM/ARM64 is preferable.

Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro

[Marek Vasut]

On 7/14/26 1:00 PM, Bjorn Helgaas wrote:
> On Mon, Jul 13, 2026 at 08:05:38PM +0200, Marek Vasut wrote:
>> On 7/13/26 7:54 PM, Bjorn Helgaas wrote:
>>> On Fri, Jul 10, 2026 at 03:35:10PM +0200, Marek Vasut wrote:
>>>> On 7/10/26 10:30 AM, Marc Zyngier wrote:
>>>>> On Thu, 09 Jul 2026 21:10:03 +0100,
>>>>> Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>>>>>>
>>>>>> Instead of pulling in the whole linux/irqchip/arm-gic-v3.h ,
>>>>>> copy the one GITS_TRANSLATER register offset macro directly into
>>>>>> the driver.  This repairs the ability to build the driver on
>>>>>> non-ARM non-GIC targets the way it was possible until now, which
>>>>>> retains good build test coverage.
>>>> ...
>>>
>>>> So in the end, it is either this patch or limit the build to
>>>> arm/arm64 . At least this patch still allows building this driver
>>>> with more compilers on the various build bots, so I would opt for
>>>> this patch here.
>>>
>>> I like the build coverage, but duplicating the #define doesn't really
>>> seem good to me.  It makes readability worse because cscope/tags now
>>> sees two definitions without an obvious reason.
>>
>> I can rename the macro, or ... sigh ... I can reduce the driver to build
>> only on ARM/ARM64. Which one do you prefer ?
> 
> I think a dependency on ARM/ARM64 is preferable.

I will send a V2 shortly.

Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro

[Marek Vasut]

On 7/14/26 9:54 AM, Geert Uytterhoeven wrote:

Hello Geert,

>>>> So in the end, it is either this patch or limit the build to
>>>> arm/arm64 . At least this patch still allows building this driver
>>>> with more compilers on the various build bots, so I would opt for
>>>> this patch here.
>>>
>>> I like the build coverage, but duplicating the #define doesn't really
>>> seem good to me.  It makes readability worse because cscope/tags now
>>> sees two definitions without an obvious reason.
>>
>> I can rename the macro, or ... sigh ... I can reduce the driver to build
> 
> That would obfuscate the code?
> 
>> only on ARM/ARM64. Which one do you prefer ?
> 
> Just add the dependency for compile-testing, just like
> PCIE_IPROC_PLATFORM does.

I will send a V2 shortly.