On Wed, Dec 11, 2019 at 6:09 PM Marco Felsch <m.felsch@xxxxxxxxxxxxxx> wrote: > I discussed it with a colleague again and he mentioned that pinctrl > should be named pinctrl instead it should be named padctrl. Quoting Documentation/driver-api/pinctl.rst: (...) Definition of PIN: - PINS are equal to pads, fingers, balls or whatever packaging input or output line you want to control and these are denoted by unsigned integers in the range 0..maxpin. (...) > We don't > reconfigure the pad to a other function it is still a device general > purpose input pad. The hw-signal flow goes always trough the gpio block > so one argument more for my solution. Also we don't configure the "pad" > to be a vsel/ena-pin. The hw-pad can only be a gpio or has an alternate > function (WDKICK for GPIO0, Seq. SYS_EN for GPIO2, Seq. PWR_EN for GPIO4). > Instead we tell the regulator to use _this_ GPIO e.g. for voltage > selection so we go the other way around. My last argument why pinctrl > isn't the correct place is that the GPIO1 can be used for > regulator-0:vsel-in and for regulator-1:enable-in. So this pad would > have different states which is invalid IMHO. Yeah it is just one of these cases where the silicon designer pulled a line of polysilicone over to the regulator enable signal and put a switch on it and say "so you can also enable the regulator with a signal from here", it can be used in parallel with anything else, which is especially messy. Special cases require special handling, since the electronic design of this thing is a bit Rube Goldberg. Yours, Linus Walleij
