Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754478AbbDOKPE (ORCPT ); Wed, 15 Apr 2015 06:15:04 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:36323 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751399AbbDOKO6 (ORCPT ); Wed, 15 Apr 2015 06:14:58 -0400 Date: Wed, 15 Apr 2015 11:14:55 +0100 From: Matt Fleming To: Borislav Petkov Cc: Andy Lutomirski , Greg Kroah-Hartman , "Kweh, Hock Leong" , Ming Lei , Ong Boon Leong , LKML , "linux-efi@vger.kernel.org" , Sam Protsenko , Peter Jones , Roy Franz Subject: Re: [PATCH v4 1/2] firmware_loader: introduce new API - request_firmware_direct_full_path() Message-ID: <20150415101455.GB4804@codeblueprint.co.uk> 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> <20150414161833.GE14069@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150414161833.GE14069@pd.tnic> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1592 Lines: 36 On Tue, 14 Apr, at 06:18:33PM, Borislav Petkov wrote: > On Tue, Apr 14, 2015 at 11:56:26AM -0400, Andy Lutomirski wrote: > > 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. > > Btw, didn't mfleming want to try using capsules for other funky stuff > like early logging and pstore-like logging in panic time so that we can > read out crash data on the next boot? Yeah, exactly. Being able to pass random data blobs to the capsule internals allows the kernel to support cool things we haven't conceived of yet, and where we want to use the capsule's in-memory persistence across reboot to pass data to the next kernel. The panic code paths is just one example. > Which would mean that capsules would need a completely different > interface, something new for shuffling lotsa binary data in and out of > the kernel and in and out of the UEFI... > > Which would make the firmware_class thing completely inappropriate for > that. Well, I haven't come across a scenario where you need a brand new interface for getting it *out* of the kernel again. And I'm happy enough with these patches for passing data in. -- Matt Fleming, Intel Open Source Technology Center -- 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/