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

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

[Greg KH]

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.

  (Note, for those who don't realize it, the uhci-hcd driver is based
  off of the uhci.c driver, and the usb-uhci-hcd driver is based off of
  the usb-uhci.c driver.  Both of these drivers now use the USB HCD
  interface, hopefully reducing some code complexity and size because of
  this.  So this means that the uhci.c and usb-uhci.c drivers are
  going to go away, just like the usb-ohci.c driver did in 2.5.16.)

  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.

  I will be doing the same thing (running speed tests, and hardware
  tests) and will be publishing those results on the linux-usb-devel
  list for others to verify.

  Then, the week of July 1, I will be taking everyone's comments and
  making a decision about which driver to keep.

thanks,

greg k-h

Re: [Linux-usb-users] What to do with all of the USB UHCI drivers in the kernel?

[Timothy E. Jedlicka - wrk]

greg@kroah.com 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?

Thanks much for your (all the USB developers) work on USB - it is great to 
have USB working under Linux, I do appreciate it.
-----
Timothy Jedlicka, bonzo@lucent.com, 1-630-713-4436, AOL-IM=bonzowork
Network Entomologist, Lucent Technologies, Testers For Hire

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

[Maksim (Max) Krasnyanskiy]

Greg,

I'm gonna speak for Bluetooth USB devices.
I do have bunch of things like Kodak digi camera, Sony DV camcorder, CF 
reader, etc. But they don't
seem to care much about which HCD is used and work equally well with both 
usb-uhci and uhci drivers.

I used to be a uhci driver fan :). But starting somewhere from 2.4.16 or so 
Bluetooth devices work much better
with usb-uhci driver (not all devices but most of them). Even thought 
Bluetooth is pretty slow (about 700kbps)
performance difference is sometimes pretty significant 20-30% (ie usb-uhci 
driver is faster).

So basically I vote for usb-uhci. However some things will have to be 
fixed. We (Bluetooth folks) have couple
of devices that refuse to work with usb-uhci (I didn't test the latest 
usb-uhci though).

Thanks
Max

>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.
>
>   (Note, for those who don't realize it, the uhci-hcd driver is based
>   off of the uhci.c driver, and the usb-uhci-hcd driver is based off of
>   the usb-uhci.c driver.  Both of these drivers now use the USB HCD
>   interface, hopefully reducing some code complexity and size because of
>   this.  So this means that the uhci.c and usb-uhci.c drivers are
>   going to go away, just like the usb-ohci.c driver did in 2.5.16.)
>
>   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.
>
>   I will be doing the same thing (running speed tests, and hardware
>   tests) and will be publishing those results on the linux-usb-devel
>   list for others to verify.
>
>   Then, the week of July 1, I will be taking everyone's comments and
>   making a decision about which driver to keep.
>
>thanks,
>
>greg k-h



Max

http://bluez.sf.net
http://vtun.sf.net

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

[Greg KH]

On Tue, May 21, 2002 at 12:41:39PM -0700, Maksim (Max) Krasnyanskiy wrote:
> Greg,
> 
> I'm gonna speak for Bluetooth USB devices.
> I do have bunch of things like Kodak digi camera, Sony DV camcorder, CF 
> reader, etc. But they don't
> seem to care much about which HCD is used and work equally well with both 
> usb-uhci and uhci drivers.
> 
> I used to be a uhci driver fan :). But starting somewhere from 2.4.16 or so 
> Bluetooth devices work much better
> with usb-uhci driver (not all devices but most of them). Even thought 
> Bluetooth is pretty slow (about 700kbps)
> performance difference is sometimes pretty significant 20-30% (ie usb-uhci 
> driver is faster).
> 
> So basically I vote for usb-uhci. However some things will have to be 
> fixed. We (Bluetooth folks) have couple
> of devices that refuse to work with usb-uhci (I didn't test the latest 
> usb-uhci though).

Sorry for the confusion, but both usb-uhci.c and uhci.c will be deleted
anyway :)

I am more interested in usb-uhci-hcd.c and uhci-hcd.c drivers, which both
showed up in 2.5.16.  Yes they are based on the previous usb-uhci.c and
uhci.c drivers respectivly, but they are a bit different (they use the
hcd core code which reduces the size of the driver.)

