On Tue, Sep 18, 2018 at 03:04:23PM -0700, Rajat Jain wrote: > On Tue, Sep 18, 2018 at 8:36 AM Mika Westerberg > <mika.westerberg@xxxxxxxxxxxxxxx> wrote: > > > > For some reason I thought GPIOLIB handles translation from GPIO ranges > > to pinctrl pins but it turns out not to be the case. This means that > > when GPIOs operations are performed for a pin controller having a custom > > GPIO base such as Cannon Lake and Ice Lake incorrect pin number gets > > used internally. > > > > Fix this in the same way we did for lock/unlock IRQ operations and > > translate the GPIO number to pin before using it. > > > > Fixes: a60eac3239f0 ("pinctrl: intel: Allow custom GPIO base for pad groups") > > Reported-by: Rajat Jain <rajatja@xxxxxxxxxx> > > Signed-off-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> > > Tested-by: Rajat Jain <rajatja@xxxxxxxxxx> > > This has fixed the issue for me. Thanks for testing! > One question, may not be related: I see this line in my logs everytime > I export a pin (GPIO40 = pin 16 in this case). Is that an indication > of a problem? > > "gpio gpiochip0: Persistence not supported for GPIO 40" It seems to be debug print if the underlying GPIO chip does not support PIN_CONFIG_PERSIST_STATE (pinctrl-intel.c does not). I would not worry about it.