From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Stephen Boyd <sboyd@codeaurora.org>,
Linus Walleij <linus.walleij@linaro.org>
Cc: linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Timur Tabi <timur@codeaurora.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property
Date: Wed, 10 Jan 2018 14:54:21 +0200 [thread overview]
Message-ID: <1515588861.7000.842.camel@linux.intel.com> (raw)
In-Reply-To: <20180110015848.11480-3-sboyd@codeaurora.org>
On Tue, 2018-01-09 at 17:58 -0800, Stephen Boyd wrote:
> 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.
> Introduce a DT property to describe the set of GPIOs that are
> available for use so that higher level OSes are able to know what
> pins to avoid reading/writing.
> +- ngpios-ranges:
> + Usage: optional
> + Value type: <prop-encoded-array>
> + Definition: Tuples of GPIO ranges (base, size) indicating
> + GPIOs available for use.
Can be name more particular?
We have on one hand gpio-range-list for mapping, on the other this one
might become generic.
So, there are few options (at least?) to consider:
1) re-use gpio-ranges
2) add a valid property to gpio-ranges
3) rename ngpios-ranges to something like gpio-valid-ranges (I don't
like it so much either, but for me it looks more descriptive than
ngpios-ranges)
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
WARNING: multiple messages have this Message-ID (diff)
From: andriy.shevchenko@linux.intel.com (Andy Shevchenko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property
Date: Wed, 10 Jan 2018 14:54:21 +0200 [thread overview]
Message-ID: <1515588861.7000.842.camel@linux.intel.com> (raw)
In-Reply-To: <20180110015848.11480-3-sboyd@codeaurora.org>
On Tue, 2018-01-09 at 17:58 -0800, Stephen Boyd wrote:
> 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.
> Introduce a DT property to describe the set of GPIOs that are
> available for use so that higher level OSes are able to know what
> pins to avoid reading/writing.
> +- ngpios-ranges:
> + Usage: optional
> + Value type: <prop-encoded-array>
> + Definition: Tuples of GPIO ranges (base, size) indicating
> + GPIOs available for use.
Can be name more particular?
We have on one hand gpio-range-list for mapping, on the other this one
might become generic.
So, there are few options (at least?) to consider:
1) re-use gpio-ranges
2) add a valid property to gpio-ranges
3) rename ngpios-ranges to something like gpio-valid-ranges (I don't
like it so much either, but for me it looks more descriptive than
ngpios-ranges)
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
next prev parent reply other threads:[~2018-01-10 13:01 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-10 1:58 [PATCH 0/3] Support qcom pinctrl protected pins Stephen Boyd
2018-01-10 1:58 ` Stephen Boyd
[not found] ` <20180110015848.11480-1-sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-01-10 1:58 ` [PATCH 1/3] gpiolib: Export gpiochip_irqchip_irq_valid() to drivers Stephen Boyd
2018-01-10 1:58 ` Stephen Boyd
2018-01-10 1:58 ` Stephen Boyd
2018-01-10 6:16 ` Bjorn Andersson
2018-01-10 6:16 ` Bjorn Andersson
2018-01-10 13:22 ` Linus Walleij
2018-01-10 13:22 ` Linus Walleij
2018-01-10 1:58 ` [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property Stephen Boyd
2018-01-10 1:58 ` Stephen Boyd
2018-01-10 12:54 ` Andy Shevchenko [this message]
2018-01-10 12:54 ` Andy Shevchenko
[not found] ` <20180110015848.11480-3-sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-01-10 13:37 ` Linus Walleij
2018-01-10 13:37 ` Linus Walleij
2018-01-10 13:37 ` Linus Walleij
2018-01-10 16:37 ` Stephen Boyd
2018-01-10 16:37 ` Stephen Boyd
2018-01-10 17:59 ` Andy Shevchenko
2018-01-10 17:59 ` Andy Shevchenko
2018-01-11 16:33 ` Grant Likely
2018-01-11 16:33 ` Grant Likely
2018-01-11 16:36 ` Timur Tabi
2018-01-11 16:36 ` Timur Tabi
2018-01-11 19:56 ` Grant Likely
2018-01-11 19:56 ` Grant Likely
2018-01-10 1:58 ` [PATCH 3/3] pinctrl: qcom: Don't allow protected pins to be requested Stephen Boyd
2018-01-10 1:58 ` Stephen Boyd
2018-01-10 6:11 ` Bjorn Andersson
2018-01-10 6:11 ` Bjorn Andersson
2018-01-22 13:55 ` Timur Tabi
2018-01-22 13:55 ` Timur Tabi
2018-01-22 20:03 ` Timur Tabi
2018-01-22 20:03 ` Timur Tabi
2018-01-22 20:03 ` Timur Tabi
2018-01-25 21:51 ` Stephen Boyd
2018-01-25 21:51 ` Stephen Boyd
2018-01-25 21:53 ` Timur Tabi
2018-01-25 21:53 ` Timur Tabi
2018-01-25 20:48 ` Timur Tabi
2018-01-25 20:48 ` Timur Tabi
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=1515588861.7000.842.camel@linux.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.