[GIT PATCH] USB patches for 2.6.17

[GIT PATCH] USB patches for 2.6.17

[Greg KH]

Here are a lot of USB patches for 2.6.17.  They do the following:

	 - rework the UHCI driver
	 - lots of new device ids added
	 - EHCI tt fixed (allowing 1.1 devices behind 2.0 hubs to work properly)
	 - new drivers added
	 - endpoint sysfs code redone
	 - lots of other small bugfixes and features added

All of these changes have been in the -mm tree for a number of months.

Please pull from:
	git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/
or if master.kernel.org hasn't synced up yet:
	master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/

The full patches will be sent to the linux-usb-devel mailing list, if
anyone wants to see them.

thanks,

greg k-h

 Documentation/power/swsusp.txt             |   37 -
 Documentation/usb/usbmon.txt               |   32 
 arch/powerpc/sysdev/fsl_soc.c              |   66 --
 arch/ppc/syslib/mpc83xx_devices.c          |    6 
 drivers/block/ub.c                         |   78 --
 drivers/media/video/usbvideo/konicawc.c    |    3 
 drivers/usb/Makefile                       |    2 
 drivers/usb/atm/usbatm.c                   |    2 
 drivers/usb/atm/xusbatm.c                  |    1 
 drivers/usb/class/cdc-acm.c                |   84 +-
 drivers/usb/class/cdc-acm.h                |   16 
 drivers/usb/core/Makefile                  |    3 
 drivers/usb/core/devio.c                   |   38 -
 drivers/usb/core/endpoint.c                |  275 ++++++++
 drivers/usb/core/file.c                    |   79 +-
 drivers/usb/core/hub.c                     |  153 +++-
 drivers/usb/core/message.c                 |  182 +++--
 drivers/usb/core/sysfs.c                   |  201 ------
 drivers/usb/core/usb.c                     |    1 
 drivers/usb/core/usb.h                     |    3 
 drivers/usb/gadget/ether.c                 |   90 +-
 drivers/usb/gadget/inode.c                 |   62 +
 drivers/usb/gadget/net2280.c               |   17 
 drivers/usb/gadget/pxa2xx_udc.c            |   13 
 drivers/usb/gadget/rndis.c                 |  389 +++++------
 drivers/usb/gadget/rndis.h                 |   26 
 drivers/usb/gadget/serial.c                |  105 ---
 drivers/usb/host/Kconfig                   |   20 
 drivers/usb/host/ehci-au1xxx.c             |   21 
 drivers/usb/host/ehci-fsl.c                |   37 -
 drivers/usb/host/ehci-hcd.c                |   50 +
 drivers/usb/host/ehci-pci.c                |   59 -
 drivers/usb/host/ehci-sched.c              |  216 ++++++
 drivers/usb/host/isp116x-hcd.c             |    4 
 drivers/usb/host/sl811-hcd.c               |    2 
 drivers/usb/host/sl811_cs.c                |    2 
 drivers/usb/host/uhci-debug.c              |   45 +
 drivers/usb/host/uhci-hcd.c                |  139 ++--
 drivers/usb/host/uhci-hcd.h                |   81 +-
 drivers/usb/host/uhci-hub.c                |    5 
 drivers/usb/host/uhci-q.c                  |  947 ++++++++++++++++-------------
 drivers/usb/input/acecad.c                 |    4 
 drivers/usb/input/aiptek.c                 |    4 
 drivers/usb/input/appletouch.c             |  117 +++
 drivers/usb/input/ati_remote.c             |    4 
 drivers/usb/input/ati_remote2.c            |    2 
 drivers/usb/input/hid-core.c               |   83 +-
 drivers/usb/input/hid-input.c              |   36 -
 drivers/usb/input/hid.h                    |   11 
 drivers/usb/input/itmtouch.c               |    4 
 drivers/usb/input/kbtab.c                  |    5 
 drivers/usb/input/keyspan_remote.c         |    4 
 drivers/usb/input/mtouchusb.c              |    4 
 drivers/usb/input/powermate.c              |    4 
 drivers/usb/input/touchkitusb.c            |    4 
 drivers/usb/input/usbkbd.c                 |    4 
 drivers/usb/input/usbmouse.c               |    4 
 drivers/usb/input/usbtouchscreen.c         |    2 
 drivers/usb/input/wacom.c                  |    5 
 drivers/usb/input/xpad.c                   |    4 
 drivers/usb/input/yealink.c                |    4 
 drivers/usb/misc/Kconfig                   |   23 
 drivers/usb/misc/Makefile                  |    2 
 drivers/usb/misc/appledisplay.c            |  383 +++++++++++
 drivers/usb/misc/cy7c63.c                  |  244 +++++++
 drivers/usb/misc/phidgetkit.c              |  303 ++++++---
 drivers/usb/misc/sisusbvga/sisusb.c        |  127 +--
 drivers/usb/misc/sisusbvga/sisusb.h        |    6 
 drivers/usb/misc/sisusbvga/sisusb_con.c    |  151 ++--
 drivers/usb/misc/sisusbvga/sisusb_init.c   |    4 
 drivers/usb/misc/sisusbvga/sisusb_init.h   |   20 
 drivers/usb/misc/sisusbvga/sisusb_struct.h |    2 
 drivers/usb/misc/usbtest.c                 |   38 -
 drivers/usb/mon/mon_dma.c                  |    5 
 drivers/usb/mon/mon_main.c                 |   23 
 drivers/usb/mon/mon_stat.c                 |    4 
 drivers/usb/mon/mon_text.c                 |   36 +
 drivers/usb/mon/usb_mon.h                  |    2 
 drivers/usb/net/asix.c                     |    4 
 drivers/usb/net/cdc_ether.c                |   14 
 drivers/usb/net/pegasus.c                  |   29 
 drivers/usb/net/rndis_host.c               |    2 
 drivers/usb/net/zaurus.c                   |   19 
 drivers/usb/serial/Kconfig                 |   18 
 drivers/usb/serial/airprime.c              |    2 
 drivers/usb/serial/console.c               |   56 +
 drivers/usb/serial/cp2101.c                |    1 
 drivers/usb/serial/cyberjack.c             |    2 
 drivers/usb/serial/cypress_m8.c            |    2 
 drivers/usb/serial/empeg.c                 |    2 
 drivers/usb/serial/ftdi_sio.c              |   13 
 drivers/usb/serial/ftdi_sio.h              |    6 
 drivers/usb/serial/garmin_gps.c            |    2 
 drivers/usb/serial/generic.c               |    4 
 drivers/usb/serial/io_edgeport.c           |   48 -
 drivers/usb/serial/ipaq.c                  |    2 
 drivers/usb/serial/ipw.c                   |    2 
 drivers/usb/serial/ir-usb.c                |    2 
 drivers/usb/serial/keyspan.c               |    2 
 drivers/usb/serial/kl5kusb105.c            |    3 
 drivers/usb/serial/omninet.c               |    2 
 drivers/usb/serial/option.c                |  139 +++-
 drivers/usb/serial/pl2303.c                |    4 
 drivers/usb/serial/usb-serial.c            |   58 +
 drivers/usb/serial/usb-serial.h            |    5 
 drivers/usb/serial/visor.c                 |    2 
 drivers/usb/serial/whiteheat.c             |    8 
 drivers/usb/storage/onetouch.c             |    3 
 drivers/usb/storage/scsiglue.c             |    4 
 drivers/usb/storage/shuttle_usbat.c        |  105 ++-
 drivers/usb/storage/shuttle_usbat.h        |    4 
 drivers/usb/storage/transport.c            |   88 +-
 drivers/usb/storage/unusual_devs.h         |   35 -
 drivers/usb/storage/usb.c                  |   51 +
 include/linux/usb.h                        |   22 
 include/linux/usb/cdc.h                    |  205 ++++++
 include/linux/usb/input.h                  |   25 
 include/linux/usb/isp116x.h                |   29 
 include/linux/usb/sl811.h                  |   26 
 include/linux/usb_cdc.h                    |  205 ------
 include/linux/usb_input.h                  |   25 
 include/linux/usb_isp116x.h                |   29 
 include/linux/usb_sl811.h                  |   26 
 123 files changed, 4169 insertions(+), 2440 deletions(-)