You also might want to check out uhci.c again in 2.4.19-pre.  It has had
a lot of previous bugs fixed and works _much_ better for me than before.

thanks,

greg k-h

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

[Greg KH]

On Tue, May 21, 2002 at 10:23:15AM -0500, Timothy E. Jedlicka - wrk wrote:
> greg@kroah.com 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?

You _might_ want to try dropping the drivers/usb tree from 2.5.x into
2.4 (and the usb files in include/linux/usb*.h too) and see what
happens.

Odds are the build process will not work, and I think some of the usbfs
changes will also not work.  But it would be interesting to see what you
found :)

So in short, I don't think that you could test out the 2.5 code on 2.4.
Is there some reason you can't run a 2.5 kernel?  Personally I run it on
lots of different machines (laptops, desktops, servers, etc.)
successfully.

If you can't run a 2.5 kernel, you can just take a look through the
code, and tell me what you think of that.  Readability is one of the
criteria I'm going to be using.

thanks,

greg k-h

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

[Maksim (Max) Krasnyanskiy]

> > So basically I vote for usb-uhci. However some things will have to be
> > fixed. We (Bluetooth folks) have couple
> > of devices that refuse to work with usb-uhci (I didn't test the latest
> > usb-uhci though).
>
>Sorry for the confusion, but both usb-uhci.c and uhci.c will be deleted 
>anyway :)
I thought that usb-uhci-hcd and uhci-hcd are direct derivatives of usb-uhci 
and uhci
(ie just minor API changes). And therefor perform exactly the same.

>I am more interested in usb-uhci-hcd.c and uhci-hcd.c drivers, which both
>showed up in 2.5.16.  Yes they are based on the previous usb-uhci.c and
>uhci.c drivers respectivly, but they are a bit different (they use the
>hcd core code which reduces the size of the driver.)
I see. Ok. I'll try 2.5.17 on one of my machines with UHCI controller.

>You also might want to check out uhci.c again in 2.4.19-pre.  It has had
>a lot of previous bugs fixed and works _much_ better for me than before.
Ok.

Thanks
Max

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

[Johannes Erdfelt]

On Tue, May 21, 2002, Maksim (Max) Krasnyanskiy <maxk@qualcomm.com> wrote:
> 
> > > So basically I vote for usb-uhci. However some things will have to be
> > > fixed. We (Bluetooth folks) have couple
> > > of devices that refuse to work with usb-uhci (I didn't test the latest
> > > usb-uhci though).
> >
> >Sorry for the confusion, but both usb-uhci.c and uhci.c will be deleted 
> >anyway :)
> I thought that usb-uhci-hcd and uhci-hcd are direct derivatives of usb-uhci 
> and uhci
> (ie just minor API changes). And therefor perform exactly the same.

I wouldn't consider it a minor API change, but theoretically they should
perform identically. Since some changes were non trivial, I wouldn't
guarantee that they behave identically :)

However, I'm not sure that's all that interesting. The code is a
straight enough port over that if there are bugs, they'll be there in
both versions, except for some trivial porting mistakes. Those are easy
to find and easy to fix normally.

The other kinds of bugs, like fundamental design flaws or bugs that
have always been there, are more interesting and likely to be in both.

IMO, I think testing with usb-uhci.c and uhci.c is still useful, but
testing with the -hcd variants is the most ideal since that will be the
final code base.

JE

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

[Maksim (Max) Krasnyanskiy]

>IMO, I think testing with usb-uhci.c and uhci.c is still useful, but
>testing with the -hcd variants is the most ideal since that will be the
>final code base.

Ok. Here is feedback on 2.5.17 uhci-hcd and usb-uhci-hcd.
I did not notice any difference in behavior. Both have the same 
performance, just like 2.4.19-pre8.

One-shot interrupt transfers are broken in *-hcd drivers. core/hcd.c 
returns EINVAL if urb->interval==0.
My Broadcom FW loader (uses usbdevfs) needs one-shot interrupts. So in 
order to test Broadcom devices
I changed to hcd.c to allow urb->interval==0. With that change uhci-hcd 
works just fine, I can load fw and
use the device. But usb-uhci-hcd kills the machine pretty hard (hw reset 
needed).

