| 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
| ||
|
Date: Fri, 13 Nov 2009 17:47:27 +0000 From: Philip Downer <phil@...devices.co.uk> To: linux-kernel@...r.kernel.org Subject: firmware loading interface Hi, I'm working for a company which is manufacturing a new pci card. The details are probably irrelevant at this stage, but for those who might be concerned the driver will be covered by the GPL and submitted upstream at or before the launch of the card. Currently I'm investigating how to provide firmware upgrades for the card, and I've been looking at the request_firmware api. All of the documentation (and mails that I've read from lkml archives) suggest that request_firmware is for use with devices without firmware stored in flash or eeprom, and to load it in to memory at initialisation of the device. However our device will have flash to store the firmware in and, whilst it looks as though it would be possible for us to use request_firmware to provide occasional firmware upgrades from userspace, I can't find any reference as to whether this is an accepted method for doing so. Could someone please confirm for me whether or not it's a good idea to use request_firmware for this, or perhaps point me at another standard method for doing firmware updates from userspace? Please note that I am not subscribed to this mailing list, so could anyone responding please CC me in their response. Philip Downer -- 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