---------------

Adrian Bunk:
      USB: sisusbvga: possible cleanups

Alan Stern:
      USB: usbcore: always turn on hub port power
      USB: net2280: add a shutdown routine
      USB: UHCI: store the endpoint type in the QH structure
      USB: UHCI: fix obscure bug in enqueue()
      usbhid: automatically set HID_QUIRK_NOGET for keyboards and mice
      UHCI: Common result routine for Control/Bulk/Interrupt
      UHCI: Remove non-iso TDs as they are used
      UHCI: Move code for cleaning up unlinked URBs
      UHCI: Eliminate the TD-removal list
      UHCI: Reimplement FSBR
      UHCI: Work around old Intel bug
      UHCI: use integer-sized frame numbers
      UHCI: fix race in ISO dequeuing
      UHCI: store the period in the queue header
      UHCI: remove ISO TDs as they are used
      gadgetfs: fix AIO interface bugs
      gadgetfs: fix memory leaks
      usbtest: report errors in iso tests
      usbhid: Remove unneeded blacklist entries
      usbcore: port reset for composite devices
      USB hub: use usb_reset_composite_device
      usb-storage: use usb_reset_composite_device
      usbhid: use usb_reset_composite_device
      usbcore: recovery from Set-Configuration failure
      usb-storage: unusual_devs entry for Nikon DSC D70s
      UHCI: remove hc_inaccessible flag
      UHCI: Improve FSBR-off timing
      USB: unusual_devs entry for Nokia N80

Andrew Morton:
      Driver for Apple Cinema Display

Arjan van de Ven:
      USB: convert the semaphores in the sisusb driver to mutexes

Bart Massey:
      USB HID/HIDBP, INPUT DRIVERS: fix various usb/input/hid-input.c bugs that make Apple Mighty Mouse work poorly

Chris Lund:
      USB: free allocated memory on io_edgeport startup memory failure

Dan Streetman:
      improved TT scheduling for EHCI

Daniel Drake:
      USB shuttle_usbat: hardcode flash detection for now
      USB: usb-storage alauda: Fix transport info mismerge
      USB: print message when device is rejected due to insufficient power