Here is a patch for hcd.c.

--- hcd.c.orig  Tue May 21 17:50:09 2002
+++ hcd.c       Tue May 21 17:01:44 2002
@@ -1456,11 +1456,9 @@
          * supports different values... this uses EHCI/UHCI defaults (and
          * EHCI can use smaller non-default values).
          */
-       switch (temp) {
-       case PIPE_ISOCHRONOUS:
-       case PIPE_INTERRUPT:
+       if (urb->interval && (temp == PIPE_ISOCHRONOUS || temp == 
PIPE_INTERRUPT)) {
                 /* too small? */
-               if (urb->interval <= 0)
+               if (urb->interval < 0)
                         return -EINVAL;
                 /* too big? */
                 switch (urb->dev->speed) {

usb-uhci-hcd has to be fixed.
btw It tries to round interval value even thought it's done by hcd.c

So, Bluetooth USB devices should work fine with either usb-uhci-hcd or 
uhci-hcd.
(assuming that above patch is applied and one-shot is fixed in usb-uhci-hcd)

On a side note. Why are URBs still not SLABified ?
Drivers still have those silly urb pools and stuff. I thought you guys were 
gonna fix that.

Max

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

[André Bonin]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]


----- Original Message -----
From: "Greg KH" <greg@kroah.com>
To: <linux-usb-devel@lists.sourceforge.net>
Cc: <linux-kernel@vger.kernel.org>; <Linux-usb-users@lists.sourceforge.net>
Sent: Monday, May 20, 2002 6:31 PM
Subject: 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 :)
>
> 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.

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).

I attached the relevant syslogs and kernel logs for a boot-up with the UHCI
driver.  The USB startup is towards the end.

List of USB devices attached:

1) AsusTek USB enhanced Host Controller
2) Logitech USB Camera (QuickCam Web)
3) NEC PCI to USB Open Host Controller
4) NEC PCI to USB Open Host Controller
5) USB Root Hub x2 (Must belong to the USB hub on my monitor, ViewSonic
G773-2)
6) USB Root Hub x2 (Must belong to the USB hub on my monitor, ViewSonic
G773-2)
7) Microsoft IntelliMouse Optical (imPs2)

Thanks!

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

*****************************************************
André Bonin
Computer Engineering Technologist
Ottawa (Ontario)
Canada
*****************************************************

