Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1360091
| From | Laxman Dewangan <ldewangan@nvidia.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog |
| Date | 2016-03-17 19:00 +0100 |
| Message-ID | <rdKng-22V-3@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <raPWa-2G3-13@gated-at.bofh.it> <rb3cK-3AY-11@gated-at.bofh.it> <rb6Nk-6gw-17@gated-at.bofh.it> <rb7zI-6OQ-5@gated-at.bofh.it> <rdIls-MU-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thursday 17 March 2016 09:16 PM, Rob Herring wrote: > On Thu, Mar 10, 2016 at 05:23:55PM +0530, Laxman Dewangan wrote: >>>> On this case, we have already property "line-name" and passed the name >>>> of the gpio via this property. >>>> The property names is "line-name" which is good for one string. We can >>>> support other property "line-names" with multiple string per GPIO index. >>>> >>>> line-names = "wlan-reset", "wlan-enable"; > Then what happens when someone wants to selectively disable gpio hogs? > > status = "okay", "disabled", "okay"; > > While I often push things to fewer nodes and more compact descriptions, > I don't think that is the right direction in this case. I dont think we need to support the individual gpio to be enable/disable by status. We need to support the status property at node level only. if individual gpio need to be enabled/disabled by status then it need to break in different hog nodes. This is same as like we have in pincontrol where we can provide the list of pin names for some configuration under same node. >>> There is currently a discussion about the future bindings for subnodes in GPIO >>> controller nodes. Please have a look at these two mail threads: >>> >>> "Device tree binding documentation for gpio-switch" >>> "gpio: of: Add support to have multiple gpios in gpio-hog" >> Second one is this patch only. Is it by intention? >> >> The binding details about the gpio-switch and names are given by property >> "lable". I think property "label" is standard way of going forward i.e. I >> post similar patch for gpio-keys device name from DT after got review >> comment. >> >> So here, we can have the gpio names under property "label" or "labels". > label is standard. labels you just made up. Yaah, lables for plural only. Otherwise no issue with "label". > >> Or am I missing anything? > The point is the more one off changes I see that are all inter-related, > the less willing I am to accept any that don't consider all the cases. > The inter-relationship here is how do we describe gpio lines that don't > otherwise have a connection to another node and how to deal with them if > that changes.
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-08 13:20 +0100
Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog Markus Pargmann <mpa@pengutronix.de> - 2016-03-09 07:30 +0100
Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-09 14:40 +0100
Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog Stephen Warren <swarren@wwwdotorg.org> - 2016-03-09 18:20 +0100
Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-10 08:30 +0100
Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog Markus Pargmann <mpa@pengutronix.de> - 2016-03-10 12:20 +0100
Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-10 13:10 +0100
Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog Rob Herring <robh@kernel.org> - 2016-03-17 16:50 +0100
Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-17 19:00 +0100
csiph-web