Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754683AbcKYNj2 (ORCPT ); Fri, 25 Nov 2016 08:39:28 -0500 Received: from mail-qk0-f171.google.com ([209.85.220.171]:33013 "EHLO mail-qk0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754248AbcKYNjV (ORCPT ); Fri, 25 Nov 2016 08:39:21 -0500 MIME-Version: 1.0 In-Reply-To: <45787444-a237-7363-5f03-0cd207cb82c2@axentia.se> References: <1479908035-18284-1-git-send-email-peda@axentia.se> <20161124151420.GF4271@katana> <46be889f-a558-0174-f638-c685b23c8ed9@axentia.se> <20161124195230.GA1666@katana> <45787444-a237-7363-5f03-0cd207cb82c2@axentia.se> From: Linus Walleij Date: Fri, 25 Nov 2016 14:39:14 +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: 1519 Lines: 39 On Fri, Nov 25, 2016 at 10:24 AM, Peter Rosin wrote: >[Me] >> struct device *gpiod_get_backing_device(struct gpio_desc *d); >> >> Is simple but is it really what you want? > > Well, my first attempt was to simply have a property in the > devicetree stating that the mux was controlled from the same > i2c bus it was muxing, but that was shot down because it > should be possible to deduce this from the implementation (or > something of that meaning, it was a while ago), which to me > meant examining the "struct device"-tree. The problem goes into any subsystem providing resources for a mux in this case, generally for example it is not OK for a device to runtime suspend or shut down its regulator or turn off its clock if it is acting as a mux. GPIO and pin control just happens to be two resource in this specific case. > For the gpio_desc it is easy. However, it is worse for the > pinctrl case. It is annoying to do this in a sense, because it starts to kill the abstraction we have created exactly in order to avoid consumers having to worry much about their providers internals. No we are opening the can and letting the stuff out all over the place. Have you looked into the discussion about device dependencies in general? Isn't this problem mappable as a subset of that? This was discussed at length at the last kernel summit: https://lwn.net/Articles/705852/ See especially Rafael's commit 9ed9895370aedd6032af2a9181c62c394d08223b to driver core in linux-next Yours, Linus Walleij