| 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
| ||
|
Message-ID: <1380562166.32071.172.camel@dvhart-mobl4.amr.corp.intel.com> Date: Mon, 30 Sep 2013 10:29:26 -0700 From: Darren Hart <dvhart@...ux.intel.com> To: LKML <linux-kernel@...r.kernel.org> Cc: Grant Likely <grant.likely@...aro.org>, Linus Walleij <linus.walleij@...aro.org> Subject: GPIO: Performance sensitive applications, gpiochip-level locking I'm currently working with a graphics driver that makes use of 2 GPIO pins for EDID communication (clock and data). In order to coexist peacefully with the driver for the GPIO chip, it must use gpiolib to request the lines, set direction, and set values. This results in a spinlock/unlock for every operation with this particular gpio driver. It would be preferable to lock the resources once, perform the EDID communication, then unlock the resources. The resources in this case are the value and direction registers off the PCI GPIO base address register which is shared with the other lines provided by the GPIO chip. Is there a best practice for dealing with this kind of configuration? If not, would it make sense to add optional gpiochip-level lock/unlock and lockless direction and value operations to the gpiochip function block? Thanks, -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -- 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