From patchwork Mon Oct 16 13:42:41 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Timur Tabi X-Patchwork-Id: 10008365 X-Patchwork-Delegate: agross@codeaurora.org Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 4599260235 for ; Mon, 16 Oct 2017 13:42:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3563E28599 for ; Mon, 16 Oct 2017 13:42:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 29E292859F; Mon, 16 Oct 2017 13:42:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A766228599 for ; Mon, 16 Oct 2017 13:42:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752133AbdJPNmp (ORCPT ); Mon, 16 Oct 2017 09:42:45 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:55096 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751714AbdJPNmo (ORCPT ); Mon, 16 Oct 2017 09:42:44 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 20E0D6087C; Mon, 16 Oct 2017 13:42:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1508161364; bh=Unx3Cy+t6C5oZ9dMyLubI+ojWhevBTYH4BQLR64QfXU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LqKhPt53SHlBRts/4Hwc2cZp/OI4T0ZTB4zYbUBFG0PgwGGvQgtfodJ4BDD7oTaq/ lm8BCSuSyXYbngaEJd/pJslfJC12eCDv/BL/n8/SUuLXEauLF/x72SfnScpbvdCQgc N6z2SNpxx6C+XaFgWdkRsrtRdzaAWoEd10w7rFS4= Received: from [10.222.143.167] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: timur@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id A23386083D; Mon, 16 Oct 2017 13:42:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1508161363; bh=Unx3Cy+t6C5oZ9dMyLubI+ojWhevBTYH4BQLR64QfXU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ix0A2U+Cj2dkGetu2+1wCiFHGCiGTMZUjQtynMCUgZ2srYOeE+VCU4LlasDcat8LR h9kh0asWDwdtcPgGrE6xrjm1JdkZhojBLRl8EEDyvPHiaoRb6znegR9hp/CtSpjOoi 2R68mLl0FDZukTW3oDKgwkJd7BnyFOPd5/GOjmzo= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org A23386083D Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=timur@codeaurora.org Subject: Re: [PATCH 0/2] [v5] pinctrl: qcom: add support for sparse GPIOs To: Linus Walleij , Stephen Boyd Cc: Andy Gross , David Brown , anjiandi@codeaurora.org, Bjorn Andersson , "linux-gpio@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-arm-msm@vger.kernel.org" , "thierry.reding@gmail.com" , Mika Westerberg , Andy Shevchenko References: <1ecdf6ee-5098-15d3-f85e-66b39a6c25f9@codeaurora.org> <619f48d2-59c7-c090-4ace-9e8db9f92064@codeaurora.org> <255ad0dc-2d16-ae7f-0b45-500e23cff1a4@codeaurora.org> <20171003220311.GU457@codeaurora.org> <20171012073922.GB18706@codeaurora.org> From: Timur Tabi Message-ID: <22ef3c75-bdf6-6aeb-a1dd-2d03eb46fd58@codeaurora.org> Date: Mon, 16 Oct 2017 08:42:41 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 10/14/2017 05:43 PM, Linus Walleij wrote: > So I guess the driver needs to know what pin registers it can't > access so the user does not get a gun to shoot in the foot with. > > If we augment gpiolib to just handle -EACCES or something > (-EIO?) from the driver .get_direction() callback for these lines, > things should be smooth? You mean like this: /* 0 = output, 1 = input */ This is what I have in my patch already. I can return any error message you like, but -ENODEV already works. The problem is that it's insufficient. I also want the non-available GPIOs to be as absent as possible. I don't want them to show up in /sys/kernel/debug/gpio, and I don't want to be able to create them via /sys/class/gpio/export. diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c index ff491da64dab..ca4ae3d76eb4 100644 --- a/drivers/pinctrl/qcom/pinctrl-msm.c +++ b/drivers/pinctrl/qcom/pinctrl-msm.c @@ -443,6 +443,14 @@ static int msm_gpio_get_direction(struct gpio_chip *chip, unsigned int offset) g = &pctrl->soc->groups[offset]; + /* + * During initialization, gpiolib may query all GPIOs for their + * initial direction, regardless if they exist, so block access + * to those that are unavailable. + */ + if (!g->npins) + return -ENODEV; + val = readl(pctrl->regs + g->ctl_reg);