USB code, as usual, is in development.
Summary:
In general, for the USB code, we need to address
o endianess
o 32/64-bit
o SMP/UP
o asm-code
~Randy
> -----Original Message-----
> From: Stefan Reinauer [mailto:stepan@suse.de]
> Sent: Wednesday, October 20, 1999 4:11 PM
> To: Dunlap, Randy
> Cc: linux-usb@suse.com; kernel@suse.de; Bernd Kaindl; Vojtech Pavlik
> Subject: RE: [kernel] RE: [linux-usb] Backport of USB to v2.2 kernel
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> On 18-Oct-99 Dunlap, Randy wrote:
> > I have used this successfully.
> >
> > I think it's fine the way just the way it is.
> >
> > ~Randy
>
> Oops. I've got one of those little USB-Bridges on a PCI card
> which I was told
> to work nicely with Linux' usb/uhci driver.
> Since I want to run a stable kernel on my development Alpha
> AXP machine, I tried
> Vojtechs usb-2.2 backport (which doesn't matter anyway, since
> after I had a
> look at it, I am sure that this didn't cause my problems)
>
> 1.) I saw that the USB/UHCI driver uses Intel assembly in
> uhci.c in two
> places. I personally do not think it is a wise decision
> to use assembly code
> in device drivers when it is not really neccessary (I
> wouldn't see, why it
> is here)
> As far as I can see, the asm code is used to do some kind
> of locked pointer
> validation for some DMA reason.
>
> The first occurance is in uhci_insert_tds_in_qh(), the second one
> is in uhci_remove_td().
> I have little understanding of writing intel assembler in
> the GNU way, but I
> guess it would be a good idea to change the code to use a
> #ifdef __i386__
> to select the assembly code on ia32, and have some
> replacement C code on
> all other platforms.
>
> 2.) The second problem is even worse. I found one "occurence" in
> uhci_remove_td() of uhci.c, too. It seems that the Linux
> 2.3 USB code is
> extremely 64bit-unclean.
>
> unsigned int me;
> me = virt_to_bus(td) | (0xe & *backptr);
>
> OHCI defines a listhead pointer at some place as follows:
> __u32 listhead;
>
> It is not very good coding style to keep addresses in
> ints. Just think
> what will happen if you use this code on machines that
> are not satisfied
> with small 32bit pointers but use 32bit ints.
>
> I have to admit, I haven't had a look at the PPC kernel
> to see how USB is
> solved here. Don't they use the uhci/ohci stuff?
>
>
> I just noticed this and I decided to tell you. I'll keep an
> eye on it, maybe
> it's easier to solve than it looks like.
>
>
> >> -----Original Message-----
> >> From: Vojtech Pavlik [mailto:vojtech@suse.cz]
> >> Sent: Saturday, October 09, 1999 8:40 AM
> >> Subject: [linux-usb] Backport of USB to v2.2 kernel
> >>
> >> Hi!
> >>
> >> I've done the backport of v2.3 USB to v2.2.12 kernel.
> >> It was fairly easy, as the differences between 2.3 and
> >> 2.2 are not so huge.
>
> [..]
>
> >>
> >> I can also add some cosmetic changes and/or fix some compilation
> >> warnings if that seems to be good. Should I?
> >>
> >> Vojtech
>
> Liebe Grüße,
> Stefan Reinauer(stepan@suse.de)
>
> - --
> SuSE GmbH Can you afford *NOT*
> Schanzäckerstr. 10 to use Linux?
> D-90443 Nürnberg
> Germany AlphaPowered
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3i
> Charset: noconv
>
> iQEVAwUBOA4tpyu+zKndEmP5AQFBEggAvDybMaedWR7qSQhNbngY7ObCtMTQtrdy
> vDdmH/ofhp4nCLsmkwjKp+L0rJcje+apjrVjhnosANJueRNZHo6jNnHzDcsZRKji
> DpGTpUZi/Jx0KBPG9EU5IauxI9oz1jyGUuydLBeNG1kjo8AgVb5MdwbJexvk+zPX
> ZstUbKp2ypT94TQEwu8hezAZk+/X3IdnhxcyxxLNlxtp1mQ2EDLBLG2cWgYvUZiy
> wKmW8jvhRiZgCxp3bFswxIinog0ThCHl1p4lJMVbKq+8bcaeGI5RYBz06xupUHsZ
> ky+ZQqq4D7MUQ+3V2l/WFXhyLBNl1DvxxsUD68RKmLlTWeOJZvvd5g==
> =NEhB
> -----END PGP SIGNATURE-----
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/