linux-kernel - Getting at gpio- and pinctrl-devices as a consumer

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 24 Nov 2016 22:35:32 +0100
From:   Peter Rosin <peda@...ntia.se>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Alexandre Courbot <gnurou@...il.com>
CC:     Wolfram Sang <wsa-dev@...g-engineering.com>,
        <linux-kernel@...r.kernel.org>,
        Peter Korsgaard <peter.korsgaard@...co.com>,
        Wolfram Sang <wsa@...-dreams.de>, <linux-i2c@...r.kernel.org>,
        <linux-gpio@...r.kernel.org>
Subject: Getting at gpio- and pinctrl-devices as a consumer

On 2016-11-24 20:52, Wolfram Sang wrote:
>> Yes, I never liked that include, but I don't know how to get
>> from struct gpio_desc * to the relevant struct device *
>> without it...
> 
> Looks to me like we should ask the GPIO maintainers if they are willing
> to export this value? I am probably not as good as you in explaining the
> details why, though...

Right. Adding Linus, Alexandre and the gpio list.

The background is that the gpio- and pinctrl-based i2c-mux drivers
need to know if the device that is used to control the mux of the
i2c-bus is also sitting on that very same i2c-bus. If it is, the
locking has to be different and a bit more relaxed. This relaxed
mode cannot be used always, as that would change the mux behavior
in an unacceptable way for stuff expecting the (traditional)
stricter locking. See Documentation/i2c/i2c-topology for more
details if you need it.

To check this, the i2c mux drivers dig out the device connected to
each gpio-pin (or pinctrl-state) and walks up the device tree to see
if the root i2c adapter that is muxed is in the loop.

When I wrote this code, I could not find a clean way to go from a
struct gpio_desc * to the relevant device, short of doing

	#include "../../gpio/gpiolib.h"

	gpio_dev = &gpio_desc->gdev->dev;

And similarly for pinctrl:

	#include "../../pinctrl/core.h"

	struct pinctrl_setting *setting;
	pinctrl_dev = setting->pctldev->dev;

I'm not very proud of that, and wonder if there is a better way
to get at the needed struct device? If not, then perhaps there
should be?

Cheers,
Peter