From: Timur Tabi <hidden> Date: 2007-02-13 16:47:25
The 'linux,boot-cpu' property and the 'chosen' node do not belong in the
DTS file, because U-Boot creates these entries in the device tree when
it boots linux.
Signed-off-by: Timur Tabi <redacted>
---
arch/powerpc/boot/dts/kuroboxHG.dts | 1 -
arch/powerpc/boot/dts/mpc7448hpc2.dts | 5 ++---
arch/powerpc/boot/dts/mpc8272ads.dts | 8 --------
arch/powerpc/boot/dts/mpc8323emds.dts | 7 +++----
arch/powerpc/boot/dts/mpc8360emds.dts | 1 -
arch/powerpc/boot/dts/mpc8560ads.dts | 1 -
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 3 +--
arch/powerpc/boot/dts/mpc866ads.dts | 1 -
arch/powerpc/boot/dts/mpc885ads.dts | 1 -
9 files changed, 6 insertions(+), 22 deletions(-)
From: Kumar Gala <hidden> Date: 2007-02-13 17:17:37
On Feb 13, 2007, at 10:47 AM, Timur Tabi wrote:
The 'linux,boot-cpu' property and the 'chosen' node do not belong
in the
DTS file, because U-Boot creates these entries in the device tree when
it boots linux.
Signed-off-by: Timur Tabi <redacted>
---
Is there some harm is having them set in the .dts?
I can see 'linux,boot-cpu' may vary on a SMP, but the majority
of .dts's are for uniproc's
- k
From: Timur Tabi <hidden> Date: 2007-02-13 17:20:51
Kumar Gala wrote:
On Feb 13, 2007, at 10:47 AM, Timur Tabi wrote:
quoted
The 'linux,boot-cpu' property and the 'chosen' node do not belong in the
DTS file, because U-Boot creates these entries in the device tree when
it boots linux.
Signed-off-by: Timur Tabi <redacted>
---
Is there some harm is having them set in the .dts?
Well, I don't think a DTS should contain a property that isn't going to be used.
It might convince people that the property belongs there.
The 'chosen' section is absent from all but one DTS for the same reason.
I can see 'linux,boot-cpu' may vary on a SMP, but the majority of .dts's
are for uniproc's
U-Boot sets it, so whatever the DTS contains is ignored.
--
Timur Tabi
Linux Kernel Developer @ Freescale
From: Timur Tabi <hidden> Date: 2007-02-13 19:33:55
Kumar Gala wrote:
On Feb 13, 2007, at 10:47 AM, Timur Tabi wrote:
quoted
The 'linux,boot-cpu' property and the 'chosen' node do not belong in the
DTS file, because U-Boot creates these entries in the device tree when
it boots linux.
Signed-off-by: Timur Tabi <redacted>
---
Is there some harm is having them set in the .dts?
Actually, I just found out that the boot-cpu property is obsolete. Instead, the
boot CPU is specified in the device tree header, and DTC will complain if it
sees linux,boot-cpu.
With that in mind, I'm going to respin this patch to include a change in
booting-without-of.txt.
--
Timur Tabi
Linux Kernel Developer @ Freescale
From: David Gibson <hidden> Date: 2007-02-14 00:31:19
On Tue, Feb 13, 2007 at 10:47:19AM -0600, Timur Tabi wrote:
The 'linux,boot-cpu' property and the 'chosen' node do not belong in the
DTS file, because U-Boot creates these entries in the device tree when
it boots linux.
Um.. at least the interrupt-controller property here should be fixed,
and thus should probably remain in the dts.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Um.. at least the interrupt-controller property here should be fixed,
and thus should probably remain in the dts.
Can you be more specific? I'm not familiar with this board, so I don't
really know what you're talking about.
The interrupt-controller property in /chosen just points to the
system's top-level interrupt controller to make it easier for the
kernel to find in the tree. I think most platforms don't actually
need or use it at present, but booting-without-of does recommend it.
As such it's a property of the board, not something which will change
from boot to boot. It would therefore be rather strange for the
bootloader to poke this property.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Timur Tabi <hidden> Date: 2007-02-14 14:05:43
David Gibson wrote:
The interrupt-controller property in /chosen just points to the
system's top-level interrupt controller to make it easier for the
kernel to find in the tree. I think most platforms don't actually
need or use it at present, but booting-without-of does recommend it.
As such it's a property of the board, not something which will change
from boot to boot. It would therefore be rather strange for the
bootloader to poke this property.
That's all the more reason to delete the 'chosen' section, isn't it?
Sicne it's wrong, deleting the entire section will just make the problem
go away. Or am I missing something?
From: David Gibson <hidden> Date: 2007-02-14 23:33:48
On Wed, Feb 14, 2007 at 08:05:40AM -0600, Timur Tabi wrote:
David Gibson wrote:
quoted
The interrupt-controller property in /chosen just points to the
system's top-level interrupt controller to make it easier for the
kernel to find in the tree. I think most platforms don't actually
need or use it at present, but booting-without-of does recommend it.
As such it's a property of the board, not something which will change
from boot to boot. It would therefore be rather strange for the
bootloader to poke this property.
That's all the more reason to delete the 'chosen' section, isn't it?
Sicne it's wrong, deleting the entire section will just make the problem
go away. Or am I missing something?
Er.. I think you're missing something.
My point is that the interrupt-controller property in /chosen *should*
be there, but it doesn't make a lot of sense for it to be set by the
bootloader (because it's a fixed property of the board). Therefore it
should be in the dts, therefore the /chosen node needs to be there to
contain it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Timur Tabi <hidden> Date: 2007-02-14 23:47:25
David Gibson wrote:
Er.. I think you're missing something.
My point is that the interrupt-controller property in /chosen *should*
be there, but it doesn't make a lot of sense for it to be set by the
bootloader (because it's a fixed property of the board). Therefore it
should be in the dts, therefore the /chosen node needs to be there to
contain it.
Ok, I understand.
Well, as soon as my other DTS-related patches are applied, I'll start working on
one for the 'chosen' section.
--
Timur Tabi
Linux Kernel Developer @ Freescale
My point is that the interrupt-controller property in /chosen *should*
be there, but it doesn't make a lot of sense for it to be set by the
bootloader (because it's a fixed property of the board).
And that means it shouldn't be in /chosen at all. It's not
just a fixed property of the board, it is a physical property
of the board. It doesn't belong in /chosen.
Segher
Is there some harm is having them set in the .dts?
I can see 'linux,boot-cpu' may vary on a SMP, but the majority
of .dts's are for uniproc's
The way this is handled in the OF binding, only multi-processor
systems are required to explicitly state their boot CPU (in
/chosen/cpu). It's quite silly to require this for single
CPU systems.
Segher
From: Timur Tabi <hidden> Date: 2007-02-15 16:18:55
David Gibson wrote:
My point is that the interrupt-controller property in /chosen *should*
be there, but it doesn't make a lot of sense for it to be set by the
bootloader (because it's a fixed property of the board). Therefore it
should be in the dts, therefore the /chosen node needs to be there to
contain it.
Ok, I've added that to my to-do list.
--
Timur Tabi
Linux Kernel Developer @ Freescale
-----Original Message-----
From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
[mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
On Behalf Of Segher Boessenkool
Sent: Wednesday, February 14, 2007 7:40 PM
To: David Gibson
Cc: linuxppc-dev@ozlabs.org; Tabi Timur-B04825
Subject: Re: [PATCH] powerpc: delete boot-cpu and chosen=20
nodes from all DTSfiles
=20
quoted
My point is that the interrupt-controller property in=20
/chosen *should*
quoted
be there, but it doesn't make a lot of sense for it to be set by the
bootloader (because it's a fixed property of the board).
=20
And that means it shouldn't be in /chosen at all. It's not
just a fixed property of the board, it is a physical property
of the board. It doesn't belong in /chosen.
I agree with Segher here. The interrupt-controller property doesn't
belong in /chosen.
The 1275 OF spec says about /chosen:
Has properties describing parameters chosen or specified at
runtime.
The typical properties are boot device, boot args, console, etc--=20
i.e. dynamic stuff set by software and not describing the physical
hardware.
I think we should stick with this definition. Separating the
dynamic properties set by firmware with physical properties of
board is cleaner and follows the original intent of /chosen.
If the kernel needs a convenient place to keep a phandle to the
top level interrupt controller, how about just under root?
(Or, we could make up a new node)
If we can remove physical board dependencies from /chosen then
we could also remove it from the DTS files and require that firmware
set up /chosen.
For obscure cases where firmware can't do this for some reason,
the developer can simply add a /chosen section to his private
DTS file.
Thoughts?
Stuart Yoder
From: Kumar Gala <hidden> Date: 2007-02-15 21:40:14
On Feb 15, 2007, at 3:26 PM, Yoder Stuart-B08248 wrote:
quoted
-----Original Message-----
From: linuxppc-dev-bounces+b08248=freescale.com@ozlabs.org
[mailto:linuxppc-dev-bounces+b08248=freescale.com@ozlabs.org]
On Behalf Of Segher Boessenkool
Sent: Wednesday, February 14, 2007 7:40 PM
To: David Gibson
Cc: linuxppc-dev@ozlabs.org; Tabi Timur-B04825
Subject: Re: [PATCH] powerpc: delete boot-cpu and chosen
nodes from all DTSfiles
quoted
My point is that the interrupt-controller property in
/chosen *should*
quoted
be there, but it doesn't make a lot of sense for it to be set by the
bootloader (because it's a fixed property of the board).
And that means it shouldn't be in /chosen at all. It's not
just a fixed property of the board, it is a physical property
of the board. It doesn't belong in /chosen.
I agree with Segher here. The interrupt-controller property doesn't
belong in /chosen.
The 1275 OF spec says about /chosen:
Has properties describing parameters chosen or specified at
runtime.
I want to reiterate something Paul mentioned, any similarity that the
device tree has to 1275 is strictly coincidental.
- k
-----Original Message-----
From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
Sent: Thursday, February 15, 2007 3:39 PM
To: Yoder Stuart-B08248
Cc: Segher Boessenkool; Benjamin Herrenschmidt;=20
linuxppc-dev@ozlabs.org
Subject: Re: purpose of /chosen node (was RE: [PATCH]=20
powerpc: delete boot-cpu and chosen nodes from all DTSfiles)
=20
=20
On Feb 15, 2007, at 3:26 PM, Yoder Stuart-B08248 wrote:
quoted
quoted
-----Original Message-----
From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org
[mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]
On Behalf Of Segher Boessenkool
Sent: Wednesday, February 14, 2007 7:40 PM
To: David Gibson
Cc: linuxppc-dev@ozlabs.org; Tabi Timur-B04825
Subject: Re: [PATCH] powerpc: delete boot-cpu and chosen
nodes from all DTSfiles
quoted
My point is that the interrupt-controller property in
/chosen *should*
quoted
be there, but it doesn't make a lot of sense for it to be=20
set by the
quoted
quoted
quoted
bootloader (because it's a fixed property of the board).
And that means it shouldn't be in /chosen at all. It's not
just a fixed property of the board, it is a physical property
of the board. It doesn't belong in /chosen.
I agree with Segher here. The interrupt-controller property doesn't
belong in /chosen.
The 1275 OF spec says about /chosen:
Has properties describing parameters chosen or specified at
runtime.
=20
I want to reiterate something Paul mentioned, any similarity=20
that the =20
device tree has to 1275 is strictly coincidental.
I understand that point, but mixing the types of properties in
/chosen doesn't buy us anything. We shouldn't be shackled by
the 1275 spec, but having nodes like /chosen with designated
purpose architecturally make sense.
/chosen shouldn't be a catch-all or a convenient place to stick
stuff. I think in this case following 1275 is a good thing.
Stuart
From: David Gibson <hidden> Date: 2007-02-15 23:01:34
On Thu, Feb 15, 2007 at 02:26:41PM -0700, Yoder Stuart-B08248 wrote:
quoted
-----Original Message-----
From: linuxppc-dev-bounces+b08248=freescale.com@ozlabs.org
[mailto:linuxppc-dev-bounces+b08248=freescale.com@ozlabs.org]
On Behalf Of Segher Boessenkool
Sent: Wednesday, February 14, 2007 7:40 PM
To: David Gibson
Cc: linuxppc-dev@ozlabs.org; Tabi Timur-B04825
Subject: Re: [PATCH] powerpc: delete boot-cpu and chosen
nodes from all DTSfiles
quoted
My point is that the interrupt-controller property in
/chosen *should*
quoted
be there, but it doesn't make a lot of sense for it to be set by the
bootloader (because it's a fixed property of the board).
And that means it shouldn't be in /chosen at all. It's not
just a fixed property of the board, it is a physical property
of the board. It doesn't belong in /chosen.
I agree with Segher here. The interrupt-controller property doesn't
belong in /chosen.
You're right. Question is, can we change it now. It's out there in
the documentation, on the other hand, I don't think the kernel
actually uses it anywhere yet. BenH, opinion?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-02-16 00:08:39
You're right. Question is, can we change it now. It's out there in
the documentation, on the other hand, I don't think the kernel
actually uses it anywhere yet. BenH, opinion?
We can change the documentation and add a little note about "obsoleted
practice". I don't think the kernel uses it.
Ben.
If the kernel needs a convenient place to keep a phandle to the
top level interrupt controller,
Well that's the first point: the kernel doesn't need this
at all, it can derive this from the rest of the tree easy
enough.
how about just under root?
CHRP does this (in an extra-plus nasty way).
(Or, we could make up a new node)
Duplicate node? No way. You can be flexible with adding
extra properties, but every node should represent a (pseudo-)
device, and every device in the system should be represented
by exactly one node.
Or you could make the convention that /aliases/interrupt-controller
points to the root interrupt controller, if you really
think you want this.
Segher
I want to reiterate something Paul mentioned, any similarity that the
device tree has to 1275 is strictly coincidental.
I'm sure you know it is not coincidental.
Now you can of course do things in a different way if
you really feel the need to, but please do it in a
non-overlapping way then. So, don't reuse /chosen
for something else than what it is meant for in OF,
etc.
Segher
I understand that point, but mixing the types of properties in
/chosen doesn't buy us anything. We shouldn't be shackled by
the 1275 spec,
Sure, you have some special needs, and some ways in which
the flat tree just _is_ different from an OF device tree;
for example, you don't have instances and ihandles.
Still it doesn't help anyone (and will in fact hurt
everyone) if people start to introduce random incompatibilities
for no good reason at all.
but having nodes like /chosen with designated
purpose architecturally make sense.
Yes. And since this node already has a well-defined
purpose in OF, you better use it for that purpose only
and make a /flattree/grabbag node for your random stuff.
/chosen shouldn't be a catch-all or a convenient place to stick
stuff. I think in this case following 1275 is a good thing.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-02-16 09:54:51
On Fri, 2007-02-16 at 08:30 +0100, Segher Boessenkool wrote:
quoted
If the kernel needs a convenient place to keep a phandle to the
top level interrupt controller,
Well that's the first point: the kernel doesn't need this
at all, it can derive this from the rest of the tree easy
enough.
Not that easy. I beleive it's better to have it expressed explicitely.
quoted
how about just under root?
CHRP does this (in an extra-plus nasty way).
quoted
(Or, we could make up a new node)
Duplicate node? No way. You can be flexible with adding
extra properties, but every node should represent a (pseudo-)
device, and every device in the system should be represented
by exactly one node.
Or you could make the convention that /aliases/interrupt-controller
points to the root interrupt controller, if you really
think you want this.
-----Original Message-----
From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]=20
Sent: Thursday, February 15, 2007 6:09 PM
To: David Gibson
Cc: Yoder Stuart-B08248; Segher Boessenkool; linuxppc-dev@ozlabs.org
Subject: Re: purpose of /chosen node (was RE: [PATCH]=20
powerpc: deleteboot-cpu and chosen nodes from all DTSfiles)
=20
=20
quoted
You're right. Question is, can we change it now. It's out there in
the documentation, on the other hand, I don't think the kernel
actually uses it anywhere yet. BenH, opinion?
=20
We can change the documentation and add a little note about "obsoleted
practice". I don't think the kernel uses it.
=20
I'll submit a patch to booting-without-of.txt for this.
Stuart
From: Kumar Gala <hidden> Date: 2007-02-16 17:01:09
On Feb 16, 2007, at 10:58 AM, Yoder Stuart-B08248 wrote:
quoted
-----Original Message-----
From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]
Sent: Thursday, February 15, 2007 6:09 PM
To: David Gibson
Cc: Yoder Stuart-B08248; Segher Boessenkool; linuxppc-dev@ozlabs.org
Subject: Re: purpose of /chosen node (was RE: [PATCH]
powerpc: deleteboot-cpu and chosen nodes from all DTSfiles)
quoted
You're right. Question is, can we change it now. It's out there in
the documentation, on the other hand, I don't think the kernel
actually uses it anywhere yet. BenH, opinion?
We can change the documentation and add a little note about
"obsoleted
practice". I don't think the kernel uses it.
I'll submit a patch to booting-without-of.txt for this.
Need to also update dtc not to "warn" about it.
- k