linux-kernel - Re: [PATCH] gpio: Add device driver for GRGPIO cores

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:	Mon, 04 Feb 2013 11:27:33 +0100
From:	Andreas Larsson <andreas@...sler.com>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Anton Vorontsov <anton.vorontsov@...aro.org>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	linux-kernel@...r.kernel.org, devicetree-discuss@...ts.ozlabs.org,
	software@...sler.com
Subject: Re: [PATCH] gpio: Add device driver for GRGPIO cores

On 2013-02-04 10:24, Linus Walleij wrote:
>>> And do you really have and test this regularly on both LE and BE hardware?
>>> I am worrying a bit about maintenance...
>>
>> I am more than happy to drop that. I will most probably never test this on
>> LE hardware.
>
> Will someone else? I'm more thinking whether it is customary in
> the SPARC drivers to do things like this, then we should follow
> that pattern of course.

It is definitely not customary in SPARC drivers. The module is marked 
"depends on OF" in Kconfig though and there seems to be no way to depend 
on an endianness. Unless someone instantiates the core in a LE system 
there is no reason for it.


>> 2) The grgpio_to_irq function is very hardware specific, and there is of
>> course no gpio_to_irq support in gpio-generic.
>
> Well, the idea about gpio-generic is to use the pieces you need
> IIRC. You may override.

Ah, I see, bgpio_init is exported, so I might be able use that from my 
driver to get rid of some functions. There is support for BE I saw now. 
It seems broken to me (flips bits, not bytes), but that can be fixed.


>> 3) Running on SPARC, I get Open Firmware information from prom, so there is
>> no platform data to access in the probe function. Of course general Open
>> Firmware support could be added to gpio-generic, but in addition my probe
>> needs to set up very hardware specific things for gpio_to_irq.
>
> We should probably add some way to handle generic GPIO
> with compatible strings etc, but that's way outside my competence
> so OK. Maybe Rob or Grant can say something.

Might be a good idea. However, by just using bgpio_init in a separate 
driver (like most other users of bgpio_init), that would not be required 
or used by me anyhow.


I'll look into using bgpio_init from my driver.

Cheers,
Andreas Larsson

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