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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZGIAaPSycsmOq690@surfacebook>
Date:   Mon, 15 May 2023 12:50:32 +0300
From:   andy.shevchenko@...il.com
To:     Ryan.Wanner@...rochip.com
Cc:     linux-gpio@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linus.walleij@...aro.org, linux-kernel@...r.kernel.org,
        Claudiu.Beznea@...rochip.com
Subject: Re: GPIO set config argument value difference in pinconf and gpiolib

Mon, May 15, 2023 at 08:21:35AM +0000, Ryan.Wanner@...rochip.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