On Wed, Apr 15, 2015 at 05:19:09PM -0700, Roy Franz wrote: > On Wed, Apr 15, 2015 at 8:45 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > On Apr 15, 2015 6:20 AM, "Greg Kroah-Hartman" > > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > >> > >> On Tue, Apr 14, 2015 at 11:52:48AM -0400, Andy Lutomirski wrote: > >> > On Tue, Apr 14, 2015 at 10:09 AM, Greg Kroah-Hartman > >> > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > >> > > On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong wrote: > >> > >> From: "Kweh, Hock Leong" <hock.leong.kweh@xxxxxxxxx> > >> > >> > >> > >> Introducing a kernel module to expose capsule loader interface > >> > >> for user to upload capsule binaries. This module leverage the > >> > >> request_firmware_direct_full_path() to obtain the binary at a > >> > >> specific path input by user. > >> > >> > >> > >> Example method to load the capsule binary: > >> > >> echo -n "/path/to/capsule/binary" > /sys/devices/platform/efi_capsule_loader/capsule_loader > >> > > > >> > > Ick, why not just have the firmware file location present, and copy it > >> > > to the sysfs file directly from userspace, instead of this two-step > >> > > process? > >> > > >> > Because it's not at all obvious how error handling should work in that case. > >> > >> I don't understand how the error handling is any different. The kernel > >> ends up copying the data in through the firmware interface both ways, we > >> just aren't creating yet-another-firmware-path in the system. > > > > If I run uefi-update-capsule foo.bin, I want it to complain if the > > UEFI call fails. In contrast, if I boot and my ath10k firmware is > > bad, there's no explicit user interaction that should fail; instead I > > have no network device and I get to read the logs and figure out why. > > IOW bad volatile device firmware is just like a bad device driver, > > whereas bad UEFI capsules are problems that should be reported to > > whatever tried to send them to UEFI. > > > > --Andy > > > There are several types of errors that can be returned by > UpdateCapsule(), allowing > us to distinguish between capsules that are not supported by the > platform, capsules > that must be updated at boot time, and capsule updates that failed due > to a device error. > I think we really do want this type of information returned to capsule loader. Ok, all of that sounds like you really want a character device, with an ioctl, to do this. Just use a misc device and your infrastructure will be handled for you (sysfs, character device, etc.) and away you go. thanks, greg k-h -- 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
