[PATCH] Add USB to MPC8349 PB platform support

[Li Yang-r58472]

> -----Original Message-----
> From: Kumar Gala [mailto:galak at kernel.crashing.org]
> Sent: Tuesday, July 18, 2006 5:39 AM
> To: Dan Malek
> Cc: Li Yang-r58472; linuxppc-dev at ozlabs.org;
linux-usb-devel at lists.sourceforge.net
> Subject: Re: [PATCH] Add USB to MPC8349 PB platform support
> 
> 
> On Jul 17, 2006, at 3:17 PM, Dan Malek wrote:
> 
> >
> > On Jul 17, 2006, at 3:16 PM, Kumar Gala wrote:
> >
> >> I disagree.  You are coming from this from a board that does
> >> everything under the sun.  I'd like to avoid having this type of
> >> initialization in the kernel.  There is a whole additional kitchen
> >> sink that could move into the kernel as well.
> >
> > Well, I'm going to have to disagree with your disagreement :-)
> > The kernel should not assume things are properly initialized
> > and rely on the boot rom to do such things.  I have several
> > reasons for this.  One is that we are always pressed to make
> > embedded systems boot more quickly, and taking time to
> > initialize things in the boot rom just makes that a totally
> > inflexible system design.  We don't need to initialize things
> > we don't use, or can postpone until later.  Two, it makes
> > us dependent upon a particular boot rom, or boot rom
> > behavior, that not all boards may choose to support.
> > Three, board designs may have external logic that requires
> > a certain start up sequence or control register access
> > that complicates the boot rom in it's ability to share
> > code or implementation.
> 
> Well, I think there is a coupling that exists between whatever your
> boot rom is and the kernel.  If you are trying to optimize boot time
> I'd say one thing you would want is to avoid multiple writing the
> same configuration registers.
> 
> I dont have an issue if a fixed function board decides to do these
> things in their kernel init instead of their boot rom.  I however,
> don't want thousand and one config options to support all the various
> ways one can configure the Freescale board.

We won't have the thousand and one config options, making use of the
device
tree.  So this is not a problem.
> 
> > There are more, but I think you see the trend.  In my
> > years of doing this kind of development, you can't
> > assume a boot rom is going to do much more than initialize
> > memory and load the kernel.  I prefer the flexibility
> > to be in the kernel, and not in the boot rom, because it
> > is so much easier to develop and control.
> 
> - kumar