On Fri, Jun 22, 2018 at 8:29 PM Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> wrote: > On Fri 22 Jun 10:58 PDT 2018, Bjorn Andersson wrote: > > On Mon 18 Jun 13:52 PDT 2018, Stephen Boyd wrote: > > > > > We rely on devices to use pinmuxing configurations in DT to select the > > > GPIO function (function 0) if they're going to use the gpio in GPIO > > > mode. Let's simplify things for driver authors by implementing > > > gpio_request_enable() for this pinctrl driver to mux out the GPIO > > > function when the gpio is use from gpiolib. > > > > > > Cc: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> > > > > Reviewed-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> (...) > While both patch 2 and 3 are convenient ways to get around the annoyance > of having to specify a pinmux state both patches then ends up relying on > some default pinconf state; which I think is bad. Nothing stops you from setting up a default conf in this callback though. But admittedly this call was added for simpler hardware. > Further more in situations like i2c-qup (downstream), where the pins are > requested as gpios in order to "bitbang" a reset this would mean that > the driver has to counter the convenience; by either switching in the > default pinmux at the end of probe or postponing the gpio_request() to > the invocation of reset and then, after issuing the gpio_release, > switching in the default pinmux explicitly again. That's a bigger problem. If the system is using device and GPIO mode orthogonally, it'd be good to leave like this. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