[-- Attachment #2: syslog --]
[-- Type: application/octet-stream, Size: 1201 bytes --]

May 21 20:36:20 Cherlyn kernel: klogd 1.4.1#10, log source = /proc/kmsg started.
May 21 20:36:20 Cherlyn kernel: uhci.c: USB Universal Host Controller Interface driver v1.1
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver usblp
May 21 20:36:20 Cherlyn kernel: printer.c: v0.12: USB Printer Device Class driver
May 21 20:36:20 Cherlyn kernel: Initializing USB Mass Storage driver...
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver usb-storage
May 21 20:36:20 Cherlyn kernel: USB Mass Storage support registered.
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver hiddev
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver hid
May 21 20:36:20 Cherlyn kernel: hid-core.c: v1.31:USB HID core driver
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver usbscanner
May 21 20:36:20 Cherlyn kernel: scanner.c: 0.4.6:USB Scanner Driver
May 21 20:36:20 Cherlyn kernel: mice: PS/2 mouse device common for all mice
May 21 20:36:21 Cherlyn /usr/sbin/gpm[221]: oops() invoked from gpn.c(454)
May 21 20:36:21 Cherlyn /usr/sbin/gpm[221]: Repeating into ImPS2 protocol not yet implemented :-(: File exists
May 21 20:36:22 Cherlyn lpd[234]: restarted

[-- Attachment #3: kern.log --]
[-- Type: application/octet-stream, Size: 1046 bytes --]

May 21 20:36:20 Cherlyn kernel: Linux version 2.5.17 (root@Cherlyn) (gcc version 2.95.4 20011002 (Debian prerelease)) #4 SMP Tue May 21 20:26:15 EST 2002
...
May 21 20:36:20 Cherlyn kernel: uhci.c: USB Universal Host Controller Interface driver v1.1
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver usblp
May 21 20:36:20 Cherlyn kernel: printer.c: v0.12: USB Printer Device Class driver
May 21 20:36:20 Cherlyn kernel: Initializing USB Mass Storage driver...
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver usb-storage
May 21 20:36:20 Cherlyn kernel: USB Mass Storage support registered.
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver hiddev
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver hid
May 21 20:36:20 Cherlyn kernel: hid-core.c: v1.31:USB HID core driver
May 21 20:36:20 Cherlyn kernel: usb.c: registered new driver usbscanner
May 21 20:36:20 Cherlyn kernel: scanner.c: 0.4.6:USB Scanner Driver
May 21 20:36:20 Cherlyn kernel: mice: PS/2 mouse device common for all mice

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

[Greg KH]

On Tue, May 21, 2002 at 06:04:21PM -0700, Maksim (Max) Krasnyanskiy wrote:
> 
> >IMO, I think testing with usb-uhci.c and uhci.c is still useful, but
> >testing with the -hcd variants is the most ideal since that will be the
> >final code base.
> 
> Ok. Here is feedback on 2.5.17 uhci-hcd and usb-uhci-hcd.
> I did not notice any difference in behavior. Both have the same 
> performance, just like 2.4.19-pre8.
> 
> One-shot interrupt transfers are broken in *-hcd drivers. core/hcd.c 
> returns EINVAL if urb->interval==0.
> My Broadcom FW loader (uses usbdevfs) needs one-shot interrupts. So in 
> order to test Broadcom devices
> I changed to hcd.c to allow urb->interval==0. With that change uhci-hcd 
> works just fine, I can load fw and
> use the device. But usb-uhci-hcd kills the machine pretty hard (hw reset 
> needed).
> 
> Here is a patch for hcd.c.

Thanks for the patch.

> On a side note. Why are URBs still not SLABified ?
> Drivers still have those silly urb pools and stuff. I thought you guys were 
> gonna fix that.

It hasn't been proven that it's really needed.  95% of the current
drivers create their urbs when the device is plugged in, and then free
them when they are removed.  Making that kind of allocation into a slab
is a bit silly :)

Now if more drivers start doing fun stuff like the visor.c driver does
in the 2.5 tree, then it might make more sense to create a URB specific
slab.

thanks,

greg k-h

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

[Greg KH]

On Tue, May 21, 2002 at 09:10:04PM -0400, André Bonin wrote:
> 
> ----- Original Message -----
> From: "Greg KH" <greg@kroah.com>
> To: <linux-usb-devel@lists.sourceforge.net>
> Cc: <linux-kernel@vger.kernel.org>; <Linux-usb-users@lists.sourceforge.net>
> Sent: Monday, May 20, 2002 6:31 PM
> Subject: 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 :)
> >
> > 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.
> 
> 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

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

[Andre Bonin]

Greg KH wrote:
> On Tue, May 21, 2002 at 09:10:04PM -0400, André Bonin wrote:
> 
>>----- Original Message -----
>>From: "Greg KH" <greg@kroah.com>
>>To: <linux-usb-devel@lists.sourceforge.net>
>>Cc: <linux-kernel@vger.kernel.org>; <Linux-usb-users@lists.sourceforge.net>
>>Sent: Monday, May 20, 2002 6:31 PM
>>Subject: 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 :)
>>>
>>>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.
>>>
>>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?

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


> 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?


> thanks,

I thank you sir!

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

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

[Maksim (Max) Krasnyanskiy]

At 10:06 PM 5/21/2002 -0700, Greg KH wrote:
> > On a side note. Why are URBs still not SLABified ?
> > Drivers still have those silly urb pools and stuff. I thought you guys 
> were
> > gonna fix that.
>
>It hasn't been proven that it's really needed.  95% of the current
>drivers create their urbs when the device is plugged in, and then free
>them when they are removed.  Making that kind of allocation into a slab
>is a bit silly :)
Well, I'm claiming that those drivers are wrong ;)
It makes sense to pre-allocate intr in, iso and bulk in URB. But (imo) it 
doesn't make much sense
to pre-allocate ctrl and bulk out. For example one might never send stuff 
out of USB serial port,
because it used only for logging or something, ut write_urb will always be 
allocated. Same
goes for ctrl, one sends ctrl requests only once in a while but URB is 
always allocated.

