On Fri, Nov 29, 2013 at 11:30 AM, boris brezillon <b.brezillon@xxxxxxxxxxx> wrote: > On 29/11/2013 11:03, Linus Walleij wrote: >> I guess one way is to obtain this GPIO in board code and just >> flick it depending on which device you register. (...) > The whole goal of moving from board files to dt is to drop all board > specific processing or initialization and only keep a common description > with generic drivers capable of handling common use cases. > > I'm not sure providing new board specific drivers is a good solution > (even if it is the simplest way to achieve our goal). > > Could we have something similar to pinctrl but with gpios : > when the device is probed the device/driver core code request the gpio > configure it appropriately and set it to the requested value (if configured > as output). This has been suggested under the name "GPIO hogs" in the past. It would work similar to how pinctrl hogs work by associating the GPIO line the controller itself, using some specific string like gpio-input-hogs = <...> / gpio-output-hogs = <...>; The gpiolib core will then grab and set up these before returning from the registration call so noone ever gets a chance to use them. > These are just thoughts, and I guess introducing new code in the > device/driver core > code is not that easy, especially when this code is here to handle specific > case > like ours. It is very easy, just write the patch, iterate it (these patches get a lot of scrutiny as it is core code, so expect some work and time to get it done), and then unless there is a blocker, I would merge it. The concept is entirely sound, just that someone needs to step up and do the work... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
