USB support on mpc5200 broken

[David Gibson]

On Mon, Sep 29, 2008 at 05:18:54PM +0200, Sven Luther wrote:
> On Mon, Sep 29, 2008 at 01:43:29PM +1000, David Gibson wrote:
> > On Sun, Sep 28, 2008 at 08:30:56PM -0500, Matt Sealey wrote:
> > >
> > > Benjamin Herrenschmidt wrote:
> > >> On Wed, 2008-09-24 at 21:09 -0400, Jon Smirl wrote:
> > >>>> Last time I noticed it was working was about ten days ago. I don't use
> > >>>> it everyday.
> > >>> Efika is broken because of this:
> > >>>
> > >>> ohci-ppc-of.c...
> > >>> 	is_bigendian =
> > >>> 		of_device_is_compatible(dn, "ohci-bigendian") ||
> > >>> 		of_device_is_compatible(dn, "ohci-be");
> > >>>
> > >>> Efika doesn't have either of those in it's compatible string.
> > >>>
> > >>> This doesn't look to me like a very reliable way to determine bigendian.
> > >>
> > >> You mean it's not reliable to expect people device-trees not to
> > >> suck ? :-)
> > 
> > Alas, this is true :(.
> > 
> > > It's reasonable to expect that device-trees do not get updated with the
> > > kernel for certain platforms (it does not fit into most quality assurance
> > > schedules to reflash every user's firmware every time they want to move up
> > > one revision to another, given the kernel release schedule of every 3-4
> > > months) and when updating the search for compatible entries it should
> > > take into account these platforms.
> > 
> > This, of course, is exactly why I *don't* recommend embedded platforms
> > move to including the device tree in the flashed firmware.  Keeping
> > the device tree in the bootwrapper means that it *is* updated with the
> > kernel and we don't have to mess around with as much backwards
> > compatibility junk.
> 
> This completely defeats the purpopse of having a separate device tree
> though, no ? I mean, we could just as well hardcode the device-tree info
> in the kernel in this case ? 

And just what form would "hardcoded" device info take in the kernel?
The *primary* purpose of the device-tree is to have a consistent
in-kernel representation of the hardware information.  A device-tree
was the obvious choice, because OF machines already used it, and it's
flexible enough to cover pretty much anything.

How the kernel gets a device tree doesn't matter so much - we don't
really care if it comes from OF, from some other firmware or if it's
built into the kernel or wrapper.

Being able to pass in the device tree is a secondary advantage in
*some* circumstances - albeit one people seem to have leapt on with
unwise enthusiasm, IMO.  This approachd also has drawbacks which can
override the advantages - specifically that firmware has always been
buggy as hell more often than not, so there's absolutely no reason to
expect that firmware will get a device tree right.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson