Devicetree
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@mailbox.org>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-pci@vger.kernel.org, "kernel test robot" <lkp@intel.com>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Yoshihiro Shimoda" <yoshihiro.shimoda.uh@renesas.com>,
	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] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro
Date: Fri, 10 Jul 2026 15:35:10 +0200	[thread overview]
Message-ID: <2cb03029-0957-4ed8-98bd-9b3e0e0bce2d@mailbox.org> (raw)
In-Reply-To: <87qzlb5jsl.wl-maz@kernel.org>

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 !

      reply	other threads:[~2026-07-10 13:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09 20:10 [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro Marek Vasut
2026-07-10  8:30 ` Marc Zyngier
2026-07-10 13:35   ` Marek Vasut [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2cb03029-0957-4ed8-98bd-9b3e0e0bce2d@mailbox.org \
    --to=marek.vasut@mailbox.org \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=krzk+dt@kernel.org \
    --cc=kwilczynski@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 \
    --cc=lkp@intel.com \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=maz@kernel.org \
    --cc=robh@kernel.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox