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]
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