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.
