If this is really a question of needing to dynamically generate the device tree, then you have no choice. It's worth mentioning, though, that the device tree compiler (dtc) does have the ability to include files, making it easier to create and maintain device trees that are static but which share devices. > -----Original Message----- > From: linux-mips-bounce@xxxxxxxxxxxxxx [mailto:linux-mips-bounce@linux- > mips.org] On Behalf Of Grant Likely > Sent: Thursday, October 14, 2010 6:29 PM > To: Warner Losh > Cc: ddaney@xxxxxxxxxxxxxxxxxx; prasun.kapoor@xxxxxxxxxxxxxxxxxx; linux- > mips@xxxxxxxxxxxxxx; devicetree-discuss@xxxxxxxxxxxxxxxx > Subject: Re: Device Tree questions WRT MIPS/Octeon SOCs. > > On Thu, Oct 14, 2010 at 7:13 PM, Warner Losh <imp@xxxxxxxxxx> wrote: > > In message: <AANLkTi=UM2p26JJMqv- > cNh8xACS_KPf_dCst5cgmh5VR@xxxxxxxxxxxxxx> > > Grant Likely <grant.likely@xxxxxxxxxxxx> writes: > > : Overall the plan makes sense, however I would suggest the > following. > > : instead of 'live' modifying the tree, another option is to carry a > set > > : of 'stock' device trees in the kernel; one per board. Of course > this > > : assumes that your current ad-hoc code is keying on the specific > board. > > : If it is interpreting data provided by the firmware, then your > > : suggestion of modifying a single stock tree probably makes more > sense, > > : or possibly a combination of the too. In general you should avoid > > : live modification as much as possible. > > > > The one draw back on this is that there's lots of different "stock" > > boards that the Cavium Octeon SDK supports. These will be difficult > > to drag along for every kernel. And they'd be mostly the same to, > > which is why I think that David is suggesting the live modification > > thing... > > Okay. Do what makes the most sense for your platform. > > g.
