From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E31D0C5DF62 for ; Wed, 6 Nov 2019 10:00:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BB182217F4 for ; Wed, 6 Nov 2019 10:00:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731855AbfKFKAk (ORCPT ); Wed, 6 Nov 2019 05:00:40 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:49497 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731649AbfKFKAj (ORCPT ); Wed, 6 Nov 2019 05:00:39 -0500 Received: from lupine.hi.pengutronix.de ([2001:67c:670:100:3ad5:47ff:feaf:1a17] helo=lupine) by metis.ext.pengutronix.de with esmtp (Exim 4.92) (envelope-from ) id 1iSI77-000065-LM; Wed, 06 Nov 2019 11:00:33 +0100 Message-ID: <576d5e496a79c00857820289f8f772d3bb090e35.camel@pengutronix.de> Subject: Re: [RFC v2 0/2] gpio: Support for shared GPIO lines on boards From: Philipp Zabel To: Peter Ujfalusi , Grygorii Strashko , Linus Walleij , Rob Herring Cc: Mark Brown , Bartosz Golaszewski , "open list:GPIO SUBSYSTEM" , "linux-kernel@vger.kernel.org" , Marek Szyprowski , Tero Kristo , Maxime Ripard , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" Date: Wed, 06 Nov 2019 11:00:32 +0100 In-Reply-To: References: <20191030120440.3699-1-peter.ujfalusi@ti.com> <5bca4eb6-6379-394f-c95e-5bbbba5308f1@ti.com> <20191030141736.GN4568@sirena.org.uk> <1258a5bf-a829-d47a-902f-bf2c3db07513@ti.com> <5669a4c1-2bc1-423b-1407-073317f7df7e@ti.com> <109f9ff2-81e0-6d3d-db60-d48cb0a4e74f@ti.com> <61c8c126-3061-e297-8dab-7333316b0754@ti.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:670:100:3ad5:47ff:feaf:1a17 X-SA-Exim-Mail-From: p.zabel@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2019-11-06 at 11:23 +0200, Peter Ujfalusi wrote: > > On 05/11/2019 20.07, Grygorii Strashko wrote: > > > > (but hey - if this is boot only then gpio-hogs should work. Are they?) > > > > > > That is another thing which almost works ;) > > > w/o gpio binding deferred probing is not possible if the GPIO controller > > > is probed later. > > > In some cases it might be even impossible to make sure that the GPIO > > > controller would probe first (GPIO extender on different i2c bus than > > > the user(s) of the gpio line) > > > In some cases moving around nodes in DT might artificially make things > > > work, but then someone compiles the expander as module, or some 'small' > > > change in kernel and the probe order on the bus changes. > > > I don't think it is a valid thing to have commits on the DT files > > > saying: move the expander front/after the hog affected user since since > > > Monday the probe order has changed. Then move it back two weeks later ;) > > > > > > > Ok. Above sounds like real problem. The implicit dependence is exist, > > but can't > > be resolved if any driver depends on gpio-hog of some gpio-controller. > > Probe deferring of gpio-controller will not lead to probe differing of > > dependent driver. > > > > Question: will gpio-hog mechanism resolve your case if it works (and > > probe differing issues)? > > I see gpio-hog to fulfill different role, use cases. It is more like > controlling muxes on boards to select between different exclusive > features. Things like route the I2S lines to analog codec or HDMI, route > RGB video to LCD panel or to HDMI, etc. > > But, if it would work it could be used for components which can be > enabled all the time. On the other hand, if a device has reset/enable > line then the driver should have a way to control it. I wonder if it would be useful to differentiate between required and suggested state in the consumer facing GPIO API for nonexclusive GPIOs. A driver that is ok with the enable line going into active state at any time while the device is suspended could use gpiod_set_value(en_gpio, 1); to resume, but gpiod_politely_suggest_value(en_gpio, 0); or similar to suspend, and the core could allow other drivers to override this state. Similarly to how the regulator framework allows consumers to set a voltage range, and the core decides on the actual voltage that fits the constraints. regards Philipp