Also as Dave pointed out kmalloc is already slabified anyway. And as I 
mentioned kmalloc
has fixed size slabs and therefor will waste some memory.

>Now if more drivers start doing fun stuff like the visor.c driver does
>in the 2.5 tree, then it might make more sense to create a URB specific
>slab.
Some drivers are still maintaining bulk URB pools which is just unnecessary 
code and mem waste.
They should allocate/free bulk urbs on demand.
visor, usbnet, hci_usb and some other driver allocate URB on demand.

I guess the reason for having driver specific URB pools is because 
usb_alloc_urb (using kmalloc) was
slow. Now if it's replaced with slab cache it's no longer the case. So 
drivers should not pre-allocate
stuff unnecessary.

It definitely doesn't hurt to have URB specific cache. You get better stats 
(like URB slab utilization, etc).
You could chose to do slab poisoning and debug URB allocations and stuff. 
You could use slab constructor
to pre-initialize some URB fields.

Max

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

[Greg KH]

On Wed, May 22, 2002 at 03:35:48PM -0400, Andre Bonin wrote:
> >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

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

> >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.

thanks,

greg k-h

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

[Martin Dalecki]

Uz.ytkownik Greg KH napisa?:
> On Wed, May 22, 2002 at 03:35:48PM -0400, Andre Bonin wrote:
> 
>>>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
> 
> 
> You only have EHCI and OHCI hardware.  No wonder the UHCI drivers do not
> work :)
> 
> 
>>>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.


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.

Re: [Linux-usb-users] Re: What to do with all of the USB UHCI drivers in the kernel?

[Martin Dalecki]

Uz.ytkownik Stephen J. Gowdy napisa?:
> 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?

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.

Thank's in advance.

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.

Re: [Linux-usb-users] Re: What to do with all of the USB UHCI drivers in the kernel?

[Stephen J. Gowdy]

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?

							rgeards,

							Stephen.

On Thu, 23 May 2002, Martin Dalecki wrote:

> Uz.ytkownik Greg KH napisa?:
> > On Wed, May 22, 2002 at 03:35:48PM -0400, Andre Bonin wrote:
> > 
> >>>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
> > 
> > 
> > You only have EHCI and OHCI hardware.  No wonder the UHCI drivers do not
> > work :)
> > 
> > 
> >>>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.
> 
> 
> 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
> 
> _______________________________________________
> Linux-usb-users@lists.sourceforge.net
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-users
> 

-- 
 /------------------------------------+-------------------------\
|Stephen J. Gowdy                     | SLAC, MailStop 34,       |
|http://www.slac.stanford.edu/~gowdy/ | 2575 Sand Hill Road,     |
|http://calendar.yahoo.com/gowdy      | Menlo Park CA 94025, USA |
|EMail: gowdy@slac.stanford.edu       | Tel: +1 650 926 3144     |
 \------------------------------------+-------------------------/

Re: [Linux-usb-users] Re: What to do with all of the USB UHCI driversin the kernel?

[Gunther Mayer]

Martin Dalecki wrote:

> Uz.ytkownik Stephen J. Gowdy napisa?:
> > 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?
>

Rename the old driver to *-old.
Rename the new drivers to the "normal" names.

There is no reason to confurce the userbase to fiddle
with their configurations. You said the old drivers could
seamlessly be replacedby s.th. better, so this policy will
implement this at it's best.

You will immediately get a lot of testing !!!

Regards, Gunther

Re: [linux-usb-devel] Re: What to do with all of the USB UHCI drivers in the kernel?

[David Brownell]

> 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.

I don't think that belongs in Linux/Documentation since it's
specific to RedHat.  Apart from the "which UHCI" confusion,
you could use the /etc/rc.d/init.d/hotplug script to start
up USB. (That's not part of RedHat though; they use kudzu to
promote what seems like more of a static config model.)

I have an RH 7.3 system that has this ... though I had to
tweak it by hand since their setup stored multiple entries
for some drivers, and didn't put EHCI first (so devices on
USB 2.0 adapters would start out with one driver, disconnect,
then reconnect using the "right" host controller):

	alias usb-controller  ehci-hcd
	alias usb-controller1 ohci-hcd
	alias usb-controller2 uhci-hcd
	alias usb-controller3 usb-ohci
	alias usb-controller4 usb-uhci

