What to do with all of the USB UHCI drivers in the kernel?

Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI controller drivers in the kernel! That's about 3 too many for me :)

Quoted 2 lines · [email protected] said:

Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI controller drivers in the kernel! That's about 3 too many for me :)

Stupid follow-up question for you. Is it possible for me to stay on 2.4.18, but test the 2.5.16 USB subsystem? I really don't want to move my whole system to 2.5.16, but would be willing to experiment with the USB parts. Is this possible? Can I just rebuild the usb modules - I'm guessing this wouldn't work, but thought I would ask anyway. Or to ask another way - any way us 2.4 folks can help?

Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI controller drivers in the kernel! That's about 3 too many for me :)

So what to do? I propose the following:

From now until July 1, I want everyone to test out both the uhci-hcd and usb-uhci-hcd drivers on just about every piece of hardware they can find. This includes SMP, UP, preempt kernels, big and little endian machines, and loads of different types of USB devices.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

----- Original Message -----
From: "Greg KH" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Monday, May 20, 2002 6:31 PM
Subject: What to do with all of the USB UHCI drivers in the kernel?

Quoted 6 lines

Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI controller drivers in the kernel! That's about 3 too many for me :)

So what to do? I propose the following:

Quoted 4 lines

From now until July 1, I want everyone to test out both the uhci-hcd and usb-uhci-hcd drivers on just about every piece of hardware they can find. This includes SMP, UP, preempt kernels, big and little endian machines, and loads of different types of USB devices.

The UHCI driver never recognizes my hardware. The OHCI driver (in the 2.4.18 kernel) does however. My Asus A7M266-D doesn't have an onboard USB but they ship an add-on card with the motherboard (made by Asus).

Quoted 19 lines · André Bonin

----- Original Message -----
From: "Greg KH" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; <[email protected]>
Sent: Monday, May 20, 2002 6:31 PM
Subject: What to do with all of the USB UHCI drivers in the kernel?

Quoted 10 lines

Ok, now that 2.5.16 is out, we have a total of 4 different USB UHCI controller drivers in the kernel! That's about 3 too many for me :)

So what to do? I propose the following:

From now until July 1, I want everyone to test out both the uhci-hcd and usb-uhci-hcd drivers on just about every piece of hardware they can find. This includes SMP, UP, preempt kernels, big and little endian machines, and loads of different types of USB devices.

Quoted 4 lines

The UHCI driver never recognizes my hardware. The OHCI driver (in the 2.4.18 kernel) does however. My Asus A7M266-D doesn't have an onboard USB but they ship an add-on card with the motherboard (made by Asus).

This is probably because you have an OHCI hardware device, not a UHCI device. What does 'lspci -v' say for your machine?

And how does 2.5.17 work for you?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 2 lines

This is probably because you have an OHCI hardware device, not a UHCI device. What does 'lspci -v' say for your machine?

Sorry, i'me not too familiar with the USB architecture. Anyway here is the relevant lspci entries (note: I did this under my working 2.4.18)

02:08.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Unknown device 807d:0035
Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at cd000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

02:08.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Unknown device 807d:0035
Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at cc800000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

02:08.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
Subsystem: Unknown device 807d:1043
Flags: bus master, medium devsel, latency 32, IRQ 17 Memory at cc000000 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2

Quoted 1 line

And how does 2.5.17 work for you?

Not too good beacuse I don't have the option of enabling OHCI :) Are we still keeping it?

Quoted 18 lines

Quoted 3 lines

This is probably because you have an OHCI hardware device, not a UHCI device. What does 'lspci -v' say for your machine?

Sorry, i'me not too familiar with the USB architecture. Anyway here is the relevant lspci entries (note: I did this under my working 2.4.18)

02:08.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Unknown device 807d:0035
Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at cd000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

02:08.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Unknown device 807d:0035
Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at cc800000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

Quoted 5 lines

02:08.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
Subsystem: Unknown device 807d:1043
Flags: bus master, medium devsel, latency 32, IRQ 17 Memory at cc000000 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2

You only have EHCI and OHCI hardware. No wonder the UHCI drivers do not work :)

Quoted 3 lines

Quoted 1 line

And how does 2.5.17 work for you?

Not too good beacuse I don't have the option of enabling OHCI :) Are we still keeping it?

Yes, use the ohci-hcd driver. Also you can use the ehci-hcd driver if you have any USB 2.0 devices, as it looks like you have a USB 2.0 controller.

