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]
Message-ID: <56323177.6010605@openwrt.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