[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 9:53 PM
> To: Li Yang-r58472
> Cc: Dan Malek; linuxppc-dev at ozlabs.org;
linux-usb-devel at lists.sourceforge.net
> Subject: Re: [PATCH] Add USB to MPC8349 PB platform support
> 
> [snip]
> 
> >> 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.
> 
> I'm talking about opening the door to a ton of options, not that we
> have them now.  For example, your patch doesnt handle the USB PHYs if
> they are on the MDS instead of the SYS board.  It doesn't handle
> setting SCCR properly for different frequency choices.  I'm concerned
> about where to draw the line because of all the ways a user can
> configure the MDS board.

My understanding is that in embedded world only this kind of versatile
development boards needs to have Linux port in mainstream kernel.  A
fixed function customer board used in embedded product will never get
into kernel source.

The reasons for Freescale to provide this kind of boards are: first,
verify functions on chip; second, demonstrate chip functions to
customer; third, validate customer application on reference board;
forth, help customer to build their own product by cutting down the
board and software.

Doing that, we do need some configure options to demonstrate main
functions.  But there won't be too many options to confuse the user.
Only key working modes are needed.  In your example, I think making USB
PHYs configurable for MDS is reasonable, but for SCCR it isn't as it is
well commented in code and is not likely to be modified.  Keep in mind
that our only purpose is making customers easier and faster in
developing their own products.
> 
> - kumar