Uz.ytkownik Greg KH napisa?:

Quoted 33 lines · Andre Bonin

Quoted 19 lines

Quoted 3 lines

This is probably because you have an OHCI hardware device, not a UHCI device. What does 'lspci -v' say for your machine?

Sorry, i'me not too familiar with the USB architecture. Anyway here is the relevant lspci entries (note: I did this under my working 2.4.18)

02:08.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Unknown device 807d:0035
Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at cd000000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

02:08.1 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Unknown device 807d:0035
Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at cc800000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 2

Quoted 5 lines

02:08.2 USB Controller: NEC Corporation USB 2.0 (rev 02) (prog-if 20 [EHCI])
Subsystem: Unknown device 807d:1043
Flags: bus master, medium devsel, latency 32, IRQ 17 Memory at cc000000 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 2

You only have EHCI and OHCI hardware. No wonder the UHCI drivers do not work :)

Quoted 2 lines

Quoted 1 line

And how does 2.5.17 work for you?

Quoted 7 lines

Quoted 2 lines

Not too good beacuse I don't have the option of enabling OHCI :) Are we still keeping it?

Yes, use the ohci-hcd driver. Also you can use the ehci-hcd driver if you have any USB 2.0 devices, as it looks like you have a USB 2.0 controller.

Could you please just do me a small favour and drop something in to linux/Documentation. Becouse I'm right now already confused about which driver to use and which alias to put in /etc/modules.conf so kudzu stops hollering about not knowing what to do
if I out of a sudden reboot in to 2.5.xx kernel.

Many thank's in advance.

PS. I could of course figure it out of my self, but since I don't attach anything to USB on my box *that* frequently.

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Hi Martin,
What do you actually want to know? That an EHCI controller should
use the ehci-hcd driver and that the OHCI controller should use the ohci-hcd controller? Or that the uhci-* drivers can't drive a EHCI or OHCI controller? Or something else?

BTW> one of the reasons I never bothered myself with kbuild-2.5 is for example that nio matter how frequently Keith
is advertising it - every time I go there to have a look at it at sf what I find is a scatter heap of .tar.gz. The documentation about how to install it makes me nervous, since I would rather just expect a diff and a README how to use it, so I never look after it.

