Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932558AbbKEDm5 (ORCPT <rfc822;w@1wt.eu>);
	Wed, 4 Nov 2015 22:42:57 -0500
Received: from mga14.intel.com ([192.55.52.115]:34174 "EHLO mga14.intel.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755693AbbKEDmy (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Wed, 4 Nov 2015 22:42:54 -0500
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.20,246,1444719600"; 
   d="scan'208";a="594286790"
From: "Kweh, Hock Leong" <hock.leong.kweh@intel.com>
To: Borislav Petkov <bp@alien8.de>
CC: Matt Fleming <matt@console-pimps.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Ong, Boon Leong" <boon.leong.ong@intel.com>,
        LKML <linux-kernel@vger.kernel.org>,
        "linux-efi@vger.kernel.org" <linux-efi@vger.kernel.org>,
        Sam Protsenko <semen.protsenko@linaro.org>,
        Peter Jones <pjones@redhat.com>, Andy Lutomirski <luto@amacapital.net>,
        "Roy Franz" <roy.franz@linaro.org>,
        James Bottomley <James.Bottomley@hansenpartnership.com>,
        Linux FS Devel <linux-fsdevel@vger.kernel.org>,
        "Fleming, Matt" <matt.fleming@intel.com>,
        "Anvin, H Peter" <h.peter.anvin@intel.com>
Subject: RE: [PATCH v9 1/1] efi: a misc char interface for user to update
 efi firmware
Thread-Topic: [PATCH v9 1/1] efi: a misc char interface for user to update
 efi firmware
Thread-Index: AQHRFJBNC81W/lCPlUaMyOpZJhbG6Z6G+NDA//+ATICAAIi5gP//mPeAgAGpBICAAfWOgIAClU9Q
Date: Thu, 5 Nov 2015 03:42:25 +0000
Message-ID: <F54AEECA5E2B9541821D670476DAE19C4A87A8D0@PGSMSX102.gar.corp.intel.com>
References: <1446055138-26047-1-git-send-email-hock.leong.kweh@intel.com>
 <1446055138-26047-2-git-send-email-hock.leong.kweh@intel.com>
 <20151101102944.GA12711@pd.tnic>
 <F54AEECA5E2B9541821D670476DAE19C4A8799FB@PGSMSX102.gar.corp.intel.com>
 <20151101105801.GB12711@pd.tnic>
 <F54AEECA5E2B9541821D670476DAE19C4A879A18@PGSMSX102.gar.corp.intel.com>
 <20151101125835.GC12711@pd.tnic>
 <F54AEECA5E2B9541821D670476DAE19C4A879C38@PGSMSX102.gar.corp.intel.com>
 <20151103201455.GD3620@pd.tnic>
In-Reply-To: <20151103201455.GD3620@pd.tnic>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.30.20.205]
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id tA53h170018071
Content-Length: 1127
Lines: 28

> -----Original Message-----
> From: Borislav Petkov [mailto:bp@alien8.de]
> Sent: Wednesday, November 04, 2015 4:15 AM
> 
> On Mon, Nov 02, 2015 at 07:17:28AM +0000, Kweh, Hock Leong wrote:
> > This is not a return value to indicate what is going now. It is a flag
> > used in "cap_info->index" which positive value has a meaning of index
> > number. I am using the negative value for the flag which similar to
> > the implementation of pointer & error pointer (ERR_PTR).
> 
> Ok, but that doesn't make any sense: you're assigning UPLOAD_DONE to
> cap_info->index only once in efi_capsule_submit_update() and you're not
> testing it anywhere. Yeah, yeah, you're implicitly testing for it by
> doing the "< 0" check.
> 
> So simply assign -1 to ->index to mean *any* type of error occurred,
> remove the defines and you can always test for "< 0" to mean "did
> something fail".
> 
> You simply don't need two error values...
> 

Ok. Noted.

Thanks & Regards,
Wilson

????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?