David Brownell:
      USB: usbnet, zaurus mtu fixup
      USB: correct the USB info in Documentation/power/swsusp.txt
      USB: more pegasus log spamming removed
      USB: cdc_ether: recognize olympus r1000 (fix regression)
      UHCI: various updates
      USB: whitespace removal from usb/gadget/ether
      USB: move <linux/usb_cdc.h> to <linux/usb/cdc.h>
      USB: move hardware-specific <linux/usb_*.h> to <linux/usb/*.h>
      USB: move <linux/usb_input.h> to <linux/usb/input.h>

Duncan Sands:
      USBATM: remove pointless inline
      USBATM: remove no-longer needed #include

Eduard Warkentin:
      USB: added support for ASIX 88178 chipset USB Gigabit Ethernet adaptor

Eric Sesterhenn:
      USB: negative index in drivers/usb/host/isp116x-hcd.c

Franck Bui-Huu:
      Fix a deadlock in usbtest
      usb-storage: get rid of the timer during URB submission
      USB: gadget-serial: fix a deadlock when closing the serial device
      USB: gadget-serial: do not save/restore IRQ flags in gs_close()

Frank Gevaerts:
      USB Serial: clean tty fields on failed device open

Giridhar Pemmasani:
      usbcore: Fix broken RNDIS config selection

Greg Kroah-Hartman:
      USB: add usb_interrupt_msg() function for api completeness.
      USB: move the endpoint specific sysfs code to it's own file
      USB: make usb_create_ep_files take a struct device
      USB: make endpoints real struct devices
      USB: move usb_device_class class devices to be real devices
      USB: convert usb class devices to real devices
      USB: only make /sys/class/usb show up when there is something in it

Guennadi Liakhovetski:
      USB: console: fix oops
      USB console: fix disconnection issues

Henk Vergonet:
      USB: add YEALINK phones to the HID_QUIRK_IGNORE blacklist

Ian Abbott:
      USB: ftdi_sio: add support for Yost Engineering ServoCenter3.1

Jeremy Fitzhardinge:
      USB: Add Sierra Wireless MC5720 ID to airprime.c

Kumar Gala:
      USB: allow multiple types of EHCI controllers to be built as modules

Luiz Fernando N. Capitulino:
      usbserial: Fixes wrong return values.

Matt Reimer:
      USB: trivial DEBUG message correction in gadget ether driver

Matthias Urlichs:
      USB: new devices for the Option driver

Micah Dowty:
      USB: Remove 4088-byte limit on usbfs control URBs
      USB: Allow high-bandwidth isochronous packets via usbfs

Milan Svoboda:
      usb gadget: allow drivers support speeds higher than full speed
      usb gadget: fix compile errors
      usb gadget: update pxa2xx_udc.c driver to fully support IXP4xx platform

Nicolas Boichat:
      USB: MacBook Pro touchpad support

Oliver Bock:
      USB: new driver for Cypress CY7C63xxx mirco controllers

Oliver Neukum:
      USB: cdc-acm: add a new special case for modems with buggy firmware

Paul Fulghum:
      USB: console: fix cr/lf issues
      USB: console: prevent ENODEV on node

Paul Serice:
      USB: EHCI works again on NVidia controllers with >2GB RAM

Pete Zaitcev:
      USB: clean out an unnecessary NULL check from ub
      usb: io_edgeport, cleanup to unicode handling
      USB serial: encapsulate schedule_work, remove double-calling
      USB: Improve Kconfig comment for mct_u232
      USB: Syntax cleanup for pl2303 (trailing backslash)
      USB: rmmod pl2303 after -28
      ub: atomic add_disk
      ub: random cleanups
      USB: io_edgeport touch-up
      USB: update usbmon, fix glued lines
      USB: implement error event in usbmon
      USB: update usbmon.txt

Peter Chubb:
      USB: shuttle_usbat: Fix handling of scatter-gather buffers
      USB: shuttle_usbat: Hardcode detection of HP CDRW devices

Philippe Retornaz:
      usb: drivers/usb/core/devio.c dereferences a userspace pointer

Ralf Baechle:
      USB: EHCI on non-Au1200 build fix

Rene Rebe:
      USB: Add Apple MacBook product IDs to usbhid

Sean Young:
      USB Phidget InterfaceKit: make inputs pollable and new device support

Stuart MacDonald:
      USB: Whiteheat: fix firmware spurious errors

Timothy Sipples:
      airprime.c: add Kyocera Wireless KPC650/Passport support

Vitja Makarov:
      USB: new cp2101 device

Re: [GIT PATCH] USB patches for 2.6.17

[Linus Torvalds]

On Wed, 21 Jun 2006, Greg KH wrote:
>
>  123 files changed, 4169 insertions(+), 2440 deletions(-)

Btw, I get

  119 files changed, 3888 insertions(+), 2159 deletions(-)

Why? Becuause my default pull script has rename detection enabled, and I 
get:

 rename include/linux/{usb_cdc.h => usb/cdc.h} (100%)
 rename include/linux/{usb_input.h => usb/input.h} (100%)
 rename include/linux/{usb_isp116x.h => usb/isp116x.h} (100%)
 rename include/linux/{usb_sl811.h => usb/sl811.h} (71%)

which explains the off-by-four number (and the smaller number of 
lines changed).

Just out of interest, could you enable that in your scripts too, so that 
renames don't show up as huge deletes/creates (well, in this case, thet 
were pretty small files, but you get the idea)?

		Linus

Re: [GIT PATCH] USB patches for 2.6.17

[Greg KH]

On Wed, Jun 21, 2006 at 03:22:19PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 21 Jun 2006, Greg KH wrote:
> >
> >  123 files changed, 4169 insertions(+), 2440 deletions(-)
> 
> Btw, I get
> 
>   119 files changed, 3888 insertions(+), 2159 deletions(-)
> 
> Why? Becuause my default pull script has rename detection enabled, and I 
> get:
> 
>  rename include/linux/{usb_cdc.h => usb/cdc.h} (100%)
>  rename include/linux/{usb_input.h => usb/input.h} (100%)
>  rename include/linux/{usb_isp116x.h => usb/isp116x.h} (100%)
>  rename include/linux/{usb_sl811.h => usb/sl811.h} (71%)
> 
> which explains the off-by-four number (and the smaller number of 
> lines changed).
> 
> Just out of interest, could you enable that in your scripts too, so that 
> renames don't show up as huge deletes/creates (well, in this case, thet 
> were pretty small files, but you get the idea)?

Ok, but how?  I'm generating the diffstat in my script with:

	git diff origin..HEAD | diffstat -p1 >> $TMP_FILE

Is there a better way to see these renames?  In playing around with 'git
diff' I didn't see how to do it, but I'm probably just not looking for
the right option...

thanks,

greg k-h

Re: [GIT PATCH] USB patches for 2.6.17

[Linus Torvalds]

On Wed, 21 Jun 2006, Greg KH wrote:
> 
> Ok, but how?  I'm generating the diffstat in my script with:
> 
> 	git diff origin..HEAD | diffstat -p1 >> $TMP_FILE
> 
> Is there a better way to see these renames?  In playing around with 'git
> diff' I didn't see how to do it, but I'm probably just not looking for
> the right option...

Look at the "diff-options" documentation. 

It's "-M" for "Detect renames" (or use -C, which actually detects copies 
too, but that will be somewhat more expensive).

That works with any diff output (ie "git log -p -M" will give log output 
with patches and rename detection turned on).

		Linus

Re: [GIT PATCH] USB patches for 2.6.17

[Linus Torvalds]

On Wed, 21 Jun 2006, Greg KH wrote:
> 
> Ok, but how?  I'm generating the diffstat in my script with:
> 
> 	git diff origin..HEAD | diffstat -p1 >> $TMP_FILE

Btw, with a recent git (ie 1.4.0+), you can just do

	git diff -M --stat origin..HEAD

to do that much more efficiently, and without any external dependency on 
the "diffstat" program (with rename detection, you really need to do this 
using git itself, because "diffstat" doesn't understand rename patches 
being renames).

In fact, in a script, add the "--summary" option too, which gives a 
summary of file creation/deletion/renames at the end.

And as usual, the diff options work fine with "git log" too, so you can do

	git log -M --stat --summary

and it will do the right thing. Look at your ae0dadcf.. commit, for 
example.

Btw, the _one_ thing to be careful about is that when you generate a real 
patch with "-M", if that patch actually has a rename, then only "git 
apply" will be able to apply it correctly, and if somebody uses a regular 
"patch" program to apply it, they'll miss out on the rename, of course.

Some day maybe the git "extended patch format" is so univerally recognized 
to be superior that everybody understands them, in the meantime you may 
not want to use "-M" to generate patches unless you know the other end 
applies them with git.

(Which also explains why "-M" is not the default, of course).

		Linus

Re: [GIT PATCH] USB patches for 2.6.17

[Greg KH]

On Wed, Jun 21, 2006 at 06:22:58PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 21 Jun 2006, Greg KH wrote:
> > 
> > Ok, but how?  I'm generating the diffstat in my script with:
> > 
> > 	git diff origin..HEAD | diffstat -p1 >> $TMP_FILE
> 
> Btw, with a recent git (ie 1.4.0+), you can just do
> 
> 	git diff -M --stat origin..HEAD
> 
> to do that much more efficiently, and without any external dependency on 
> the "diffstat" program (with rename detection, you really need to do this 
> using git itself, because "diffstat" doesn't understand rename patches 
> being renames).

Great, thanks, that works fine.  And it's faster :)

> In fact, in a script, add the "--summary" option too, which gives a 
> summary of file creation/deletion/renames at the end.

Ok, will do.  The next pull I send you will have the new format.

> And as usual, the diff options work fine with "git log" too, so you can do
> 
> 	git log -M --stat --summary
> 
> and it will do the right thing. Look at your ae0dadcf.. commit, for 
> example.
> 
> Btw, the _one_ thing to be careful about is that when you generate a real 
> patch with "-M", if that patch actually has a rename, then only "git 
> apply" will be able to apply it correctly, and if somebody uses a regular 
> "patch" program to apply it, they'll miss out on the rename, of course.
> 
> Some day maybe the git "extended patch format" is so univerally recognized 
> to be superior that everybody understands them, in the meantime you may 
> not want to use "-M" to generate patches unless you know the other end 
> applies them with git.
> 
> (Which also explains why "-M" is not the default, of course).

For now I'll leave -M off, as people might want to apply the patches
from email.  Although it might cut down on main bandwidth, and they can
always refer to the git tree or original patch...  I'll think about that
one.

thanks,

greg k-h

Re: [GIT PATCH] USB patches for 2.6.17

[Greg KH]

On Thu, Jun 22, 2006 at 11:18:26AM -0700, Greg KH wrote:
> On Wed, Jun 21, 2006 at 06:22:58PM -0700, Linus Torvalds wrote:
> > And as usual, the diff options work fine with "git log" too, so you can do
> > 
> > 	git log -M --stat --summary
> > 
> > and it will do the right thing. Look at your ae0dadcf.. commit, for 
> > example.
> > 
> > Btw, the _one_ thing to be careful about is that when you generate a real 
> > patch with "-M", if that patch actually has a rename, then only "git 
> > apply" will be able to apply it correctly, and if somebody uses a regular 
> > "patch" program to apply it, they'll miss out on the rename, of course.
> > 
> > Some day maybe the git "extended patch format" is so univerally recognized 
> > to be superior that everybody understands them, in the meantime you may 
> > not want to use "-M" to generate patches unless you know the other end 
> > applies them with git.
> > 
> > (Which also explains why "-M" is not the default, of course).
> 
> For now I'll leave -M off, as people might want to apply the patches
> from email.  Although it might cut down on main bandwidth, and they can
> always refer to the git tree or original patch...  I'll think about that
> one.

I take that back.  I just used -M for the W1 patch series and I think it
is very helpful as it shows only the lines that change in a rename,
which can easily get lost in the noise of a longer patch.

Very nice stuff, have I mentioned lately how much I love git?

thanks,

greg k-h

Re: [GIT PATCH] USB patches for 2.6.17

[Randy.Dunlap]

On Thu, 22 Jun 2006 11:30:21 -0700 Greg KH wrote:

> On Thu, Jun 22, 2006 at 11:18:26AM -0700, Greg KH wrote:
> > On Wed, Jun 21, 2006 at 06:22:58PM -0700, Linus Torvalds wrote:
> > > And as usual, the diff options work fine with "git log" too, so you can do
> > > 
> > > 	git log -M --stat --summary
> > > 
> > > and it will do the right thing. Look at your ae0dadcf.. commit, for 
> > > example.
> > > 
> > > Btw, the _one_ thing to be careful about is that when you generate a real 
> > > patch with "-M", if that patch actually has a rename, then only "git 
> > > apply" will be able to apply it correctly, and if somebody uses a regular 
> > > "patch" program to apply it, they'll miss out on the rename, of course.
> > > 
> > > Some day maybe the git "extended patch format" is so univerally recognized 
> > > to be superior that everybody understands them, in the meantime you may 
> > > not want to use "-M" to generate patches unless you know the other end 
> > > applies them with git.
> > > 
> > > (Which also explains why "-M" is not the default, of course).
> > 
> > For now I'll leave -M off, as people might want to apply the patches
> > from email.  Although it might cut down on main bandwidth, and they can
> > always refer to the git tree or original patch...  I'll think about that
> > one.
> 
> I take that back.  I just used -M for the W1 patch series and I think it
> is very helpful as it shows only the lines that change in a rename,
> which can easily get lost in the noise of a longer patch.
> 
> Very nice stuff, have I mentioned lately how much I love git?

Um, I was going to say that my patch wasn't listed in the
shortlog that you sent (for W1), but it's there, just mis-attributed
to Evgeniy (#13/14).

---
~Randy

Re: [GIT PATCH] USB patches for 2.6.17

[Greg KH]

On Thu, Jun 22, 2006 at 11:49:00AM -0700, Randy.Dunlap wrote:
> 
> Um, I was going to say that my patch wasn't listed in the
> shortlog that you sent (for W1), but it's there, just mis-attributed
> to Evgeniy (#13/14).

I think that happened as Evgeniy sent it to me without the "From:" line
on the top of the email, which would have preserved your attribute.
Evgeniy, care to do that next time?

thanks,

greg k-h

Re: [GIT PATCH] USB patches for 2.6.17

[Linus Torvalds]

On Thu, 22 Jun 2006, Greg KH wrote:
> 
> I take that back.  I just used -M for the W1 patch series and I think it
> is very helpful as it shows only the lines that change in a rename,
> which can easily get lost in the noise of a longer patch.

Yes. The main reason to do rename detection is not that the patch shrinks 
(although it does), but simply because in many cases it makes the patch a 
hell of a lot more readable. It's often much more obvious what is actually 
going on, when you don't see it as a large "one file got deleted, another 
one added" thing.

> Very nice stuff, have I mentioned lately how much I love git?

It does seem to be working out, doesn't it?

I'm just constantly surprised by how people don't even seem to realize 
what it can do sometimes. Part of it is that development has been pretty 
active (and some of the things it can do simply weren't there three months 
ago), but part of it must be because people don't even expect it to be 
able to do something like that.

The "git log -p" thing is wonderful, but it's even more wonderful when you 
realize that you can ask it to just tell you what changed in a specific 
set of subdirectories. Or when you realize that you can actually have two 
branches, and ask it to show only the commits that are in one and not the 
other (even if the branches are _not_ subsets of each other).

For example, if you track my branch separately (not merging, and not 
rebasing - just doing something like "git fetch linus" to track where I 
am), you can always just do things like

	git log -p ..linus drivers/usb/

to see what _I_ have merged that might touch drivers/usb/, but that isn't 
in your branch because I ended up taking a patch from somebody else (for 
example, you might see some USB change that the MIPS merges brought in).

That kind of thing has, I believe, been the biggest success of the whole 
git model (the "track whole _trees_ rather than individual files").

I realize that some people are used to individual file tracking, and that 
the git model makes "git annotate individual_file.c" pretty inefficient, 
but at least for me, the whole sub-tree tracking is a _lot_ more 
important, and I don't think anybody else can do it as effortlessly and 
efficiently as git does.

The above kind of command line is just _so_ powerful. Maybe it's because 
I'm a top-level maintainer, but I basically _never_ care about a single 
file, but often care about one (or a few) subdirectory.

And Junio has done a stellar job at maintaining git. 

		Linus

Re: [GIT PATCH] USB patches for 2.6.17

[Sam Ravnborg]

> I'm just constantly surprised by how people don't even seem to realize 
> what it can do sometimes. Part of it is that development has been pretty 
> active (and some of the things it can do simply weren't there three months 
> ago), but part of it must be because people don't even expect it to be 
> able to do something like that.

Personally I'm still missing two things:
1) A command to let me see what this Linus guy have applied compared to
my tree - without touching anything in my tree. bk changes -R
2) A dry-run of a fetch+pull. I can do that if I really study the man
pages I know. But "git pull --dry-run" would be more convinient.

Other than that I will say that I'm pleased with the funtionality that
I use - that's maybe 10% of the possibilities...

	Sam

Re: [GIT PATCH] USB patches for 2.6.17

[Petr Baudis]

Dear diary, on Thu, Jun 22, 2006 at 10:01:47PM CEST, I got a letter
where Sam Ravnborg <sam@ravnborg.org> said that...
> Personally I'm still missing two things:
> 1) A command to let me see what this Linus guy have applied compared to
> my tree - without touching anything in my tree. bk changes -R

You can cg-fetch / git fetch and then either "cg-log -m" or
"git log -r ..origin".

> 2) A dry-run of a fetch+pull. I can do that if I really study the man
> pages I know. But "git pull --dry-run" would be more convinient.

What would that involve? Isn't git pull --no-commit enough?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.

Re: [GIT PATCH] USB patches for 2.6.17

[Linus Torvalds]

On Thu, 22 Jun 2006, Sam Ravnborg wrote:
> 
> Personally I'm still missing two things:
> 1) A command to let me see what this Linus guy have applied compared to
> my tree - without touching anything in my tree. bk changes -R

	git fetch linus
	git log ..linus

Yes, it will fetch the things into your database, unlike BK, but that's 
kind of the point. That's what makes branches so powerful (you can do a 
lot more than "bk changes -R").

> 2) A dry-run of a fetch+pull. I can do that if I really study the man
> pages I know. But "git pull --dry-run" would be more convinient.

Hmm? Again, do

	git fetch <thing-to-be-fetched>

into a local branch first. That gets it into your repo, so that you can do 
things.

After that, I'm not quite sure what you mean by "--dry-run". Do you mean 
to know about file-level conflicts? You do need to do the merge in order 
to know whether the conflicts can be resolved, but even without doing the 
merge you can look for _file_level_ conflicts by other means.

I don't think anybody has done it, but a script like

	OTHER="$1"
	BASE=$(git-merge-base HEAD $OTHER) || exit
	git-merge-tree $BASE HEAD $OTHER | grep -v '^0'

will show if there were file-level conflicts (in a pretty strange format, 
admittedly).

Of course, 99% of the time, a three-way merge will just handle those fine 
(the output from "git-merge-tree" is enough to know to do a three-way 
merge on temp-files, if you want to try that).

		Linus

Re: [GIT PATCH] USB patches for 2.6.17

[Linus Torvalds]

On Thu, 22 Jun 2006, Linus Torvalds wrote:
> 
> After that, I'm not quite sure what you mean by "--dry-run". Do you mean 
> to know about file-level conflicts? You do need to do the merge in order 
> to know whether the conflicts can be resolved, but even without doing the 
> merge you can look for _file_level_ conflicts by other means.

Btw, what you can always do is just

	git pull <other-end>
	.. look at the result ..
	git reset --hard ORIG_HEAD

and you should be ok. It's obviously not a dry-run, it's more of a "do it 
and then undo it", but hey, it should _work_.

(Look out for dirty state, though. "git pull" will happily pull into a 
dirty tree if the changes don't actually affect any dirty files. The "git 
reset --hard" thing will undo all dirty state, though).

		Linus

Re: [GIT PATCH] USB patches for 2.6.17

[Linus Torvalds]

On Wed, 21 Jun 2006, Greg KH wrote:
>
> Here are a lot of USB patches for 2.6.17.  They do the following:

I think these may be responsible for:

	Bluetooth: L2CAP ver 2.8
	Bluetooth: L2CAP socket layer initialized
	Bluetooth: HIDP (Human Interface Emulation) ver 1.1
	Bluetooth: RFCOMM socket layer initialized
	Bluetooth: RFCOMM TTY layer initialized
	Bluetooth: RFCOMM ver 1.7
	BUG: unable to handle kernel paging request at virtual address 5a5a5a5a
	 printing eip:
	c02a58f8
	*pde = 00000000
	Oops: 0000 [#1]
	SMP 
	Modules linked in: rfcomm hidp l2cap hci_usb bluetooth ip_conntrack_netbios_ns ipt_REJECT iptable_filter ip_tables ip6table_filter ip6_tables cpufreq_ondemand lp pcspkr intel_agp agpgart
	CPU:    0
	EIP:    0060:[<c02a58f8>]    Not tainted VLI
	EFLAGS: 00210206   (2.6.17-gd588fcbe #211) 
	EIP is at usbdev_open+0xb4/0x1ec
	eax: 0bd00005   ebx: 5a5a5a5a   ecx: 5a5a58d2   edx: dd991e4c
	esi: de020bdc   edi: c712da68   ebp: c6eeaee8   esp: c6eeaeac
	ds: 007b   es: 007b   ss: 0068
	Process hid2hci (pid: 3719, threadinfo=c6eea000 task=ddfb8570)
	Stack: c854dc28 dd22cd70 00000000 00000005 c6eeaed4 c016bd39 c6eeaf3c 00000001 
	       c6eea000 00000000 dd22cd70 c6eeaee8 00000000 c050b8a0 dd22cd70 c6eeaf04 
	       c01678a4 c854dc28 c6eeaf04 c854dc28 dd22cd70 00000000 c6eeaf20 c015e424 
	Call Trace:
	 <c0103c46> show_stack_log_lvl+0x85/0x8f  <c0103dc3> show_registers+0x13b/0x1af
	 <c0103fac> die+0x175/0x285  <c011a86d> do_page_fault+0x428/0x522
	 <c0103777> error_code+0x4f/0x54  <c01678a4> chrdev_open+0x11a/0x171
	 <c015e424> __dentry_open+0xc8/0x1ab  <c015e575> nameidata_to_filp+0x1c/0x2e
	 <c015e5b5> do_filp_open+0x2e/0x35  <c015e5fc> do_sys_open+0x40/0xba
	 <c015e6a2> sys_open+0x16/0x18  <c0102c0f> sysenter_past_esp+0x54/0x75
	Code: 00 8b 35 cc 77 61 c0 8b 8e 9c 00 00 00 81 e9 88 01 00 00 eb 16 8b 45 d0 0d 00 00 d0 0b 39 81 94 01 00 00 74 81 8d 8b 78 
	fe ff ff <8b> 99 88 01 00 00 0f 18 03 90 8d 91 88 01 00 00 8d 86 9c 00 00 
	EIP: [<c02a58f8>] usbdev_open+0xb4/0x1ec SS:ESP 0068:c6eeaeac

where that 5a5a5a5a is possibly/probably due to SLAB debugging (it's the 
"POISON_INUSE" pattern)

It might have happened before too, of course, I just haven't seen it 
before (even though I've had SLAB debugging on all the time on that 
machine).

It seems to actually be from usbdev_lookup_minor(), which has been inlined 
(damn compiler), and it's the "node.next" access in the

	list_for_each_entry(device, &usb_device_class->devices, node) {

loop.

Any ideas? 

			Linus

Re: [GIT PATCH] USB patches for 2.6.17

[Greg KH]

On Thu, Jun 22, 2006 at 04:11:26PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 21 Jun 2006, Greg KH wrote:
> >
> > Here are a lot of USB patches for 2.6.17.  They do the following:
> 
> I think these may be responsible for:
> 
> 	Bluetooth: L2CAP ver 2.8
> 	Bluetooth: L2CAP socket layer initialized
> 	Bluetooth: HIDP (Human Interface Emulation) ver 1.1
> 	Bluetooth: RFCOMM socket layer initialized
> 	Bluetooth: RFCOMM TTY layer initialized
> 	Bluetooth: RFCOMM ver 1.7
> 	BUG: unable to handle kernel paging request at virtual address 5a5a5a5a
> 	 printing eip:
> 	c02a58f8
> 	*pde = 00000000
> 	Oops: 0000 [#1]
> 	SMP 
> 	Modules linked in: rfcomm hidp l2cap hci_usb bluetooth ip_conntrack_netbios_ns ipt_REJECT iptable_filter ip_tables ip6table_filter ip6_tables cpufreq_ondemand lp pcspkr intel_agp agpgart
> 	CPU:    0
> 	EIP:    0060:[<c02a58f8>]    Not tainted VLI
> 	EFLAGS: 00210206   (2.6.17-gd588fcbe #211) 
> 	EIP is at usbdev_open+0xb4/0x1ec
> 	eax: 0bd00005   ebx: 5a5a5a5a   ecx: 5a5a58d2   edx: dd991e4c
> 	esi: de020bdc   edi: c712da68   ebp: c6eeaee8   esp: c6eeaeac
> 	ds: 007b   es: 007b   ss: 0068
> 	Process hid2hci (pid: 3719, threadinfo=c6eea000 task=ddfb8570)
> 	Stack: c854dc28 dd22cd70 00000000 00000005 c6eeaed4 c016bd39 c6eeaf3c 00000001 
> 	       c6eea000 00000000 dd22cd70 c6eeaee8 00000000 c050b8a0 dd22cd70 c6eeaf04 
> 	       c01678a4 c854dc28 c6eeaf04 c854dc28 dd22cd70 00000000 c6eeaf20 c015e424 
> 	Call Trace:
> 	 <c0103c46> show_stack_log_lvl+0x85/0x8f  <c0103dc3> show_registers+0x13b/0x1af
> 	 <c0103fac> die+0x175/0x285  <c011a86d> do_page_fault+0x428/0x522
> 	 <c0103777> error_code+0x4f/0x54  <c01678a4> chrdev_open+0x11a/0x171
> 	 <c015e424> __dentry_open+0xc8/0x1ab  <c015e575> nameidata_to_filp+0x1c/0x2e
> 	 <c015e5b5> do_filp_open+0x2e/0x35  <c015e5fc> do_sys_open+0x40/0xba
> 	 <c015e6a2> sys_open+0x16/0x18  <c0102c0f> sysenter_past_esp+0x54/0x75
> 	Code: 00 8b 35 cc 77 61 c0 8b 8e 9c 00 00 00 81 e9 88 01 00 00 eb 16 8b 45 d0 0d 00 00 d0 0b 39 81 94 01 00 00 74 81 8d 8b 78 
> 	fe ff ff <8b> 99 88 01 00 00 0f 18 03 90 8d 91 88 01 00 00 8d 86 9c 00 00 
> 	EIP: [<c02a58f8>] usbdev_open+0xb4/0x1ec SS:ESP 0068:c6eeaeac
> 
> where that 5a5a5a5a is possibly/probably due to SLAB debugging (it's the 
> "POISON_INUSE" pattern)
> 
> It might have happened before too, of course, I just haven't seen it 
> before (even though I've had SLAB debugging on all the time on that 
> machine).
> 
> It seems to actually be from usbdev_lookup_minor(), which has been inlined 
> (damn compiler), and it's the "node.next" access in the
> 
> 	list_for_each_entry(device, &usb_device_class->devices, node) {
> 
> loop.
> 
> Any ideas? 

I saw this once when debugging the usb code, but could never reproduce
it, so I attributed it to an incomplete build at the time, as a reboot
fixed it.

Is this easy to trigger for you?

thanks,

greg k-h

Re: [GIT PATCH] USB patches for 2.6.17

[Linus Torvalds]

On Thu, 22 Jun 2006, Greg KH wrote:
>
> I saw this once when debugging the usb code, but could never reproduce
> it, so I attributed it to an incomplete build at the time, as a reboot
> fixed it.

I'm pretty sure the build was good, but it may well be timing-related.

> Is this easy to trigger for you?

No. I've never seen it before on this machine (and it's that Mac Mini that 
I've been rebooting several times a day for the last week), so if it's an 
old bug, it's definitely not repeatable. I was thinking it would be 
something new..

I'll let you know if I can repro it.

		Linus

Re: [GIT PATCH] USB patches for 2.6.17

[Greg KH]

On Thu, Jun 22, 2006 at 04:48:43PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 22 Jun 2006, Greg KH wrote:
> >
> > I saw this once when debugging the usb code, but could never reproduce
> > it, so I attributed it to an incomplete build at the time, as a reboot
> > fixed it.
> 
> I'm pretty sure the build was good, but it may well be timing-related.
> 
> > Is this easy to trigger for you?
> 
> No. I've never seen it before on this machine (and it's that Mac Mini that 
> I've been rebooting several times a day for the last week), so if it's an 
> old bug, it's definitely not repeatable. I was thinking it would be 
> something new..

I would think it's something new too, as I did change that very line
that oopsed.  That's why I found it odd that I couldn't reproduce it
anymore.

> I'll let you know if I can repro it.

Thanks, that would help out a lot.

greg k-h

Re: [GIT PATCH] USB patches for 2.6.17

[Jeremy Fitzhardinge]

Greg KH wrote:
> I saw this once when debugging the usb code, but could never reproduce
> it, so I attributed it to an incomplete build at the time, as a reboot
> fixed it.
>
> Is this easy to trigger for you?
>   

This is the same oops as I posted yesterday: "2.6.17-mm1: oops in 
Bluetooth stuff, usbdev_open".  I haven't seen it since...

    J

Re: [GIT PATCH] USB patches for 2.6.17

[Andrew Morton]

Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
> Greg KH wrote:
> > I saw this once when debugging the usb code, but could never reproduce
> > it, so I attributed it to an incomplete build at the time, as a reboot
> > fixed it.
> >
> > Is this easy to trigger for you?
> >   
> 
> This is the same oops as I posted yesterday: "2.6.17-mm1: oops in 
> Bluetooth stuff, usbdev_open".  I haven't seen it since...
> 

That's a kernel-wide list of USB devices, isn't it?  Which means that some
driver other than the bluetooth one has got itself freed up while still
being on the list.

If so, it could be any driver at all..

Re: [GIT PATCH] USB patches for 2.6.17

[Greg KH]

On Thu, Jun 22, 2006 at 05:17:32PM -0700, Andrew Morton wrote:
> Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> >
> > Greg KH wrote:
> > > I saw this once when debugging the usb code, but could never reproduce
> > > it, so I attributed it to an incomplete build at the time, as a reboot
> > > fixed it.
> > >
> > > Is this easy to trigger for you?
> > >   
> > 
> > This is the same oops as I posted yesterday: "2.6.17-mm1: oops in 
> > Bluetooth stuff, usbdev_open".  I haven't seen it since...
> > 
> 
> That's a kernel-wide list of USB devices, isn't it?  Which means that some
> driver other than the bluetooth one has got itself freed up while still
> being on the list.
> 
> If so, it could be any driver at all..

Hopefully we have the list locked properly while we are walking it, so
that should not happen, but I'll go back and verify that I got it all
correct...

thanks,

greg k-h

Re: [GIT PATCH] USB patches for 2.6.17

[Andrew Morton]

Greg KH <gregkh@suse.de> wrote:
>
> I would think it's something new too, as I did change that very line
> that oopsed.  That's why I found it odd that I couldn't reproduce it
> anymore.

device_destroy() looks wrong.  It alters the class->devices list outside
its lock.

--- 25/drivers/base/core.c~device_destroy-locking-fix	Thu Jun 22 17:29:07 2006
+++ 25-akpm/drivers/base/core.c	Thu Jun 22 17:29:34 2006
@@ -632,14 +632,13 @@ void device_destroy(struct class *class,
 	list_for_each_entry(dev_tmp, &class->devices, node) {
 		if (dev_tmp->devt == devt) {
 			dev = dev_tmp;
+			list_del_init(&dev->node);
 			break;
 		}
 	}
 	up(&class->sem);
 
-	if (dev) {
-		list_del_init(&dev->node);
+	if (dev)
 		device_unregister(dev);
-	}
 }
 EXPORT_SYMBOL_GPL(device_destroy);

That won't be it though.

Re: [GIT PATCH] USB patches for 2.6.17

[Greg KH]

On Thu, Jun 22, 2006 at 05:22:30PM -0700, Greg KH wrote:
> On Thu, Jun 22, 2006 at 05:17:32PM -0700, Andrew Morton wrote:
> > Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> > >
> > > Greg KH wrote:
> > > > I saw this once when debugging the usb code, but could never reproduce
> > > > it, so I attributed it to an incomplete build at the time, as a reboot
> > > > fixed it.
> > > >
> > > > Is this easy to trigger for you?
> > > >   
> > > 
> > > This is the same oops as I posted yesterday: "2.6.17-mm1: oops in 
> > > Bluetooth stuff, usbdev_open".  I haven't seen it since...
> > > 
> > 
> > That's a kernel-wide list of USB devices, isn't it?  Which means that some
> > driver other than the bluetooth one has got itself freed up while still
> > being on the list.
> > 
> > If so, it could be any driver at all..
> 
> Hopefully we have the list locked properly while we are walking it, so
> that should not happen, but I'll go back and verify that I got it all
> correct...

Oh crap, that's it.  There's a race when a device switches
configurations and the endpoints disappear.  I was locking in the wrong
functions...  Let me beat on the fix for a bit to make sure I have it
right.

thanks,

greg k-h

Re: [GIT PATCH] USB patches for 2.6.17

[Greg KH]

On Thu, Jun 22, 2006 at 05:32:15PM -0700, Andrew Morton wrote:
> Greg KH <gregkh@suse.de> wrote:
> >
> > I would think it's something new too, as I did change that very line
> > that oopsed.  That's why I found it odd that I couldn't reproduce it
> > anymore.
> 
> device_destroy() looks wrong.  It alters the class->devices list outside
> its lock.
> 
> --- 25/drivers/base/core.c~device_destroy-locking-fix	Thu Jun 22 17:29:07 2006
> +++ 25-akpm/drivers/base/core.c	Thu Jun 22 17:29:34 2006
> @@ -632,14 +632,13 @@ void device_destroy(struct class *class,
>  	list_for_each_entry(dev_tmp, &class->devices, node) {
>  		if (dev_tmp->devt == devt) {
>  			dev = dev_tmp;
> +			list_del_init(&dev->node);
>  			break;
>  		}
>  	}
>  	up(&class->sem);
>  
> -	if (dev) {
> -		list_del_init(&dev->node);
> +	if (dev)
>  		device_unregister(dev);
> -	}
>  }
>  EXPORT_SYMBOL_GPL(device_destroy);
> 
> That won't be it though.

No, and that function doesn't get called for the usb endpoints, it goes
through a different path, that's the problem...  I think I've found it
now, let me reboot a bunch...

thanks,

greg k-h

Re: [GIT PATCH] USB patches for 2.6.17

[Greg KH]

On Thu, Jun 22, 2006 at 04:11:26PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 21 Jun 2006, Greg KH wrote:
> >
> > Here are a lot of USB patches for 2.6.17.  They do the following:
> 
> I think these may be responsible for:
> 
> 	Bluetooth: L2CAP ver 2.8
> 	Bluetooth: L2CAP socket layer initialized
> 	Bluetooth: HIDP (Human Interface Emulation) ver 1.1
> 	Bluetooth: RFCOMM socket layer initialized
> 	Bluetooth: RFCOMM TTY layer initialized
> 	Bluetooth: RFCOMM ver 1.7
> 	BUG: unable to handle kernel paging request at virtual address 5a5a5a5a
> 	 printing eip:
> 	c02a58f8
> 	*pde = 00000000
> 	Oops: 0000 [#1]
> 	SMP 
> 	Modules linked in: rfcomm hidp l2cap hci_usb bluetooth ip_conntrack_netbios_ns ipt_REJECT iptable_filter ip_tables ip6table_filter ip6_tables cpufreq_ondemand lp pcspkr intel_agp agpgart
> 	CPU:    0
> 	EIP:    0060:[<c02a58f8>]    Not tainted VLI
> 	EFLAGS: 00210206   (2.6.17-gd588fcbe #211) 
> 	EIP is at usbdev_open+0xb4/0x1ec
> 	eax: 0bd00005   ebx: 5a5a5a5a   ecx: 5a5a58d2   edx: dd991e4c
> 	esi: de020bdc   edi: c712da68   ebp: c6eeaee8   esp: c6eeaeac
> 	ds: 007b   es: 007b   ss: 0068
> 	Process hid2hci (pid: 3719, threadinfo=c6eea000 task=ddfb8570)
> 	Stack: c854dc28 dd22cd70 00000000 00000005 c6eeaed4 c016bd39 c6eeaf3c 00000001 
> 	       c6eea000 00000000 dd22cd70 c6eeaee8 00000000 c050b8a0 dd22cd70 c6eeaf04 
> 	       c01678a4 c854dc28 c6eeaf04 c854dc28 dd22cd70 00000000 c6eeaf20 c015e424 
> 	Call Trace:
> 	 <c0103c46> show_stack_log_lvl+0x85/0x8f  <c0103dc3> show_registers+0x13b/0x1af
> 	 <c0103fac> die+0x175/0x285  <c011a86d> do_page_fault+0x428/0x522
> 	 <c0103777> error_code+0x4f/0x54  <c01678a4> chrdev_open+0x11a/0x171
> 	 <c015e424> __dentry_open+0xc8/0x1ab  <c015e575> nameidata_to_filp+0x1c/0x2e
> 	 <c015e5b5> do_filp_open+0x2e/0x35  <c015e5fc> do_sys_open+0x40/0xba
> 	 <c015e6a2> sys_open+0x16/0x18  <c0102c0f> sysenter_past_esp+0x54/0x75
> 	Code: 00 8b 35 cc 77 61 c0 8b 8e 9c 00 00 00 81 e9 88 01 00 00 eb 16 8b 45 d0 0d 00 00 d0 0b 39 81 94 01 00 00 74 81 8d 8b 78 
> 	fe ff ff <8b> 99 88 01 00 00 0f 18 03 90 8d 91 88 01 00 00 8d 86 9c 00 00 
> 	EIP: [<c02a58f8>] usbdev_open+0xb4/0x1ec SS:ESP 0068:c6eeaeac
> 
> where that 5a5a5a5a is possibly/probably due to SLAB debugging (it's the 
> "POISON_INUSE" pattern)
> 
> It might have happened before too, of course, I just haven't seen it 
> before (even though I've had SLAB debugging on all the time on that 
> machine).
> 
> It seems to actually be from usbdev_lookup_minor(), which has been inlined 
> (damn compiler), and it's the "node.next" access in the
> 
> 	list_for_each_entry(device, &usb_device_class->devices, node) {
> 
> loop.
> 
> Any ideas? 

Ok, this was a stupid one on my part, I'm really surprised that it
didn't trigger all the time.  Here's a patch for it.  Sorry about this.

This just survived a lot of unloads and reloads and devices disappearing
and added.

thanks,

greg k-h

---------------------

From: Greg Kroah-Hartman <gregkh@suse.de>
Subject: Driver core: fix locking issues with the devices that are attached to classes

Doh, that was foolish...

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/base/core.c |   19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

--- gregkh-2.6.orig/drivers/base/core.c
+++ gregkh-2.6/drivers/base/core.c
@@ -356,6 +356,13 @@ int device_add(struct device *dev)
 	if (parent)
 		klist_add_tail(&dev->knode_parent, &parent->klist_children);
 
+	if (dev->class) {
+		/* tie the class to the device */
+		down(&dev->class->sem);
+		list_add_tail(&dev->node, &dev->class->devices);
+		up(&dev->class->sem);
+	}
+
 	/* notify platform of device entry */
 	if (platform_notify)
 		platform_notify(dev);
