Re: [PATCH v6 2/4] pinctrl: imx: answer OUTPUT_ENABLE/INPUT_ENABLE queries from the pad register

From: Bartosz Golaszewski

Date: Wed Sep 16 2026 - 05:43:18 EST


On Tue, 15 Sep 2026 10:04:59 +0200, Mehmet Fide <mehmet.fide@xxxxxxxxx> said:
> From: Mehmet Fide <mehmet.fide@xxxxxxxxxxxxxxxxxx>
>
> The mmio pinconf get callback ignores which parameter was requested and
> returns the raw conf register, so a generic query through
> pinctrl_gpio_get_config() gets register bits back instead of the packed
> parameter it asked for.
>
> Decode the requested parameter and answer PIN_CONFIG_OUTPUT_ENABLE and
> PIN_CONFIG_INPUT_ENABLE on SoCs that declare where those bits live in
> the pad register; Vybrid has OBE at bit 1 and IBE at bit 0. The answer
> is 0 with the bit value as the argument, which is what the
> pinctrl_gpio_get_config() users (gpio-by-pinctrl, and gpio-mmio in the
> next patch) expect. Other parameters and the SCU based SoCs, whose
> firmware call returns the raw pad value as well, get -ENOTSUPP; a pin
> the device tree never configured gets -EINVAL, as the raw helper already
> does, so a caller can tell "no answer for this pin" from "this
> controller never answers".
>
> The only in-tree user of the raw register was the debugfs group dump,
> which called the callback with an uninitialized config; it now reads
> the register through its own helper, like the single pin dump already
> did.
>
> The set callback is not touched: the fsl,pins binding hands it the raw
> pad register value and that stays the only thing it accepts. Nothing
> in-tree sends generic parameters to it on these SoCs; making it
> understand them is a separate change.
>
> This gives gpio-mmio a way to read back the line direction on chips
> whose direction lives in the pin controller.
>
> Suggested-by: Bartosz Golaszewski <brgl@xxxxxxxxxx>
> Signed-off-by: Mehmet Fide <mehmet.fide@xxxxxxxxxxxxxxxxxx>
> Reviewed-by: Haibo Chen <haibo.chen@xxxxxxx>
> Reviewed-by: Linus Walleij <linusw@xxxxxxxxxx>
> ---

Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxxxxxxxx>