linux-toradex.git/drivers/usb, branch v2.6.18.3 Linux kernel for Apalis and Colibri modules [PATCH] correct keymapping on Powerbook built-in USB ISO keyboards 2006-11-19T03:28:03+00:00 Olaf Hering olh@suse.de 2006-11-09T03:58:07+00:00 26192851aed037f2c928d9cc5d42f507876625b5 similar to the version in adbhid_input_register(): The '<>' key and the '^°' key on a german keyboard is swapped. Provide correct keys to userland, external USB keyboards will not work correctly when the 'badmap'/'goodmap' workarounds from xkeyboard-config are used. It is expected that distributions drop the badmap/goodmap part from keycodes/macintosh in the xkeyboard-config package. This is probably 2.6.18.x material, if major distros settle on 2.6.18. Signed-off-by: Olaf Hering <olh@suse.de> Cc: Greg KH <greg@kroah.com> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
similar to the version in adbhid_input_register(): The '<>' key and the
'^°' key on a german keyboard is swapped.  Provide correct keys to
userland, external USB keyboards will not work correctly when the
'badmap'/'goodmap' workarounds from xkeyboard-config are used.

It is expected that distributions drop the badmap/goodmap part from
keycodes/macintosh in the xkeyboard-config package.

This is probably 2.6.18.x material, if major distros settle on 2.6.18.

Signed-off-by: Olaf Hering <olh@suse.de>
Cc: Greg KH <greg@kroah.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
[PATCH] usbtouchscreen: use endpoint address from endpoint descriptor 2006-11-19T03:28:01+00:00 Daniel Ritz daniel.ritz-ml@swissonline.ch 2006-11-03T22:59:28+00:00 b7d3dcaa7a0b39129ac089ab1a6d9179c0a7fb1b use the endpoint address from the endpoint descriptor instead of the hardcoding it to 0x81. at least some ITM based screen use a different address and don't work without this. Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Cc: Ralf Lehmann <ralf@lehmann.cc> Cc: J.P. Delport <jpdelport@csir.co.za> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
use the endpoint address from the endpoint descriptor instead of the hardcoding
it to 0x81. at least some ITM based screen use a different address and don't work
without this.

Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Cc: Ralf Lehmann <ralf@lehmann.cc>
Cc: J.P. Delport <jpdelport@csir.co.za>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
[PATCH] USB: failure in usblp's error path 2006-11-19T03:28:01+00:00 Oliver Neukum oliver@neukum.name 2006-11-03T22:59:29+00:00 fa4788169281af4b64d1fb077f6312fef535c184 USB: failure in usblp's error path if urb submission fails due to a transient error here eg. ENOMEM , the driver is dead. This fixes it. Regards Oliver Signed-off-by: Oliver Neukum <oliver@neukum.name> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
USB: failure in usblp's error path

if urb submission fails due to a transient error here eg. ENOMEM
, the driver is dead. This fixes it.

	Regards
		Oliver