@@ -456,6 +463,9 @@ void device_del(struct device * dev)
 		sysfs_remove_link(&dev->kobj, "device");
 		sysfs_remove_link(&dev->parent->kobj, class_name);
 		kfree(class_name);
+		down(&dev->class->sem);
+		list_del_init(&dev->node);
+		up(&dev->class->sem);
 	}
 	device_remove_file(dev, &dev->uevent_attr);
 
@@ -602,11 +612,6 @@ struct device *device_create(struct clas
 	if (retval)
 		goto error;
 
-	/* tie the class to the device */
-	down(&class->sem);
-	list_add_tail(&dev->node, &class->devices);
-	up(&class->sem);
-
 	return dev;
 
 error:
@@ -637,9 +642,7 @@ void device_destroy(struct class *class,
 	}
 	up(&class->sem);
 
-	if (dev) {
-		list_del_init(&dev->node);
+	if (dev)
 		device_unregister(dev);
-	}
 }
 EXPORT_SYMBOL_GPL(device_destroy);

Re: [GIT PATCH] USB patches for 2.6.17

[Evgeniy Polyakov]

On Thu, Jun 22, 2006 at 11:54:56AM -0700, Greg KH (gregkh@suse.de) wrote:
> On Thu, Jun 22, 2006 at 11:49:00AM -0700, Randy.Dunlap wrote:
> > 
> > Um, I was going to say that my patch wasn't listed in the
> > shortlog that you sent (for W1), but it's there, just mis-attributed
> > to Evgeniy (#13/14).
> 
> I think that happened as Evgeniy sent it to me without the "From:" line
> on the top of the email, which would have preserved your attribute.
> Evgeniy, care to do that next time?

I.e. first line should look like
From: Someone Who Sent be the mail <and address here> ?

Sure will do.

> thanks,
> 
> greg k-h

-- 
	Evgeniy Polyakov

Re: [GIT PATCH] USB patches for 2.6.17

[Greg KH]

On Fri, Jun 23, 2006 at 09:52:41AM +0400, Evgeniy Polyakov wrote:
> On Thu, Jun 22, 2006 at 11:54:56AM -0700, Greg KH (gregkh@suse.de) wrote:
> > On Thu, Jun 22, 2006 at 11:49:00AM -0700, Randy.Dunlap wrote:
> > > 
> > > Um, I was going to say that my patch wasn't listed in the
> > > shortlog that you sent (for W1), but it's there, just mis-attributed
> > > to Evgeniy (#13/14).
> > 
> > I think that happened as Evgeniy sent it to me without the "From:" line
> > on the top of the email, which would have preserved your attribute.
> > Evgeniy, care to do that next time?
> 
> I.e. first line should look like
> From: Someone Who Sent be the mail <and address here> ?

Yes, that's the correct format.

thanks,

greg k-h