Note that the "uhci-hcd" would be "usb-uhci-hcd" if you're trying
to experiment with that version on the 2.5 kernel, if you're not
doing manual rmmod/modprobe (which I usually end up doing).

That causes silly boot messages for the hardware or drivers you
may not have, but works reliably/correctly for all current kernels.

- Dave

kb25 manual [was Re: [Linux-usb-users] Re: What to do with all of the USB UHCI drivers in the kernel?]

[Tomas Szepe]

> 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?


T.

Re: kb25 manual [was Re: [Linux-usb-users] Re: What to do with all of the USB UHCI drivers in the kernel?]

[Randy.Dunlap]

On Thu, 23 May 2002, Tomas Szepe wrote:

| > 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.

-- 
~Randy

Re: kb25 manual [was Re: [Linux-usb-users] Re: What to do with all of the USB UHCI drivers in the kernel?]

[Tomas Szepe]

> | > 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.

How about submitting one to Keith yourself then? :)

No really, I don't think there's a problem with the manual.
If you just want to learn how to compile a kernel, you can
skim thru the first section of the file in under 30 seconds.

> Other than that, I like it.

Who doesn't. I mean, apart from Wayne Brown who hates to have
to remember to issue simpler commands. ;)


T.

Re: [Linux-usb-users] Re: What to do with all of the USB UHCI drivers in the kernel?

[Greg KH]

On Thu, May 23, 2002 at 04:25:50PM +0200, Martin Dalecki wrote:
> 
> 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.

Hm, Kudzu shouldn't care, you just should not be able to load the
usb-ohci module on startup.  At least that's what happens to me on my
boxes.

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
	greg@kroah.com your comments, as one of these modules will be
	going away in the near 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.

Heh, I don't mess around with module aliasing, so I don't know the first
thing of what to do in this situation.  Someone reading the above
documentation should be able to figure it all out.

