2011/5/4 Tony Lindgren <tony@xxxxxxxxxxx>: > * Linus Walleij <linus.walleij@xxxxxxxxxx> [110504 00:37]: >> 2011/5/3 Kevin Hilman <khilman@xxxxxx>: >> >> > Are you OK with a move of the current OMAP GPIO drivers (rather ugly) >> > into drivers/gpio first, followed by the cleanup/restructure patches? >> >> In my case I actually did some cleanup after moving the driver for >> U300, but I think this is a question to the GPIO maintainer who >> I want to ACK this stuff in the end. >> >> Grant? >> >> You can always squash it later ... > > Personally I would prefer absolutely minimal clean-up of current > code before moving to drivers/gpio to cut down the "crazy churn" in > arch/arm/. Also then further changes are easier for the GPIO > maintainers to review. > > Of course I understand that this might cause extra load for the > GPIO maintainers, so it's up to the GPIO maintainers to set the > required standards before accepting the code into drivers/gpio. After discussion with Grant (in person) here at UDS I am informed that he will not be able to review my GPIO consolidation patches in time to make adjustments needed for this merge window, so we're aiming at early 2.6.41 for these. He has indicated that he has problems with the chosen config mechanism and that we may need to back a few technical assumptions out, and we need some more time for that. For example we may need to refer to configurations by a string or indeed export the struct gpio_chip accessor function gpio_to_chip() and use custom functions for special stuff, as was the first idea. I will do the refactoring once I have a clear indication from the maintainer where he wants this to end up, so my GPIO consolidation patches will need to rest for a while. For TI I guess this currently means you simply cannot work on GPIO stuff until you know where to go with it unless you allow the OMAP GPIO authors to keep churning in arch/arm/*... That's unless Grant is OK with us moving stuff into drivers/gpio that does *not* use gpiolib and utilize singletons to get at the gpio_chip addresses (i.e. current form) and keep it churning like that until it can be refactored. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
