From: Jonathan Cameron <jic23@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>,
Lars-Peter Clausen <lars@metafoo.de>
Cc: Eva Rachel Retuya <eraretuya@gmail.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Michael Hennerich <Michael.Hennerich@analog.com>,
Hartmut Knaack <knaack.h@gmx.de>,
Peter Meerwald <pmeerw@pmeerw.net>,
Greg KH <gregkh@linuxfoundation.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <Mark.Rutland@arm.com>
Subject: Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale
Date: Sat, 19 Nov 2016 12:32:42 +0000 [thread overview]
Message-ID: <f381ab09-7bad-acea-ead2-a6a370598918@kernel.org> (raw)
In-Reply-To: <CACRpkdbWqxUWc+40AYSY7XX2ZFYSZEBcU3FusOrunG+-GCZGwQ@mail.gmail.com>
On 14/11/16 23:12, Linus Walleij wrote:
> On Mon, Nov 14, 2016 at 7:53 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
>
>> It's about figuring out the setting of a "GPIO" that can't be changed from
>> software.
>>
>> Devices sometimes, instead of a configuration bus like I2C or SPI, use
>> simple input pins, that can either be set to high or low, to allow software
>> the state of the device. The GPIO API is typically used to configure these pins.
>>
>> This works fine as long as the pin is connected to a GPIO. But sometimes the
>> system designer decides that a settings does not need to be configurable, in
>> this case the pin will be tied to logic low or high directly on the PCB
>> without any GPIO controller being involved.
>>
>> Sometimes a driver wants to know how the pin is wired up so it can report to
>> userspace this part runs in the following mode and the mode can't be
>> changed. In a sense it is like a reverse GPIO hog.
>>
>> Considering that this is a common usecase the question was how this can be
>> implemented in a driver independent way to avoid code duplication and
>> slightly different variations of what is effectively the same DT/ACPI binding.
>>
>> E.g. lets say for a configurable pin you use
>>
>> range-gpio = <&gpio ...>;
>>
>> and for a static pin
>>
>> range-gpio-fixed = <1>;
>>
>> Or something similar.
>
> Aha I understand.
>
> Usually I feel we need not shoehorn stuff into GPIO because it is convenient,
> it might be best to leave the GPIO optional and if it is not there, look for
> a custom attribute that represents the "hogging" to 0/1. I think trying
> to extend GPIO bindings to cover it is overgeneralization, instead go
> for a local binding for this kind of devices.
>
> But mainly it is a question to the DT bindings maintainers.
That's a reasonable approach, but I'd certainly like to see a generic binding
to describe it. It's a pretty common situation.
Seems more likely we'll get a device tree maintainer response if we cc them ;)
So Mark, Rob and thoughts on this?
Thanks,
Jonathan
>
> Yours,
> Linus Walleij
>
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org>
Cc: Eva Rachel Retuya
<eraretuya-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Michael Hennerich
<Michael.Hennerich-OyLXuOCK7orQT0dZR+AlfA@public.gmane.org>,
Hartmut Knaack <knaack.h-Mmb7MZpHnFY@public.gmane.org>,
Peter Meerwald <pmeerw-jW+XmwGofnusTnJN9+BGXg@public.gmane.org>,
Greg KH
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale
Date: Sat, 19 Nov 2016 12:32:42 +0000 [thread overview]
Message-ID: <f381ab09-7bad-acea-ead2-a6a370598918@kernel.org> (raw)
In-Reply-To: <CACRpkdbWqxUWc+40AYSY7XX2ZFYSZEBcU3FusOrunG+-GCZGwQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 14/11/16 23:12, Linus Walleij wrote:
> On Mon, Nov 14, 2016 at 7:53 PM, Lars-Peter Clausen <lars-Qo5EllUWu/uELgA04lAiVw@public.gmane.org> wrote:
>
>> It's about figuring out the setting of a "GPIO" that can't be changed from
>> software.
>>
>> Devices sometimes, instead of a configuration bus like I2C or SPI, use
>> simple input pins, that can either be set to high or low, to allow software
>> the state of the device. The GPIO API is typically used to configure these pins.
>>
>> This works fine as long as the pin is connected to a GPIO. But sometimes the
>> system designer decides that a settings does not need to be configurable, in
>> this case the pin will be tied to logic low or high directly on the PCB
>> without any GPIO controller being involved.
>>
>> Sometimes a driver wants to know how the pin is wired up so it can report to
>> userspace this part runs in the following mode and the mode can't be
>> changed. In a sense it is like a reverse GPIO hog.
>>
>> Considering that this is a common usecase the question was how this can be
>> implemented in a driver independent way to avoid code duplication and
>> slightly different variations of what is effectively the same DT/ACPI binding.
>>
>> E.g. lets say for a configurable pin you use
>>
>> range-gpio = <&gpio ...>;
>>
>> and for a static pin
>>
>> range-gpio-fixed = <1>;
>>
>> Or something similar.
>
> Aha I understand.
>
> Usually I feel we need not shoehorn stuff into GPIO because it is convenient,
> it might be best to leave the GPIO optional and if it is not there, look for
> a custom attribute that represents the "hogging" to 0/1. I think trying
> to extend GPIO bindings to cover it is overgeneralization, instead go
> for a local binding for this kind of devices.
>
> But mainly it is a question to the DT bindings maintainers.
That's a reasonable approach, but I'd certainly like to see a generic binding
to describe it. It's a pretty common situation.
Seems more likely we'll get a device tree maintainer response if we cc them ;)
So Mark, Rob and thoughts on this?
Thanks,
Jonathan
>
> Yours,
> Linus Walleij
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-11-19 12:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-11 6:34 [PATCH 0/2] staging: iio: ad7606: move driver out of staging Eva Rachel Retuya
2016-11-11 6:34 ` [PATCH 1/2] staging: iio: ad7606: replace range/range_available with corresponding scale Eva Rachel Retuya
2016-11-11 14:18 ` Lars-Peter Clausen
2016-11-12 14:22 ` Eva Rachel Retuya
2016-11-14 10:25 ` Lars-Peter Clausen
2016-11-12 14:24 ` Jonathan Cameron
2016-11-14 10:30 ` Lars-Peter Clausen
2016-11-14 17:26 ` Jonathan Cameron
2016-11-14 16:58 ` Linus Walleij
2016-11-14 18:53 ` Lars-Peter Clausen
2016-11-14 22:15 ` Jonathan Cameron
2016-11-14 22:15 ` Jonathan Cameron
2016-11-14 23:12 ` Linus Walleij
2016-11-19 12:32 ` Jonathan Cameron [this message]
2016-11-19 12:32 ` Jonathan Cameron
2016-11-11 6:34 ` [PATCH 2/2] staging: iio: ad7606: move out of staging Eva Rachel Retuya
2016-11-11 14:22 ` Lars-Peter Clausen
2016-11-12 14:26 ` Jonathan Cameron
2016-11-12 14:32 ` Eva Rachel Retuya
2016-11-12 14:42 ` Jonathan Cameron
2016-11-11 16:10 ` kbuild test robot
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=f381ab09-7bad-acea-ead2-a6a370598918@kernel.org \
--to=jic23@kernel.org \
--cc=Mark.Rutland@arm.com \
--cc=Michael.Hennerich@analog.com \
--cc=devicetree@vger.kernel.org \
--cc=eraretuya@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linus.walleij@linaro.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmeerw@pmeerw.net \
--cc=robh+dt@kernel.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.