On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot <acour...@nvidia.com> wrote:
> Would anyone be opposed to having a gpio_get() function that works similarly > to e.g. regulator_get() and clk_get()? I understand the concept and why you want to do this. However I think the global GPIO numberspace defeats the purpose. gpio_get() should get an abstract handle just like clk_get() or regulator_get(), not a fixed numeral. That is the only way to really transit away from the global GPIO numberspace. The proper refactoring I can see is to introduce an orthogonal mechanism that will return something like a struct gpio_handle * when you call gpio_get(), and then use a new set of accessor functions to manipulate the GPIO, like gpio_handle_set()/ etc for all known GPIO operations. So defined in a new #ifdef CONFIG_GPIO_HANDLES or so in a new <linux/gpio-handles.h> header and like the other subsystems handling abstract resources just passing an opaque pointer cookie around. Then when migrating a driver to use this mechanism, only include <linux/gpio-handles.h> and make that one driver only use the abstract interface and get rid of the global numberspace. Then we can have drivers that under a transition period will support both the global numberspace and this new handle-based access pattern. Then migrate all clients over to <linux/gpio-handle.h> and finally kill off the old global numberspace and only use handles with that driver. So a much more thorough refactoring is needed, just doing a simple int lookup returning global GPIO numbers will likely only make the current mess worse. This more ambitious refactoring path is going to be a large endavour and will likely go through a lot of reviews and debate, but something like this is badly needed for the GPIO subsystem. Maybe Grant will have different opinions though so this is not the final word on this issue... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
