[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 at 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 at 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 at intel.com>
>>>> Closes: https://lore.kernel.org/oe-kbuild-all/202607100310.iQw5m9Uo-lkp@intel.com/
>>>> Signed-off-by: Marek Vasut <marek.vasut+renesas at mailbox.org>
>>>> ---
>>>> Cc: "Krzysztof Wilczyński" <kwilczynski at kernel.org>
>>>> Cc: Bjorn Helgaas <bhelgaas at google.com>
>>>> Cc: Catalin Marinas <catalin.marinas at arm.com>
>>>> Cc: Conor Dooley <conor+dt at kernel.org>
>>>> Cc: Geert Uytterhoeven <geert+renesas at glider.be>
>>>> Cc: Krzysztof Kozlowski <krzk+dt at kernel.org>
>>>> Cc: Lorenzo Pieralisi <lpieralisi at kernel.org>
>>>> Cc: Manivannan Sadhasivam <mani at kernel.org>
>>>> Cc: Marc Zyngier <maz at kernel.org>
>>>> Cc: Rob Herring <robh at kernel.org>
>>>> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh at renesas.com>
>>>> Cc: devicetree at vger.kernel.org
>>>> Cc: linux-arm-kernel at lists.infradead.org
>>>> Cc: linux-doc at vger.kernel.org
>>>> Cc: linux-kernel at vger.kernel.org
>>>> Cc: linux-pci at vger.kernel.org
>>>> Cc: linux-renesas-soc at 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