On Wed, 2015-10-14 at 07:24PM +0200, Lars-Peter Clausen wrote: > On 10/14/2015 06:54 PM, Sören Brinkmann wrote: > > 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. > > Hm, right. We could also make it a user-selectable config symbol. In that > case you only need to disable one symbol when you don't have FPGA support > rather than one for each driver. Although I'm not quite sure where to put > such a symbol. Eventually, the FPGA manager subsystem could probably provide some high level config symbols. Though, it is probably also not given that every FPGA-enabled platform needs the FPGA manager. Sören
