linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Stephen Boyd <swboyd@chromium.org>,
	Linus Walleij <linus.walleij@linaro.org>
Cc: Stephen Boyd <sboyd@codeaurora.org>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, Timur Tabi <timur@codeaurora.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	linux-gpio@vger.kernel.org
Subject: Re: [PATCH v3 3/3] pinctrl: qcom: Don't allow protected pins to be requested
Date: Wed, 21 Mar 2018 20:07:09 +0200	[thread overview]
Message-ID: <1521655629.23017.84.camel@linux.intel.com> (raw)
In-Reply-To: <20180321165848.89751-4-swboyd@chromium.org>

On Wed, 2018-03-21 at 09:58 -0700, Stephen Boyd wrote:
> From: Stephen Boyd <sboyd@codeaurora.org>
> 
> 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 <sboyd@codeaurora.org>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>

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 <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

  reply	other threads:[~2018-03-21 18:07 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 16:58 [PATCH v3 0/3] Support qcom pinctrl protected pins Stephen Boyd
2018-03-21 16:58 ` [PATCH v3 1/3] dt-bindings: gpio: Add a gpio-reserved-ranges property Stephen Boyd
2018-03-21 16:58 ` [PATCH v3 2/3] gpiolib: Support 'gpio-reserved-ranges' property Stephen Boyd
2018-03-21 17:59   ` Andy Shevchenko
2018-03-21 18:02     ` Andy Shevchenko
2018-03-21 19:59     ` Stephen Boyd
2018-03-21 20:31       ` Andy Shevchenko
2018-03-27 13:24       ` Linus Walleij
2018-03-21 16:58 ` [PATCH v3 3/3] pinctrl: qcom: Don't allow protected pins to be requested Stephen Boyd
2018-03-21 18:07   ` Andy Shevchenko [this message]
2018-03-21 20:04     ` Stephen Boyd
2018-03-21 20:30       ` Andy Shevchenko
2018-03-21 20:17   ` Stephen Boyd
2018-03-23  0:16   ` Timur Tabi
2018-03-23  0:23     ` Timur Tabi
2018-03-23  0:59       ` Timur Tabi
2018-03-23 11:34         ` Andy Shevchenko
2018-03-23 14:03           ` Timur Tabi
2018-03-23 11:36     ` Andy Shevchenko
2018-03-23 16:21       ` Stephen Boyd
2018-03-23 16:25         ` Timur Tabi
2018-03-23 16:31         ` Andy Shevchenko
2018-03-23 16:32           ` Andy Shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1521655629.23017.84.camel@linux.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sboyd@codeaurora.org \
    --cc=swboyd@chromium.org \
    --cc=timur@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).