Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966438AbeAJQhi (ORCPT + 1 other); Wed, 10 Jan 2018 11:37:38 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:33978 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966295AbeAJQhf (ORCPT ); Wed, 10 Jan 2018 11:37:35 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org B93F460BDF Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=sboyd@codeaurora.org Date: Wed, 10 Jan 2018 08:37:33 -0800 From: Stephen Boyd To: Linus Walleij Cc: Rob Herring , Grant Likely , "linux-kernel@vger.kernel.org" , linux-arm-msm@vger.kernel.org, Linux ARM , Timur Tabi , Andy Shevchenko , Bjorn Andersson , linux-gpio@vger.kernel.org, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" Subject: Re: [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property Message-ID: <20180110163733.GH21040@codeaurora.org> References: <20180110015848.11480-1-sboyd@codeaurora.org> <20180110015848.11480-3-sboyd@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 01/10, Linus Walleij wrote: > On Wed, Jan 10, 2018 at 2:58 AM, Stephen Boyd wrote: > > > +- ngpios-ranges: > > + Usage: optional > > + Value type: > > + Definition: Tuples of GPIO ranges (base, size) indicating > > + GPIOs available for use. > > + > > Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for > > a general description of GPIO and interrupt bindings. > > I like the tuples syntax. That's fine. It's like gpio-ranges we have > already to map between pin controllers and GPIO. > > I don't think we can reuse gpio-ranges because that is > exclusively for pin control ATM, it would be fine if the ranges > were for a specific device, like pin control does, like: > > gpio-ranges = <&secure_world_thing 0 20 10>; > > But you definately would need a node to tie it to, so that the > driver for that node can specify that it's gonna take the > GPIOs. > > But I think the semantics should be the inverse. That you > point out "holes" with the lines we *can't* use. Ok. I can invert the logic and push it into the core part of the code. I'll leave the ACPI part in the msm driver. > > We already support a generic property "ngpios" that says how > many of the GPIOs (counted from zero) that can be used, > so if those should be able to use this as a generic property it > is better with the inverse semantics and say that the > "reserved-gpio-ranges", "secureworld-gpio-ranges" > (or whatever we decide to call it) takes precedence over > ngpios so we don't end up in ambigous places. > > Then, will it be possible to put the parsing, handling and > disablement of these ranges into drivers/gpio/gpiolib-of.c > where we handle the ranges today, or do we need to > do it in the individual drivers? > I'll cook that up right now to do the inverse thing in the gpiolib core code with a 'reserved-gpio-ranges' property. I haven't looked in much detail, but I would hope that it would work pretty easily. Should it be decoupled from the GPIOLIB_IRQCHIP config? If the idea is generic, then it may not be related to irq lines, but for the qcom driver it was all fine because all three concepts: irq, gpios, and pins have a one to one relationship. The only place it breaks down is if we have more pins than gpios, in which case I punted and just considered non-gpio pins as always valid. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project