Linus Walleij <linus.walleij@xxxxxxxxxx> writes: [...] > 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. The churn will happen one way or another. the only question is whether it happens in drivers/gpio or arch/arm/*. Grant, what's your feeling here. How much ugliness are you willing to tolerate in a bulk move to drivers/gpio. At least for OMAP, I am personally be working on the cleanup/move so I can work either way, although I know Tony has an obvious preference for moving it to drivers/gpio. :) The OMAP driver is already using gpiolib. The main ugliness in the OMAP driver is the awful ifdeffery used to handle the differences across the various SoCs in the OMAP family. I've already got most of that cleaned up[1]. Kevin [1] http://marc.info/?l=linux-omap&m=130351321022770&w=2 -- 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
