On Wed, Oct 4, 2017 at 9:35 AM, Quentin Schulz <quentin.schulz@xxxxxxxxxxxxxxxxxx> wrote: > Just to be a little more precise, > - 0: drive low > - 1: drive high > - 2: input with interrupt triggering > - 3: LDO on > - 4: LDO off > - 5~7: floating (or ADC) > > for AXP813, and > - 0: drive low > - 1: drive high > - 2: input with interrupt triggering > - 3: LDO on > - 4: ADC > - 5~7: floating Fair enough, it's mux modes that the pin supports, no big surprises. > So I think what you suggested Linus is not really relevant here as the > regulator framework will take care of disabling the regulator when > needed (for AXP813 via the ldo_off "muxing" selected by the regulator > framework). I think I see why I got confused. The point is that your mode for setting it to "LDO on" should have the pin control state connected to the relevant device. It should be connected to the regulator and nothing else, so if there is a fixed regulator or whatever in the device tree, it should have pinctrl-0 and pinctrl-names = ".."; here is is for some obscure reason connected to the GPIO controller (!) instead, and the actual consumer of this state is NOT the GPIO controller, but quite obviously the regulator, so put the pinctrl business in that regulator node instead. "default" mode is OK on a regulator, as that can be expected to make the pin precisely a regulator pin. Forget my ramblings about a "regulator" state. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html