GPIO set config argument value difference in pinconf and gpiolib

GPIO set config argument value difference in pinconf and gpiolib

[Ryan.Wanner]

Hello,

I have a question about gpiochip_generic_config function. I noticed when
calling this function the pin configuration is incorrect for
push-pull/open-drain in pinctrl-at91-pio4. I traced this down to a
argument value that is incorrect, this is extracted from the config
using pinconf_to_config_argument. The pinctrl driver processes this
config argument value correctly but when gpiolib calls this function
that value is not passed causing the argument to be 0 in the function
atmel_conf_pin_config_group_set. I see this same structure in other
pinctrl drivers as well.

It seems that gpio_set_config is called which hard codes 0 into
gpio_set_config_with_arugment function call making the argument 0 when
passed into the pinctrl set config function. It seems that the correct
way would to mimic the gpio_set_bias function handling of this argument
value. Doing a small local test seems to confirm my suggestion.

Best,
Ryan Wanner

Re: GPIO set config argument value difference in pinconf and gpiolib

[andy.shevchenko]

Mon, May 15, 2023 at 08:21:35AM +0000, Ryan.Wanner@microchip.com kirjoitti:
> Hello,
> 
> I have a question about gpiochip_generic_config function. I noticed when
> calling this function the pin configuration is incorrect for
> push-pull/open-drain in pinctrl-at91-pio4. I traced this down to a
> argument value that is incorrect, this is extracted from the config
> using pinconf_to_config_argument. The pinctrl driver processes this
> config argument value correctly but when gpiolib calls this function
> that value is not passed causing the argument to be 0 in the function
> atmel_conf_pin_config_group_set. I see this same structure in other
> pinctrl drivers as well.
> 
> It seems that gpio_set_config is called which hard codes 0 into
> gpio_set_config_with_arugment function call making the argument 0 when
> passed into the pinctrl set config function.

Correct.

> It seems that the correct
> way would to mimic the gpio_set_bias function handling of this argument
> value. Doing a small local test seems to confirm my suggestion.

Nope. The driver developer(s) didn't get this correctly. The state
configuration are booleans, hence argument is ignored. It can be anything.

Seems they missed to add the switch to PUSH_PULL.

TL;DR: I'm pretty sure this is the bug in the above mentioned driver.

-- 
With Best Regards,
Andy Shevchenko