[PATCH] USB: compilation failure on usb/image/microtek.c

maybe typo?

Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: clean up all iPod models in unusual_devs.h

Phil Dibowitz wrote:
> 1. You're adding product IDs 1202, 1203, 1204, and 1205. 1203 was
> already there, but you remove it, OK, but 1205 is already there, so
> you'll need to fix that.

I was not removing 1203, it's just the extension of the bcd range. You are 
right about 1205, as I wrote, it was a patch against 2.6.11.7. Attached is 
a patch against 2.6.12-rc2.

> 2. I'm OK with the full bcd range if Apple is changing it on firmware
> revs... fine, but it's bcd, not hex... 0x9999 =)

I just copied from other entries. There're a lot 0xffffs in unusual_dev.h, 
so I assumed it is correct. I changed it to 0x9999.

> 3. It's rather obnoxious to take the original submitter's credit away.

I didn't remove it, I changed it to "based on...". Because I changed 
something (the range) in his entry, I thought it is the best to take the 
responsibility but keep the origin. Anyway, in the new patch I did it in a 
different way.

> 4. Your /proc/bus/usb/devices shows 1204, but I see no evidence 1202 is
> really an iPod.

I don't have an old iPod mini, but you find a lot of evidence here:

http://www.google.com/search?q=0x1202+ipod

Especially this one:

http://www.qbik.ch/usb/devices/showdescr.php?id=2737

> It also looks like 1205's entry is getting mangled, but I haven't
> attempted to apply the patch, so I'm not sure.

No, the patch was ok, but I agree it looks strange. It's not very 
readable, because I cannot tell diff to work blockwise instead of 
linewise. Because of the similarity of the entries, diff splits and merges 
them. Anyway, the new patch "looks" better. ;-)

Signed-off-by: Sven Anderson <sven-linux@anderson.de>
Signed-off-by: Phil Dibowitz <phil@ipom.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: add HP49G+ Calculator USB Serial support

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: fix up the HP49G+ Calculator USB Serial driver

Fix compiler warnings, and remove unneeded #includes

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: new SiS device id

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: drivers/usb/input/usbkbd.c: make a function static

This patch makes a needlessly global function static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: drivers/usb/media/sn9c102_core.c: make 2 functions static

This patch makes two needlessly global functions static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: drivers/usb/media/pwc/: make code static

This patch makes needlessly global code static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: drivers/usb/net/zd1201.c: make some code static

This patch makes some needlessly global code static.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: scripts/mod/file2alias.c: handle numeric ranges for USB bcdDevice

Another attempt at that...

The attached patch fixes the longstanding problem with USB bcdDevice
numeric ranges incorrectly converted into patterns for MODULE_ALIAS
generation.  Previously it put both the lower and the upper limits into
the pattern, dlXdhY, making it impossible to fnmatch against except for
a few special cases, like dl*dh* or dlXdhX.

The patch makes it generate multiple MODULE_ALIAS lines covering the
whole range with fnmatch-able patterns.  E.g. for a range between 0x0001
and 0x8345 it gives the following patterns:

000[1-9]
00[1-9]*
0[1-9]*
[1-7]*
8[0-2]*
83[0-3]*
834[0-5]

Since bcdDevice is 2 bytes wide = 4 digits in hex representation, the
max no. of patters is 2 * 4 - 1 = 7.

The values are BCD (binary-coded decimals) and not hex, so patterns
using a dash seem to be safe regardless of locale collation order.

The patch changes bcdDevice part of the alias from dlXdhY to dZ, but
this shouldn't have big compatibility issues because fnmatch()-based
modprobing hasn't yet been widely used.  Besides, the most common (and
almost the only working) case of dl*dh* becomes d* and thus continues to
work.

The patch is against 2.6.12-rc2, applies to -mm3 with an offset.  The
matching patch to fix the MODALIAS environment variable now generated by
the usb hotplug function follows.

Signed-off-by: Roman Kagan <rkagan@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: MODALIAS change for bcdDevice

The patch below adjusts the MODALIAS generated by the usb hotplug
function to match the proposed change to scripts/mod/file2alias.c.

Signed-off-by: Roman Kagan <rkagan@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] usbnet: Convert ASIX code to use new status infrastructure

Modify the ASIX USB Ethernet code to make use of the new status
infrastructure in usbnet.

Additionally, add a link_reset() handler to the struct usbnet
structure to provide a generic means for a driver to perform link
reset tasks such as a determining link speed and setting
device flags accordingly.


Signed-off-by: David Hollis <dhollis@davehollis.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: better usbnet zaurus/mdlm/... fix

This is a somewhat more comprehensive fix for the problem of devices
like the newer Zaurii ... or in this case some Motorola cell phones.

To recap, the problem's root cause is that these devices aren't using
standard USB class specifications for their network links, and so far
we've had to add lots of device-specific driver entries.  The vendor
fix abuses the CDC MDLM descriptors (they _could_ have conformed to
the spec, but didn't) and defines a "Belcarra firmware" pseudo-class.

This patch recognizes that pseudo-class by the GUIDs in those descriptors,
and handles the devices that just use the Zaurus framing.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] USB: Fix for ati_remote

when stealing code from ati_remote for a GPL-driver of my usbradio (because of
its neat usb int transfers) I found out, that the inbuf is freed twice.

I don't have the ati-remote, so I don't know it is a problem at all, but it
looks strange to me anyway. Also I don't know if it has been fixed already in
newer kernel versions.


From: Patrick Boettcher <patrick.boettcher@desy.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[AX25] Introduce ax25_type_trans

Replacing the open coded equivalents and making ax25 look more like
a linux network protocol, i.e. more similar to inet.

Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[ATM]: [he] Use the DMA_32BIT_MASK constant from dma-mapping.h

Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch>
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>
[ATM]: [fore200e] pci doesn't use global board list; use pci_register_driver()

Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>
[SLIP]: Remove redundant NULL pointer checks prior to kfree

Signed-off-by: Jesper Juhl <juhl-lkml@dif.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
[TCP]: skb pcount with MTU discovery

The problem is that when doing MTU discovery, the too-large segments in
the write queue will be calculated as having a pcount of >1.  When
tcp_write_xmit() is trying to send, tcp_snd_test() fails the cwnd test
when pcount > cwnd.

The segments are eventually transmitted one at a time by keepalive, but
this can take a long time.

This patch checks if TSO is enabled when setting pcount.

Signed-off-by: John Heffner <jheffner@psc.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
[ATM]: ENI155P error handling fix

From: Panagiotis Issaris <takis@lumumba.luc.ac.be>

In the ENI155P device driver in six possible failure cases the requested
irq is not being released.

In three of the above possible failure cases additionally there seems to
be a memory leak.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>