Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro
From: Marek Vasut
Date: Mon Jul 13 2026 - 19:28:55 EST
On 7/13/26 5:20 PM, Marc Zyngier wrote:
On Fri, 10 Jul 2026 14:35:10 +0100,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].
Marek Vasut <marek.vasut@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxx>
Closes: https://lore.kernel.org/oe-kbuild-all/202607100310.iQw5m9Uo-lkp@xxxxxxxxx/
Signed-off-by: Marek Vasut <marek.vasut+renesas@xxxxxxxxxxx>
---
Cc: "Krzysztof Wilczyński" <kwilczynski@xxxxxxxxxx>
Cc: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
Cc: Catalin Marinas <catalin.marinas@xxxxxxx>
Cc: Conor Dooley <conor+dt@xxxxxxxxxx>
Cc: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
Cc: Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>
Cc: Lorenzo Pieralisi <lpieralisi@xxxxxxxxxx>
Cc: Manivannan Sadhasivam <mani@xxxxxxxxxx>
Cc: Marc Zyngier <maz@xxxxxxxxxx>
Cc: Rob Herring <robh@xxxxxxxxxx>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@xxxxxxxxxxx>
Cc: devicetree@xxxxxxxxxxxxxxx
Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
Cc: linux-doc@xxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx
Cc: linux-pci@xxxxxxxxxxxxxxx
Cc: linux-renesas-soc@xxxxxxxxxxxxxxx
---
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?
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