linux-kernel - Re: [PATCH v2 0/4] gpiolib: some fixup patches

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] [day] [month] [year] [list]

Date:	Thu, 28 Feb 2013 06:47:38 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	Ryan Mallon <rmallon@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"acourbot@...dia.com" <acourbot@...dia.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: [PATCH v2 0/4] gpiolib: some fixup patches

On Thu, Feb 28, 2013 at 6:21 AM, Linus Walleij <linus.walleij@...aro.org> wrote:
> On Wed, Feb 27, 2013 at 8:52 AM, Grant Likely <grant.likely@...retlab.ca> wrote:
>
>> I've been playing with an idea of pulling in some basic MMIO gpio
>> access directly into gpiolib so that when appropriate gpiolib itself
>> can have a fast path for doing the register access and shadow register
>> management.
>
> Shadow registers: isn't that what regmap usually does? Or
> what are you referring to here?

Yes, regmap does shadow registers, but that is another layer of
indirection that would nullify the advantage of a fast path.

> But fastpath MMIO in the gpiolib is an appealing thought,
> given that this was a design impetus in the early history of
> the subsystem.

Indeed. I've worked on many a platform that struggled to bitbang fast
enough. A lot of the time it came down to too much indirection and
mucking about when it came to actually manipulating the GPIO. I would
like do some experiments in ways to implement a fast path and see what
the code generation looks like. Any indirection is expensive so the
trick is to minimize the number of dereferences and callbacks
involved. Unfortunately there are several common access modes that I
think should be supported, the most important being single data
register vs. set/clr and direction registers with different
polarities. Also, should the fast path only do 8-bit accesses, or can
16, 32 and 64 bit banks be supported?

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