linux-kernel - Re: [PATCH v5 1/3] gpio: Cygnus: define Broadcom Cygnus GPIO binding

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:	Fri, 12 Dec 2014 09:17:27 -0800
From:	Ray Jui <rjui@...adcom.com>
To:	Alexandre Courbot <gnurou@...il.com>, Arnd Bergmann <arnd@...db.de>
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>,
	"Linus Walleij" <linus.walleij@...aro.org>,
	Grant Likely <grant.likely@...aro.org>,
	Christian Daudt <bcm@...thebug.org>,
	Matt Porter <mporter@...aro.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Russell King <linux@....linux.org.uk>,
	Joe Perches <joe@...ches.com>,
	Scott Branden <sbranden@...adcom.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	<bcm-kernel-feedback-list@...adcom.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH v5 1/3] gpio: Cygnus: define Broadcom Cygnus GPIO binding



On 12/12/2014 5:05 AM, Alexandre Courbot wrote:
> On Fri, Dec 12, 2014 at 9:08 PM, Arnd Bergmann <arnd@...db.de> wrote:
>> On Thursday 11 December 2014 16:05:04 Ray Jui wrote:
>>> +
>>> +- linux,gpio-base:
>>> +    Base GPIO number of this controller
>>> +
>>>
>>
>> We've NAK'ed properties like this multiple times before, and it
>> doesn't get any better this time. What are you trying to achieve
>> here?
>
> I am to blame for suggesting using this property to Ray, and I am
> fully aware that this has been rejected before, but look at what
> people came with recently to palliate the lack of control over the
> GPIO number space for DT platforms:
>
> http://www.spinics.net/lists/arm-kernel/msg384847.html
> https://lkml.org/lkml/2014/12/10/133
>
> Right now GPIO numbering for platforms using DT is a very inconsistent
> process, subject to change by the simple action of adjusting the value
> of ARCH_NR_GPIOS (which we did recently, btw), adding a new GPIO
> controller, or changing the probe order of devices. For users of the
> integer or sysfs interfaces, this results in GPIO numbers that change,
> and drivers and/or user-space programs that behave incorrectly.
> Ironically, the only way to have consistent numbers is to use the old
> platform files, where you can specify the base number of a gpio_chip.
>
> DT is actually probably not such a bad place to provide consistency in
> GPIO numbering. It has a global vision of the system layout, including
> all GPIO controllers and the number of GPIOs they include, and thus
> can make informed decisions. It provides a consistent result
> regardless of probe order. And allowing it to assign GPIO bases to
> controllers will free us from the nonsensical dependency of some
> arbitrary upper-bound for GPIO numbers that ARCH_NR_GPIOS imposes on
> us. Also about ARCH_NR_GPIOS, the plan is to eventually remove it
> since we don't need it anymore after the removal of the global
> gpio_descs array. This will again interfere with the numbering of GPIO
> chips that do not have a base number provided.
>
> Note that I don't really like this, either - but the problem is the
> GPIO integer interface. Until everyone has upgraded to gpiod and we
> have a replacement for the current sysfs interface (this will take a
> while) we have to cope with this. This issue has been bothering users
> for years, so this time I'd like to try and solve it the less ugly
> way. If there is a better solution, of course I'm all for it.
>
Agreed.

Since we are just starting to upstream all of our drivers for 
iProc/Cygnus, enforcing all of our new drivers to use the gpiod 
interface is not an issue and is something that should be done.

Our current issue is really on the sysfs interface, as I mentioned 
earlier, a lot of our customers use the sysfs interface for GPIO access. 
Until the sysfs interface issue is resolved, we sort of need a way to 
maintain the GPIO base between different GPIO controllers.
--
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/