Signed-off-by: Oliver Neukum <oliver@neukum.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
[PATCH] usbfs: private mutex for open, release, and remove 2006-11-04T01:33:50+00:00 Alan Stern stern@rowland.harvard.edu 2006-07-02T02:05:01+00:00 108d51a5710a51ed46353655efc7d165b4c57b60 The usbfs code doesn't provide sufficient mutual exclusion among open, release, and remove. Release vs. remove is okay because they both acquire the device lock, but open is not exclusive with either one. All three routines modify the udev->filelist linked list, so they must not run concurrently. Apparently someone gave this a minimum amount of thought in the past by explicitly acquiring the BKL at the start of the usbdev_open routine. Oddly enough, there's a comment pointing out that locking is unnecessary because chrdev_open already has acquired the BKL. But this ignores the point that the files in /proc/bus/usb/* are not char device files; they are regular files and so they don't get any special locking. Furthermore it's necessary to acquire the same lock in the release and remove routines, which the code does not do. Yet another problem arises because the same file_operations structure is accessible through both the /proc/bus/usb/* and /dev/usb/usbdev* file nodes. Even when one of them has been removed, it's still possible for userspace to open the other. So simple locking around the individual remove routines is insufficient; we need to lock the entire usb_notify_remove_device notifier chain. Rather than rely on the BKL, this patch (as723) introduces a new private mutex for the purpose. Holding the BKL while invoking a notifier chain doesn't seem like a good idea. Cc: Dave Jones <davej@redhat.com> [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212952] Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org> 
The usbfs code doesn't provide sufficient mutual exclusion among open,
release, and remove.  Release vs. remove is okay because they both
acquire the device lock, but open is not exclusive with either one.  All
three routines modify the udev->filelist linked list, so they must not
run concurrently.

Apparently someone gave this a minimum amount of thought in the past by
explicitly acquiring the BKL at the start of the usbdev_open routine.
Oddly enough, there's a comment pointing out that locking is unnecessary
because chrdev_open already has acquired the BKL.

But this ignores the point that the files in /proc/bus/usb/* are not
char device files; they are regular files and so they don't get any
special locking.  Furthermore it's necessary to acquire the same lock in
the release and remove routines, which the code does not do.

Yet another problem arises because the same file_operations structure is
accessible through both the /proc/bus/usb/* and /dev/usb/usbdev* file
nodes.  Even when one of them has been removed, it's still possible for
userspace to open the other.  So simple locking around the individual
remove routines is insufficient; we need to lock the entire
usb_notify_remove_device notifier chain.

Rather than rely on the BKL, this patch (as723) introduces a new private
mutex for the purpose.  Holding the BKL while invoking a notifier chain
doesn't seem like a good idea.

Cc: Dave Jones <davej@redhat.com>
[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212952]
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
USB: Allow compile in g_ether, fix typo 2006-10-13T20:23:21+00:00 Tony Lindgren tony@atomide.com 2006-09-23T03:17:48+00:00 edd5ef8326717b3d90f57daf565ff45fc7fddf99 Allows compiling g_ether in and fixes a typo with MUSB_HDRC Signed-off-by: Tony Lindgren <tony@atomide.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
Allows compiling g_ether in and fixes a typo with MUSB_HDRC

Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: Fix unload oops and memory leak in yealink driver 2006-09-12T10:10:21+00:00 Henk Vergonet Henk.Vergonet@gmail.com 2006-09-08T00:21:01+00:00 3e2aac366f40f4cf4f3b1d9101b27f703998dfbc This patch fixes a memory leak and a kernel oops when trying to unload the driver, due to an unbalanced cleanup. Thanks Ivar Jensen for spotting my mistake. Signed-off-by: Henk Vergonet <henk.vergonet@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This patch fixes a memory leak and a kernel oops when trying to unload
the driver, due to an unbalanced cleanup.
Thanks Ivar Jensen for spotting my mistake.

Signed-off-by: Henk Vergonet <henk.vergonet@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usbserial: Reference leak 2006-09-12T10:10:20+00:00 Matthias Urlichs smurf@smurf.noris.de 2006-09-11T10:35:20+00:00 5992583889ce6b7960e8023e356b2a0930ebce7c A sufficiently-large number of USB serial devices causes a reference leak when /proc/tty/drivers/usbserial is read. Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
A sufficiently-large number of USB serial devices causes a reference leak
when /proc/tty/drivers/usbserial is read.

Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usbtouchscreen: fix ITM data reading 2006-09-07T22:23:04+00:00 Kai Lindhom megantti@gmail.com 2006-09-07T19:25:51+00:00 09494d5d11628f118496747b74db3e56d071c6bc From: Kai Lindhom <megantti@gmail.com> Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Acked-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
From: Kai Lindhom <megantti@gmail.com>
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Acked-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: New device ID for ftdi_sio usb serial driver 2006-09-07T22:23:04+00:00 Ralf Schlatterbeck rsc@runtux.com 2006-09-06T10:15:02+00:00 eaede2cb75f8f8d492342e7c1469635237b32795 The patch adds a new device ID for the Gamma Scout Geiger counter device. Signed-off-by: Ralf Schlatterbeck <rsc@runtux.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
The patch adds a new device ID for the Gamma Scout Geiger counter
device.

Signed-off-by: Ralf Schlatterbeck <rsc@runtux.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
USB: Support for USB20SVGA-WH & USB20SVGA-DG 2006-09-07T22:23:04+00:00 Nobuhiro Iwamatsu hemamu@t-base.ne.jp 2006-09-01T02:32:28+00:00 3003b9f78920226367c2f2d3a5598397578a730b This patch is support USB20SVGA-WH & USB20SVGA-DG of the sisusb device. As for this device, Device ID is different according to the color of the product. A blue device is supported. However, a green, white device is not supported. http://www.lubic.jp/uv_method.html ( Japanese only ) . Green, white USB20SVGA comes to work by applying the patch . And, it be able to use three USB20SVGA( Blue , Green , White ). Signed-off-by: Nobuhiro Iwamatsu <hemamu@t-base.ne.jp> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 
This patch is support USB20SVGA-WH & USB20SVGA-DG of the sisusb device.
As for this device, Device ID is different according to the color of the
product.  A blue device is supported. However, a green, white device is
not supported.

http://www.lubic.jp/uv_method.html ( Japanese only ) .

Green, white USB20SVGA comes to work by applying the patch .
And, it  be able to use three USB20SVGA( Blue , Green , White ).

Signed-off-by: Nobuhiro Iwamatsu <hemamu@t-base.ne.jp>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>