From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756041AbcDLGrG (ORCPT ); Tue, 12 Apr 2016 02:47:06 -0400 Received: from mga02.intel.com ([134.134.136.20]:26246 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751181AbcDLGrE (ORCPT ); Tue, 12 Apr 2016 02:47:04 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,472,1455004800"; d="scan'208";a="83505478" Date: Tue, 12 Apr 2016 09:46:57 +0300 From: Mika Westerberg To: Jiang Qiu Cc: Linus Walleij , Alexandre Courbot , Andy Shevchenko , Alan Tull , Jamie Iles , charles.chenxin@huawei.com, "linux-kernel@vger.kernel.org" , "linux-gpio@vger.kernel.org" , ACPI Devel Maling List , Linuxarm Subject: Re: [PATCH v7 3/3] gpio: dwapb: add gpio-signaled acpi event support Message-ID: <20160412064657.GF1714@lahna.fi.intel.com> References: <1459926480-32966-1-git-send-email-qiujiang@huawei.com> <1459926480-32966-4-git-send-email-qiujiang@huawei.com> <20160408083830.GT1727@lahna.fi.intel.com> <570B9BEA.8060608@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <570B9BEA.8060608@huawei.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 11, 2016 at 08:43:22PM +0800, Jiang Qiu wrote: > > Currently it just complains if something goes wrong. The GPIO driver > > itself can still work just fine (including interrupts). > > > > I'm fine to change it to return an error code. > Agree, if add a error code for acpi_gpiochip_request_interrupts(), it looks more pretty. > > However, this function is common for other part, maybe cause any other effects if I > do this change, did you think so? I'm thinking what the callers are going to do with the error code. Basically it means that we were not able to attach and configure ACPI event GPIOs. It does not prevent GPIO drivers from functioning so they probably just print out some warning message and continue probing, and we already warn in acpi_gpiochip_request_interrupts() if something fails. Unless Linus W insists, let's just keep it as is for now :)