Received: by 10.223.185.116 with SMTP id b49csp3947363wrg; Tue, 6 Mar 2018 07:30:23 -0800 (PST) X-Google-Smtp-Source: AG47ELvjufUxVD/AljX/wxdMLXC+WAo81eL+1Jdu1MqPXbUkSCPcVL3dbKmBTtVBHpndcMSs9Nsa X-Received: by 10.98.78.68 with SMTP id c65mr14459201pfb.65.1520350223551; Tue, 06 Mar 2018 07:30:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520350223; cv=none; d=google.com; s=arc-20160816; b=vodqFRg+KjkddSo0dXxW73q/Akc8YnP1HB7ohJl7KoUr3MmRhY0E9kBNB2XcWpkGpM zQkKaIfgpgkbktAwTqJHtytW3bG1IM07JjzjP3kKDBrH44f/m1jTAJQoVxuFK5QdZx52 TyTil9PBX/JausdJWt+oeCWn2+qkiuJRPcRVA4fwMc/5y1T+yKKLWyEODdh5Y1qos982 Zy5jkjA07FEFiQKbHW/Ti0gtEvAu4F8vzSA4AvKnKXuUFSlRPeadd1enM2CHtSNlWIAb vOueCSq+bmNjRsygUfMymSxz7P8cAEgmcqs4vOYQtQoDznk0HvZLu/jZQt4lMlJ9TcKN M50A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=3xav70B0pSSBIYu72/5+zHWTTHureFYu23bO4TFvAqA=; b=pJD/39ljlZdewV5sg2YcUZNtJUa6br00obkzCaQoAlc/FZvus8i/dts+WboXI15gcd yxdyOaaSJLuF8QBSJLnR4n67azCwTQsl1F7gt/sl4v/7G2JnkbpsB/JSFHZ8D60ohhkz c0seeiVH+cb+9EAQ79F5W0OHHmOmtVI8HUKyFqNBJTZrlePl6vOGbaPjNhNo7iAVRjD0 MyTL6unzL2iMO3Vd3o3aNLoC6xgjzgkwyOX1qp7OItG0TUET9pegR3HYELYHnyMBS4wi wkCaA6dsD/NjoIdXB0MPwEBMw9h8Z6aUweoSoB4EBWEen9OBmjVwwE3i7z8mNZxxTS/j cLfw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y67si12156665pfd.195.2018.03.06.07.30.08; Tue, 06 Mar 2018 07:30:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753656AbeCFP3N (ORCPT + 99 others); Tue, 6 Mar 2018 10:29:13 -0500 Received: from bert.emutex.com ([91.103.1.109]:48185 "EHLO bert.emutex.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750817AbeCFP3L (ORCPT ); Tue, 6 Mar 2018 10:29:11 -0500 Received: from [92.51.199.138] (helo=statler.emutex.com) by bert.emutex.com with esmtp (Exim 4.84) (envelope-from ) id 1etEX7-00013l-Lm; Tue, 06 Mar 2018 15:29:41 +0000 Received: from 169.red-83-50-205.dynamicip.rima-tde.net ([83.50.205.169] helo=[192.168.1.39]) by statler.emutex.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1etEWa-0005BL-Fq; Tue, 06 Mar 2018 15:29:08 +0000 Subject: Re: [PATCH] pinctrl: intel: Implement intel_gpio_get_direction callback To: Andy Shevchenko Cc: Mika Westerberg , Heikki Krogerus , Linus Walleij , linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org References: <20180306134213.16898-1-javier@emutex.com> <3585081b-70af-5c31-08c0-84e96b6055bc@emutex.com> <1520348165.10722.438.camel@linux.intel.com> <1520348368.10722.440.camel@linux.intel.com> From: Javier Arteaga Message-ID: <44e5cabd-c772-9fb6-52a4-887ba3c98fcc@emutex.com> Date: Tue, 6 Mar 2018 15:29:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0 MIME-Version: 1.0 In-Reply-To: <1520348368.10722.440.camel@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Spam-Report: Spam detection software, running on the system "statler.emutex.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 06/03/2018 14:59, Andy Shevchenko wrote: > On Tue, 2018-03-06 at 16:56 +0200, Andy Shevchenko wrote: >> On Tue, 2018-03-06 at 14:31 +0000, Javier Arteaga wrote: > >>>> +static int intel_gpio_get_direction(struct gpio_chip *chip, >>>> unsigned int offset) >>>> +{ > >>>> + if (padcfg0 & PADCFG0_PMODE_MASK) >>>> + return -EINVAL; >> >> Actually we might return direction of GPIO function while pin is in >> some >> other mode, though it would probably make not much sense in practice. > > One more though, this is a call back for GPIO function anyway, so, above > condition should never happen. I think it's safe to remove it > completely. [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/03/2018 14:59, Andy Shevchenko wrote: > On Tue, 2018-03-06 at 16:56 +0200, Andy Shevchenko wrote: >> On Tue, 2018-03-06 at 14:31 +0000, Javier Arteaga wrote: > >>>> +static int intel_gpio_get_direction(struct gpio_chip *chip, >>>> unsigned int offset) >>>> +{ > >>>> + if (padcfg0 & PADCFG0_PMODE_MASK) >>>> + return -EINVAL; >> >> Actually we might return direction of GPIO function while pin is in >> some >> other mode, though it would probably make not much sense in practice. > > One more though, this is a call back for GPIO function anyway, so, above > condition should never happen. I think it's safe to remove it > completely. The story behind that check is likely *not* a valid usecase: the current iteration of the UP board drivers use gpiod_get_direction() *while* requesting GPIOs to mirror SoC GPIO config on the on-board FPGA. So the direction doesn't make sense for pins set to function mode. As per your other feedback that driver should be reworked anyway - that's not a reason to keep the check. I just thought it's a bit more defensive, and saw there's some precedent of doing this: f002d07c56c7 ("gpio: tegra: Implement gpio_get_direction callback") That being said I don't have a strong argument either way :) I'll resend if you still feel it's unnecessary. Thanks for reviewing!