On Mon, 2014-11-03 at 22:32 -0800, Andy Lutomirski wrote: > > It seems like a large fraction of the code in this module exists just > to work around the fact that request_firmware doesn't do what you want > it to do. You have code to: > > - Prevent the /lib/firmware mechanism from working. > - Avoid a deadlock by doing strange things in the unload code. > - Allow more than one capsule per module load. (Isn't this hard to > use? User code will have to wait for the next firmware request before > sending a second capsule.) > > All of this is for dubious gain. You have to do three separate opens > in sysfs to upload a capsule, and there's no way to report back to > userspace whether the EFI call worked and whether a reboot is needed. Whether or not a reboot is required is indicated in the capsule image itself, i.e. the capsule tells the firmware whether an immediate reboot is required not the other way around. The firmware does tell the kernel what *kind* of a reboot is required, but that doesn't need reporting to userspace. > What's the benefit of using the firmware interface here? I originally implemented something to send capsules to the firmware via sysfs files back in 2013 and I basically ended up duplicating 25% of the code that's already in drivers/base/firmware_class.c. If you're objecting to the lack of modularity in firmware_class.c, then we could probably carve up the functionality we require a little more neatly (like not having to do the /lib/firmware avoidance hacks), but firmware_class.c should definitely be used as the foundation. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
