From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <23d2e4300809291824i16a20affk824777263fb4a19a@mail.gmail.com> Date: Mon, 29 Sep 2008 20:24:57 -0500 From: "Raquel and Bill" To: "Sven Luther" , "Matt Sealey" , linuxppc-dev Subject: Re: USB support on mpc5200 broken In-Reply-To: <20080930011234.GA6189@yookeroo.seuss> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <9e4733910809241451x7492d2a9s56b4cb4ee0fe0244@mail.gmail.com> <9e4733910809241809r58bddc2ax4759b70c3f07f6cf@mail.gmail.com> <1222307447.8277.147.camel@pasglop> <48E02FD0.8000809@genesi-usa.com> <20080929034329.GB8694@yookeroo.seuss> <20080929151854.GA29375@powerlinux.fr> <20080930011234.GA6189@yookeroo.seuss> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , ..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 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@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > -- http://bbrv.blogspot.com/