On Wed, 2015-10-14 at 05:57PM +0200, Lars-Peter Clausen wrote: > On 10/14/2015 05:18 PM, Sören Brinkmann wrote: > > On Wed, 2015-10-14 at 01:51PM +0100, Zubair Lutfullah Kakakhel wrote: > >> MIPSfpga uses the axi gpio controller. Enable the driver for MIPS. > >> > >> Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@xxxxxxxxxx> > >> --- > >> drivers/gpio/Kconfig | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig > >> index 8949b3f..58e9afd 100644 > >> --- a/drivers/gpio/Kconfig > >> +++ b/drivers/gpio/Kconfig > >> @@ -508,7 +508,7 @@ config GPIO_XGENE_SB > >> > >> config GPIO_XILINX > >> tristate "Xilinx GPIO support" > >> - depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86) > >> + depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86 || MIPS) > > > > Hmm, in general, this driver is hopefully generic enough that it doesn't > > have any real architecture dependencies. And I suspect, we want to > > enable this driver for ARM64 for ZynqMP soon too. Should we probably > > drop these arch dependencies completely? It seems to become quite a long list. > > I've been thinking about this a while ago. This is certainly not the only > driver affected by this problem. But the thing is people always complain if > new symbols become visable in Kconfig that don't apply to their platform. > > Maybe we should introduce a HAS_REPROGRAMABLE_LOGIC (or similar) feature > Kconfig symbol and let platforms which have a FPGA select it and let drivers > for FPGA peripherals depend on it. Sounds like a good idea to me. But, does that work for all use-cases. E.g. if you plug some PCIe card with an FPGA into an x86(_64) machine. That would allow you to use those drivers, but I'm not sure how that could pull in the new config symbol. Sören -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
