Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756667AbbHZHev (ORCPT ); Wed, 26 Aug 2015 03:34:51 -0400 Received: from mail-ob0-f176.google.com ([209.85.214.176]:35687 "EHLO mail-ob0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756363AbbHZHeu (ORCPT ); Wed, 26 Aug 2015 03:34:50 -0400 MIME-Version: 1.0 In-Reply-To: References: <1438048204-632-1-git-send-email-bjorn.andersson@sonymobile.com> <20150728210040.GE19610@dtor-ws> <20150810224109.GN6519@usrtlx11787.corpusers.net> Date: Wed, 26 Aug 2015 09:34:49 +0200 Message-ID: Subject: Re: [PATCH] input: gpio_keys: Don't report events on gpio failure From: Linus Walleij To: Alexandre Courbot Cc: Bjorn Andersson , Dmitry Torokhov , "linux-input@vger.kernel.org" , "linux-kernel@vger.kernel.org" , John Stultz , "linux-gpio@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1059 Lines: 24 On Mon, Aug 17, 2015 at 8:59 AM, Alexandre Courbot wrote: > So I'd say it makes sense to propagate errors returned by the driver's > get() hook. This might contradict some of our earlier statements about > simplifying the GPIO API, but is preferrable to having to make a > decision as to which valid value to return if the driver fails... > > It should then be made very clear in the documentation that the only > positive values ever returned by the GPIO API will be 0 and 1 (we > already have a clamping mechanism for that IIRC), and that negative > values are propagated as-is. > > Linus, does that seem reasonable to you? Does anyone has the intention > to address that one or should I add it to my short-term TODO list? I'm aligned with this. Go ahead on this path. Yours, Linus Walleij -- 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/