* Re: [PATCH 2/2] ARM: dt: tegra: cardhu: register core regulator tps65911 [not found] ` <20120601210451.GC4258-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> @ 2012-06-02 21:19 ` Olof Johansson [not found] ` <CAOesGMgYAR938F8PnVWaymzMBQwDKeAiUgEP81bv2nN14NmLGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 6+ messages in thread From: Olof Johansson @ 2012-06-02 21:19 UTC (permalink / raw) To: Mark Brown Cc: Stephen Warren, Laxman Dewangan, Stephen Warren, linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Grant Likely, Rob Herring [+devicetree-discuss and grant/rob] On Fri, Jun 1, 2012 at 2:04 PM, Mark Brown <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> wrote: > On Fri, Jun 01, 2012 at 02:44:00PM -0600, Stephen Warren wrote: > >> Could you expand on "named property" a bit; I'm not quite sure what >> you're getting at - literally a property with name "named" (which >> would be the same as regulator-id under just a different property >> name), or ...? > > Just a property where we only care about a name (ie, that the property > is present). > >> > Can't we use the right hand side of this? It appears to just be >> > syntactic sugar without any current meaning. > >> The stuff to the right of @ is the "unit address" and must match the >> value in the reg property. Using that was the first proposal I had >> above (which I also didn't like as much) > > The stuff to the left of the @ is just noise right now, though - it has > no meaning currently. It's filled in with "regulator" because we need > to put something there AFAICT. Right. In general (and historically) in the device tree, names of the nodes should have meaning for the person reading the device tree, but it's not meant to be used for software to figure out the hardware configuration -- that should instead be handled through compatible + other properties. Names are generally kept fairly generic (ethernet, cpus, memory, pci, etc). Where it starts to become gray area is when it comes down to specific bindings, and essentially the device nodes underneath of those devices. It's been generally accepted that we can put meaning to the names there if needed, but it's still better to avoid it. I was originally OK with the regulator binding where names have meaning, but after having looked at it a bit recently when looking at bindings for some new boards we have, I realized that the original suggestion for regulator bindings doesn't necessarily isolate the naming dependencies to only be under the regulators in question. In particular, for things such as fixed regulators, they can be located at other places in the device tree. Maybe the solution to that case is to just aggregate them in one place and make a pseudo-binding for that (or those, in case of multiple locations). On the rest of the name-has-meaning discussion, I think it would be cleaner to move away from it now while there's relatively few users of it (with a migratin path), rather than revise it later. But I'll leave it to Grant and Rob to decide which way the prefer things to be. I think they might both be travelling around LC/LinuxCon events at the moment though. -Olof ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <CAOesGMgYAR938F8PnVWaymzMBQwDKeAiUgEP81bv2nN14NmLGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH 2/2] ARM: dt: tegra: cardhu: register core regulator tps65911 [not found] ` <CAOesGMgYAR938F8PnVWaymzMBQwDKeAiUgEP81bv2nN14NmLGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2012-06-03 2:45 ` Rob Herring [not found] ` <4FCACFB6.2060601-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2012-06-03 11:55 ` Mark Brown 1 sibling, 1 reply; 6+ messages in thread From: Rob Herring @ 2012-06-03 2:45 UTC (permalink / raw) To: Olof Johansson Cc: linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Mark Brown, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring, Laxman Dewangan, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org On 06/02/2012 04:19 PM, Olof Johansson wrote: > [+devicetree-discuss and grant/rob] > > On Fri, Jun 1, 2012 at 2:04 PM, Mark Brown > <broonie-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> wrote: >> On Fri, Jun 01, 2012 at 02:44:00PM -0600, Stephen Warren wrote: >> >>> Could you expand on "named property" a bit; I'm not quite sure what >>> you're getting at - literally a property with name "named" (which >>> would be the same as regulator-id under just a different property >>> name), or ...? >> >> Just a property where we only care about a name (ie, that the property >> is present). >> >>>> Can't we use the right hand side of this? It appears to just be >>>> syntactic sugar without any current meaning. >> >>> The stuff to the right of @ is the "unit address" and must match the >>> value in the reg property. Using that was the first proposal I had >>> above (which I also didn't like as much) >> >> The stuff to the left of the @ is just noise right now, though - it has >> no meaning currently. It's filled in with "regulator" because we need >> to put something there AFAICT. > > Right. In general (and historically) in the device tree, names of the > nodes should have meaning for the person reading the device tree, but > it's not meant to be used for software to figure out the hardware > configuration -- that should instead be handled through compatible + > other properties. > > Names are generally kept fairly generic (ethernet, cpus, memory, pci, etc). > > Where it starts to become gray area is when it comes down to specific > bindings, and essentially the device nodes underneath of those > devices. It's been generally accepted that we can put meaning to the > names there if needed, but it's still better to avoid it. > > I was originally OK with the regulator binding where names have > meaning, but after having looked at it a bit recently when looking at > bindings for some new boards we have, I realized that the original > suggestion for regulator bindings doesn't necessarily isolate the > naming dependencies to only be under the regulators in question. In > particular, for things such as fixed regulators, they can be located > at other places in the device tree. > > Maybe the solution to that case is to just aggregate them in one place > and make a pseudo-binding for that (or those, in case of multiple > locations). > > On the rest of the name-has-meaning discussion, I think it would be > cleaner to move away from it now while there's relatively few users of > it (with a migratin path), rather than revise it later. But I'll leave > it to Grant and Rob to decide which way the prefer things to be. I > think they might both be travelling around LC/LinuxCon events at the > moment though. I tend to agree with Steven's and Olof's comments in this thread. As the node names generally don't have much meaning, I don't think we should start now. We've already got multiple styles of bindings and I don't think we need more. Rob > > -Olof > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org > https://lists.ozlabs.org/listinfo/devicetree-discuss ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <4FCACFB6.2060601-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH 2/2] ARM: dt: tegra: cardhu: register core regulator tps65911 [not found] ` <4FCACFB6.2060601-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2012-06-03 12:05 ` Mark Brown [not found] ` <20120603120506.GG4258-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> 0 siblings, 1 reply; 6+ messages in thread From: Mark Brown @ 2012-06-03 12:05 UTC (permalink / raw) To: Rob Herring Cc: linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Laxman Dewangan [-- Attachment #1.1: Type: text/plain, Size: 1055 bytes --] On Sat, Jun 02, 2012 at 09:45:10PM -0500, Rob Herring wrote: > I tend to agree with Steven's and Olof's comments in this thread. As the > node names generally don't have much meaning, I don't think we should > start now. We've already got multiple styles of bindings and I don't > think we need more. Well, if we're going to go with an existing idiom the normal thing would be an ordered array which is absolutely abysmal from a usability standpoint. Compatible properties don't work as the whole reason we have an issue here is that people want to have a single node representing a group of regulators - for regulators which we can add a compatible property to we're already doing that and have no issue. What device tree seems to need rather badly is a way of representing key/value pairs - aside from the legacy bindings that seems to be the major source of pain when trying to contort things into DT. Using the "regulator" string that we have to put in the binding (which is currently totally meaningless) does seem like a good way forward here. [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] [-- Attachment #2: Type: text/plain, Size: 192 bytes --] _______________________________________________ devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org https://lists.ozlabs.org/listinfo/devicetree-discuss ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <20120603120506.GG4258-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>]
* Re: [PATCH 2/2] ARM: dt: tegra: cardhu: register core regulator tps65911 [not found] ` <20120603120506.GG4258-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org> @ 2012-06-03 16:11 ` Mitch Bradley [not found] ` <4FCB8CA9.40602-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 0 siblings, 1 reply; 6+ messages in thread From: Mitch Bradley @ 2012-06-03 16:11 UTC (permalink / raw) To: Mark Brown Cc: linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring, Laxman Dewangan, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [-- Attachment #1.1: Type: text/plain, Size: 1435 bytes --] On 6/3/2012 2:05 AM, Mark Brown wrote: > On Sat, Jun 02, 2012 at 09:45:10PM -0500, Rob Herring wrote: > >> I tend to agree with Steven's and Olof's comments in this thread. As the >> node names generally don't have much meaning, I don't think we should >> start now. We've already got multiple styles of bindings and I don't >> think we need more. > > Well, if we're going to go with an existing idiom the normal thing would > be an ordered array which is absolutely abysmal from a usability > standpoint. Compatible properties don't work as the whole reason we > have an issue here is that people want to have a single node > representing a group of regulators - for regulators which we can add a > compatible property to we're already doing that and have no issue. > > What device tree seems to need rather badly is a way of representing > key/value pairs - Perhaps ironically, the fundamental device tree construct - the "property" - is a key/value pair. > aside from the legacy bindings that seems to be the > major source of pain when trying to contort things into DT. > > Using the "regulator" string that we have to put in the binding (which > is currently totally meaningless) does seem like a good way forward > here. > > > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org > https://lists.ozlabs.org/listinfo/devicetree-discuss [-- Attachment #1.2: Type: text/html, Size: 2443 bytes --] [-- Attachment #2: Type: text/plain, Size: 192 bytes --] _______________________________________________ devicetree-discuss mailing list devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org https://lists.ozlabs.org/listinfo/devicetree-discuss ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <4FCB8CA9.40602-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>]
* Re: [PATCH 2/2] ARM: dt: tegra: cardhu: register core regulator tps65911 [not found] ` <4FCB8CA9.40602-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> @ 2012-06-03 18:37 ` Mark Brown 0 siblings, 0 replies; 6+ messages in thread From: Mark Brown @ 2012-06-03 18:37 UTC (permalink / raw) To: Mitch Bradley Cc: Rob Herring, linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Laxman Dewangan [-- Attachment #1: Type: text/plain, Size: 471 bytes --] On Sun, Jun 03, 2012 at 06:11:21AM -1000, Mitch Bradley wrote: > >What device tree seems to need rather badly is a way of representing > >key/value pairs - > Perhaps ironically, the fundamental device tree construct - the > "property" - is a key/value pair. Yeah, I know - the problem is when the value is itself a node, at least as far as I can tell. It's also frustrating that nodes have this user bit of identifying text that we can't seem to use for some reason. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] ARM: dt: tegra: cardhu: register core regulator tps65911 [not found] ` <CAOesGMgYAR938F8PnVWaymzMBQwDKeAiUgEP81bv2nN14NmLGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-06-03 2:45 ` Rob Herring @ 2012-06-03 11:55 ` Mark Brown 1 sibling, 0 replies; 6+ messages in thread From: Mark Brown @ 2012-06-03 11:55 UTC (permalink / raw) To: Olof Johansson Cc: Stephen Warren, Laxman Dewangan, Stephen Warren, linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Grant Likely, Rob Herring [-- Attachment #1: Type: text/plain, Size: 386 bytes --] On Sat, Jun 02, 2012 at 02:19:57PM -0700, Olof Johansson wrote: > naming dependencies to only be under the regulators in question. In > particular, for things such as fixed regulators, they can be located > at other places in the device tree. I'm sorry, I can't parse this at all. What "naming dependencies" are you talking about? This is purely an issue for multi-regulator chips. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-06-03 18:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1337691917-15040-2-git-send-email-ldewangan@nvidia.com>
[not found] ` <4FBBC192.7030900@wwwdotorg.org>
[not found] ` <4FBBC830.2060802@nvidia.com>
[not found] ` <4FBBCA8F.3050903@wwwdotorg.org>
[not found] ` <4FBBD33C.8020802@nvidia.com>
[not found] ` <4FBBDA97.6000006@wwwdotorg.org>
[not found] ` <4FBBDE06.5080806@nvidia.com>
[not found] ` <4FC916AC.4060804@wwwdotorg.org>
[not found] ` <20120601204052.GB4258@opensource.wolfsonmicro.com>
[not found] ` <4FC92990.5030104@wwwdotorg.org>
[not found] ` <20120601210451.GC4258@opensource.wolfsonmicro.com>
[not found] ` <20120601210451.GC4258-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-06-02 21:19 ` [PATCH 2/2] ARM: dt: tegra: cardhu: register core regulator tps65911 Olof Johansson
[not found] ` <CAOesGMgYAR938F8PnVWaymzMBQwDKeAiUgEP81bv2nN14NmLGg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-06-03 2:45 ` Rob Herring
[not found] ` <4FCACFB6.2060601-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-06-03 12:05 ` Mark Brown
[not found] ` <20120603120506.GG4258-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
2012-06-03 16:11 ` Mitch Bradley
[not found] ` <4FCB8CA9.40602-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-06-03 18:37 ` Mark Brown
2012-06-03 11:55 ` Mark Brown
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).