Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752564AbcKXX3v (ORCPT ); Thu, 24 Nov 2016 18:29:51 -0500 Received: from mail-qt0-f180.google.com ([209.85.216.180]:32777 "EHLO mail-qt0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751515AbcKXX3l (ORCPT ); Thu, 24 Nov 2016 18:29:41 -0500 MIME-Version: 1.0 In-Reply-To: References: <1479908035-18284-1-git-send-email-peda@axentia.se> <20161124151420.GF4271@katana> <46be889f-a558-0174-f638-c685b23c8ed9@axentia.se> <20161124195230.GA1666@katana> From: Linus Walleij Date: Fri, 25 Nov 2016 00:29:40 +0100 Message-ID: Subject: Re: Getting at gpio- and pinctrl-devices as a consumer To: Peter Rosin Cc: Alexandre Courbot , Wolfram Sang , "linux-kernel@vger.kernel.org" , Peter Korsgaard , Wolfram Sang , "linux-i2c@vger.kernel.org" , "linux-gpio@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1640 Lines: 45 On Thu, Nov 24, 2016 at 10:35 PM, Peter Rosin wrote: > 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? Surely if I can be convinced that we need helpers for this in GPIO and/or pin control we can add them. They just need to be named something reasonable and be generally useful for other situations of similar nature. struct device *gpiod_get_backing_device(struct gpio_desc *d); Is simple but is it really what you want? Yours, Linus Walleij