linux-kernel - Re: [PATCH RFC 1/2] 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: <20120929195754.GC17667@game.jcrosoft.org>
Date:	Sat, 29 Sep 2012 21:57:54 +0200
From:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
To:	Roland Stigge <stigge@...com.de>
Cc:	linus.walleij@...aro.org, linux-kernel@...r.kernel.org,
	w.sang@...gutronix.de, grant.likely@...retlab.ca,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib

On 20:32 Fri 28 Sep     , Roland Stigge wrote:
> Hi,
> 
> On 28/09/12 18:01, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>Maybe like this, for some struct block *?
> >>
> >>block = set_block_prepare(gc, pins, values, size);
> >>if (block) {
> >>	set_block(gc, block);
> >>	...
> >>	set_block_unprepare(gc, block);
> >>}
> >>
> >>Would mean that all supported drivers would need to implement those 3
> >>new functions... Need to be careful about not introducing bloat...
> >the prepare is gpiolib specific, it will be a helper to conver a gpio list to
> >a gpio block list
> >
> >I was thinking more
> >
> >block = gpio_block_prepare(pins, size);
> >
> >gpio_block_set_value(pin0, val);
> >gpio_block_set_value(pin1, val);
> >gpio_block_set_value(pin2, val);
> >gpio_block_set(block);
> >
> >andfor get
> >
> >gpio_block_get(block)
> >val = gpio_block_get_value(block, pin0);
> >val = gpio_block_get_value(block, pin1);
> >
> >for the gpio driver ti's transparent
> 
> Problem here is that it's only an intermediate format since hardware
> often needs special preparation of the data.
> 
> But will evaluate what makes most sense.
the key point here is to avoid to manipualte data each time we call
gpio_block_set

hardware specific will have to be handle at driver level

Best Regards,
J.
--
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/