Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932882AbbDNP4z (ORCPT ); Tue, 14 Apr 2015 11:56:55 -0400 Received: from mail-la0-f44.google.com ([209.85.215.44]:33703 "EHLO mail-la0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932819AbbDNP4s (ORCPT ); Tue, 14 Apr 2015 11:56:48 -0400 MIME-Version: 1.0 In-Reply-To: <20150414140806.GD5989@kroah.com> References: <1429004697-28320-1-git-send-email-hock.leong.kweh@intel.com> <1429004697-28320-2-git-send-email-hock.leong.kweh@intel.com> <20150414140806.GD5989@kroah.com> From: Andy Lutomirski Date: Tue, 14 Apr 2015 11:56:26 -0400 Message-ID: Subject: Re: [PATCH v4 1/2] firmware_loader: introduce new API - request_firmware_direct_full_path() To: Greg Kroah-Hartman Cc: "Kweh, Hock Leong" , Ming Lei , Matt Fleming , Ong Boon Leong , LKML , "linux-efi@vger.kernel.org" , Sam Protsenko , Peter Jones , Roy Franz , Borislav Petkov 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: 1649 Lines: 37 On Tue, Apr 14, 2015 at 10:08 AM, Greg Kroah-Hartman wrote: > On Tue, Apr 14, 2015 at 05:44:55PM +0800, Kweh, Hock Leong wrote: >> From: "Kweh, Hock Leong" >> >> Introduce this new API for loading firmware from a specific location >> instead of /lib/firmware/ by providing a full path to the firmware >> file. > > Ick, why would we want this? > Because this mechanism should still work even if /lib is unwriteable (e.g it's on squashfs or a read-only NFS root). In this regard, UEFI capsules are very much unlike firmware_class firmware. firmware_class firmwise is kind of like device drivers; it generally comes from the same vendor as your kernel image and /lib/modules, and it can be updated by the same mechanism. UEFI capsules, on the other hand, are one-time things that should be loaded at the explicit request of the admin. There is no reason whatsoever that they should exist on persistent storage, and, in fact, there's a very good reason that they should not. On little embedded devices, which will apparently be the initial users of this code, keeping the capsules around is a waste of valuable space. This is why I think that the right approach would be to avoid using firmware_class entirely for this. IMO a simple_char device would be the way to go (hint hint...) but other simple approaches are certainly possible. --Andy -- 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/