linux-kernel - Re: [PATCH] gpio: support for Synopsys DesignWare APB GPIO

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: <20110405081817.GA4797@pulham.picochip.com>
Date:	Tue, 5 Apr 2011 09:18:18 +0100
From:	Jamie Iles <jamie@...ieiles.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	Jamie Iles <jamie@...ieiles.com>,
	Anton Vorontsov <cbouatmailru@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Russell King <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>, Nicolas Pitre <nico@...xnic.net>
Subject: Re: [PATCH] gpio: support for Synopsys DesignWare APB GPIO

On Mon, Apr 04, 2011 at 08:48:38PM -0600, Grant Likely wrote:
> On Sun, Apr 03, 2011 at 04:22:44PM +0100, Jamie Iles wrote:
> > The reason I proposed this was for controllers where the registers 
> > aren't grouped together for each bank.  For example, the Synopsys 
> > block has:
> > 
> > 	0x00-0x08 bank A control registers
> > 	0x0c-0x14 bank B control registers
> > 	...
> > 	0x50	  bank A input register
> > 	0x54	  bank B input register.
> > 
> > So when you mentioned before using a single register resource with 
> > offsets I understood it to be something like what I've proposed 
> > otherwise multiple banks would have overlapping resources (or the 
> > resource would just be used to indicate the start address rather than 
> > start + end).
> 
> That may be a problem for request_mem_region() which would indeed
> prevent the driver from specifying the full register range with
> offsets inside it.  I suspect that the platform_bus_type will inhibit
> two platform_devices with overlapping regions from getting registered.
> Fair enough, that is a pretty strong argument for Anton's model.  I
> don't think it would be a good idea to try and work around it by
> making the resource only include the start address.
> 
> It does mean some gymnastics for a device tree binding to figure out
> which registers are present, but the appropriate behaviour could be
> selected by a set of compatible values for each kind of register
> interface.

OK, I'll start having a look at this then.  I have a few other things on 
at the moment so it may take me a little while to get onto it but I'll 
try and get some patches posted fairly quickly.

Anton, I'm happy to do some of the changes that Thomas suggested such as 
removing some of the runtime calculations too unless you're planning on 
doing these.

> > 
> > Also, it's not clear here but this would create one gpio_chip per bank.
> 
> And that's bad why?  :-)

Not a bad thing, I just realized that my initial description was far 
from complete!

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