Received: by 10.213.65.68 with SMTP id h4csp10835imn; Wed, 21 Mar 2018 11:08:31 -0700 (PDT) X-Google-Smtp-Source: AG47ELv5dYAHJL/SJR5+/P5BlFwYoczhu+yh7Xituhd+o3+eDOUntl751M4llMNaBhpC8HrEkf3k X-Received: by 2002:a17:902:41:: with SMTP id 59-v6mr22015562pla.248.1521655711915; Wed, 21 Mar 2018 11:08:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521655711; cv=none; d=google.com; s=arc-20160816; b=AsIwMfR7ecQu9Y5ASvNnZLnOAE5TsD0e+8eqiaKYgu1rMW7r1oM5r9TLab+p9ls0ky QdXyttRO3qMisgXVjfvxQDg61M9aEGQn6qJzaRps5oHvVWW0PrJbLIWkLgAJTiRarfNV anGczEtEfDjiCJuXt53KAgymFft+SpjkBl47RhrH3+bEktbR43rYTlbcXiy9mWRjODZD rzOoL5O5CIt86AANX0wsyJ0MSWhq7qW3lCRzAOkQ05jGw4VdxnluMAkPDs0g4vHmngaH cU8tvE+zXHoFo08zK97hdk4jvvigRqHdKFs72KO2C16RYd7RR8QYsGKLL36M7ai5qsak LzbA== 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:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=pab/oSqo6HoZfgM2MQODNyVBKES3VhoC+232gn/k42Y=; b=gzC03vcxryLZRS3CatSSTYSdaxiLZYl7VHspt79DValaG9gTxHD0jNMB06qYvj3XGY L3vlIcWzJpzy7zC6zRl2EsGkqlR/ouqwuVlMnJnpIWaGr06hVpD+hFzE/9gWqfkmX7Gx xCJ28Thu2WbfV3DBPBAdyvZRctNZ1VtV7ralIvgLsUK+4P/gP9JMaPu7yb5cAD6XAF5U Rw2FzjqSXgG/Gj9USbZM8x9/NDYxW0CbqN91OoqUZzv/l5y/jTiZ4Hnliatq7pRiUxAh UhYK/ivCNHuHK355WYKWJL0kPU+BInXNE8KtEgLmDizMCOgnbQiscoD0OTGcXryNKRoB K3yA== 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 r72si3373469pfa.338.2018.03.21.11.08.16; Wed, 21 Mar 2018 11:08:31 -0700 (PDT) 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 S1752664AbeCUSHR (ORCPT + 99 others); Wed, 21 Mar 2018 14:07:17 -0400 Received: from mga18.intel.com ([134.134.136.126]:25924 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752454AbeCUSHO (ORCPT ); Wed, 21 Mar 2018 14:07:14 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2018 11:07:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,340,1517904000"; d="scan'208";a="26403894" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by fmsmga008.fm.intel.com with ESMTP; 21 Mar 2018 11:07:11 -0700 Message-ID: <1521655629.23017.84.camel@linux.intel.com> Subject: Re: [PATCH v3 3/3] pinctrl: qcom: Don't allow protected pins to be requested From: Andy Shevchenko To: Stephen Boyd , Linus Walleij Cc: Stephen Boyd , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, Timur Tabi , Bjorn Andersson , Grant Likely , linux-gpio@vger.kernel.org Date: Wed, 21 Mar 2018 20:07:09 +0200 In-Reply-To: <20180321165848.89751-4-swboyd@chromium.org> References: <20180321165848.89751-1-swboyd@chromium.org> <20180321165848.89751-4-swboyd@chromium.org> Organization: Intel Finland Oy Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5-1+b1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-03-21 at 09:58 -0700, Stephen Boyd wrote: > From: Stephen Boyd > > Some qcom platforms make some GPIOs or pins unavailable for use > by non-secure operating systems, and thus reading or writing the > registers for those pins will cause access control issues and > reset the device. With a DT/ACPI property to describe the set of > pins that are available for use, parse the available pins and set > the irq valid bits for gpiolib to know what to consider 'valid'. > This should avoid any issues with gpiolib. Furthermore, implement > the pinmux_ops::request function so that pinmux can also make > sure to not use pins that are unavailable. > > Signed-off-by: Stephen Boyd > Signed-off-by: Stephen Boyd Hmm... > +static int msm_pinmux_request(struct pinctrl_dev *pctldev, unsigned > offset) > +{ > + struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev); > + struct gpio_chip *chip = &pctrl->chip; > + > + if (gpiochip_line_is_valid(chip, offset)) > + return 0; > + > + return -EINVAL; Perhaps traditional pattern if (!...) return -EINVAL; return 0; ? > +} > seq_printf(s, " %dmA", msm_regval_to_drive(drive)); > - seq_printf(s, " %s", pulls[pull]); > + seq_printf(s, " %s\n", pulls[pull]); I had commented this once, but you ignored by some reason. I would rather just move seq_puts(s, "\n"); here. The rationale behind, besides making diff more neat, is to reduce possible burden in the future if someone would like to squeeze more data in between. > + tmp = kmalloc_array(len, sizeof(tmp[0]), GFP_KERNEL); sizeof(*tmp) ? > + if (!tmp) > + return -ENOMEM; -- Andy Shevchenko Intel Finland Oy