archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <>
To: Stephen Boyd <>,
	Rob Herring <>,
	Grant Likely
Cc: ""
	Linux ARM
	Timur Tabi <>,
	Andy Shevchenko
	Bjorn Andersson
Subject: Re: [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property
Date: Wed, 10 Jan 2018 14:37:53 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, Jan 10, 2018 at 2:58 AM, 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.
> Cc: <>
> Signed-off-by: Stephen Boyd <>

I like the idea, let's check what we think about the details regarding
naming and semantics, I need feedback from some DT people
in particular.

Paging in Grant on this as he might have some input.

> I stuck this inside msm8996, but maybe it can go somewhere more generic?

Yeah just put it in Documentation/devicetree/bindings/gpio/gpio.txt
Everyone and its dog doing GPIO reservations "from another world"
will need to use this.

> +- ngpios-ranges:
> +       Usage: optional
> +       Value type: <prop-encoded-array>
> +       Definition: Tuples of GPIO ranges (base, size) indicating
> +                   GPIOs available for use.
> +
>  Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
>  a general description of GPIO and interrupt bindings.

I like the tuples syntax. That's fine. It's like gpio-ranges we have
already to map between pin controllers and GPIO.

I don't think we can reuse gpio-ranges because that is
exclusively for pin control ATM, it would be fine if the ranges
were for a specific device, like pin control does, like:

gpio-ranges = <&secure_world_thing 0 20 10>;

But you definately would need a node to tie it to, so that the
driver for that node can specify that it's gonna take the

But I think the semantics should be the inverse. That you
point out "holes" with the lines we *can't* use.

We already support a generic property "ngpios" that says how
many of the GPIOs (counted from zero) that can be used,
so if those should be able to use this as a generic property it
is better with the inverse semantics and say that the
"reserved-gpio-ranges", "secureworld-gpio-ranges"
(or whatever we decide to call it) takes precedence over
ngpios so we don't end up in ambigous places.

Then, will it be possible to put the parsing, handling and
disablement of these ranges into drivers/gpio/gpiolib-of.c
where we handle the ranges today, or do we need to
do it in the individual drivers?

Linus Walleij
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to
More majordomo info at

  parent reply	other threads:[~2018-01-10 13:37 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10  1:58 [PATCH 0/3] Support qcom pinctrl protected pins Stephen Boyd
     [not found] ` <>
2018-01-10  1:58   ` [PATCH 1/3] gpiolib: Export gpiochip_irqchip_irq_valid() to drivers Stephen Boyd
2018-01-10  6:16     ` Bjorn Andersson
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 12:54   ` Andy Shevchenko
     [not found]   ` <>
2018-01-10 13:37     ` Linus Walleij [this message]
2018-01-10 16:37       ` Stephen Boyd
2018-01-10 17:59         ` Andy Shevchenko
2018-01-11 16:33       ` Grant Likely
2018-01-11 16:36         ` Timur Tabi
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  6:11   ` Bjorn Andersson
2018-01-22 13:55   ` Timur Tabi
2018-01-22 20:03     ` Timur Tabi
2018-01-25 21:51     ` Stephen Boyd
2018-01-25 21:53       ` 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:

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

  git send-email \ \ \
    --cc=andriy.shevchenko-VuQAYsv1563Yd54FQh9/ \ \ \
    --cc=grant.likely-s3s/ \ \ \ \ \ \ \ \

* 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).