| > BTW> one of the reasons I never bothered myself with kbuild-2.5
| > is for example that nio matter how frequently Keith
| > is advertising it - every time I go there to have a look at it
| > at sf what I find is a scatter heap of .tar.gz. The documentation
| > about how to install it makes me nervous, since I would
| > rather just expect a diff and a README how to use it, so I never
| > look after it.
|
| Duh... All you need is the core package (diff #1), the architecture
| independent modifications package (diff #2) and finally diff #3 that
| adds the arch-specific stuff. Everything's in a single list on sf.
|
| then just do s/t like
| cd /usr/src/linux-2.4.19-pre8 && zcat \
| 	../kbuild-2.5-core-14.gz \
| 	../kbuild-2.5-common-2.4.19-pre8-1.gz \
| 	../kbuild-2.5-i386-2.4.19-pre8-1.gz \
| 	| patch -sp1
|
| and read the comprehensive manual in Documentation/kbuild/
|
| What's there to be nervous about?

so there should just be a short, simple readme about how to install and use it -- not one that is 2400 lines long. Other than that, I like it.

Other than that, I like it.

Quoted 14 lines

| > BTW> one of the reasons I never bothered myself with kbuild-2.5
| > is for example that nio matter how frequently Keith
| > is advertising it - every time I go there to have a look at it
| > at sf what I find is a scatter heap of .tar.gz. The documentation
| > about how to install it makes me nervous, since I would
| > rather just expect a diff and a README how to use it, so I never
| > look after it.
|
| Duh... All you need is the core package (diff #1), the architecture
| independent modifications package (diff #2) and finally diff #3 that
| adds the arch-specific stuff. Everything's in a single list on sf.
|
| then just do s/t like
| cd /usr/src/linux-2.4.19-pre8 && zcat \

Quoted 8 lines

| 	../kbuild-2.5-core-14.gz \
| 	../kbuild-2.5-common-2.4.19-pre8-1.gz \
| 	../kbuild-2.5-i386-2.4.19-pre8-1.gz \
| 	| patch -sp1
|
| and read the comprehensive manual in Documentation/kbuild/
|
| What's there to be nervous about?

Uz.ytkownik Tomas Szepe napisa?:

Quoted 14 lines

Quoted 14 lines

| > BTW> one of the reasons I never bothered myself with kbuild-2.5
| > is for example that nio matter how frequently Keith
| > is advertising it - every time I go there to have a look at it
| > at sf what I find is a scatter heap of .tar.gz. The documentation
| > about how to install it makes me nervous, since I would
| > rather just expect a diff and a README how to use it, so I never
| > look after it.
|
| Duh... All you need is the core package (diff #1), the architecture
| independent modifications package (diff #2) and finally diff #3 that
| adds the arch-specific stuff. Everything's in a single list on sf.
|
| then just do s/t like
| cd /usr/src/linux-2.4.19-pre8 && zcat \

Quoted 8 lines

Quoted 8 lines

| 	../kbuild-2.5-core-14.gz \
| 	../kbuild-2.5-common-2.4.19-pre8-1.gz \
| 	../kbuild-2.5-i386-2.4.19-pre8-1.gz \
| 	| patch -sp1
|
| and read the comprehensive manual in Documentation/kbuild/
|
| What's there to be nervous about?

Well perhaps lazy would be more adequate to express my feelings. First why the hell three different diff files?
I don't give a damn witt about what the internal architecure of it is.

And I don't wan't to miss any non i386 build. (I have ARM for example as well.) I don't wan't to care whatever this is all complete. And I just expect the documentation about how to use it right at the top in README or INSTALL. I'm a human and humans tend to love to stick to habits. And I already got in to the habit of:

- One thing one patch.
- Something to compile look after README or INSTALL first there.

Even the kbuild name isn't intuitive
new-kernel-build would be more clear.

I really just wan't to see how it works first and I wan't to see that it indeed work's better then what I have already before I look at how it is done

Call me arrogant (and most propably it would be justifyed in this case), but this aggressive splitup gives me prejudictions about the whole thing simply beeing overdesigned...

Well what I know is the following: Kudzu did set up my system to use usb-ohci driver similar. And now you have apparently started to obsolete some of them. I know that there are still two drivers supported. So I would really really wellcome it if you would just write up some documentation about the *whole* transition from using some old driver to the one which is supposed to be the driver used in the future.

Most likely this would be of course module aliasing entires which could be used in /etc/modules.conf to cheat around kudzu - this way it would be for example possible to have a nice dual boot configuration.

(I can adjust my boot scripts to set up an apriopriate symlink from /etc/modules.conf to modules-2.5.18.confg and modules-2.4.18.conf debpending what I'm booting anyway...)

In short - if you change something about the configuration and usage - just document it please.

Uz.ytkownik Stephen J. Gowdy napisa?:

Quoted 5 lines

Hi Martin,
What do you actually want to know? That an EHCI controller should
use the ehci-hcd driver and that the OHCI controller should use the ohci-hcd controller? Or that the uhci-* drivers can't drive a EHCI or OHCI controller? Or something else?

Anyway, here's the documentation that you need:
The module usb-ohci is now gone. Use ohci-hcd instead.

The people with UHCI controllers have a big more documentation to read:
The module uhci is now gone. If you used this module, use uhci-hcd instead. The module usb-uhci is now gone. If you used this module, use usb-uhci-hcd instead. If you have a preference over which UHCI module works better for you, please email [email protected] your comments, as one of these modules will be going away in the near future.

Uz.ytkownik Greg KH napisa?:

Quoted 10 lines

Anyway, here's the documentation that you need:
The module usb-ohci is now gone. Use ohci-hcd instead.

The people with UHCI controllers have a big more documentation to read:
The module uhci is now gone. If you used this module, use uhci-hcd instead. The module usb-uhci is now gone. If you used this module, use usb-uhci-hcd instead. If you have a preference over which UHCI module works better for you, please email [email protected] your comments, as one of these modules will be going away in the near future.

Thank's that is explaining it.
But I would have loved it if it appeared with + in front in the patch somewhere. That's the only true problem I had. OK?

BTW.> usb-ohci seems to be a more reasonable name, since it tells me directly - hey buddy I'm USB the -hcd doen't tell me anything in addition and is entierly redundant, or is there a ohci.o module there?

And why not just doing the following.

1. Rename usb-ohci to usb-ohci-old

2. Rename ohci-hcd to usb-ohci

Much less grief and guessing what happens :-).

Just a suggestion.

Quoted 24 lines · Martin Dalecki

Uz.ytkownik Greg KH napisa?:

Quoted 10 lines

Anyway, here's the documentation that you need:
The module usb-ohci is now gone. Use ohci-hcd instead.

The people with UHCI controllers have a big more documentation to read:
The module uhci is now gone. If you used this module, use uhci-hcd instead. The module usb-uhci is now gone. If you used this module, use usb-uhci-hcd instead. If you have a preference over which UHCI module works better for you, please email [email protected] your comments, as one of these modules will be going away in the near future.

Thank's that is explaining it.
But I would have loved it if it appeared with + in front in the patch somewhere. That's the only true problem I had. OK?

BTW.> usb-ohci seems to be a more reasonable name, since it tells me directly - hey buddy I'm USB the -hcd doen't tell me anything in addition and is entierly redundant, or is there a ohci.o module there?

Quoted 7 lines

And why not just doing the following.

1. Rename usb-ohci to usb-ohci-old

2. Rename ohci-hcd to usb-ohci

Much less grief and guessing what happens :-).

Quoted 4 lines

Just a suggestion.

You do not understand the _cause_ for the rename.

hcd stands for Host Controller Device. The names mark them as that. Now you can argue, that all the SCSI controller modules do not have HBC (host bus controller) in their name - and then look at the different naming of the other scsi modules:

scsi_mod.o sd_mod.o sg.o sr_mod.o st.o

Also not very intuitiv. We could put them in different subdirs...

Quoted 25 lines · Peter Wächtler

Quoted 24 lines · Martin Dalecki

Uz.ytkownik Greg KH napisa?:

Quoted 10 lines

Anyway, here's the documentation that you need:
The module usb-ohci is now gone. Use ohci-hcd instead.

The people with UHCI controllers have a big more documentation to read:
The module uhci is now gone. If you used this module, use uhci-hcd instead. The module usb-uhci is now gone. If you used this module, use usb-uhci-hcd instead. If you have a preference over which UHCI module works better for you, please email [email protected] your comments, as one of these modules will be going away in the near future.

Thank's that is explaining it.
But I would have loved it if it appeared with + in front in the patch somewhere. That's the only true problem I had. OK?

BTW.> usb-ohci seems to be a more reasonable name, since it tells me directly - hey buddy I'm USB the -hcd doen't tell me anything in addition and is entierly redundant, or is there a ohci.o module there?

Quoted 7 lines

Quoted 7 lines

And why not just doing the following.

1. Rename usb-ohci to usb-ohci-old

2. Rename ohci-hcd to usb-ohci

Much less grief and guessing what happens :-).

Second this (in fact "first this").
Elegant solution which would not only habe prevented this thread but help developers and users no end.

Quoted 6 lines

Quoted 4 lines

Just a suggestion.

You do not understand the _cause_ for the rename.

Martin and me understand what hcd means, and we think it is non-untuitive and user-hostile.

Quoted 10 lines

hcd stands for Host Controller Device. The names mark them as that. Now you can argue, that all the SCSI controller modules do not have HBC (host bus controller) in their name - and then look at the different naming of the other scsi modules:

scsi_mod.o sd_mod.o sg.o sr_mod.o st.o

Also not very intuitiv. We could put them in different subdirs...

Obviously you cannot balance between intuitive and user-friendly.

_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users

Could you please just do me a small favour and drop something in to linux/Documentation. Becouse I'm right now already confused about which driver to use and which alias to put in /etc/modules.conf so kudzu stops hollering about not knowing what to do
if I out of a sudden reboot in to 2.5.xx kernel.

From now until July 1, I want everyone to test out both the uhci-hcd and usb-uhci-hcd drivers on just about every piece of hardware they can find.

Quoted 3 lines · Greg KH

From now until July 1, I want everyone to test out both the uhci-hcd and usb-uhci-hcd drivers on just about every piece of hardware they can find.

I need this patch to convince the Makefile to build the new drivers.

Let me (and the linux-usb-devel list) know about any thoughts you have pertaining to liking one of the drivers over the other one. Speed tests, size tests, code pretty tests, comment spelling tests, documentation tests, you name it, I want to know about it. If you don't want your comments to be public, send them to me directly and I will not let anyone else know what you said, but will use the info to try to pick which one should stay.

From now until July 1, I want everyone to test out both the uhci-hcd and usb-uhci-hcd drivers on just about every piece of hardware they can find. This includes SMP, UP, preempt kernels, big and little endian machines, and loads of different types of USB devices.