linux-kernel - Re: [PATCH RESEND 1/5 v6] gpio: Add a block GPIO API to gpiolib

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: <CACxGe6uFs=12fH2DH=+kXq3Q2DjQ_CmfbzbmAig2iHiEezngGQ@mail.gmail.com>
Date:	Thu, 1 Nov 2012 16:14:16 +0100
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Roland Stigge <stigge@...com.de>, gregkh@...uxfoundation.org,
	linus.walleij@...aro.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, w.sang@...gutronix.de,
	jbe@...gutronix.de, plagnioj@...osoft.com, highguy@...il.com,
	daniel-gl@....net, rmallon@...il.com
Subject: Re: [PATCH RESEND 1/5 v6] gpio: Add a block GPIO API to gpiolib

On Wed, Oct 31, 2012 at 8:30 PM, Mark Brown
<broonie@...nsource.wolfsonmicro.com> wrote:
> On Wed, Oct 31, 2012 at 04:00:17PM +0100, Grant Likely wrote:
>
>> For the API, I don't think it is a good idea at all to try and
>> abstract away gpios on multiple controllers. I understand that it
>> makes life a lot easier for userspace to abstract those details away,
>> but the problem is that it hides very important information about how
>> the system is actually constructed that is important to actually get
>> things to work. For example, say you have a gpio-connected device with
>> the constraint that GPIOA must change either before or at the same
>> time as GPIOB, but never after. If those GPIOs are on separate
>> controllers, then the order is completely undefined, and the user has
>> no way to control that other than to fall back to manipulating GPIOs
>> one at a time again (and losing all the performance benefits). Either
>> controller affinity needs to be explicit in the API, or the API needs
>> to be constraint oriented (ie. a stream of commands and individual
>> commands can be coalesced if they meet the constraints**). Also, the
>> API requires remapping the GPIO numbers which forces the code to be a
>> lot more complex than it needs to be.
>
> It feels like I'm missing something here but can we not simply say that
> if the user cares about the ordering of the signal changes within an
> update then they should be doing two separate updates?  Most of the
> cases I'm aware of do things as an update with a strobe or clock that
> latches the values.
>
> The big advantage of grouping things together is that it means that we
> centralise the fallback code.

The internal ABI is less of an issue because it is a whole lot easier
to change compared to a userspace ABI (though I think we can do a lot
better before deciding to merge it). Userspace also appears to be the
intended usage, so I've focused my review on that use case.

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/