USB support on mpc5200 broken

[Raquel and Bill]

..wasn't the real issue for the device tree to get the firmware right?

R&B

On Mon, Sep 29, 2008 at 8:12 PM, David Gibson
<david at gibson.dropbear.id.au> wrote:
> 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
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>



-- 
http://bbrv.blogspot.com/