Quote:
maybe this little fix?
Code:
$ diff -ruN efika.forth-20071114 efika.forth-corsair
--- efika.forth-20071114 2007-11-14 16:30:18.000000000 +0100
+++ efika.forth-corsair 2008-01-23 20:27:21.487348076 +0100
@@ -98,7 +98,7 @@
\ as this is a destructive change
1 1 = if
s" /builtin/usb" find-device
- s" usb-ohci" device-type
+ s" mpc5200-ohci" device-type
s" " encode-string s" big-endian" property
s" mpc5200-ohci" encode-string
will test now.
EDIT: No, it doesn't work. Let's take a closer look at the code in ohci-ppc-of.c...
Okay, two hints.
ohci-ppc-of.c has two parts which detect the controller. One is the main compatibility list at the bottom of the file.
"ohci-bigendian" or "ohci-be" is what you want to look for here.
Then there is the quirks list, which determines if the frame number quirk is needed. "mpc5200-ohci" is what is checked here.
So, the compatibility property should include both of those. In fact, I am fairly sure both of these are already in the compatibility property for the Efika anyway.
What has happened here is 2.6.24 has not included the work in the patchset that I intended to support;
http://patchwork.ozlabs.org/linuxppc/pa ... f&id=14380
The addition of the big-endian property or the rationalisation of ohci to usb-ohci (since FireWire also calls it's controllers ohci, it's confusing). Then there is the rationalisation of properties proposed by Jon Smirl (which I sort of agree with) so just in case we should include those, and of course Linux developers think the "device_type" property is an irrelevance these days, so we should duplicate the expected value in "compatible" just to make sure we are REALLY future proof.
I guess, the recommended property list would be:
usb-ohci, ohci-bigendian, ohci-be, mpc5200-ohci, mpc5200b-ohci, mpc5200-usb-ohci, mpc5200b-usb-ohci, fsl,mpc5200b-usb-ohci and fsl,mpc5200-usb-ohci.
And the big-endian property. That'll fix everything, including any future patches.
Code:
\ New USB binding
s" /builtin/usb" find-device
s" usb-ohci" device-type
s" " encode-string s" big-endian" property
s" fsl,mpc5200b" s" model" property
\ may I just say that Linux really, really sucks?
s" mpc5200-ohci" encode-string
s" mpc5200-usb-ohci" encode-string encode+
s" usb-ohci" encode-string encode+
s" ohci-bigendian" encode-string encode+
s" ohci-be" encode-string encode+
s" mpc5200-ohci" encode-string encode+
s" mpc5200b-ohci" encode-string encode+
s" mpc5200-usb-ohci" encode-string encode+
s" mpc5200b-usb-ohci" encode-string encode+
s" fsl,mpc5200b-usb-ohci" encode-string encode+
s" fsl,mpc5200b-usb-ohci" encode-string encode+
s" compatible" property
device-end
Best practise and non-moronic driver design should really be checking for "compatible" of usb-ohci, the "big-endian" property, and selecting the mpc5200 quirk based on a "model" property if present. However, Linux developers usually don't consider the greater ramifications of their choices beyond the scope of the patch they submit, and simply code what they like and what works for now, then patches are accepted without much review, boards are designed around these device trees and we are stuck with property lists that go on forever even though subsequent code audits reveal that the ideas were unsound.
This is what you get for playing the Linux game. Do you understand now why we do not release firmware updates too often? Things have to settle down or we run the risk of some patch we missed, or some decision by a developer 30 days after firmware release, breaking our Linux support.
As for the Forth query,
s" is a synonym for
" - it begins the definition of a string. I consider the single quote rather weird and makes the code less readable, so I use s" simply so that it is more evident that this is the start of a string.