[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b481ed92-c9d2-b4da-b484-6d8bec6038f0@axentia.se>
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
Powered by blists - more mailing lists