From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Matt Sealey <matt@genesi-usa.com>
Cc: linuxppc-dev <Linuxppc-dev@ozlabs.org>,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: USB support on mpc5200 broken
Date: Wed, 01 Oct 2008 13:31:41 +1000 [thread overview]
Message-ID: <1222831901.12264.8.camel@pasglop> (raw)
In-Reply-To: <48E243C5.7000100@genesi-usa.com>
> This is what we were recommended to use at the time. There is a patch
> on www.powerdeveloper.org which tweaks the tree to make it ultra-compliant
> with the Linux version of things, which implements every variation. It
> also implements a suggested patch which added a "big-endian" property
> (not built in to the compatible property, but another property).
>
> I don't see why THAT patch got reverted as it was a great idea that we
> all agreed was a great idea.
I agree. Something needs to be fixed on the OHCI OF stuff, it should
definitely cope with the "big-endian" property (which is a practice
borrowed from Apple that I recommended I think back then) and I don't
see any problem with having ohci-be in the "compatible" property, its
trivial enough to cope in the driver and being anal about it on the
kernel side doesn't really bring any benefit.
Care to send a patch ?
> Linux development around here is getting really schizophrenic. Nobody
> is writing these decisions down even as comments in the source code..
That isn't entirely true. There's the ePAPR effort on power.org that is
codifying a lot of that, and there are binding documents dropped in
Documentation/powerpc.
> No; you can have little endian OHCI controllers on big endian machines.
> It's a property of the host controller, not the system architecture, just
> like PCI is always little endian (except when you have magic in hardware
> like Amiga PowerUP cards which endianswap for you :)
In fact, you can have both kinds on the same machine.
Note about the Amiga stuff: it's a bad idea :-) Every attempt at
"magically" fixing endian in HW is a recipe for tears and disasters.
Approximately ... always. The only cases that I know that have a remote
chance of being useful are specifically programmable swappers on a given
device or per-page endian configuration in the processor (like BooKE).
Cheers,
Ben.
next prev parent reply other threads:[~2008-10-01 3:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-24 21:51 USB support on mpc5200 broken Jon Smirl
2008-09-25 1:09 ` Jon Smirl
2008-09-25 1:50 ` Benjamin Herrenschmidt
2008-09-25 2:40 ` Jon Smirl
2008-09-29 1:30 ` Matt Sealey
2008-09-29 3:43 ` David Gibson
2008-09-29 14:14 ` Jon Smirl
2008-09-29 14:22 ` Peter Korsgaard
2008-09-29 14:28 ` Jon Smirl
2008-09-29 15:07 ` Peter Korsgaard
2008-09-29 20:18 ` Scott Wood
2008-09-29 21:04 ` Jon Smirl
2008-09-29 22:02 ` Grant Likely
2008-09-30 15:20 ` Matt Sealey
2008-10-01 3:31 ` Benjamin Herrenschmidt [this message]
2008-10-01 9:46 ` Carsten Schlote
2008-10-01 10:36 ` Benjamin Herrenschmidt
2008-10-06 21:06 ` Matt Sealey
2008-09-29 15:18 ` Sven Luther
2008-09-29 17:05 ` Peter Korsgaard
2008-09-30 1:12 ` David Gibson
2008-09-30 1:24 ` Raquel and Bill
2008-09-30 15:15 ` Matt Sealey
2008-11-03 15:41 ` Grant Likely
2008-11-03 16:21 ` Jon Smirl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1222831901.12264.8.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=Linuxppc-dev@ozlabs.org \
--cc=david@gibson.dropbear.id.au \
--cc=matt@genesi-usa.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).