purpose of /chosen node (was RE: [PATCH] powerpc: delete boot-cpu and chosen nodes from all DTSfiles)

[Yoder Stuart-B08248]

> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=freescale.com at ozlabs.org 
> [mailto:linuxppc-dev-bounces+b08248=freescale.com at ozlabs.org] 
> On Behalf Of Segher Boessenkool
> Sent: Wednesday, February 14, 2007 7:40 PM
> To: David Gibson
> Cc: linuxppc-dev at ozlabs.org; Tabi Timur-B04825
> Subject: Re: [PATCH] powerpc: delete boot-cpu and chosen 
> nodes from all DTSfiles
> 
> > 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.

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-- 
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