From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [PATCH v4 1/2] firmware_loader: introduce new API - request_firmware_direct_full_path() Date: Tue, 14 Apr 2015 18:18:33 +0200 Message-ID: <20150414161833.GE14069@pd.tnic> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-efi-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andy Lutomirski Cc: Greg Kroah-Hartman , "Kweh, Hock Leong" , Ming Lei , Matt Fleming , Ong Boon Leong , LKML , "linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Sam Protsenko , Peter Jones , Roy Franz List-Id: linux-efi@vger.kernel.org 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? 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. Hmmm? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755773AbbDNQVE (ORCPT ); Tue, 14 Apr 2015 12:21:04 -0400 Received: from mail.skyhub.de ([78.46.96.112]:44466 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753196AbbDNQUx (ORCPT ); Tue, 14 Apr 2015 12:20:53 -0400 Date: Tue, 14 Apr 2015 18:18:33 +0200 From: Borislav Petkov To: Andy Lutomirski Cc: Greg Kroah-Hartman , "Kweh, Hock Leong" , Ming Lei , Matt Fleming , 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: <20150414161833.GE14069@pd.tnic> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? 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. Hmmm? -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --