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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 30 Sep 2012 17:46:29 +0200 From: Roland Stigge <stigge@...com.de> To: Stijn Devriendt <highguy@...il.com> CC: grant.likely@...retlab.ca, linus.walleij@...aro.org, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, w.sang@...gutronix.de, jbe@...gutronix.de, Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>, bgat@...lgatliff.com Subject: Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib On 30/09/12 17:19, Stijn Devriendt wrote: >> If I understand correctly, it's a violation (single-value should hold >> for read and write). >> >> To solve it, I have the following in mind: /sys/.../gpiogroupXXX/ >> contains files "bit0" ... "bit31" which contain a gpio number each, >> empty if "unconnected". > > Unfortunately that means you can't atomically create a group. I don't see a big advantage of having atomic create/request. Most important is set/get, isn't it? I assume the following usage pattern: * Create(request) - non atomic (maybe atomic but why not add GPIOs later?) * Set - atomic * Get - atomic * ... > It also creates a mess to keep ordering intact and to either > keep the current pin state or override it at allocation-time. Ordering should stay intact, and later add/delete operations could be possible. I meant bit0 ... bit31 in the gpio block as such: bit0 - "80" bit1 - "" (i.e. unconnected) bit2 - "85" bit3 - "2" ... bit31 - "" This scheme can support multiple gpio_chips, as discussed with Linus and JC, which of course can't always guarantee real simultaneous I/O but provide virtual I/O word access (32bit/64bit). > Rules are rules, but why make the interface overly complex when > the multi-value file is saner, cleaner and simpler? Simply because they won't (and probably shouldn't) accept it mainline. Roland -- 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/
Powered by blists - more mailing lists