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:	Wed, 28 Oct 2015 08:39:47 -0700
From:	Ray Jui <rjui@...adcom.com>
To:	Pramod Kumar <pramodku@...adcom.com>,
	Linus Walleij <linus.walleij@...aro.org>
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>,
	"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>,
	Jonas Gorski <jogo@...nwrt.org>
Subject: Re: [PATCH 07/11] pinctrl: use ngpios propety from DT



On 10/28/2015 4:52 AM, Pramod Kumar wrote:
> Hi Linus,
>
>> -----Original Message-----
>> From: Linus Walleij [mailto:linus.walleij@...aro.org]
>> Sent: 27 October 2015 15:22
>> To: Pramod Kumar
>> Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Ray Jui;
>> Scott Branden; Russell King; linux-gpio@...r.kernel.org; bcm-kernel-feedback-
>> list; Jason Uy; Masahiro Yamada; Thomas Gleixner; Laurent Pinchart;
>> devicetree@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; linux-
>> kernel@...r.kernel.org; Jonas Gorski
>> Subject: Re: [PATCH 07/11] pinctrl: use ngpios propety from DT
>>
>> On Mon, Oct 19, 2015 at 7:43 AM, Pramod Kumar <pramodku@...adcom.com>
>> wrote:
>>
>>> Since identical hardware is used in several instances and all pins are
>>> not routed to pinctrl hence getting total number of gpios from DT make
>>> more sense hence stop using total number of gpios pins from drivers
>>> and extract it from DT.
>>>
>>> Signed-off-by: Pramod Kumar <pramodku@...adcom.com>
>>> Reviewed-by: Ray Jui <rjui@...adcom.com>
>>> Reviewed-by: Scott Branden <sbranden@...adcom.com>
>>
>> This patch is wrong.
>>
>> Keep this per-compatible code, and only overrid the ngpios if and only if:
>>
>> - The ngpios is set in the DT node
>> - The ngpios in the DT node is *smaller* than the hardware
>>    defined number of GPIOs.
>>
>> ngpios is for restricting the number of available lines due to routing etc, not to
>> define what the hardware has, because the hardware most certainly have all the
>> lines, it's just that you're not using all of them.
>>
>> Yours,
>> Linus Walleij
>
> 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.

Just to confirm, N can be *any number*, and when it exceeds 32, 
additional registers will be created by the library, correct? I think 
that's what I saw with Cygnus, where 3 instances of this GPIO controller 
was used, with two of them less supporting less than 32 GPIOs and one of 
them (ASIU) supporting 146 GPIOs, in which case, 5 register banks are 
used with 0x200 segment each.

>
> 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.

The closest I can think of is to tie a very large number of N to the 
"brcm,iproc-gpio" compatible string for all new iProc SoCs, but even 
that, one can argue how large is *large*

> 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.
>
> Regards,
> Pramod
>
--
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/