linux-kernel - Re: [PATCH] irqchip/xilinx: Expose Kconfig option

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87916c069789a91a5bb0856c6ff9d72c36a59dd5.camel@calian.com>
Date:   Fri, 16 Apr 2021 18:14:40 +0000
From:   Robert Hancock <robert.hancock@...ian.com>
To:     "maz@...nel.org" <maz@...nel.org>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "michal.simek@...inx.com" <michal.simek@...inx.com>
Subject: Re: [PATCH] irqchip/xilinx: Expose Kconfig option

On Fri, 2021-04-16 at 18:53 +0100, Marc Zyngier wrote:
> On Fri, 16 Apr 2021 17:05:49 +0100,
> Robert Hancock <robert.hancock@...ian.com> wrote:
> > On Fri, 2021-04-16 at 14:41 +0100, Marc Zyngier wrote:
> > > On Fri, 16 Apr 2021 00:32:50 +0100,
> > > Robert Hancock <robert.hancock@...ian.com> wrote:
> > > > Previously the XILINX_INTC config option was hidden and only
> > > > auto-selected on the MicroBlaze platform. However, this IP can also be
> > > > used on other platforms. Allow this option to be user-enabled.
> > > > 
> > > > Signed-off-by: Robert Hancock <robert.hancock@...ian.com>
> > > 
> > > I don't think this is a good idea. In general, people have no idea
> > > which interrupt controller they need to select. So you either end-up
> > > with a missing interrupt controller, or a bunch you really don't need.
> > > 
> > > This is essentially a platform constraint, and this should directly be
> > > selected by the platform if you have this IP in your system.
> > > 
> > > Thanks,
> > > 
> > > 	M.
> > 
> > The problem is essentially that at the platform level, we don't know, other
> > than in the MicroBlaze case where we know it will be used as the platform's
> > primary interrupt controller. In our case, we are using this IP core on the
> > ZynqMP platform as a secondary cascaded interrupt controller in the FPGA
> > portion of the device.
> > But many ZynqMP configurations wouldn't have this device present, it
> > depends on what the user instantiates in the programmable logic.
> > Also, this core could just as easily be instantiated in standalone
> > Xilinx FPGAs which could be connected to many different platforms
> > over a PCIe, AXI, etc.  bus.
> 
> Not compiling it for some users is great if you happen to *know* what
> you have to select, which is probably a single digit percentage of the
> people that build their own kernel. At least having it to depend on
> ZYNQMP (or some other FPGA platform) would narrow it down.
> 
> And if you have some other HW in your FPGA, you can make the config
> fragment for this HW select the right interrupt controller. But I'm
> definitely not keen on making this a universally user-selectable
> driver.

In general there is no specific or unique config option for what is
instantiated in an FPGA, it is completely up to the whims of whoever set it up.
You can instantiate whatever logic cores you want and there is no guarantee
whether they will or won't end up using this interrupt controller in the path
somewhere, so having a dependency there doesn't make much sense. For FPGA logic
it's ultimately up to the user to ensure the kernel config they are using has
the right drivers enabled for the cores they are using. Kconfig doesn't and
can't really help in this regard.

There's some precedent on this issue with drivers for various other FPGA-based
IP cores for SPI, I2C, Ethernet etc. Often they started out with an
architecture constraint which limited them to the platform they were originally
developed with, but which was later removed because the ability to use them in
standalone FPGAs means that the platforms they could potentially be used with
are basically unconstrained.

> 
> > So I don't think having this as a platform constraint makes sense.
> 
> I don't think imposing this on *everyone*, across all supported
> architectures and platforms makes any sense. Surely, people who build
> their own HW (because that's what we are talking about here) can be
> bothered to add the small Kconfig fragment that is required to their
> kernel build.

-- 
Robert Hancock
Senior Hardware Designer, Calian Advanced Technologies
www.calian.com