> -----Original Message----- > From: Andy Lutomirski [mailto:luto@xxxxxxxxxxxxxx] > Sent: Tuesday, November 04, 2014 2:32 PM > > 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.) I did try to upload more than one capsule binaries and I don't observe a long wait is required. In fact, it seem to me the interface is instantly re-created. > > 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. I have not encounter any capsule update that does not require reboot. Base on my understanding, the EFI firmware only do the binary decoding during the next reboot. If the binary is broken/corrupted, you would only know during the next reboot. On kernel driver point of view, it just registers the binary by calling the EFI API UpdateCapsule(). May be Matt you could help out with this? Regarding the EFI call failed message, besides obtains from the dmesg log, you also can verify that through this sysfs: /sys/devices/platform/efi_capsule_user_helper/capsule_loaded I did mention this in the commit message as showed below: Besides the request_firmware user helper interface, this module also exposes a 'capsule_loaded' file note for user to verify the number of successfully uploaded capsule binaries. This file note has the read only attribute. > > What's the benefit of using the firmware interface here? > > --Andy ��.n��������+%������w��{.n�����{����* jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
