On Tue, Apr 16, 2013 at 11:27:41AM +0900, Alex Courbot wrote: > On 04/15/2013 04:43 PM, Christian Ruppert wrote: > >Hello Alexandre, > > > >On Fri, Apr 12, 2013 at 11:42:42AM -0700, Alexandre Courbot wrote: > >>Hi Vineet, > >> > >>On Thu, Apr 11, 2013 at 7:05 AM, Vineet Gupta > >><Vineet.Gupta1@xxxxxxxxxxxx> wrote: > >>>I'm the maintainer for arch/arc. > >>> > >>>For 3.10, we are going to have a sub-platform included which enables GPIO. > >>>However given that your patch is still not in a maintainer tree I'm going to apply > >>>the platform patch with GENERIC_GPIO and it would show up in -next as well. But > >>>don't be alarmed - to align with your work, Christian or you can then possibly > >>>apply a patch to make arch/arc/* confirm to your work - preferably via your > >>>tree/patchseries - OK ? > >> > >>I guess that would work, but since I assume your platforms' GPIO > >>implementation use gpiolib anyway wouldn't it be simpler and more > >>logical to directly require it? > >> > >>If you have reasons for not doing so I'm ok with doing the switch > >>later too, anyway that's what I had to do for all the other archs. > > > >The GPIO driver patch was proposed on lkml a few days ago and although I > >am not aware of any "GENERIC" methods it uses it does not compile > >without GENERIC_GPIO being defined (errors in of_gpio.h etc). You can > >review the patch at https://lkml.org/lkml/2013/4/10/385. > > > >We'd be happy to accept any guidance on how to remove GENERIC_GPIO. > >Also, I'm not sure the custom interface to the pin controller is a great > >solution and suggestions are welcome. The goal is to remove redundancy > >between the drivers in the definition of pin groups. > > Hi Christian, > > Thanks for the link to the patch. This is rather puzzling - in > drivers/gpio/Kconfig your GPIO_TB10X config option seems to be under > the "if GPIOLIB" condition which is what I expect, since your driver > uses gpiolib. If you go to the GPIOLIB config option, you notice > that is explicitly selects GENERIC_GPIO as a result of being > enabled. Therefore CONFIG_GENERIC_GPIO should always be defined > whenever your driver is compiled and it should not be needed to > select it elsewhere. Do we agree on that? > > I'd really like to go to the bottom of this since I saw several > similar issues already, but I don't understand how this can happen > at all. Having the .config of both the working (with GENERIC_GPIO > selected) and non-working (only GPIOLIB selected) cases would > probably be helpful, could you send them to me? > > Thanks, > Alex. Hello Alexandre, Thanks for taking a look at the driver. I think the issue we see is due to the fact that "Platforms must declare GENERIC_GPIO support in their Kconfig (boolean true)" (from Documentation/gpio.txt). This seems to be still the case at the moment and I haven't found a way around it. Removing the config GENERIC_GPIO section from our platform's Kconfig (see arch/arc/plat-tb10x/Kconfig in linux-next) results in compilation errors. This seems logical since "config GPIOLIB" only selects GENERIC_GPIO but assumes it is defined elsewhere. We were wondering if we could get rid of the "config GENERIC_GPIO" section in the new platform's Kconfig in order to avoid adding things you are going to remove again soon and in order to check if there aren't any hidden dependencies on GENERIC_GPIO in the driver. Do I understand your mail correctly that this is not yet possible? Greetings, Christian -- Christian Ruppert , <christian.ruppert@xxxxxxxxxx> /| Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pré-Fleuri _// | bilis Systems CH-1228 Plan-les-Ouates -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
