* "magic" handling of memory nodes
@ 2014-04-24 11:33 ` Leif Lindholm
0 siblings, 0 replies; 6+ messages in thread
From: Leif Lindholm @ 2014-04-24 11:33 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
grant.likely-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Hi,
Following on the special handling of nodes called memory@0, I went to
have a look at the various platforms that do not actually declare a
device_type = "memory" for their "memory" nodes.
Firstly, we currently have 162(ish, I did a sloppy grep) such .dts{i}
files in the kernel tree.
Secondly, the only reason these platforms could ever have worked is
because they include .dtsi files that define a memory node with a
type explicitly set. Since this node already exists, its contents get
overridden, but the type tag remains. Of course, this only happens
with nodes called explicitly "memory" - but it happens regardless of
what other things they contain.
In the ARM tree, most of these seem to stem from the inclusion of
skeleton.dtsi.
I don't really know what could/should be done about this, but it
does not feel optimal.
/
Leif
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* "magic" handling of memory nodes
@ 2014-04-24 11:33 ` Leif Lindholm
0 siblings, 0 replies; 6+ messages in thread
From: Leif Lindholm @ 2014-04-24 11:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Following on the special handling of nodes called memory at 0, I went to
have a look at the various platforms that do not actually declare a
device_type = "memory" for their "memory" nodes.
Firstly, we currently have 162(ish, I did a sloppy grep) such .dts{i}
files in the kernel tree.
Secondly, the only reason these platforms could ever have worked is
because they include .dtsi files that define a memory node with a
type explicitly set. Since this node already exists, its contents get
overridden, but the type tag remains. Of course, this only happens
with nodes called explicitly "memory" - but it happens regardless of
what other things they contain.
In the ARM tree, most of these seem to stem from the inclusion of
skeleton.dtsi.
I don't really know what could/should be done about this, but it
does not feel optimal.
/
Leif
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "magic" handling of memory nodes
2014-04-24 11:33 ` Leif Lindholm
@ 2014-04-24 16:57 ` Stephen Warren
-1 siblings, 0 replies; 6+ messages in thread
From: Stephen Warren @ 2014-04-24 16:57 UTC (permalink / raw)
To: Leif Lindholm, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
grant.likely-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
On 04/24/2014 05:33 AM, Leif Lindholm wrote:
> Hi,
>
> Following on the special handling of nodes called memory@0, I went to
> have a look at the various platforms that do not actually declare a
> device_type = "memory" for their "memory" nodes.
>
> Firstly, we currently have 162(ish, I did a sloppy grep) such .dts{i}
> files in the kernel tree.
>
> Secondly, the only reason these platforms could ever have worked is
> because they include .dtsi files that define a memory node with a
> type explicitly set. Since this node already exists, its contents get
> overridden, but the type tag remains. Of course, this only happens
> with nodes called explicitly "memory" - but it happens regardless of
> what other things they contain.
That's precisely how DT includes/overrides are supposed to work, and is
entirely expected and normal.
Since skeleton.dtsi already says:
memory { device_type = "memory"; reg = <0 0>; };
... then any .dts which includes that already has the device_type
property set, so there's no need to repeat that property. Subsequent
changes to /memory/reg have no impact on /memory/device_type; any new
node definitions simply over-write any previous definitions of a
redefined property, but leave unmentioned properties unchanged (unless
you /delete-property/).
If skeleton.dtsi were changed to remove that property then yes a lot of
files would then need to set it, but why would it be removed?
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* "magic" handling of memory nodes
@ 2014-04-24 16:57 ` Stephen Warren
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Warren @ 2014-04-24 16:57 UTC (permalink / raw)
To: linux-arm-kernel
On 04/24/2014 05:33 AM, Leif Lindholm wrote:
> Hi,
>
> Following on the special handling of nodes called memory at 0, I went to
> have a look at the various platforms that do not actually declare a
> device_type = "memory" for their "memory" nodes.
>
> Firstly, we currently have 162(ish, I did a sloppy grep) such .dts{i}
> files in the kernel tree.
>
> Secondly, the only reason these platforms could ever have worked is
> because they include .dtsi files that define a memory node with a
> type explicitly set. Since this node already exists, its contents get
> overridden, but the type tag remains. Of course, this only happens
> with nodes called explicitly "memory" - but it happens regardless of
> what other things they contain.
That's precisely how DT includes/overrides are supposed to work, and is
entirely expected and normal.
Since skeleton.dtsi already says:
memory { device_type = "memory"; reg = <0 0>; };
... then any .dts which includes that already has the device_type
property set, so there's no need to repeat that property. Subsequent
changes to /memory/reg have no impact on /memory/device_type; any new
node definitions simply over-write any previous definitions of a
redefined property, but leave unmentioned properties unchanged (unless
you /delete-property/).
If skeleton.dtsi were changed to remove that property then yes a lot of
files would then need to set it, but why would it be removed?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: "magic" handling of memory nodes
2014-04-24 16:57 ` Stephen Warren
@ 2014-04-25 10:44 ` Leif Lindholm
-1 siblings, 0 replies; 6+ messages in thread
From: Leif Lindholm @ 2014-04-25 10:44 UTC (permalink / raw)
To: Stephen Warren
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
grant.likely-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
On Thu, Apr 24, 2014 at 10:57:03AM -0600, Stephen Warren wrote:
> > Secondly, the only reason these platforms could ever have worked is
> > because they include .dtsi files that define a memory node with a
> > type explicitly set. Since this node already exists, its contents get
> > overridden, but the type tag remains. Of course, this only happens
> > with nodes called explicitly "memory" - but it happens regardless of
> > what other things they contain.
>
> That's precisely how DT includes/overrides are supposed to work, and is
> entirely expected and normal.
Understood.
> Since skeleton.dtsi already says:
>
> memory { device_type = "memory"; reg = <0 0>; };
>
> ... then any .dts which includes that already has the device_type
> property set, so there's no need to repeat that property. Subsequent
> changes to /memory/reg have no impact on /memory/device_type; any new
> node definitions simply over-write any previous definitions of a
> redefined property, but leave unmentioned properties unchanged (unless
> you /delete-property/).
>
> If skeleton.dtsi were changed to remove that property then yes a lot of
> files would then need to set it, but why would it be removed?
Thank you for the explanation.
All of the device trees with memory@ nodes do explicitly specify the
device_type.
I do still find the setup (as opposed to the mechanism) somewhat
counterintuituve. The effect is pretty much that of a potentially
architecture-specific magic keyword.
/
Leif
--
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* "magic" handling of memory nodes
@ 2014-04-25 10:44 ` Leif Lindholm
0 siblings, 0 replies; 6+ messages in thread
From: Leif Lindholm @ 2014-04-25 10:44 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 24, 2014 at 10:57:03AM -0600, Stephen Warren wrote:
> > Secondly, the only reason these platforms could ever have worked is
> > because they include .dtsi files that define a memory node with a
> > type explicitly set. Since this node already exists, its contents get
> > overridden, but the type tag remains. Of course, this only happens
> > with nodes called explicitly "memory" - but it happens regardless of
> > what other things they contain.
>
> That's precisely how DT includes/overrides are supposed to work, and is
> entirely expected and normal.
Understood.
> Since skeleton.dtsi already says:
>
> memory { device_type = "memory"; reg = <0 0>; };
>
> ... then any .dts which includes that already has the device_type
> property set, so there's no need to repeat that property. Subsequent
> changes to /memory/reg have no impact on /memory/device_type; any new
> node definitions simply over-write any previous definitions of a
> redefined property, but leave unmentioned properties unchanged (unless
> you /delete-property/).
>
> If skeleton.dtsi were changed to remove that property then yes a lot of
> files would then need to set it, but why would it be removed?
Thank you for the explanation.
All of the device trees with memory@ nodes do explicitly specify the
device_type.
I do still find the setup (as opposed to the mechanism) somewhat
counterintuituve. The effect is pretty much that of a potentially
architecture-specific magic keyword.
/
Leif
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-04-25 10:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-24 11:33 "magic" handling of memory nodes Leif Lindholm
2014-04-24 11:33 ` Leif Lindholm
[not found] ` <20140424113311.GR5904-t77nlHhSwNqAroYi2ySoxKxOck334EZe@public.gmane.org>
2014-04-24 16:57 ` Stephen Warren
2014-04-24 16:57 ` Stephen Warren
[not found] ` <5359425F.9090200-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2014-04-25 10:44 ` Leif Lindholm
2014-04-25 10:44 ` Leif Lindholm
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.