> (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.

We really don't use CHANGES anymore.  Where do you propose things like
the above few sentences go to where everyone will know to look?

thanks,

greg k-h

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

[Peter Osterlund]

Greg KH <greg@kroah.com> writes:

>   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.

--- linux/drivers/usb/Makefile.orig	Thu May 23 19:37:56 2002
+++ linux/drivers/usb/Makefile	Thu May 23 19:32:44 2002
@@ -12,6 +12,8 @@
 subdir-$(CONFIG_USB_EHCI_HCD)	+= host
 subdir-$(CONFIG_USB_OHCI_HCD)	+= host
 subdir-$(CONFIG_USB_OHCI)	+= host
+subdir-$(CONFIG_USB_UHCI_HCD)	+= host
+subdir-$(CONFIG_USB_UHCI_HCD_ALT)	+= host
 subdir-$(CONFIG_USB_UHCI_ALT)	+= host
 subdir-$(CONFIG_USB_UHCI)	+= host
 
-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: kb25 manual [was Re: [Linux-usb-users] Re: What to do with all of the USB UHCI drivers in the kernel?]

[Martin Dalecki]

Uz.ytkownik Tomas Szepe napisa?:
>>| > 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?


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...

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

[Greg KH]

On Thu, May 23, 2002 at 07:41:22PM +0200, Peter Osterlund wrote:
> Greg KH <greg@kroah.com> writes:
> 
> >   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.

Already in Linus' tree, and will show up in 2.5.18.

thanks,

greg k-h

Re: [Linux-usb-users] Re: What to do with all of the USB UHCI drivers in the kernel?

[Martin Dalecki]

Uz.ytkownik Greg KH napisa?:

> 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
> 	greg@kroah.com 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.

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

[Peter Osterlund]

Greg KH <greg@kroah.com> writes:

>   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.

I did a simple test reading a bunch of files from a Freecom CDRW
drive.

usb-uhci-hcd           17840   0 (unused)

        pengo:/cdrw$ time wc petero/mp3/madonna/*
        ...
         188462 1091976 50386286 total

        real    1m24.930s
        user    0m10.440s
        sys     0m1.360s

uhci-hcd               24608   0 (unused)

        pengo:/cdrw$ time wc petero/mp3/madonna/*
        ...
         188462 1091976 50386286 total

        real    1m33.095s
        user    0m12.670s
        sys     0m11.870s

So the usb-uhci-hcd driver is 27% smaller, gives a 10% higher transfer
rate and produces less system load during the data transfers. (About
70% idle time versus 50% idle time on my 233MHz MMX system.)

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: kb25 manual [was Re: [Linux-usb-users] Re: What to do with all of the USB UHCI drivers in the kernel?]

[Tomas Szepe]

> Uz.ytkownik Tomas Szepe napisa?:
> >>| > 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?
> 
> 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:

Well, if you took the time to look at the code, you'd realize
it's actually very practical. The main package is really just
the very core of the system, something that you needn't touch
at all if going from one kernel revision to another. Obviously,
the "common" patch restructures the Makefile skeleton and other
stuff that is shared across all archs. No need to explain the
arch-specific diff I guess.

So, when upgrading to another kernel release, you end up only
having to "patch -R + patch" the "build recipes" (a couple K),
not the system core (a 1MB diff) that scarcely ever changes.

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

Well, I guess Keith could add an INSTALL file to the d/l list on sf.
If it's to only read "hey, you grab these 3 files and feed them to
patch," it's not much work and apparently there are people who will
find such info helpful.

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

Who cares about the name, man :)
I mean, as far as I'm concerned, if it's called hrmops55 and does
the thing right, I'm not saying a word against it.

> 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

-> go -> read -> the -> manual -> thankyou :)

> 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...

It's really not.


T.

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

[Pierre Rousselet]

Greg KH wrote:
 >   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.

2.5.17, USB onboard Abit BE6, modem ADSL Speedtouch USB :

1) uhci without loading the modem driver :
# modprobe uhci
# rmmod uhci
OOPS (not logged)
kernel: kmem_cache_destroy: Can't free all objects cff416f8
kernel: uhci: not all urb_priv's were freed

2) usb-uhci uhci-hcd usb-uhci-hcd produce no visible difference in the
operation of the modem (62 kbytes/s for 608 kbits/s connexion speed).


Pierre
-- 
------------------------------------------------
   Pierre Rousselet <pierre.rousselet@wanadoo.fr>
------------------------------------------------

Re: [Linux-usb-users] Re: What to do with all of the USB UHCI drivers

[Peter Wächtler]

Martin Dalecki wrote:
> Uz.ytkownik Greg KH napisa?:
> 
>> 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
>>     greg@kroah.com 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.
> 

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...

Re: [Linux-usb-users] Re: What to do with all of the USB UHCI drivers

[Gunther Mayer]

Peter Wächtler wrote:

> Martin Dalecki wrote:
> > Uz.ytkownik Greg KH napisa?:
> >
> >> 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
> >>     greg@kroah.com 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 :-).

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

>
> >
> > 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.


>
>
> 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.

Re: [Linux-usb-users] Re: What to do with all of the USB UHCI drivers

[Stephen J. Gowdy]

I don't have a problem with the new names. Users shouldn't care, and when 
they do they want to report problems. It would help to know what they are 
actually talking about without need to remember which kernel the rename 
happened in (and that distributions may backport the changes to earlier 
kernels would only complicate this more).

On Fri, 24 May 2002, Gunther Mayer wrote:

> Peter Wächtler wrote:
> 
> > Martin Dalecki wrote:
> > > Uz.ytkownik Greg KH napisa?:
> > >
> > >> 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
> > >>     greg@kroah.com 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 :-).
> 
> Second this (in fact "first this").
> Elegant solution which would not only habe prevented this thread
> but help developers and users no end.
> 
> >
> > >
> > > 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.
> 
> 
> >
> >
> > 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
> 
> _______________________________________________
> Linux-usb-users@lists.sourceforge.net
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-users
> 

-- 
 /------------------------------------+-------------------------\
|Stephen J. Gowdy                     | SLAC, MailStop 34,       |
|http://www.slac.stanford.edu/~gowdy/ | 2575 Sand Hill Road,     |
|http://calendar.yahoo.com/gowdy      | Menlo Park CA 94025, USA |
|EMail: gowdy@slac.stanford.edu       | Tel: +1 650 926 3144     |
 \------------------------------------+-------------------------/