Re: [PATCH v2 3/3] efi: Capsule update with user helper interface

[Matt Fleming <matt.fleming@intel.com>]

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.