Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751181AbbD2VfK (ORCPT ); Wed, 29 Apr 2015 17:35:10 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:38091 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750911AbbD2VfG (ORCPT ); Wed, 29 Apr 2015 17:35:06 -0400 Message-ID: <1430343304.2189.25.camel@HansenPartnership.com> Subject: Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware From: James Bottomley To: "Kweh, Hock Leong" Cc: Andy Lutomirski , Peter Jones , Greg Kroah-Hartman , Matt Fleming , Ming Lei , "Ong, Boon Leong" , LKML , "linux-efi@vger.kernel.org" , Sam Protsenko , Roy Franz , Borislav Petkov , Al Viro , Linux FS Devel Date: Wed, 29 Apr 2015 14:35:04 -0700 In-Reply-To: References: <20150415131906.GC21491@kroah.com> <20150417134924.GB19794@kroah.com> <20150417143640.GB3671@codeblueprint.co.uk> <20150420144323.GA7261@kroah.com> <20150421075620.GA11000@kroah.com> <1429665679.2207.44.camel@HansenPartnership.com> <20150422132734.GB12062@redhat.com> <1429715913.2195.22.camel@HansenPartnership.com> <1429798187.2170.3.camel@HansenPartnership.com> <1429888575.2182.20.camel@HansenPartnership.com> <1430174136.2314.49.camel@HansenPartnership.com> <1430175112.2314.56.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1917 Lines: 41 On Wed, 2015-04-29 at 11:23 +0000, Kweh, Hock Leong wrote: > I agree with James. Due to different people may have different needs. But > from our side, we would just like to have a simple interface for us to upload > the efi capsule and perform update. We do not have any use case or need > to get info from QueryCapsuleUpdate(). Let me give a suggestion here: > please allow me to focus on deliver this simple loading interface and > upstream it. Then later whoever has the actual use case or needs on the ioctl > implementation, he or she could enhance base on this simple loading interface. > What do you guys think? > > Let me summarize the latest design idea: > - No longer leverage on firmware class but use misc device > - Do not use platform device but use device_create() > - User just need to perform "cat file.bin > /sys/.../capsule_loader" in the shell > - File operation functions include: open(), read(), write() and flush() > - Perform mutex lock in open() then release the mutex in flush() for avoiding > race condition / concurrent loading > - Perform the capsule update and error return at flush() function > > Is there anything I missed? Any one still have concern with this idea? > Thanks for providing the ideas as well as the review. I think that's pretty much it. Why don't you let me construct a straw man patch. It's going to be a bit controversial because it involves adding flush operations to sysfs and kernfs, slicing apart firmware_class.c to extract the transaction handling stuff and creating an new efi update capsule file which makes use of it. Once we have code, we at least have something more concrete to argue over. James -- 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/