linux-kernel - Re: [PATCH 07/11] pinctrl: use ngpios propety from DT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Oct 2015 15:47:19 +0100
From:	Jonas Gorski <jogo@...nwrt.org>
To:	Linus Walleij <linus.walleij@...aro.org>,
	Pramod Kumar <pramodku@...adcom.com>
Cc:	Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>, Ray Jui <rjui@...adcom.com>,
	Scott Branden <sbranden@...adcom.com>,
	Russell King <linux@....linux.org.uk>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
	Jason Uy <jasonuy@...adcom.com>,
	Masahiro Yamada <yamada.masahiro@...ionext.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 07/11] pinctrl: use ngpios propety from DT

On 29.10.2015 15:36, Linus Walleij wrote:
> On Wed, Oct 28, 2015 at 12:52 PM, Pramod Kumar <pramodku@...adcom.com> wrote:
> 
>> I discussed with ASIC team regarding this iProc GPIO block. They use a library to create the GPIOs block where "total number of GPIO pins( let say N) in GPIO block" is used as an parameter.
>> Library uses a construct for *a* GPIO pin. This gets instantiated N times to create a complete GPIO block with N pins.
>>
>> All iProc based SoCs uses this library. So I'm not sure whether attaching "total number of GPIOs pins" to compatible-string make sense in this case.
>> I personally feel that passing this number from the DT makes more sense here. Any iProc based future as well as current SoCs would be able to use this driver without any change.
>>
>> Please advise us in this case.
> 
> Hm! You make a good case.
> 
> But this contradicts the traditional use of ngpios.
> 
> But on the other hand:
> git grep ngpio Documentation/devicetree/bindings/gpio/
> 
> Gives at hand that the use of ngpio[s] is a complete mess.
> 
> :(
> 
> I will think about patching the standard bindings to fix this mess
> and include your case. Give me some time.

Using ngpios to restrict the amount of actually available GPIOs from
the possible amount of GPIOs seems a rather limited use, as rerouted
gpios are seldom at the end of the GPIO space.

So maybe it makes more sense to use ngpio as the number of
possible gpios and then have an additional "reserved-gpios"
bitmask / list of unavailable gpios?

Ideally those would be just consumed by a pinctrl instance, but I
guess that these are sometimes controlled through pinstrapping,
so there might be no driver to attach to them.

Regards
Jonas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/