Hi Shimoda-san, On Mon, Jul 8, 2019 at 11:08 AM Yoshihiro Shimoda <yoshihiro.shimoda.uh@xxxxxxxxxxx> wrote: > R-Car PWM controller requires the gpio to output zero duty, > this patch allows to roll it back from gpio to mux when the gpio > is freed. > > Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@xxxxxxxxxxx> Thanks for your patch! > --- a/drivers/pinctrl/sh-pfc/pinctrl.c > +++ b/drivers/pinctrl/sh-pfc/pinctrl.c > @@ -26,6 +26,7 @@ > #include "../pinconf.h" > > struct sh_pfc_pin_config { > + unsigned int mux_mark; Due to padding, adding this field will increase memory consumption by 6 bytes per pin. Probably sh_pfc_pin_group.{pins,mux} should be changed from unsigned int to u16, but that's out of scope for this patch. > bool mux_set; > bool gpio_enabled; > }; > @@ -353,6 +354,15 @@ static int sh_pfc_func_set_mux(struct pinctrl_dev *pctldev, unsigned selector, > spin_lock_irqsave(&pfc->lock, flags); > > for (i = 0; i < grp->nr_pins; ++i) { > + int idx = sh_pfc_get_pin_index(pfc, grp->pins[i]); > + struct sh_pfc_pin_config *cfg = &pmx->configs[idx]; > + > + /* > + * This doesn't assume the order which gpios are enabled > + * and then mux is set. I'm sorry, I don't understand what you mean? Can you please reword or elaborate? > + */ > + WARN_ON(cfg->gpio_enabled); Can this actually happen? Should this cause a failure instead? > + > ret = sh_pfc_config_mux(pfc, grp->mux[i], PINMUX_TYPE_FUNCTION); > if (ret < 0) > goto done; > @@ -364,6 +374,7 @@ static int sh_pfc_func_set_mux(struct pinctrl_dev *pctldev, unsigned selector, > struct sh_pfc_pin_config *cfg = &pmx->configs[idx]; > > cfg->mux_set = true; > + cfg->mux_mark = grp->mux[i]; > } > > done: > @@ -417,6 +428,9 @@ static void sh_pfc_gpio_disable_free(struct pinctrl_dev *pctldev, > > spin_lock_irqsave(&pfc->lock, flags); > cfg->gpio_enabled = false; > + /* If mux is already set, this configure it here */ configures > + if (cfg->mux_set) > + sh_pfc_config_mux(pfc, cfg->mux_mark, PINMUX_TYPE_FUNCTION); Have you considered the case where more than one pin of a pinmux group was used as a GPIO? In that case sh_pfc_gpio_disable_free() will be called multiple times, possibly with the same mux_mark. I don't think this will cause issues, though. > spin_unlock_irqrestore(&pfc->lock, flags); > } Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds