Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756285AbbDOPqB (ORCPT ); Wed, 15 Apr 2015 11:46:01 -0400 Received: from mail-oi0-f53.google.com ([209.85.218.53]:36256 "EHLO mail-oi0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751424AbbDOPpv (ORCPT ); Wed, 15 Apr 2015 11:45:51 -0400 MIME-Version: 1.0 In-Reply-To: <20150415132000.GD21491@kroah.com> References: <1429004697-28320-1-git-send-email-hock.leong.kweh@intel.com> <1429004697-28320-3-git-send-email-hock.leong.kweh@intel.com> <20150414140914.GE5989@kroah.com> <20150415132000.GD21491@kroah.com> From: Andy Lutomirski Date: Wed, 15 Apr 2015 08:45:20 -0700 Message-ID: Subject: Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware To: Greg KH Cc: Borislav Petkov , Matt Fleming , Ong Boon Leong , "linux-efi@vger.kernel.org" , Roy Franz , Sam Protsenko , "Kweh, Hock Leong" , LKML , Peter Jones , Ming Lei Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1983 Lines: 46 On Apr 15, 2015 6:20 AM, "Greg Kroah-Hartman" 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 > > wrote: > > > On Tue, Apr 14, 2015 at 05:44:56PM +0800, Kweh, Hock Leong wrote: > > >> From: "Kweh, Hock Leong" > > >> > > >> 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 > > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/