RE: [PATCH v2 0/3] Enable user helper interface for efi capsule update
-Original Message- From: Fleming, Matt Sent: Tuesday, November 04, 2014 10:08 PM To: Greg Kroah-Hartman Good point, I don't know. Who ever wrote this code should know this, can someone please provide a use-case for how this is all supposed to work? That would be Wilson. He's wanting to use this to send updates to the firmware on the Intel Quark, I think. Hi Matt, I believe Greg already got that from the commit message on my patch 3/3. Thanks. Regards, Wilson
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, 2014-11-03 at 16:38 -0800, Greg Kroah-Hartman wrote: Good point, I don't know. Who ever wrote this code should know this, can someone please provide a use-case for how this is all supposed to work? That would be Wilson. He's wanting to use this to send updates to the firmware on the Intel Quark, I think. -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On 11/02/2014 07:07 PM, Kweh Hock Leong wrote: From: Kweh, Hock Leong hock.leong.kweh-ral2jqcrhueavxtiumw...@public.gmane.org Hi Guys, This patchset is created on top of efi: Capsule update support patch: http://permalink.gmane.org/gmane.linux.kernel.efi/4837 It leverages the request_firmware_nowait() to expose the user helper interface for user to upload the capsule binary and calling the efi_capsule_update() API to pass the binary to EFI firmware. I don't get it. Why is the firmware interface at all reasonable for uploading capsules? The firmware interface makes sense for nonvolatile firmware where hotplugging something or otherwise loading a driver needs a blob. But uploading an EFI capsule is an *action*, not something that should happen transparently. If there's an EFI firmware update available and the user wants to install it, then the userspace tool should install it, and it shouldn't hang around in /lib/firmware. In fact, you shouldn't even need /lib to be on writable media to use this. And you most certainly don't want the EFI capsule hanging around so that it might be accidentally installed again if the hard disk is moved. ISTM there should be some file in sysfs to which you can write a capsule, or perhaps a chardev and an ioctl. --Andy Besides build in kernel, the design also cater for build as kernel driver module. This patchset introduce a new API (request_firmware_abort()) at firmware_class so that the driver module could be unloaded by calling the API to properly stop user helper interface and release the device. Thanks. --- changelog v2: [PATCH 1/3] * use fw_lookup_buf() instead of __fw_lookup_buf() function call * move the fw_lookup_buf() function out of the CONFIG_PM_SLEEP block [PATCH 2/3] * no change [PATCH 3/3] * no change Kweh, Hock Leong (3): firmware loader: Introduce new API - request_firmware_abort() firmware loader: fix hung task warning dump efi: Capsule update with user helper interface drivers/base/firmware_class.c | 56 -- drivers/firmware/efi/Kconfig | 13 ++ drivers/firmware/efi/Makefile |1 + drivers/firmware/efi/efi-capsule-user-helper.c | 246 include/linux/firmware.h |4 + 5 files changed, 306 insertions(+), 14 deletions(-) create mode 100644 drivers/firmware/efi/efi-capsule-user-helper.c -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote: On 11/02/2014 07:07 PM, Kweh Hock Leong wrote: From: Kweh, Hock Leong hock.leong.kweh-ral2jqcrhueavxtiumw...@public.gmane.org Hi Guys, This patchset is created on top of efi: Capsule update support patch: http://permalink.gmane.org/gmane.linux.kernel.efi/4837 It leverages the request_firmware_nowait() to expose the user helper interface for user to upload the capsule binary and calling the efi_capsule_update() API to pass the binary to EFI firmware. I don't get it. Why is the firmware interface at all reasonable for uploading capsules? Tradition dictates that BIOS updates go through the firmware interface, that way you don't have to write a new userspace tool, which is a good thing. The firmware interface makes sense for nonvolatile firmware where hotplugging something or otherwise loading a driver needs a blob. Or BIOS data. We've been doing it this way for a long time now. But uploading an EFI capsule is an *action*, not something that should happen transparently. If there's an EFI firmware update available and the user wants to install it, then the userspace tool should install it, and it shouldn't hang around in /lib/firmware. In fact, you shouldn't even need /lib to be on writable media to use this. What does /lib have to do with this? And you most certainly don't want the EFI capsule hanging around so that it might be accidentally installed again if the hard disk is moved. ISTM there should be some file in sysfs to which you can write a capsule, or perhaps a chardev and an ioctl. No, just use the firmware interface please. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, Nov 3, 2014 at 1:27 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote: On 11/02/2014 07:07 PM, Kweh Hock Leong wrote: From: Kweh, Hock Leong hock.leong.kweh-ral2jqcrhueavxtiumw...@public.gmane.org Hi Guys, This patchset is created on top of efi: Capsule update support patch: http://permalink.gmane.org/gmane.linux.kernel.efi/4837 It leverages the request_firmware_nowait() to expose the user helper interface for user to upload the capsule binary and calling the efi_capsule_update() API to pass the binary to EFI firmware. I don't get it. Why is the firmware interface at all reasonable for uploading capsules? Tradition dictates that BIOS updates go through the firmware interface, that way you don't have to write a new userspace tool, which is a good thing. The firmware interface makes sense for nonvolatile firmware where hotplugging something or otherwise loading a driver needs a blob. Or BIOS data. We've been doing it this way for a long time now. On what system? Dell? IMO this sucks from a UI point of view. When I install wifi firmware, I expect to stick it somewhere and have the driver find it, because the driver knows exactly when it needs the firmware. When I update my BIOS, I want to click a button or type a command and update my bios. But uploading an EFI capsule is an *action*, not something that should happen transparently. If there's an EFI firmware update available and the user wants to install it, then the userspace tool should install it, and it shouldn't hang around in /lib/firmware. In fact, you shouldn't even need /lib to be on writable media to use this. What does /lib have to do with this? Where else does the file come from, given that udev no longer supports userspace firmware loading? Is there really some pre-existing tool that pokes it into the sysfs firmware class thing? Since EFI capsules are apparently on their way to becoming a ubiquitous mechanism, I think it might be time to rethink request_firmware for this. --Andy -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, Nov 03, 2014 at 01:32:46PM -0800, Andy Lutomirski wrote: On Mon, Nov 3, 2014 at 1:27 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote: On 11/02/2014 07:07 PM, Kweh Hock Leong wrote: From: Kweh, Hock Leong hock.leong.kweh-ral2jqcrhueavxtiumw...@public.gmane.org Hi Guys, This patchset is created on top of efi: Capsule update support patch: http://permalink.gmane.org/gmane.linux.kernel.efi/4837 It leverages the request_firmware_nowait() to expose the user helper interface for user to upload the capsule binary and calling the efi_capsule_update() API to pass the binary to EFI firmware. I don't get it. Why is the firmware interface at all reasonable for uploading capsules? Tradition dictates that BIOS updates go through the firmware interface, that way you don't have to write a new userspace tool, which is a good thing. The firmware interface makes sense for nonvolatile firmware where hotplugging something or otherwise loading a driver needs a blob. Or BIOS data. We've been doing it this way for a long time now. On what system? Dell? Yes. IMO this sucks from a UI point of view. When I install wifi firmware, I expect to stick it somewhere and have the driver find it, because the driver knows exactly when it needs the firmware. When I update my BIOS, I want to click a button or type a command and update my bios. I agree, it should be triggered by something, not just automagically loaded whenever the kernel randomly looks for it. But uploading an EFI capsule is an *action*, not something that should happen transparently. If there's an EFI firmware update available and the user wants to install it, then the userspace tool should install it, and it shouldn't hang around in /lib/firmware. In fact, you shouldn't even need /lib to be on writable media to use this. What does /lib have to do with this? Where else does the file come from, given that udev no longer supports userspace firmware loading? Is there really some pre-existing tool that pokes it into the sysfs firmware class thing? Well, you can specify other locations than /lib/firmware/ for firmware updates, but yes, you are right, it should be in /lib somewhere. But /lib doesn't need to be writable, it's a read-only file. Since EFI capsules are apparently on their way to becoming a ubiquitous mechanism, I think it might be time to rethink request_firmware for this. What do you suggest instead? A custom sysfs file? What is going to trigger it to be loaded? A userspace script that someone else has to write? :) thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, Nov 03, 2014 at 03:08:08PM -0800, Andy Lutomirski wrote: On Mon, Nov 3, 2014 at 3:02 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Nov 03, 2014 at 01:32:46PM -0800, Andy Lutomirski wrote: On Mon, Nov 3, 2014 at 1:27 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote: On 11/02/2014 07:07 PM, Kweh Hock Leong wrote: From: Kweh, Hock Leong hock.leong.kweh-ral2jqcrhueavxtiumw...@public.gmane.org Hi Guys, This patchset is created on top of efi: Capsule update support patch: http://permalink.gmane.org/gmane.linux.kernel.efi/4837 It leverages the request_firmware_nowait() to expose the user helper interface for user to upload the capsule binary and calling the efi_capsule_update() API to pass the binary to EFI firmware. I don't get it. Why is the firmware interface at all reasonable for uploading capsules? Tradition dictates that BIOS updates go through the firmware interface, that way you don't have to write a new userspace tool, which is a good thing. The firmware interface makes sense for nonvolatile firmware where hotplugging something or otherwise loading a driver needs a blob. Or BIOS data. We've been doing it this way for a long time now. On what system? Dell? Yes. IMO this sucks from a UI point of view. When I install wifi firmware, I expect to stick it somewhere and have the driver find it, because the driver knows exactly when it needs the firmware. When I update my BIOS, I want to click a button or type a command and update my bios. I agree, it should be triggered by something, not just automagically loaded whenever the kernel randomly looks for it. But uploading an EFI capsule is an *action*, not something that should happen transparently. If there's an EFI firmware update available and the user wants to install it, then the userspace tool should install it, and it shouldn't hang around in /lib/firmware. In fact, you shouldn't even need /lib to be on writable media to use this. What does /lib have to do with this? Where else does the file come from, given that udev no longer supports userspace firmware loading? Is there really some pre-existing tool that pokes it into the sysfs firmware class thing? Well, you can specify other locations than /lib/firmware/ for firmware updates, but yes, you are right, it should be in /lib somewhere. But /lib doesn't need to be writable, it's a read-only file. I assume that whoever downloaded the firmware update will want to install it, right? I don't really expect distros to ship EFI capsules in packages that install to /lib/firmware. Won't there be userspace code that either installs a capsule from some URL or uses some future magical find-my-firmware service? Good point, I don't know. Who ever wrote this code should know this, can someone please provide a use-case for how this is all supposed to work? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Enable user helper interface for efi capsule update
On Mon, Nov 3, 2014 at 4:38 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Nov 03, 2014 at 03:08:08PM -0800, Andy Lutomirski wrote: On Mon, Nov 3, 2014 at 3:02 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Nov 03, 2014 at 01:32:46PM -0800, Andy Lutomirski wrote: On Mon, Nov 3, 2014 at 1:27 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Mon, Nov 03, 2014 at 11:33:23AM -0800, Andy Lutomirski wrote: On 11/02/2014 07:07 PM, Kweh Hock Leong wrote: From: Kweh, Hock Leong hock.leong.kweh-ral2jqcrhueavxtiumw...@public.gmane.org Hi Guys, This patchset is created on top of efi: Capsule update support patch: http://permalink.gmane.org/gmane.linux.kernel.efi/4837 It leverages the request_firmware_nowait() to expose the user helper interface for user to upload the capsule binary and calling the efi_capsule_update() API to pass the binary to EFI firmware. I don't get it. Why is the firmware interface at all reasonable for uploading capsules? Tradition dictates that BIOS updates go through the firmware interface, that way you don't have to write a new userspace tool, which is a good thing. The firmware interface makes sense for nonvolatile firmware where hotplugging something or otherwise loading a driver needs a blob. Or BIOS data. We've been doing it this way for a long time now. On what system? Dell? Yes. IMO this sucks from a UI point of view. When I install wifi firmware, I expect to stick it somewhere and have the driver find it, because the driver knows exactly when it needs the firmware. When I update my BIOS, I want to click a button or type a command and update my bios. I agree, it should be triggered by something, not just automagically loaded whenever the kernel randomly looks for it. But uploading an EFI capsule is an *action*, not something that should happen transparently. If there's an EFI firmware update available and the user wants to install it, then the userspace tool should install it, and it shouldn't hang around in /lib/firmware. In fact, you shouldn't even need /lib to be on writable media to use this. What does /lib have to do with this? Where else does the file come from, given that udev no longer supports userspace firmware loading? Is there really some pre-existing tool that pokes it into the sysfs firmware class thing? Well, you can specify other locations than /lib/firmware/ for firmware updates, but yes, you are right, it should be in /lib somewhere. But /lib doesn't need to be writable, it's a read-only file. I assume that whoever downloaded the firmware update will want to install it, right? I don't really expect distros to ship EFI capsules in packages that install to /lib/firmware. Won't there be userspace code that either installs a capsule from some URL or uses some future magical find-my-firmware service? Good point, I don't know. Who ever wrote this code should know this, can someone please provide a use-case for how this is all supposed to work? There's a partial description here: http://download.microsoft.com/download/5/f/5/5f5d16cd-2530-4289-8019-94c6a20bed3c/windows-uefi-firmware-update-platform.docx It looks like there may need to be a way to atomically load several capsules in the same UpdateCapsule call so that userspace can do fancy things like ask for an image to be displayed while the update is applied. --Andy -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Enable user helper interface for efi capsule update
From: Kweh, Hock Leong hock.leong.k...@intel.com Hi Guys, This patchset is created on top of efi: Capsule update support patch: http://permalink.gmane.org/gmane.linux.kernel.efi/4837 It leverages the request_firmware_nowait() to expose the user helper interface for user to upload the capsule binary and calling the efi_capsule_update() API to pass the binary to EFI firmware. Besides build in kernel, the design also cater for build as kernel driver module. This patchset introduce a new API (request_firmware_abort()) at firmware_class so that the driver module could be unloaded by calling the API to properly stop user helper interface and release the device. Thanks. --- changelog v2: [PATCH 1/3] * use fw_lookup_buf() instead of __fw_lookup_buf() function call * move the fw_lookup_buf() function out of the CONFIG_PM_SLEEP block [PATCH 2/3] * no change [PATCH 3/3] * no change Kweh, Hock Leong (3): firmware loader: Introduce new API - request_firmware_abort() firmware loader: fix hung task warning dump efi: Capsule update with user helper interface drivers/base/firmware_class.c | 56 -- drivers/firmware/efi/Kconfig | 13 ++ drivers/firmware/efi/Makefile |1 + drivers/firmware/efi/efi-capsule-user-helper.c | 246 include/linux/firmware.h |4 + 5 files changed, 306 insertions(+), 14 deletions(-) create mode 100644 drivers/firmware/efi/efi-capsule-user-helper.c -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-efi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
