9 years agolockd: use rpc client's cl_nodename for id encoding
Stanislav Kinsbursky [Tue, 18 Sep 2012 09:37:18 +0000 (13:37 +0400)]
lockd: use rpc client's cl_nodename for id encoding

commit 303a7ce92064c285a04c870f2dc0192fdb2968cb upstream.

Taking hostname from uts namespace if not safe, because this cuold be
performind during umount operation on child reaper death. And in this case
current->nsproxy is NULL already.

Signed-off-by: Stanislav Kinsbursky <>
Signed-off-by: Trond Myklebust <>
Signed-off-by: Ben Hutchings <>
9 years agolocalmodconfig: Fix localyesconfig to set to 'y' not 'm'
Yuta Ando [Mon, 1 Oct 2012 14:24:30 +0000 (23:24 +0900)]
localmodconfig: Fix localyesconfig to set to 'y' not 'm'

commit 4eae518d4b01b0cbf2f0d8edb5a6f3d6245ee8fb upstream.

The kbuild target 'localyesconfig' has been same as 'localmodconfig'
since the commit 50bce3e "kconfig/ merge
local{mod,yes}config". The commit expects this script generates
different configure depending on target, but it was not yet implemented.

So I added code that sets to 'yes' when target is 'localyesconfig'.

Signed-off-by: Yuta Ando <>
Signed-off-by: Steven Rostedt <>
Signed-off-by: Ben Hutchings <>
9 years agoIB/srp: Avoid having aborted requests hang
Bart Van Assche [Fri, 24 Aug 2012 10:29:11 +0000 (10:29 +0000)]
IB/srp: Avoid having aborted requests hang

commit d8536670916a685df116b5c2cb256573fd25e4e3 upstream.

We need to call scsi_done() for commands after we abort them.

Signed-off-by: Bart Van Assche <>
Acked-by: David Dillow <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Ben Hutchings <>
9 years agoIB/srp: Fix use-after-free in srp_reset_req()
Bart Van Assche [Fri, 24 Aug 2012 10:27:54 +0000 (10:27 +0000)]
IB/srp: Fix use-after-free in srp_reset_req()

commit 9b796d06d5d1b1e85ae2316a283ea11dd739ef96 upstream.

srp_free_req() uses the scsi_cmnd structure contents to unmap
buffers, so we must invoke srp_free_req() before we release
ownership of that structure.

Signed-off-by: Bart Van Assche <>
Acked-by: David Dillow <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Ben Hutchings <>
9 years agoIPoIB: Fix use-after-free of multicast object
Patrick McHardy [Thu, 30 Aug 2012 07:01:30 +0000 (07:01 +0000)]
IPoIB: Fix use-after-free of multicast object

commit bea1e22df494a729978e7f2c54f7bda328f74bc3 upstream.

Fix a crash in ipoib_mcast_join_task().  (with help from Or Gerlitz)

Commit c8c2afe360b7 ("IPoIB: Use rtnl lock/unlock when changing device
flags") added a call to rtnl_lock() in ipoib_mcast_join_task(), which
is run from the ipoib_workqueue, and hence the workqueue can't be
flushed from the context of ipoib_stop().

In the current code, ipoib_stop() (which doesn't flush the workqueue)
calls ipoib_mcast_dev_flush(), which goes and deletes all the
multicast entries.  This takes place without any synchronization with
a possible running instance of ipoib_mcast_join_task() for the same
ipoib device, leading to a crash due to NULL pointer dereference.

Fix this by making sure that the workqueue is flushed before
ipoib_mcast_dev_flush() is called.  To make that possible, we move the
RTNL-lock wrapped code to ipoib_mcast_join_finish().

Signed-off-by: Patrick McHardy <>
Signed-off-by: Roland Dreier <>
Signed-off-by: Ben Hutchings <>
9 years agomtd: nandsim: bugfix: fail if overridesize is too big
Richard Genoud [Wed, 12 Sep 2012 12:26:26 +0000 (14:26 +0200)]
mtd: nandsim: bugfix: fail if overridesize is too big

commit bb0a13a13411c4ce24c48c8ff3cdf7b48d237240 upstream.

If override size is too big, the module was actually loaded instead of
failing, because retval was not set.

This lead to memory corruption with the use of the freed structs nandsim
and nand_chip.

Signed-off-by: Richard Genoud <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: David Woodhouse <>
Signed-off-by: Ben Hutchings <>
9 years agoJFFS2: don't fail on bitflips in OOB
Brian Norris [Fri, 31 Aug 2012 22:01:19 +0000 (15:01 -0700)]
JFFS2: don't fail on bitflips in OOB

commit 74d83beaa229aac7d126ac1ed9414658ff1a89d2 upstream.

JFFS2 was designed without thought for OOB bitflips, it seems, but they
can occur and will be reported to JFFS2 via mtd_read_oob()[1]. We don't
want to fail on these transactions, since the data was corrected.

[1] Few drivers report bitflips for OOB-only transactions. With such
    drivers, this patch should have no effect.

Signed-off-by: Brian Norris <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: David Woodhouse <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agomtd: omap2: fix module loading
Andreas Bießmann [Fri, 31 Aug 2012 11:35:42 +0000 (13:35 +0200)]
mtd: omap2: fix module loading

commit 4d3d688da8e7016f15483e9319b41311e1db9515 upstream.

Unloading the omap2 nand driver missed to release the memory region which will
result in not being able to request it again if one want to load the driver
later on.

This patch fixes following error when loading omap2 module after unloading:
~ $ rmmod omap2
~ $ modprobe omap2
[   37.420928] omap2-nand: probe of omap2-nand.0 failed with error -16
~ $

This error was introduced in 67ce04bf2746f8a1f8c2a104b313d20c63f68378 which
was the first commit of this driver.

Signed-off-by: Andreas Bießmann <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: David Woodhouse <>
Signed-off-by: Ben Hutchings <>
9 years agomtd: omap2: fix omap_nand_remove segfault
Andreas Bießmann [Fri, 31 Aug 2012 11:35:41 +0000 (13:35 +0200)]
mtd: omap2: fix omap_nand_remove segfault

commit 7d9b110269253b1d5858cfa57d68dfc7bf50dd77 upstream.

Do not kfree() the mtd_info; it is handled in the mtd subsystem and
already freed by nand_release(). Instead kfree() the struct
omap_nand_info allocated in omap_nand_probe which was not freed before.

This patch fixes following error when unloading the omap2 module:

~ $ rmmod omap2
------------[ cut here ]------------
kernel BUG at mm/slab.c:3126!
Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
Modules linked in: omap2(-)
CPU: 0    Not tainted  (3.6.0-rc3-00230-g155e36d-dirty #3)
PC is at cache_free_debugcheck+0x2d4/0x36c
LR is at kfree+0xc8/0x2ac
pc : [<c01125a0>]    lr : [<c0112efc>]    psr: 200d0193
sp : c521fe08  ip : c0e8ef90  fp : c521fe5c
r10: bf0001fc  r9 : c521e000  r8 : c0d99c8c
r7 : c661ebc0  r6 : c065d5a4  r5 : c65c4060  r4 : c78005c0
r3 : 00000000  r2 : 00001000  r1 : c65c4000  r0 : 00000001
Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 86694019  DAC: 00000015
Process rmmod (pid: 549, stack limit = 0xc521e2f0)
Stack: (0xc521fe08 to 0xc5220000)
fe00:                   c008a874 c00bf44c c515c6d0 200d0193 c65c4860 c515c240
fe20: c521fe3c c521fe30 c008a9c0 c008a854 c521fe5c c65c4860 c78005c0 bf0001fc
fe40: c780ff40 a00d0113 c521e000 00000000 c521fe84 c521fe60 c0112efc c01122d8
fe60: c65c4860 c0673778 c06737ac 00000000 00070013 00000000 c521fe9c c521fe88
fe80: bf0001fc c0112e40 c0673778 bf001ca8 c521feac c521fea0 c02ca11c bf0001ac
fea0: c521fec4 c521feb0 c02c82c4 c02ca100 c0673778 bf001ca8 c521fee4 c521fec8
fec0: c02c8dd8 c02c8250 00000000 bf001ca8 bf001ca8 c0804ee0 c521ff04 c521fee8
fee0: c02c804c c02c8d20 bf001924 00000000 bf001ca8 c521e000 c521ff1c c521ff08
ff00: c02c950c c02c7fbc bf001d48 00000000 c521ff2c c521ff20 c02ca3a4 c02c94b8
ff20: c521ff3c c521ff30 bf001938 c02ca394 c521ffa4 c521ff40 c009beb4 bf001930
ff40: c521ff6c 70616d6f b6fe0032 c0014f84 70616d6f b6fe0032 00000081 60070010
ff60: c521ff84 c521ff70 c008e1f4 c00bf328 0001a004 70616d6f c521ff94 0021ff88
ff80: c008e368 0001a004 70616d6f b6fe0032 00000081 c0015028 00000000 c521ffa8
ffa0: c0014dc0 c009bcd0 0001a004 70616d6f bec2ab38 00000880 bec2ab38 00000880
ffc0: 0001a004 70616d6f b6fe0032 00000081 00000319 00000000 b6fe1000 00000000
ffe0: bec2ab30 bec2ab20 00019f00 b6f539c0 60070010 bec2ab38 aaaaaaaa aaaaaaaa
[<c01122cc>] (cache_free_debugcheck+0x0/0x36c) from [<c0112efc>] (kfree+0xc8/0x2ac)
[<c0112e34>] (kfree+0x0/0x2ac) from [<bf0001fc>] (omap_nand_remove+0x5c/0x64 [omap2])
[<bf0001a0>] (omap_nand_remove+0x0/0x64 [omap2]) from [<c02ca11c>] (platform_drv_remove+0x28/0x2c)
 r5:bf001ca8 r4:c0673778
[<c02ca0f4>] (platform_drv_remove+0x0/0x2c) from [<c02c82c4>] (__device_release_driver+0x80/0xdc)
[<c02c8244>] (__device_release_driver+0x0/0xdc) from [<c02c8dd8>] (driver_detach+0xc4/0xc8)
 r5:bf001ca8 r4:c0673778
[<c02c8d14>] (driver_detach+0x0/0xc8) from [<c02c804c>] (bus_remove_driver+0x9c/0x104)
 r6:c0804ee0 r5:bf001ca8 r4:bf001ca8 r3:00000000
[<c02c7fb0>] (bus_remove_driver+0x0/0x104) from [<c02c950c>] (driver_unregister+0x60/0x80)
 r6:c521e000 r5:bf001ca8 r4:00000000 r3:bf001924
[<c02c94ac>] (driver_unregister+0x0/0x80) from [<c02ca3a4>] (platform_driver_unregister+0x1c/0x20)
 r5:00000000 r4:bf001d48
[<c02ca388>] (platform_driver_unregister+0x0/0x20) from [<bf001938>] (omap_nand_driver_exit+0x14/0x1c [omap2])
[<bf001924>] (omap_nand_driver_exit+0x0/0x1c [omap2]) from [<c009beb4>] (sys_delete_module+0x1f0/0x2ec)
[<c009bcc4>] (sys_delete_module+0x0/0x2ec) from [<c0014dc0>] (ret_fast_syscall+0x0/0x48)
 r8:c0015028 r7:00000081 r6:b6fe0032 r5:70616d6f r4:0001a004
Code: e1a00005 eb0d9172 e7f001f2 e7f001f2 (e7f001f2)
---[ end trace 6a30b24d8c0cc2ee ]---
Segmentation fault

This error was introduced in 67ce04bf2746f8a1f8c2a104b313d20c63f68378 which
was the first commit of this driver.

Signed-off-by: Andreas Bießmann <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: David Woodhouse <>
Signed-off-by: Ben Hutchings <>
9 years agomtd: mtdpart: break it as soon as we parse out the partitions
Huang Shijie [Sat, 18 Aug 2012 17:07:41 +0000 (13:07 -0400)]
mtd: mtdpart: break it as soon as we parse out the partitions

commit c51803ddba10d80d9f246066802c6e359cf1d44c upstream.

We may cause a memory leak when the @types has more then one parser.

Take the `default_mtd_part_types` for example. The default_mtd_part_types has
two parsers now: `cmdlinepart` and `ofpart`.

Assume the following case:
The kernel command line sets the partitions like:
But the devicetree file(such as arch/arm/boot/dts/imx28-evk.dts) also sets
the same partitions as the kernel command line does.

In the current code, the partitions parsed out by the `ofpart` will
overwrite the @pparts which has already set by the `cmdlinepart` parser,
and the the partitions parsed out by the `cmdlinepart` is missed.
A memory leak occurs.

So we should break the code as soon as we parse out the partitions,
In actually, this patch makes a priority order between the parsers.
If one parser has already parsed out the partitions successfully,
it's no need to use another parser anymore.

Signed-off-by: Huang Shijie <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: David Woodhouse <>
Signed-off-by: Ben Hutchings <>
9 years agomtd: autcpu12-nvram: Fix compile breakage
Alexander Shiyan [Wed, 15 Aug 2012 16:28:05 +0000 (20:28 +0400)]
mtd: autcpu12-nvram: Fix compile breakage

commit d1f55c680e5d021e7066f4461dd678d42af18898 upstream.

Update driver autcpu12-nvram.c so it compiles; map_read32/map_write32
no longer exist in the kernel so the driver is totally broken.
Additionally, map_info name passed to simple_map_init is incorrect.

Signed-off-by: Alexander Shiyan <>
Acked-by: Arnd Bergmann <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: David Woodhouse <>
Signed-off-by: Ben Hutchings <>
9 years agoInput: synaptics - adjust threshold for treating position values as negative
Seth Forshee [Fri, 28 Sep 2012 17:29:21 +0000 (10:29 -0700)]
Input: synaptics - adjust threshold for treating position values as negative

commit 824efd37415961d38821ecbd9694e213fb2e8b32 upstream.

Commit c039450 (Input: synaptics - handle out of bounds values from the
hardware) caused any hardware reported values over 7167 to be treated as
a wrapped-around negative value. It turns out that some firmware uses
the value 8176 to indicate a finger near the edge of the touchpad whose
actual position cannot be determined. This value now gets treated as
negative, which can cause pointer jumps and broken edge scrolling on
these machines.

I only know of one touchpad which reports negative values, and this
hardware never reports any value lower than -8 (i.e. 8184). Moving the
threshold for treating a value as negative up to 8176 should work fine
then for any hardware we currently know about, and since we're dealing
with unspecified behavior it's probably the best we can do. The special
8176 value is also likely to result in sudden jumps in position, so
let's also clamp this to the maximum specified value for the axis.


Signed-off-by: Seth Forshee <>
Reviewed-by: Daniel Kurtz <>
Tested-by: Alan Swanson <>
Tested-by: Arteom <>
Signed-off-by: Dmitry Torokhov <>
Signed-off-by: Ben Hutchings <>
9 years agostaging: comedi: jr3_pci: fix iomem dereference
Ian Abbott [Thu, 27 Sep 2012 16:45:27 +0000 (17:45 +0100)]
staging: comedi: jr3_pci: fix iomem dereference

commit e1878957b4676a17cf398f7f5723b365e9a2ca48 upstream.

Correct a direct dereference of I/O memory to use an appropriate I/O
memory access function.  Note that the pointer being dereferenced is not
currently tagged with `__iomem` but I plan to correct that for 3.7.

Signed-off-by: Ian Abbott <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agokbuild: Do not package /boot and /lib in make tar-pkg
Michal Marek [Tue, 25 Sep 2012 14:03:03 +0000 (16:03 +0200)]
kbuild: Do not package /boot and /lib in make tar-pkg

commit fe04ddf7c2910362f3817c8156e41cbd6c0ee35d upstream.

There were reports of users destroying their Fedora installs by a kernel
tarball that replaces the /lib -> /usr/lib symlink. Let's remove the
toplevel directories from the tarball to prevent this from happening.

Reported-by: Andi Kleen <>
Suggested-by: Ben Hutchings <>
Signed-off-by: Michal Marek <>
[bwh: Fold in commit 3ce9e53e788881da0d5f3912f80e0dd6b501f304 to avoid
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon: force MSIs on RS690 asics
Alex Deucher [Wed, 26 Sep 2012 16:40:45 +0000 (12:40 -0400)]
drm/radeon: force MSIs on RS690 asics

commit fb6ca6d154cdcd53e7f27f8dbba513830372699b upstream.

There are so many quirks, lets just try and force
this for all RS690s.  See:

Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon: Add MSI quirk for gateway RS690
Alex Deucher [Wed, 26 Sep 2012 16:31:45 +0000 (12:31 -0400)]
drm/radeon: Add MSI quirk for gateway RS690

commit 3a6d59df80897cc87812b6826d70085905bed013 upstream.

Fixes another system on:

Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/radeon: only adjust default clocks on NI GPUs
Alex Deucher [Fri, 14 Sep 2012 14:59:26 +0000 (10:59 -0400)]
drm/radeon: only adjust default clocks on NI GPUs

commit 2e3b3b105ab3bb5b6a37198da4f193cd13781d13 upstream.

SI asics store voltage information differently so we
don't have a way to deal with it properly yet.

Signed-off-by: Alex Deucher <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag
Jani Nikula [Wed, 26 Sep 2012 15:43:10 +0000 (18:43 +0300)]
drm/i915: use adjusted_mode instead of mode for checking the 6bpc force flag

commit 0c96c65b48fba3ffe9822a554cbc0cd610765cd5 upstream.

The dithering introduced in

commit 3b5c78a35cf7511c15e09a9b0ffab290a42d9bcf
Author: Adam Jackson <>
Date:   Tue Dec 13 15:41:00 2011 -0800

    drm/i915/dp: Dither down to 6bpc if it makes the mode fit

stores the INTEL_MODE_DP_FORCE_6BPC flag in the private_flags of the
adjusted mode, while i9xx_crtc_mode_set() and ironlake_crtc_mode_set() use
the original mode, without the flag, so it would never have any
effect. However, the BPC was clamped by VBT settings, making things work by
coincidence, until that part was removed in

commit 4344b813f105a19f793f1fd93ad775b784648b95
Author: Daniel Vetter <>
Date:   Fri Aug 10 11:10:20 2012 +0200

Use adjusted_mode instead of mode when checking for
INTEL_MODE_DP_FORCE_6BPC to make the flag have effect.

v2: Don't forget to fix this in i9xx_crtc_mode_set() also, pointed out by
Daniel both before and after sending the first patch.

CC: Adam Jackson <>
Signed-off-by: Jani Nikula <>
Reviewed-by: Adam Jackson <>
Signed-off-by: Daniel Vetter <>
[bwh: Backported to 3.2:
 - Adjust context
 - intel_choose_pipe_bpp_dither() doesn't take a drm_framebuffer argument]
Signed-off-by: Ben Hutchings <>
9 years agocoredump: prevent double-free on an error path in core dumper
Denys Vlasenko [Wed, 26 Sep 2012 01:34:50 +0000 (11:34 +1000)]
coredump: prevent double-free on an error path in core dumper

commit f34f9d186df35e5c39163444c43b4fc6255e39c5 upstream.

In !CORE_DUMP_USE_REGSET case, if elf_note_info_init fails to allocate
memory for info->fields, it frees already allocated stuff and returns
error to its caller, fill_note_info.  Which in turn returns error to its
caller, elf_core_dump.  Which jumps to cleanup label and calls
free_note_info, which will happily try to free all info->fields again.

This is the fix.

Signed-off-by: Oleg Nesterov <>
Signed-off-by: Denys Vlasenko <>
Cc: Venu Byravarasu <>
Signed-off-by: Andrew Morton <>
Signed-off-by: Ben Hutchings <>
9 years agoext4: fix fdatasync() for files with only i_size changes
Jan Kara [Thu, 27 Sep 2012 01:52:20 +0000 (21:52 -0400)]
ext4: fix fdatasync() for files with only i_size changes

commit b71fc079b5d8f42b2a52743c8d2f1d35d655b1c5 upstream.

Code tracking when transaction needs to be committed on fdatasync(2) forgets
to handle a situation when only inode's i_size is changed. Thus in such
situations fdatasync(2) doesn't force transaction with new i_size to disk
and that can result in wrong i_size after a crash.

Fix the issue by updating inode's i_datasync_tid whenever its size is

Reported-by: Kristian Nielsen <>
Signed-off-by: Jan Kara <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoext4: always set i_op in ext4_mknod()
Bernd Schubert [Thu, 27 Sep 2012 01:24:57 +0000 (21:24 -0400)]
ext4: always set i_op in ext4_mknod()

commit 6a08f447facb4f9e29fcc30fb68060bb5a0d21c2 upstream.

ext4_special_inode_operations have their own ifdef CONFIG_EXT4_FS_XATTR
to mask those methods. And ext4_iget also always sets it, so there is
an inconsistency.

Signed-off-by: Bernd Schubert <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agoserial: pl011: handle corruption at high clock speeds
Linus Walleij [Wed, 26 Sep 2012 15:21:36 +0000 (17:21 +0200)]
serial: pl011: handle corruption at high clock speeds

commit c5dd553b9fd069892c9e2de734f4f604e280fa7a upstream.

This works around a few glitches in the ST version of the PL011
serial driver when using very high baud rates, as we do in the
Ux500: 3, 3.25, 4 and 4.05 Mbps.

Problem Observed/rootcause:

When using high baud-rates, and the baudrate*8 is getting close to
the provided clock frequency (so a division factor close to 1), when
using bursts of characters (so they are abutted), then it seems as if
there is not enough time to detect the beginning of the start-bit which
is a timing reference for the entire character, and thus the sampling
moment of character bits is moving towards the end of each bit, instead
of the middle.

Increase slightly the RX baud rate of the UART above the theoretical
baudrate by 5%. This will definitely give more margin time to the
UART_RX to correctly sample the data at the middle of the bit period.

Also fix the ages old copy-paste error in the very stressed comment,
it's referencing the registers used in the PL010 driver rather than
the PL011 ones.

Signed-off-by: Guillaume Jaunet <>
Signed-off-by: Christophe Arnal <>
Signed-off-by: Matthias Locher <>
Signed-off-by: Rajanikanth HV <>
Cc: Bibek Basu <>
Cc: Par-Gunnar Hjalmdahl <>
Signed-off-by: Linus Walleij <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoserial: set correct baud_base for EXSYS EX-41092 Dual 16950
Flavio Leitner [Sat, 22 Sep 2012 00:04:34 +0000 (21:04 -0300)]
serial: set correct baud_base for EXSYS EX-41092 Dual 16950

commit 26e8220adb0aec43b7acafa0f1431760eee28522 upstream.

Apparently the same card model has two IDs, so this patch
complements the commit 39aced68d664291db3324d0fcf0985ab5626aac2
adding the missing one.

Signed-off-by: Flavio Leitner <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
9 years agostaging: comedi: s626: don't dereference insn->data
Ian Abbott [Mon, 24 Sep 2012 16:20:52 +0000 (17:20 +0100)]
staging: comedi: s626: don't dereference insn->data

commit b655c2c4782ed3e2e71d2608154e295a3e860311 upstream.

`s626_enc_insn_config()` is incorrectly dereferencing `insn->data` which
is a pointer to user memory.  It should be dereferencing the separate
`data` parameter that points to a copy of the data in kernel memory.

Signed-off-by: Ian Abbott <>
Reviewed-by: H Hartley Sweeten <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoext4: online defrag is not supported for journaled files
Dmitry Monakhov [Wed, 26 Sep 2012 16:32:54 +0000 (12:32 -0400)]
ext4: online defrag is not supported for journaled files

commit f066055a3449f0e5b0ae4f3ceab4445bead47638 upstream.

Proper block swap for inodes with full journaling enabled is
truly non obvious task. In order to be on a safe side let's
explicitly disable it for now.

Signed-off-by: Dmitry Monakhov <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agoext4: move_extent code cleanup
Dmitry Monakhov [Wed, 26 Sep 2012 16:32:19 +0000 (12:32 -0400)]
ext4: move_extent code cleanup

commit 03bd8b9b896c8e940f282f540e6b4de90d666b7c upstream.

- Remove usless checks, because it is too late to check that inode != NULL
  at the moment it was referenced several times.
- Double lock routines looks very ugly and locking ordering relays on
  order of i_ino, but other kernel code rely on order of pointers.
  Let's make them simple and clean.
- check that inodes belongs to the same SB as soon as possible.

Signed-off-by: Dmitry Monakhov <>
Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/i915: make sure we write all the DIP data bytes
Paulo Zanoni [Tue, 25 Sep 2012 16:23:34 +0000 (13:23 -0300)]
drm/i915: make sure we write all the DIP data bytes

commit adf00b26d18e1b3570451296e03bcb20e4798cdd upstream.

... even if the actual infoframe is smaller than the maximum possible

If we don't write all the 32 DIP data bytes the InfoFrame ECC may not
be correctly calculated in some cases (e.g., when changing the port),
and this will lead to black screens on HDMI monitors. The ECC value is
generated by the hardware.

I don't see how this should break anything since we're writing 0 and
that should be the correct value, so this patch should be safe.

Notice that on IVB and older we actually have 64 bytes available for
VIDEO_DIP_DATA, but only bytes 0-31 actually store infoframe data: the
others are either read-only ECC values or marked as "reserved". On HSW
we only have 32 bytes, and the ECC value is stored on its own separate
read-only register. See BSpec.

This patch fixes bug #46761, which is marked as a regression
introduced by commit 4e89ee174bb2da341bf90a84321c7008a3c9210d:
    drm/i915: set the DIP port on ibx_write_infoframe

Before commit 4e89 we were just failing to send AVI infoframes when we
needed to change the port, which can lead to black screens in some
cases. After commit 4e89 we started sending infoframes, but with a
possibly wrong ECC value. After this patch I hope we start sending
correct infoframes.

Version 2:
  - Improve commit message
  - Try to make the code more clear

Signed-off-by: Paulo Zanoni <>
Reviewed-by: Rodrigo Vivi <>
Signed-off-by: Daniel Vetter <>
[bwh: Backported to 3.2: only two write_infoframe functions to be modified]
Signed-off-by: Ben Hutchings <>
9 years agodrm/i915: add some barriers when changing DIPs
Paulo Zanoni [Mon, 28 May 2012 19:43:00 +0000 (16:43 -0300)]
drm/i915: add some barriers when changing DIPs

commit 9d9740f099f2eaf309c4c9cbc0d732507140db28 upstream.

On IVB and older, we basically have two registers: the control and the
data register. We write a few consecutitve times to the control
register, and we need these writes to arrive exactly in the specified

Also, when we're changing the data register, we need to guarantee that
anything written to the control register already arrived (since
changing the control register can change where the data register
points to). Also, we need to make sure all the writes to the data
register happen exactly in the specified order, and we also *can't*
read the data register during this process, since reading and/or
writing it will change the place it points to.

So invoke the "better safe than sorry" rule and just be careful and
put barriers everywhere :)

On HSW we still have a control register that we write many times, but
we have many data registers.

Demanded-by: Chris Wilson <>
Signed-off-by: Paulo Zanoni <>
Signed-off-by: Daniel Vetter <>
[bwh: Backported to 3.2:
 - There are only two write_infoframe functions to be modified
 - The other VIDEO_DIP_CTL writes are in entirely different functions]
Signed-off-by: Ben Hutchings <>
9 years agoxhci: Intel Panther Point BEI quirk.
Sarah Sharp [Wed, 19 Sep 2012 23:27:26 +0000 (16:27 -0700)]
xhci: Intel Panther Point BEI quirk.

commit 80fab3b244a22e0ca539d2439bdda50e81e5666f upstream.

When a device with an isochronous endpoint is behind a hub plugged into
the Intel Panther Point xHCI host controller, and the driver submits
multiple frames per URB, the xHCI driver will set the Block Event
Interrupt (BEI) flag on all but the last TD for the URB.  This causes
the host controller to place an event on the event ring, but not send an
interrupt.  When the last TD for the URB completes, BEI is cleared, and
we get an interrupt for the whole URB.

However, under a Panther Point xHCI host controller, if the parent hub
is unplugged when one or more events from transfers with BEI set are on
the event ring, a port status change event is placed on the event ring,
but no interrupt is generated.  This means URBs stop completing, and the
USB device disconnect is not noticed.  Something like a USB headset will
cause mplayer to hang when the device is disconnected.

If another transfer is sent (such as running `sudo lsusb -v`), the next
transfer event seems to "unstick" the event ring, the xHCI driver gets
an interrupt, and the disconnect is reported to the USB core.

The fix is not to use the BEI flag under the Panther Point xHCI host.
This will impact power consumption and system responsiveness, because
the xHCI driver will receive an interrupt for every frame in all
isochronous URBs instead of once per URB.

Intel chipset developers confirm that this bug will be hit if the BEI
flag is used on any endpoint, not just ones that are behind a hub.

This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."

Signed-off-by: Sarah Sharp <>
Signed-off-by: Ben Hutchings <>
9 years agoath9k: Disable ASPM only for AR9285
Sujith Manoharan [Fri, 21 Sep 2012 18:44:28 +0000 (00:14 +0530)]
ath9k: Disable ASPM only for AR9285

commit 046b6802c8d3c8a57448485513bf7291633e0fa3 upstream.

Currently, ASPM is disabled for all WLAN+BT combo chipsets
when BTCOEX is enabled. This is incorrect since the workaround
is required only for WB195, which is a AR9285+AR3011 combo
solution. Fix this by checking for the HW version when enabling
the workaround.

Signed-off-by: Sujith Manoharan <>
Tested-by: Paul Stewart <>
Signed-off-by: John W. Linville <>
[bwh: Backported to 3.2: ath9k_hw_get_btcoex_scheme() function is missing]
Signed-off-by: Ben Hutchings <>
Lin Ming [Mon, 16 Jul 2012 08:30:21 +0000 (16:30 +0800)]

commit fc54ab72959edbf229b65ac74b2f122d799ca002 upstream.

The _OSC method may exist in module level code,
so it must be called after ACPI_FULL_INITIALIZATION

On some new platforms with Zero-Power-Optical-Disk-Drive (ZPODD)
support, this fix is necessary to save power.

Signed-off-by: Lin Ming <>
Tested-by: Aaron Lu <>
Signed-off-by: Len Brown <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: ftdi_sio: add TIAO USB Multi-Protocol Adapter (TUMPA) support
Antonio Ospite [Sun, 23 Sep 2012 07:57:25 +0000 (09:57 +0200)]
USB: ftdi_sio: add TIAO USB Multi-Protocol Adapter (TUMPA) support

commit 54575b05af36959dfb6a49a3e9ca0c2b456b7126 upstream.

TIAO/DIYGADGET USB Multi-Protocol Adapter (TUMPA) is an FTDI FT2232H
based device which provides an easily accessible JTAG, SPI, I2C, serial

FTDI FT2232H provides two serial channels (A and B), but on the TUMPA
channel A is dedicated to JTAG/SPI while channel B can be used for
UART/RS-232: use the ftdi_jtag_quirk to expose only channel B as
a usb-serial interface to userspace.

Signed-off-by: Antonio Ospite <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agousb: host: xhci: Fix Null pointer dereferencing with 71c731a for non-x86 systems
Vivek Gautam [Sat, 22 Sep 2012 12:41:19 +0000 (18:11 +0530)]
usb: host: xhci: Fix Null pointer dereferencing with 71c731a for non-x86 systems

commit 457a73d346187c2cc5d599072f38676f18f130e0 upstream.

In 71c731a: usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
when extracting DMI strings (vendor or product_name) to mark them as quirk
we may get NULL pointer in case of non-x86 systems which won't define
CONFIG_DMI. Hence susbsequent strstr() calls crash while driver probing.

So, returning 'false' here in case we get a NULL vendor or product_name.

This is tested with ARM (exynos) system.

This patch should be backported to stable kernels as old as 3.6, that
contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host:
xhci: Fix Compliance Mode on SN65LVPE502CP Hardware"

Signed-off-by: Vivek Gautam <>
Signed-off-by: Sarah Sharp <>
Reported-by: Sebastian Gottschall (DD-WRT) <>
Signed-off-by: Ben Hutchings <>
9 years agoIncrease XHCI suspend timeout to 16ms
Michael Spang [Fri, 14 Sep 2012 17:05:49 +0000 (13:05 -0400)]
Increase XHCI suspend timeout to 16ms

commit a6e097dfdfd189b6929af6efa1d289af61858386 upstream.

The Intel XHCI specification says that after clearing the run/stop bit
the controller may take up to 16ms to halt. We've seen a device take
14ms, which with the current timeout of 10ms causes the kernel to
abort the suspend. Increasing the timeout to the recommended value
fixes the problem.

This patch should be backported to kernels as old as 2.6.37, that
contain the commit 5535b1d5f8885695c6ded783c692e3c0d0eda8ca "USB: xHCI:
PCI power management implementation".

Signed-off-by: Michael Spang <>
Signed-off-by: Sarah Sharp <>
Signed-off-by: Ben Hutchings <>
9 years agoscsi_dh_alua: Enable STPG for unavailable ports
Bart Van Assche [Fri, 24 Aug 2012 09:08:41 +0000 (09:08 +0000)]
scsi_dh_alua: Enable STPG for unavailable ports

commit e47f8976d8e573928824a06748f7bc82c58d747f upstream.

A quote from SPC-4: "While in the unavailable primary target port
asymmetric access state, the device server shall support those of
the following commands that it supports while in the active/optimized
state: [ ... ] d) SET TARGET PORT GROUPS; [ ... ]". Hence enable
sending STPG to a target port group that is in the unavailable state.

Signed-off-by: Bart Van Assche <>
Reviewed-by: Mike Christie <>
Acked-by: Hannes Reinecke <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agoscsi_remove_target: fix softlockup regression on hot remove
Dan Williams [Wed, 29 Aug 2012 05:12:10 +0000 (22:12 -0700)]
scsi_remove_target: fix softlockup regression on hot remove

commit bc3f02a795d3b4faa99d37390174be2a75d091bd upstream.

John reports:
 BUG: soft lockup - CPU#2 stuck for 23s! [kworker/u:8:2202]
 Call Trace:
  [<ffffffff8141782a>] scsi_remove_target+0xda/0x1f0
  [<ffffffff81421de5>] sas_rphy_remove+0x55/0x60
  [<ffffffff81421e01>] sas_rphy_delete+0x11/0x20
  [<ffffffff81421e35>] sas_port_delete+0x25/0x160
  [<ffffffff814549a3>] mptsas_del_end_device+0x183/0x270

...introduced by commit 3b661a9 "[SCSI] fix hot unplug vs async scan race".

Don't restart lookup of more stargets in the multi-target case, just
arrange to traverse the list once, on the assumption that new targets
are always added at the end.  There is no guarantee that the target will
change state in scsi_target_reap() so we can end up spinning if we

Acked-by: Jack Wang <>
LKML-Reference: <>
Reported-by: John Drescher <>
Tested-by: John Drescher <>
Signed-off-by: Dan Williams <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agoibmvscsi: Fix host config length field overflow
Benjamin Herrenschmidt [Mon, 30 Jul 2012 01:33:05 +0000 (11:33 +1000)]
ibmvscsi: Fix host config length field overflow

commit 225c56960fcafeccc2b6304f96cd3f0dbf42a16a upstream.

The length field in the host config packet is only 16-bit long, so
passing it 0x10000 (64K which is our standard PAGE_SIZE) doesn't
work and result in an empty config from the server.

Signed-off-by: Benjamin Herrenschmidt <>
Acked-by: Robert Jennings <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agozfcp: only access zfcp_scsi_dev for valid scsi_device
Martin Peschke [Tue, 4 Sep 2012 13:23:36 +0000 (15:23 +0200)]
zfcp: only access zfcp_scsi_dev for valid scsi_device

commit d436de8ce25f53a8a880a931886821f632247943 upstream.

__scsi_remove_device (e.g. due to dev_loss_tmo) calls
zfcp_scsi_slave_destroy which in turn sends a close LUN FSF request to
the adapter. After 30 seconds without response,
zfcp_erp_timeout_handler kicks the ERP thread failing the close LUN
ERP action. zfcp_erp_wait in zfcp_erp_lun_shutdown_wait and thus
zfcp_scsi_slave_destroy returns and then scsi_device is no longer
valid. Sometime later the response to the close LUN FSF request may
finally come in. However, commit
"[SCSI] zfcp: Use SCSI device data zfcp_scsi_dev instead of zfcp_unit"
introduced a number of attempts to unconditionally access struct
zfcp_scsi_dev through struct scsi_device causing a use-after-free.
This leads to an Oops due to kernel page fault in one of:
zfcp_fsf_abort_fcp_command_handler, zfcp_fsf_open_lun_handler,
zfcp_fsf_close_lun_handler, zfcp_fsf_req_trace,
Move dereferencing of zfcp private data zfcp_scsi_dev allocated in
scsi_device via scsi_transport_reserve_device after the check for
potentially aborted FSF request and thus no longer valid scsi_device.
Only then assign sdev_to_zfcp(sdev) to the local auto variable struct
zfcp_scsi_dev *zfcp_sdev.

Signed-off-by: Martin Peschke <>
Signed-off-by: Steffen Maier <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agozfcp: restore refcount check on port_remove
Steffen Maier [Tue, 4 Sep 2012 13:23:34 +0000 (15:23 +0200)]
zfcp: restore refcount check on port_remove

commit d99b601b63386f3395dc26a699ae703a273d9982 upstream.

Upstream commit f3450c7b917201bb49d67032e9f60d5125675d6a
"[SCSI] zfcp: Replace local reference counting with common kref"
accidentally dropped a reference count check before tearing down
zfcp_ports that are potentially in use by zfcp_units.
Even remote ports in use can be removed causing
unreachable garbage objects zfcp_ports with zfcp_units.
Thus units won't come back even after a manual port_rescan.
The kref of zfcp_port->dev.kobj is already used by the driver core.
We cannot re-use it to track the number of zfcp_units.
Re-introduce our own counter for units per port
and check on port_remove.

Signed-off-by: Steffen Maier <>
Reviewed-by: Heiko Carstens <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agozfcp: remove invalid reference to list iterator variable
Julia Lawall [Tue, 4 Sep 2012 13:23:33 +0000 (15:23 +0200)]
zfcp: remove invalid reference to list iterator variable

commit ca579c9f136af4274ccfd1bcaee7f38a29a0e2e9 upstream.

If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure.  Thus this value should not be used after
the end of the iterator.  Replace port->adapter->scsi_host by

This problem was found using Coccinelle (

Oversight in upsteam commit of v2.6.37
"[SCSI] zfcp: Move ACL/CFDC code to zfcp_cfdc.c"
which merged the content of zfcp_erp_port_access_changed().

Signed-off-by: Julia Lawall <>
Signed-off-by: Steffen Maier <>
Reviewed-by: Martin Peschke <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agozfcp: Do not wakeup while suspended
Steffen Maier [Tue, 4 Sep 2012 13:23:32 +0000 (15:23 +0200)]
zfcp: Do not wakeup while suspended

commit cb45214960bc989af8b911ebd77da541c797717d upstream.

If the mapping of FCP device bus ID and corresponding subchannel
is modified while the Linux image is suspended, the resume of FCP
devices can fail. During resume, zfcp gets callbacks from cio regarding
the modified subchannels but they can be arbitrarily mixed with the
restore/resume callback. Since the cio callbacks would trigger
adapter recovery, zfcp could wakeup before the resume callback.
Therefore, ignore the cio callbacks regarding subchannels while
being suspended. We can safely do so, since zfcp does not deal itself
with subchannels. For problem determination purposes, we still trace the
ignored callback events.

The following kernel messages could be seen on resume:

kernel: <WWPN>: parent <FCP device bus ID> should not be sleeping

As part of adapter reopen recovery, zfcp performs auto port scanning
which can erroneously try to register new remote ports with
scsi_transport_fc and the device core code complains about the parent
(adapter) still sleeping.

kernel: zfcp.3dff9c: <FCP device bus ID>:\
 Setting up the QDIO connection to the FCP adapter failed
<last kernel message repeated 3 more times>
kernel: zfcp.574d43: <FCP device bus ID>:\
 ERP cannot recover an error on the FCP device

In such cases, the adapter gave up recovery and remained blocked along
with its child objects: remote ports and LUNs/scsi devices. Even the
adapter shutdown as part of giving up recovery failed because the ccw
device state remained disconnected. Later, the corresponding remote
ports ran into dev_loss_tmo. As a result, the LUNs were erroneously
not available again after resume.

Even a manually triggered adapter recovery (e.g. sysfs attribute
failed, or device offline/online via sysfs) could not recover the
adapter due to the remaining disconnected state of the corresponding
ccw device.

Signed-off-by: Steffen Maier <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agozfcp: Bounds checking for deferred error trace
Steffen Maier [Tue, 4 Sep 2012 13:23:31 +0000 (15:23 +0200)]
zfcp: Bounds checking for deferred error trace

commit 01e60527f0a49b3d7df603010bd6079bb4b6cf07 upstream.

The pl vector has scount elements, i.e. pl[scount-1] is the last valid
element. For maximum sized requests, payload->counter == scount after
the last loop iteration. Therefore, do bounds checking first (with
boolean shortcut) to not access the invalid element pl[scount].

Do not trust the maximum sbale->scount value from the HBA
but ensure we won't access the pl vector out of our allocated bounds.
While at it, clean up scoping and prevent unnecessary memset.

Minor fix for 86a9668a8d29ea711613e1cb37efa68e7c4db564
"[SCSI] zfcp: support for hardware data router"

Signed-off-by: Steffen Maier <>
Reviewed-by: Martin Peschke <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agozfcp: Make trace record tags unique
Steffen Maier [Tue, 4 Sep 2012 13:23:30 +0000 (15:23 +0200)]
zfcp: Make trace record tags unique

commit 0100998dbfe6dfcd90a6e912ca7ed6f255d48f25 upstream.

Duplicate fssrh_2 from a54ca0f62f953898b05549391ac2a8a4dad6482b
"[SCSI] zfcp: Redesign of the debug tracing for HBA records."
complicates distinction of generic status read response from
local link up.
Duplicate fsscth1 from 2c55b750a884b86dea8b4cc5f15e1484cc47a25c
"[SCSI] zfcp: Redesign of the debug tracing for SAN records."
complicates distinction of good common transport response from
invalid port handle.

Signed-off-by: Steffen Maier <>
Reviewed-by: Martin Peschke <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agorcu: Fix day-one dyntick-idle stall-warning bug
Paul E. McKenney [Sat, 22 Sep 2012 20:55:30 +0000 (13:55 -0700)]
rcu: Fix day-one dyntick-idle stall-warning bug

commit a10d206ef1a83121ab7430cb196e0376a7145b22 upstream.

Each grace period is supposed to have at least one callback waiting
for that grace period to complete.  However, if CONFIG_NO_HZ=n, an
extra callback-free grace period is no big problem -- it will chew up
a tiny bit of CPU time, but it will complete normally.  In contrast,
CONFIG_NO_HZ=y kernels have the potential for all the CPUs to go to
sleep indefinitely, in turn indefinitely delaying completion of the
callback-free grace period.  Given that nothing is waiting on this grace
period, this is also not a problem.

That is, unless RCU CPU stall warnings are also enabled, as they are
in recent kernels.  In this case, if a CPU wakes up after at least one
minute of inactivity, an RCU CPU stall warning will result.  The reason
that no one noticed until quite recently is that most systems have enough
OS noise that they will never remain absolutely idle for a full minute.
But there are some embedded systems with cut-down userspace configurations
that consistently get into this situation.

All this begs the question of exactly how a callback-free grace period
gets started in the first place.  This can happen due to the fact that
CPUs do not necessarily agree on which grace period is in progress.
If a CPU still believes that the grace period that just completed is
still ongoing, it will believe that it has callbacks that need to wait for
another grace period, never mind the fact that the grace period that they
were waiting for just completed.  This CPU can therefore erroneously
decide to start a new grace period.  Note that this can happen in
TREE_RCU and TREE_PREEMPT_RCU even on a single-CPU system:  Deadlock
considerations mean that the CPU that detected the end of the grace
period is not necessarily officially informed of this fact for some time.

Once this CPU notices that the earlier grace period completed, it will
invoke its callbacks.  It then won't have any callbacks left.  If no
other CPU has any callbacks, we now have a callback-free grace period.

This commit therefore makes CPUs check more carefully before starting a
new grace period.  This new check relies on an array of tail pointers
into each CPU's list of callbacks.  If the CPU is up to date on which
grace periods have completed, it checks to see if any callbacks follow
the RCU_DONE_TAIL segment, otherwise it checks to see if any callbacks
follow the RCU_WAIT_TAIL segment.  The reason that this works is that
the RCU_WAIT_TAIL segment will be promoted to the RCU_DONE_TAIL segment
as soon as the CPU is officially notified that the old grace period
has ended.

This change is to cpu_needs_another_gp(), which is called in a number
of places.  The only one that really matters is in rcu_start_gp(), where
the root rcu_node structure's ->lock is held, which prevents any
other CPU from starting or completing a grace period, so that the
comparison that determines whether the CPU is missing the completion
of a grace period is stable.

Reported-by: Becky Bruce <>
Reported-by: Subodh Nijsure <>
Reported-by: Paul Walmsley <>
Signed-off-by: Paul E. McKenney <>
Signed-off-by: Paul E. McKenney <>
Tested-by: Paul Walmsley <> # OMAP3730, OMAP4430
Signed-off-by: Ben Hutchings <>
9 years agoiscsi-target: Correctly set 0xffffffff field within ISCSI_OP_REJECT PDU
Nicholas Bellinger [Sun, 23 Sep 2012 00:21:06 +0000 (17:21 -0700)]
iscsi-target: Correctly set 0xffffffff field within ISCSI_OP_REJECT PDU

commit f25590f39d543272f7ae7b00d533359c8d7ff331 upstream.

This patch adds a missing iscsi_reject->ffffffff assignment within
iscsit_send_reject() code to properly follow RFC-3720 Section 10.17
Bytes 16 -> 19 for the PDU format definition of ISCSI_OP_REJECT.

We've not seen any initiators care about this bytes in practice, but
as Ronnie reported this was causing trouble with wireshark packet
decoding lets go ahead and fix this up now.

Reported-by: Ronnie Sahlberg <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Ben Hutchings <>
9 years agocan: mscan-mpc5xxx: fix return value check in mpc512x_can_get_clock()
Wei Yongjun [Fri, 21 Sep 2012 07:09:47 +0000 (15:09 +0800)]
can: mscan-mpc5xxx: fix return value check in mpc512x_can_get_clock()

commit f61bd0585dfc7d99db4936d7467de4ca8e2f7ea0 upstream.

In case of error, the function clk_get() returns ERR_PTR()
and never returns NULL pointer. The NULL test in the error
handling should be replaced with IS_ERR().

dpatch engine is used to auto generated this patch.

Signed-off-by: Wei Yongjun <>
Acked-by: Wolfgang Grandegger <>
Signed-off-by: Marc Kleine-Budde <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: qcaux: add Pantech vendor class match
Bjørn Mork [Wed, 19 Sep 2012 20:02:03 +0000 (22:02 +0200)]
USB: qcaux: add Pantech vendor class match

commit c638eb2872b3af079501e7ee44cbb8a5cce9b4b5 upstream.

The three Pantech devices UML190 (106c:3716), UML290 (106c:3718) and
P4200 (106c:3721) all use the same subclasses to identify vendor
specific functions.  Replace the existing device specific entries
with generic vendor matching, adding support for the P4200.

Signed-off-by: Bjørn Mork <>
Cc: Thomas Schäfer <>
Acked-by: Dan Williams <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoUSB: option: blacklist QMI interface on ZTE MF683
Bjørn Mork [Wed, 19 Sep 2012 20:02:12 +0000 (22:02 +0200)]
USB: option: blacklist QMI interface on ZTE MF683

commit 160c9425ac52cb30502be2d9c5e848cec91bb115 upstream.

Interface #5 on ZTE MF683 is a QMI/wwan interface.

Signed-off-by: Bjørn Mork <>
Cc: Shawn J. Goff <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agostaging: comedi: fix memory leak for saved channel list
Ian Abbott [Wed, 19 Sep 2012 18:37:39 +0000 (19:37 +0100)]
staging: comedi: fix memory leak for saved channel list

commit c8cad4c89ee3b15935c532210ae6ebb5c0a2734d upstream.

When `do_cmd_ioctl()` allocates memory for the kernel copy of a channel
list, it frees any previously allocated channel list in
`async->cmd.chanlist` and replaces it with the new one.  However, if the
device is ever removed (or "detached") the cleanup code in
`cleanup_device()` in "drivers.c" does not free this memory so it is

A sensible place to free the kernel copy of the channel list is in
`do_become_nonbusy()` as at that point the comedi asynchronous command
associated with the channel list is no longer valid.  Free the channel
list in `do_become_nonbusy()` instead of `do_cmd_ioctl()` and clear the
pointer to prevent it being freed more than once.

Note that `cleanup_device()` could be called at an inappropriate time
while the comedi device is open, but that's a separate bug not related
to this this patch.

Signed-off-by: Ian Abbott <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoext4: fix potential deadlock in ext4_nonda_switch()
Theodore Ts'o [Thu, 20 Sep 2012 02:42:36 +0000 (22:42 -0400)]
ext4: fix potential deadlock in ext4_nonda_switch()

commit 00d4e7362ed01987183e9528295de3213031309c upstream.

In ext4_nonda_switch(), if the file system is getting full we used to
call writeback_inodes_sb_if_idle().  The problem is that we can be
holding i_mutex already, and this causes a potential deadlock when
writeback_inodes_sb_if_idle() when it tries to take s_umount.  (See
lockdep output below).

As it turns out we don't need need to hold s_umount; the fact that we
are in the middle of the write(2) system call will keep the superblock
pinned.  Unfortunately writeback_inodes_sb() checks to make sure
s_umount is taken, and the VFS uses a different mechanism for making
sure the file system doesn't get unmounted out from under us.  The
simplest way of dealing with this is to just simply grab s_umount
using a trylock, and skip kicking the writeback flusher thread in the
very unlikely case that we can't take a read lock on s_umount without

Also, we now check the cirteria for kicking the writeback thread
before we decide to whether to fall back to non-delayed writeback, so
if there are any outstanding delayed allocation writes, we try to get
them resolved as soon as possible.

   [ INFO: possible circular locking dependency detected ]
   3.6.0-rc1-00042-gce894ca #367 Not tainted
   dd/8298 is trying to acquire lock:
    (&type->s_umount_key#18){++++..}, at: [<c02277d4>] writeback_inodes_sb_if_idle+0x28/0x46

   but task is already holding lock:
    (&sb->s_type->i_mutex_key#8){+.+...}, at: [<c01ddcce>] generic_file_aio_write+0x5f/0xd3

   which lock already depends on the new lock.

   2 locks held by dd/8298:
    #0:  (sb_writers#2){.+.+.+}, at: [<c01ddcc5>] generic_file_aio_write+0x56/0xd3
    #1:  (&sb->s_type->i_mutex_key#8){+.+...}, at: [<c01ddcce>] generic_file_aio_write+0x5f/0xd3

   stack backtrace:
   Pid: 8298, comm: dd Not tainted 3.6.0-rc1-00042-gce894ca #367
   Call Trace:
    [<c015b79c>] ? console_unlock+0x345/0x372
    [<c06d62a1>] print_circular_bug+0x190/0x19d
    [<c019906c>] __lock_acquire+0x86d/0xb6c
    [<c01999db>] ? mark_held_locks+0x5c/0x7b
    [<c0199724>] lock_acquire+0x66/0xb9
    [<c02277d4>] ? writeback_inodes_sb_if_idle+0x28/0x46
    [<c06db935>] down_read+0x28/0x58
    [<c02277d4>] ? writeback_inodes_sb_if_idle+0x28/0x46
    [<c02277d4>] writeback_inodes_sb_if_idle+0x28/0x46
    [<c026f3b2>] ext4_nonda_switch+0xe1/0xf4
    [<c0271ece>] ext4_da_write_begin+0x27/0x193
    [<c01dcdb0>] generic_file_buffered_write+0xc8/0x1bb
    [<c01ddc47>] __generic_file_aio_write+0x1dd/0x205
    [<c01ddce7>] generic_file_aio_write+0x78/0xd3
    [<c026d336>] ext4_file_write+0x480/0x4a6
    [<c0198c1d>] ? __lock_acquire+0x41e/0xb6c
    [<c0180944>] ? sched_clock_cpu+0x11a/0x13e
    [<c01967e9>] ? trace_hardirqs_off+0xb/0xd
    [<c018099f>] ? local_clock+0x37/0x4e
    [<c0209f2c>] do_sync_write+0x67/0x9d
    [<c0209ec5>] ? wait_on_retry_sync_kiocb+0x44/0x44
    [<c020a7b9>] vfs_write+0x7b/0xe6
    [<c020a9a6>] sys_write+0x3b/0x64
    [<c06dd4bd>] syscall_call+0x7/0xb

Signed-off-by: "Theodore Ts'o" <>
Signed-off-by: Ben Hutchings <>
9 years agoSUNRPC: Ensure that the TCP socket is closed when in CLOSE_WAIT
Trond Myklebust [Wed, 12 Sep 2012 20:49:15 +0000 (16:49 -0400)]
SUNRPC: Ensure that the TCP socket is closed when in CLOSE_WAIT

commit a519fc7a70d1a918574bb826cc6905b87b482eb9 upstream.

Instead of doing a shutdown() call, we need to do an actual close().
Ditto if/when the server is sending us junk RPC headers.

Signed-off-by: Trond Myklebust <>
Tested-by: Simon Kirby <>
Signed-off-by: Ben Hutchings <>
9 years agostaging: comedi: don't dereference user memory for INSN_INTTRIG
Ian Abbott [Tue, 18 Sep 2012 18:46:58 +0000 (19:46 +0100)]
staging: comedi: don't dereference user memory for INSN_INTTRIG

commit 5d06e3df280bd230e2eadc16372e62818c63e894 upstream.

`parse_insn()` is dereferencing the user-space pointer `insn->data`
directly when handling the `INSN_INTTRIG` comedi instruction.  It
shouldn't be using `insn->data` at all; it should be using the separate
`data` pointer passed to the function.  Fix it.

Signed-off-by: Ian Abbott <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoBluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn
Gustavo Padovan [Wed, 15 Aug 2012 04:38:11 +0000 (01:38 -0300)]
Bluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn

commit ee66401bb94b1f2ce51089c341dcdd25d26ae631 upstream.

Foxconn devices has a vendor specific class of device, we will match them
differently now.

Signed-off-by: Gustavo Padovan <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agoPCI: Check P2P bridge for invalid secondary/subordinate range
Yinghai Lu [Tue, 11 Sep 2012 00:19:33 +0000 (17:19 -0700)]
PCI: Check P2P bridge for invalid secondary/subordinate range

commit 1965f66e7db08d1ebccd24a59043eba826cc1ce8 upstream.

For bridges with "secondary > subordinate", i.e., invalid bus number
apertures, we don't enumerate anything behind the bridge unless the
user specified "pci=assign-busses".

This patch makes us automatically try to reassign the downstream bus
numbers in this case (just for that bridge, not for all bridges as
"pci=assign-busses" does).

We don't discover all the devices on the Intel DP43BF motherboard
without this change (or "pci=assign-busses") because its BIOS configures
a bridge as:

    pci 0000:00:1e.0: PCI bridge to [bus 20-08] (subtractive decode)

[bhelgaas: changelog, change message to dev_info]
Reported-by: Brian C. Huffman <>
Reported-by: VL <>
Tested-by: VL <>
Signed-off-by: Yinghai Lu <>
Signed-off-by: Bjorn Helgaas <>
Signed-off-by: Ben Hutchings <>
9 years agoworkqueue: fix possible stall on try_to_grab_pending() of a delayed work item
Lai Jiangshan [Tue, 18 Sep 2012 17:40:00 +0000 (10:40 -0700)]
workqueue: fix possible stall on try_to_grab_pending() of a delayed work item

commit 3aa62497594430ea522050b75c033f71f2c60ee6 upstream.

Currently, when try_to_grab_pending() grabs a delayed work item, it
leaves its linked work items alone on the delayed_works.  The linked
work items are always NO_COLOR and will cause future
cwq_activate_first_delayed() increase cwq->nr_active incorrectly, and
may cause the whole cwq to stall.  For example,

state: cwq->max_active = 1, cwq->nr_active = 1
       one work in cwq->pool, many in cwq->delayed_works.

step1: try_to_grab_pending() removes a work item from delayed_works
       but leaves its NO_COLOR linked work items on it.

step2: Later on, cwq_activate_first_delayed() activates the linked
       work item increasing ->nr_active.

step3: cwq->nr_active = 1, but all activated work items of the cwq are
       NO_COLOR.  When they finish, cwq->nr_active will not be
       decreased due to NO_COLOR, and no further work items will be
       activated from cwq->delayed_works. the cwq stalls.

Fix it by ensuring the target work item is activated before stealing
PENDING in try_to_grab_pending().  This ensures that all the linked
work items are activated without incorrectly bumping cwq->nr_active.

tj: Updated comment and description.

Signed-off-by: Lai Jiangshan <>
Signed-off-by: Tejun Heo <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agointel-iommu: Default to non-coherent for domains unattached to iommus
Alex Williamson [Sat, 12 Nov 2011 00:26:44 +0000 (17:26 -0700)]
intel-iommu: Default to non-coherent for domains unattached to iommus

commit 2e12bc29fc5a12242d68e11875db3dd58efad9ff upstream.

domain_update_iommu_coherency() currently defaults to setting domains
as coherent when the domain is not attached to any iommus.  This
allows for a window in domain_context_mapping_one() where such a
domain can update context entries non-coherently, and only after
update the domain capability to clear iommu_coherency.

This can be seen using KVM device assignment on VT-d systems that
do not support coherency in the ecap register.  When a device is
added to a guest, a domain is created (iommu_coherency = 0), the
device is attached, and ranges are mapped.  If we then hot unplug
the device, the coherency is updated and set to the default (1)
since no iommus are attached to the domain.  A subsequent attach
of a device makes use of the same dmar domain (now marked coherent)
updates context entries with coherency enabled, and only disables
coherency as the last step in the process.

To fix this, switch domain_update_iommu_coherency() to use the
safer, non-coherent default for domains not attached to iommus.

Signed-off-by: Alex Williamson <>
Tested-by: Donald Dutile <>
Acked-by: Donald Dutile <>
Acked-by: Chris Wright <>
Signed-off-by: Joerg Roedel <>
[bwh: Backported to 3.2: dmar_domain::iommu_bmp is a single unsigned long
 not an array, so add &]
Signed-off-by: Ben Hutchings <>
9 years agopowerpc/eeh: Lock module while handling EEH event
Gavin Shan [Mon, 17 Sep 2012 04:34:27 +0000 (04:34 +0000)]
powerpc/eeh: Lock module while handling EEH event

commit feadf7c0a1a7c08c74bebb4a13b755f8c40e3bbc upstream.

The EEH core is talking with the PCI device driver to determine the
action (purely reset, or PCI device removal). During the period, the
driver might be unloaded and in turn causes kernel crash as follows:

EEH: Detected PCI bus error on PHB#4-PE#10000
EEH: This PCI device has failed 3 times in the last hour
lpfc 0004:01:00.0: 0:2710 PCI channel disable preparing for reset
Unable to handle kernel paging request for data at address 0x00000490
Faulting instruction address: 0xd00000000e682c90
cpu 0x1: Vector: 300 (Data Access) at [c000000fc75ffa20]
    pc: d00000000e682c90: .lpfc_io_error_detected+0x30/0x240 [lpfc]
    lr: d00000000e682c8c: .lpfc_io_error_detected+0x2c/0x240 [lpfc]
    sp: c000000fc75ffca0
   msr: 8000000000009032
   dar: 490
 dsisr: 40000000
  current = 0xc000000fc79b88b0
  paca    = 0xc00000000edb0380  softe: 0  irq_happened: 0x00
    pid   = 3386, comm = eehd
enter ? for help
[c000000fc75ffca0c000000fc75ffd30 (unreliable)
[c000000fc75ffd30c00000000004fd3c .eeh_report_error+0x7c/0xf0
[c000000fc75ffdc0c00000000004ee00 .eeh_pe_dev_traverse+0xa0/0x180
[c000000fc75ffe70c00000000004ffd8 .eeh_handle_event+0x68/0x300
[c000000fc75fff00c0000000000503a0 .eeh_event_handler+0x130/0x1a0
[c000000fc75fff90c000000000020138 .kernel_thread+0x54/0x70

The patch increases the reference of the corresponding driver modules
while EEH core does the negotiation with PCI device driver so that the
corresponding driver modules can't be unloaded during the period and
we're safe to refer the callbacks.

Reported-by: Alexey Kardashevskiy <>
Signed-off-by: Gavin Shan <>
Signed-off-by: Benjamin Herrenschmidt <>
[bwh: Backported to 3.2:
 - Adjust context
 - Reporting functions return int (success = 0), not void * (success = NULL)
 - Assume that the 'dev' arguments are non-null]
Signed-off-by: Ben Hutchings <>
9 years agotarget: fix return code in target_core_init_configfs error path
Peter Senna Tschudin [Mon, 17 Sep 2012 18:05:33 +0000 (20:05 +0200)]
target: fix return code in target_core_init_configfs error path

commit 37bb7899ca366dc212b71b150e78566d04808cc0 upstream.

This patch fixes error cases within target_core_init_configfs() to
properly set ret = -ENOMEM before jumping to the out_global exception

This was originally discovered with the following Coccinelle semantic
match information:

Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.  A simplified version of the semantic match
that finds this problem is as follows: (

// <smpl>
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
ret@p1 = 0
... when != ret = e1
    when != &ret
  ... when != ret = e2
      when forall
 return ret;
// </smpl>

Signed-off-by: Peter Senna Tschudin <>
Signed-off-by: Nicholas Bellinger <>
Signed-off-by: Ben Hutchings <>
9 years agostaging: speakup_soft: Fix reading of init string
Ben Hutchings [Sun, 16 Sep 2012 03:18:50 +0000 (04:18 +0100)]
staging: speakup_soft: Fix reading of init string

commit 40fe4f89671fb3c7ded94190fb267402a38b0261 upstream.

softsynth_read() reads a character at a time from the init string;
when it finds the null terminator it sets the initialized flag but
then repeats the last character.

Additionally, if the read() buffer is not big enough for the init
string, the next read() will start reading from the beginning again.
So the caller may never progress to reading anything else.

Replace the simple initialized flag with the current position in
the init string, carried over between calls.  Switch to reading
real data once this reaches the null terminator.

(This assumes that the length of the init string can't change, which
seems to be the case.  Really, the string and position belong together
in a per-file private struct.)

Tested-by: Samuel Thibault <>
Signed-off-by: Ben Hutchings <>
Signed-off-by: Greg Kroah-Hartman <>
9 years agorc: ite-cir: Initialise ite_dev::rdev earlier
Ben Hutchings [Sun, 19 Aug 2012 22:32:27 +0000 (19:32 -0300)]
rc: ite-cir: Initialise ite_dev::rdev earlier

commit 4b961180ef275035b1538317ffd0e21e80e63e77 upstream.

ite_dev::rdev is currently initialised in ite_probe() after
rc_register_device() returns.  If a newly registered device is opened
quickly enough, we may enable interrupts and try to use ite_dev::rdev
before it has been initialised.  Move it up to the earliest point we
can, right after calling rc_allocate_device().

Reported-and-tested-by: YunQiang Su <>
Signed-off-by: Ben Hutchings <>
Signed-off-by: Mauro Carvalho Chehab <>
9 years agohpsa: Use LUN reset instead of target reset
Stephen M. Cameron [Thu, 26 Jul 2012 16:34:10 +0000 (11:34 -0500)]
hpsa: Use LUN reset instead of target reset

commit 21e89afd325849eb38adccf382df16cc895911f9 upstream.

It turns out Smart Array logical drives do not support target
reset and when the target reset fails, the logical drive will
be taken off line.  Symptoms look like this:

hpsa 0000:03:00.0: Abort request on C1:B0:T0:L0
hpsa 0000:03:00.0: resetting device 1:0:0:0
hpsa 0000:03:00.0: cp ffff880037c56000 is reported invalid (probably means target device no longer present)
hpsa 0000:03:00.0: resetting device failed.
sd 1:0:0:0: Device offlined - not ready after error recovery
sd 1:0:0:0: rejecting I/O to offline device
EXT3-fs error (device sdb1): read_block_bitmap:

LUN reset is supported though, and is what we should be using.
Target reset is also disruptive in shared SAS situations,
for example, an external MSA1210m which does support target
reset attached to Smart Arrays in multiple hosts -- a target
reset from one host is disruptive to other hosts as all LUNs
on the target will be reset and will abort all outstanding i/os
back to all the attached hosts.  So we should use LUN reset,
not target reset.

Tested this with Smart Array logical drives and with tape drives.
Not sure how this bug survived since 2009, except it must be very
rare for a Smart Array to require more than 30s to complete a request.

Signed-off-by: Stephen M. Cameron <>
Signed-off-by: James Bottomley <>
Signed-off-by: Ben Hutchings <>
9 years agoxHCI: cancel command after command timeout
Elric Fu [Wed, 27 Jun 2012 08:31:52 +0000 (16:31 +0800)]
xHCI: cancel command after command timeout

commit 6e4468b9a0793dfb53eb80d9fe52c739b13b27fd upstream.

The patch is used to cancel command when the command isn't
acknowledged and a timeout occurs.

This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.

Signed-off-by: Elric Fu <>
Signed-off-by: Sarah Sharp <>
Tested-by: Miroslav Sabljic <>
Signed-off-by: Ben Hutchings <>
9 years agoxHCI: add aborting command ring function
Elric Fu [Wed, 27 Jun 2012 08:31:12 +0000 (16:31 +0800)]
xHCI: add aborting command ring function

commit b92cc66c047ff7cf587b318fe377061a353c120f upstream.

Software have to abort command ring and cancel command
when a command is failed or hang. Otherwise, the command
ring will hang up and can't handle the others. An example
of a command that may hang is the Address Device Command,
because waiting for a SET_ADDRESS request to be acknowledged
by a USB device is outside of the xHC's ability to control.

To cancel a command, software will initialize a command
descriptor for the cancel command, and add it into a
cancel_cmd_list of xhci.

Sarah: Fixed missing newline on "Have the command ring been stopped?"
debugging statement.

This patch should be backported to kernels as old as 3.0, that contain
the commit 7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an
assertion to check for virt_dev=0 bug." That commit papers over a NULL
pointer dereference, and this patch fixes the underlying issue that
caused the NULL pointer dereference.

Signed-off-by: Elric Fu <>
Signed-off-by: Sarah Sharp <>
Tested-by: Miroslav Sabljic <>
Signed-off-by: Ben Hutchings <>
9 years agoxHCI: add cmd_ring_state
Elric Fu [Wed, 27 Jun 2012 08:30:57 +0000 (16:30 +0800)]
xHCI: add cmd_ring_state

commit c181bc5b5d5c79b71203cd10cef97f802fb6f9c1 upstream.

Adding cmd_ring_state for command ring. It helps to verify
the current command ring state for controlling the command
ring operations.

This patch should be backported to kernels as old as 3.0.  The commit
7ed603ecf8b68ab81f4c83097d3063d43ec73bb8 "xhci: Add an assertion to
check for virt_dev=0 bug." papers over the NULL pointer dereference that
I now believe is related to a timed out Set Address command.  This (and
the four patches that follow it) contain the real fix that also allows
VIA USB 3.0 hubs to consistently re-enumerate during the plug/unplug
stress tests.

Signed-off-by: Elric Fu <>
Signed-off-by: Sarah Sharp <>
Tested-by: Miroslav Sabljic <>
Signed-off-by: Ben Hutchings <>
9 years agoxhci: Warn when hosts don't halt.
Sarah Sharp [Fri, 16 Mar 2012 19:58:20 +0000 (12:58 -0700)]
xhci: Warn when hosts don't halt.

commit 5af98bb06dee79d28c805f9fd0805ce791121784 upstream.

Eric Fu reports a problem with his VIA host controller fetching a zeroed
event ring pointer on resume from suspend.  The host should have been
halted, but we can't be sure because that code ignores the return value
from xhci_halt().  Print a warning when the host controller refuses to
halt within XHCI_MAX_HALT_USEC (currently 16 seconds).

(Update: it turns out that the VIA host controller is reporting a halted
state when it fetches the zeroed event ring pointer.  However, we still
need this warning for other host controllers.)

Signed-off-by: Sarah Sharp <>
Signed-off-by: Ben Hutchings <>
9 years agogspca_pac7302: add support for device 1ae7:2001 Speedlink Snappy Microphone SL-6825-SBK
Frank Schäfer [Sun, 9 Sep 2012 18:02:19 +0000 (15:02 -0300)]
gspca_pac7302: add support for device 1ae7:2001 Speedlink Snappy Microphone SL-6825-SBK

commit 97d2fbf501e3cf105ac957086c7e40e62e15cdf8 upstream.

Signed-off-by: Frank Schäfer <>
Signed-off-by: Hans de Goede <>
Signed-off-by: Mauro Carvalho Chehab <>
[bwh: Backported to 3.2: adjust filename]
Signed-off-by: Ben Hutchings <>
9 years agogspca_pac7302: Add usb-id for 145f:013c
Hans de Goede [Fri, 30 Dec 2011 22:15:53 +0000 (19:15 -0300)]
gspca_pac7302: Add usb-id for 145f:013c

commit 4d6454dbae935825e729f34dc7410bb1b22c7944 upstream.

Reported by: Grzegorz Woźniak

Signed-off-by: Hans de Goede <>
Signed-off-by: Mauro Carvalho Chehab <>
Signed-off-by: Ben Hutchings <>
9 years agoslab: fix the DEADLOCK issue on l3 alien lock
Michael Wang [Wed, 5 Sep 2012 02:33:18 +0000 (10:33 +0800)]
slab: fix the DEADLOCK issue on l3 alien lock

commit 947ca1856a7e60aa6d20536785e6a42dff25aa6e upstream.

DEADLOCK will be report while running a kernel with NUMA and LOCKDEP enabled,
the process of this fake report is:

   kmem_cache_free() //free obj in cachep
-> cache_free_alien() //acquire cachep's l3 alien lock
-> __drain_alien_cache()
-> free_block()
-> slab_destroy()
-> kmem_cache_free() //free slab in cachep->slabp_cache
-> cache_free_alien() //acquire cachep->slabp_cache's l3 alien lock

Since the cachep and cachep->slabp_cache's l3 alien are in the same lock class,
fake report generated.

This should not happen since we already have init_lock_keys() which will
reassign the lock class for both l3 list and l3 alien.

However, init_lock_keys() was invoked at a wrong position which is before we
invoke enable_cpucache() on each cache.

Since until set slab_state to be FULL, we won't invoke enable_cpucache()
on caches to build their l3 alien while creating them, so although we invoked
init_lock_keys(), the l3 alien lock class won't change since we don't have
them until invoked enable_cpucache() later.

This patch will invoke init_lock_keys() after we done enable_cpucache()
instead of before to avoid the fake DEADLOCK report.

Michael traced the problem back to a commit in release 3.0.0:

commit 30765b92ada267c5395fc788623cb15233276f5c
Author: Peter Zijlstra <>
Date:   Thu Jul 28 23:22:56 2011 +0200

    slab, lockdep: Annotate the locks before using them

    Fernando found we hit the regular OFF_SLAB 'recursion' before we
    annotate the locks, cure this.

    The relevant portion of the stack-trace:

    > [    0.000000]  [<c085e24f>] rt_spin_lock+0x50/0x56
    > [    0.000000]  [<c04fb406>] __cache_free+0x43/0xc3
    > [    0.000000]  [<c04fb23f>] kmem_cache_free+0x6c/0xdc
    > [    0.000000]  [<c04fb2fe>] slab_destroy+0x4f/0x53
    > [    0.000000]  [<c04fb396>] free_block+0x94/0xc1
    > [    0.000000]  [<c04fc551>] do_tune_cpucache+0x10b/0x2bb
    > [    0.000000]  [<c04fc8dc>] enable_cpucache+0x7b/0xa7
    > [    0.000000]  [<c0bd9d3c>] kmem_cache_init_late+0x1f/0x61
    > [    0.000000]  [<c0bba687>] start_kernel+0x24c/0x363
    > [    0.000000]  [<c0bba0ba>] i386_start_kernel+0xa9/0xaf

Reported-by: Fernando Lopez-Lezcano <nando@ccrma.Stanford.EDU>
Acked-by: Pekka Enberg <>
Signed-off-by: Peter Zijlstra <>
Signed-off-by: Ingo Molnar <>
The commit moved init_lock_keys() before we build up the alien, so we
failed to reclass it.

Acked-by: Christoph Lameter <>
Tested-by: Paul E. McKenney <>
Signed-off-by: Michael Wang <>
Signed-off-by: Pekka Enberg <>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <>
9 years agotools/hv: Fix exit() error code
Ben Hutchings [Wed, 5 Sep 2012 21:37:36 +0000 (14:37 -0700)]
tools/hv: Fix exit() error code

commit 6bb22fea25624ab593eee376fa5fb82d1b13f45a upstream.

Linux native exit codes are 8-bit unsigned values.  exit(-1) results
in an exit code of 255, which is usually reserved for shells reporting
'command not found'.  Use the portable value EXIT_FAILURE.  (Not that
this matters much for a daemon.)

Signed-off-by: Ben Hutchings <>
Signed-off-by: K. Y. Srinivasan <>
Signed-off-by: Greg Kroah-Hartman <>
[bwh: Backported to 3.2: drop changes to exit() calls not in this version]

9 years agofirmware: Add missing attributes to EFI variable attribute print out from sysfs
Khalid Aziz [Mon, 10 Sep 2012 18:52:42 +0000 (12:52 -0600)]
firmware: Add missing attributes to EFI variable attribute print out from sysfs

commit 7083909023bbe29b3176e92d2d089def1aa7aa1e upstream.

Some of the EFI variable attributes are missing from print out from
/sys/firmware/efi/vars/*/attributes. This patch adds those in. It also
updates code to use pre-defined constants for masking current value
of attributes.

Signed-off-by: Khalid Aziz <>
Reviewed-by: Kees Cook <>
Acked-by: Matthew Garrett <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoUBI: erase free PEB with bitflip in EC header
Matthieu CASTET [Wed, 22 Aug 2012 14:03:46 +0000 (16:03 +0200)]
UBI: erase free PEB with bitflip in EC header

commit 193819cf2e6e395b1e1be2d36785dc5563a6edca upstream.

Without this patch, these PEB are not scrubbed until we put data in them.
Bitflip can accumulate latter and we can loose the EC header (but VID header
should be intact and allow to recover data).

Signed-off-by: Matthieu Castet <>
Signed-off-by: Artem Bityutskiy <>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <>
9 years agoUBI: fix autoresize handling in R/O mode
Artem Bityutskiy [Sat, 18 Aug 2012 12:11:42 +0000 (14:11 +0200)]
UBI: fix autoresize handling in R/O mode

commit abb3e01103eb4e2ea5c15e6fedbc74e08bd4cc2b upstream.

Currently UBI fails in autoresize when it is in R/O mode (e.g., because the
underlying MTD device is R/O). This patch fixes the issue - we just skip
autoresize and print a warning.

Reported-by: Pali Rohár <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: Ben Hutchings <>
9 years agon_gsm: memory leak in uplink error path
Russ Gorby [Mon, 13 Aug 2012 12:45:30 +0000 (13:45 +0100)]
n_gsm: memory leak in uplink error path

commit 88ed2a60610974443335c924d7cb8e5dcf9dbdc1 upstream.

Uplink (TX) network data will go through gsm_dlci_data_output_framed
there is a bug where if memory allocation fails, the skb which
has already been pulled off the list will be lost.

In addition TX skbs were being processed in LIFO order

Fixed the memory leak, and changed to FIFO order processing

Signed-off-by: Russ Gorby <>
Tested-by: Kappel, LaurentX <>
Signed-off-by: Alan Cox <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agon_gsm: replace kfree_skb w/ appropriate dev_* versions
Russ Gorby [Mon, 13 Aug 2012 12:45:15 +0000 (13:45 +0100)]
n_gsm: replace kfree_skb w/ appropriate dev_* versions

commit 329e56780e514a7ab607bcb51a52ab0dc2669414 upstream.

Drivers are supposed to use the dev_* versions of the kfree_skb
interfaces. In a couple of cases we were called with IRQs
disabled as well which kfree_skb() does not expect.

Replaced kfree_skb calls w/ dev_kfree_skb and dev_kfree_skb_any

Signed-off-by: Russ Gorby <>
Tested-by: Yin, Fengwei <>
Signed-off-by: Alan Cox <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agon_gsm: avoid accessing freed memory during CMD_FCOFF condition
Russ Gorby [Mon, 13 Aug 2012 12:44:59 +0000 (13:44 +0100)]
n_gsm: avoid accessing freed memory during CMD_FCOFF condition

commit b4338e1efc339986cf6c0a3652906e914a86e2d3 upstream.

gsm_data_kick was recently modified to allow messages on the
tx queue bound for DLCI0 to flow even during FCOFF conditions.
Unfortunately we introduced a bug discovered by code inspection
where subsequent list traversers can access freed memory if
the DLCI0 messages were not all at the head of the list.

Replaced singly linked tx list w/ a list_head and used
provided interfaces for traversing and deleting members.

Signed-off-by: Russ Gorby <>
Tested-by: Yin, Fengwei <>
Signed-off-by: Alan Cox <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agon_gsm: added interlocking for gsm_data_lock for certain code paths
Russ Gorby [Mon, 13 Aug 2012 12:44:40 +0000 (13:44 +0100)]
n_gsm: added interlocking for gsm_data_lock for certain code paths

commit 5e44708f75b0f8712da715d6babb0c21089b2317 upstream.

There were some locking holes in the management of the MUX's
message queue for 2 code paths:
1) gsmld_write_wakeup
2) receipt of CMD_FCON flow-control message
In both cases gsm_data_kick is called w/o locking so it can collide
with other other instances of gsm_data_kick (pulling messages tx_tail)
or potentially other instances of __gsm_data_queu (adding messages to tx_head)

Changed to take the tx_lock in these 2 cases

Signed-off-by: Russ Gorby <>
Tested-by: Yin, Fengwei <>
Signed-off-by: Alan Cox <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agochar: n_gsm: remove message filtering for contipated DLCI
samix.lebsir [Mon, 13 Aug 2012 12:44:22 +0000 (13:44 +0100)]
char: n_gsm: remove message filtering for contipated DLCI

commit 10c6c383e43565c9c6ec07ff8eb2825f8091bdf0 upstream.

The design of uplink flow control in the mux driver is
that for constipated channels data will backup into the
per-channel fifos, and any messages that make it to the
outbound message queue will still go out.
Code was added to also stop messages that were in the outbound
queue but this requires filtering through all the messages on the
queue for stopped dlcis and changes some of the mux logic unneccessarily.

The message fiiltering was removed to be in line w/ the original design
as the message filtering does not provide any solution.
Extra debug messages used during investigation were also removed.

Signed-off-by: samix.lebsir <>
Signed-off-by: Alan Cox <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agon_gsm : Flow control handling in Mux driver
Frederic Berat [Mon, 13 Aug 2012 12:43:58 +0000 (13:43 +0100)]
n_gsm : Flow control handling in Mux driver

commit c01af4fec2c8f303d6b3354d44308d9e6bef8026 upstream.

- Correcting handling of FCon/FCoff in order to respect 27.010 spec
- Consider FCon/off will overide all dlci flow control except for
  dlci0 as we must be able to send control frames.
- Dlci constipated handling according to FC, RTC and RTR values.
- Modifying gsm_dlci_data_kick and gsm_dlci_data_sweep according
  to dlci constipated value

Signed-off-by: Frederic Berat <>
Signed-off-by: Russ Gorby <>
Signed-off-by: Alan Cox <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agon_gsm: uplink SKBs accumulate on list
Russ Gorby [Mon, 13 Aug 2012 12:43:36 +0000 (13:43 +0100)]
n_gsm: uplink SKBs accumulate on list

commit 192b6041e75bb4a2aae73834037038cea139a92d upstream.

gsm_dlci_data_kick will not call any output function if tx_bytes > THRESH_LO
furthermore it will call the output function only once if tx_bytes == 0
If the size of the IP writes are on the order of THRESH_LO
we can get into a situation where skbs accumulate on the outbound list
being starved for events to call the output function.

gsm_dlci_data_kick now calls the sweep function when tx_bytes==0

Signed-off-by: Russ Gorby <>
Tested-by: Kappel, LaurentX <>
Signed-off-by: Alan Cox <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agon_gsm.c: Implement 3GPP27.010 DLC start-up procedure in MUX
xiaojin [Mon, 13 Aug 2012 12:43:15 +0000 (13:43 +0100)]
n_gsm.c: Implement 3GPP27.010 DLC start-up procedure in MUX

commit 7e8ac7b23b67416700dfb8b4136a4e81ce675b48 upstream.

In 3GPP27.010 5.8.1, it defined:
The TE multiplexer initiates the establishment of the multiplexer control channel by sending a SABM frame on DLCI 0 using the procedures of clause 5.4.1.
Once the multiplexer channel is established other DLCs may be established using the procedures of clause 5.4.1.
This patch implement 5.8.1 in MUX level, it make sure DLC0 is the first channel to be setup.

[or for those not familiar with the specification: it was possible to try
 and open a data connection while the control channel was not yet fully
 open, which is a spec violation and confuses some modems]

Signed-off-by: xiaojin <>
Tested-by: Yin, Fengwei <>
[tweaked the order we check things and error code]
Signed-off-by: Alan Cox <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoRemove BUG_ON from n_tty_read()
Stanislav Kozina [Thu, 16 Aug 2012 11:01:47 +0000 (12:01 +0100)]
Remove BUG_ON from n_tty_read()

commit e9490e93c1978b6669f3e993caa3189be13ce459 upstream.

Change the BUG_ON to WARN_ON and return in case of tty->read_buf==NULL. We want to track a
couple of long standing reports of this but at the same time we can avoid killing the box.

Signed-off-by: Stanislav Kozina <>
Signed-off-by: Alan Cox <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoTTY: ttyprintk, don't touch behind tty->write_buf
Jiri Slaby [Tue, 7 Aug 2012 19:47:39 +0000 (21:47 +0200)]
TTY: ttyprintk, don't touch behind tty->write_buf

commit ee8b593affdf893012e57f4c54a21984d1b0d92e upstream.

If a user provides a buffer larger than a tty->write_buf chunk and
passes '\r' at the end of the buffer, we touch an out-of-bound memory.

Add a check there to prevent this.

Signed-off-by: Jiri Slaby <>
Cc: Samo Pogacnik <>
Signed-off-by: Greg Kroah-Hartman <>
Signed-off-by: Ben Hutchings <>
9 years agoworkqueue: add missing smp_wmb() in process_one_work()
Tejun Heo [Fri, 3 Aug 2012 17:30:45 +0000 (10:30 -0700)]
workqueue: add missing smp_wmb() in process_one_work()

commit 959d1af8cffc8fd38ed53e8be1cf4ab8782f9c00 upstream.

WORK_STRUCT_PENDING is used to claim ownership of a work item and
process_one_work() releases it before starting execution.  When
someone else grabs PENDING, all pre-release updates to the work item
should be visible and all updates made by the new owner should happen

Grabbing PENDING uses test_and_set_bit() and thus has a full barrier;
however, clearing doesn't have a matching wmb.  Given the preceding
spin_unlock and use of clear_bit, I don't believe this can be a
problem on an actual machine and there hasn't been any related report
but it still is theretically possible for clear_pending to permeate
upwards and happen before work->entry update.

Add an explicit smp_wmb() before work_clear_pending().

Signed-off-by: Tejun Heo <>
Cc: Oleg Nesterov <>
Signed-off-by: Ben Hutchings <>
9 years agodrm/i915: prevent possible pin leak on error path
Eugeni Dodonov [Mon, 18 Jun 2012 22:03:38 +0000 (19:03 -0300)]
drm/i915: prevent possible pin leak on error path

commit ab3951eb74e7c33a2f5b7b64d72e82f1eea61571 upstream.

We should not hit this under any sane conditions, but still, this does not
looks right.

CC: Chris Wilson <>
CC: Daniel Vetter <>
Reported-by: Herton Ronaldo Krzesinski <>
Reviewed-by: Chris Wlison <>
Signed-off-by: Eugeni Dodonov <>
Signed-off-by: Daniel Vetter <>
Signed-off-by: Ben Hutchings <>
9 years agomtd: nand: Use the mirror BBT descriptor when reading its version
Shmulik Ladkani [Sun, 10 Jun 2012 10:58:12 +0000 (13:58 +0300)]
mtd: nand: Use the mirror BBT descriptor when reading its version

commit 7bb9c75436212813b38700c34df4bbb6eb82debe upstream.

The code responsible for reading the version of the mirror bbt was
incorrectly using the descriptor of the main bbt.

Pass the mirror bbt descriptor to 'scan_read_raw' when reading the
version of the mirror bbt.

Signed-off-by: Shmulik Ladkani <>
Acked-by: Sebastian Andrzej Siewior <>
Signed-off-by: Artem Bityutskiy <>
Signed-off-by: David Woodhouse <>
Signed-off-by: Ben Hutchings <>
9 years agoisci: fix isci_pci_probe() generates warning on efi failure path
Dan Williams [Fri, 22 Jun 2012 18:31:14 +0000 (11:31 -0700)]
isci: fix isci_pci_probe() generates warning on efi failure path

commit 6d70a74ffd616073a68ae0974d98819bfa8e6da6 upstream.

The oem parameter image embedded in the efi variable is at an offset
from the start of the variable.  However, in the failure path we try to
free the 'orom' pointer which is only valid when the paramaters are
being read from the legacy option-rom space.

Since failure to load the oem parameters is unlikely and we keep the
memory around in the success case just defer all de-allocation to devm.

Reported-by: Don Morris <>
Signed-off-by: Dan Williams <>
Signed-off-by: Ben Hutchings <>
9 years agoLinux 3.2.31 v3.2.31
Ben Hutchings [Wed, 10 Oct 2012 02:31:37 +0000 (03:31 +0100)]
Linux 3.2.31

9 years agoBluetooth: Add support for Sony Vaio T-Series
Yevgeniy Melnichuk [Tue, 7 Aug 2012 14:18:10 +0000 (19:48 +0530)]
Bluetooth: Add support for Sony Vaio T-Series

commit bc21fde2d549d1cb1ebef04016eb7affa43bb5c1 upstream.

Add Sony Vaio T-Series Bluetooth Module( 0x489:0xE036) to
the blacklist of btusb module and add it to the ath3k module.

output of cat /sys/kernel/debug/usb/devices

T:  Bus=01 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  5 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0489 ProdID=e036 Rev= 0.02
S:  Manufacturer=Atheros Communications
S:  Product=Bluetooth USB Host Controller
S:  SerialNumber=Alaska Day 2006
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

Signed-off-by: Yevgeniy Melnichuk <>
Signed-off-by: Mohammed Shafi Shajakhan <>
Acked-by: Marcel Holtmann <>
Signed-off-by: Gustavo Padovan <>
Signed-off-by: Ben Hutchings <>
9 years agoBluetooth: add support for atheros 0489:e057
Peng Chen [Wed, 1 Aug 2012 02:11:59 +0000 (10:11 +0800)]
Bluetooth: add support for atheros 0489:e057

commit 2096ae6ca647302d50a68aa36cb66a00e7dfac70 upstream.

    Add support for the AR3012 chip found on Fioxconn.

    usb-devices shows:

    T:  Bus=06 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 44 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0489 ProdID=e057 Rev= 0.02
    C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms

Signed-off-by: Peng Chen <>
Signed-off-by: Gustavo Padovan <>
Signed-off-by: Ben Hutchings <>
9 years agoBluetooth: add support for atheros 0930:0219
Giancarlo Formicuccia [Sun, 10 Jun 2012 06:33:11 +0000 (08:33 +0200)]
Bluetooth: add support for atheros 0930:0219

commit 6c4ae5c2e7bfbb7d10d73611f69ac8a8609d84fd upstream.

Add support for the AR3012 chip found on the Toshiba Sallite M840-1000-XQ.

usb-devices shows:

T:  Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0930 ProdID=0219 Rev=00.02
S:  Manufacturer=Atheros Communications
S:  Product=Bluetooth USB Host Controller
S:  SerialNumber=Alaska Day 2006
C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb

Signed-off-by: Giancarlo Formicuccia <>
Signed-off-by: Gustavo Padovan <>
Signed-off-by: Ben Hutchings <>
9 years agoBluetooth: Support AR3011 in Acer Iconia Tab W500
Marek Vasut [Fri, 8 Jun 2012 12:32:50 +0000 (14:32 +0200)]
Bluetooth: Support AR3011 in Acer Iconia Tab W500

commit 6eda541d12116b4772baa09d3e8d7b0389df4289 upstream.

Acer used this chip connected via USB:

Bus 005 Device 005: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass          224 Wireless
  bDeviceSubClass         1 Radio Frequency
  bDeviceProtocol         1 Bluetooth
  bMaxPacketSize0        64
  idVendor           0x0cf3 Atheros Communications, Inc.
  idProduct          0x3005 AR3011 Bluetooth
  bcdDevice            0.01
  iManufacturer           0
  iProduct                0
  iSerial                 0
  bNumConfigurations      1

Signed-off-by: Marek Vasut <>
Cc: Gustavo Padovan <>
Cc: Johan Hedberg <>
Cc: Marcel Holtmann <>
Signed-off-by: Gustavo Padovan <>
Signed-off-by: Ben Hutchings <>
9 years agotg3: Fix TSO CAP for 5704 devs w / ASF enabled
Matt Carlson [Mon, 28 Nov 2011 09:41:03 +0000 (09:41 +0000)]
tg3: Fix TSO CAP for 5704 devs w / ASF enabled

[ Upstream commit cf9ecf4b631f649a964fa611f1a5e8874f2a76db ]

On the earliest TSO capable devices, TSO was accomplished through
firmware.  The TSO cannot coexist with ASF management firmware though.
The tg3 driver determines whether or not ASF is enabled by calling
tg3_get_eeprom_hw_cfg(), which checks a particular bit of NIC memory.
Commit dabc5c670d3f86d15ee4f42ab38ec5bd2682487d, entitled "tg3: Move
TSO_CAPABLE assignment", accidentally moved the code that determines
TSO capabilities earlier than the call to tg3_get_eeprom_hw_cfg().  As a
consequence, the driver was attempting to determine TSO capabilities
before it had all the data it needed to make the decision.

This patch fixes the problem by revisiting and reevaluating the decision
after tg3_get_eeprom_hw_cfg() is called.

Signed-off-by: Matt Carlson <>
Signed-off-by: Michael Chan <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoaoe: assert AoE packets marked as requiring no checksum
Ed Cashin [Wed, 19 Sep 2012 15:46:39 +0000 (15:46 +0000)]
aoe: assert AoE packets marked as requiring no checksum

[ Upstream commit 8babe8cc6570ed896b7b596337eb8fe730c3ff45 ]

In order for the network layer to see that AoE requires
no checksumming in a generic way, the packets must be
marked as requiring no checksum, so we make this requirement
explicit with the assertion.

Signed-off-by: Ed Cashin <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet: do not disable sg for packets requiring no checksum
Ed Cashin [Wed, 19 Sep 2012 15:49:00 +0000 (15:49 +0000)]
net: do not disable sg for packets requiring no checksum

[ Upstream commit c0d680e577ff171e7b37dbdb1b1bf5451e851f04 ]

A change in a series of VLAN-related changes appears to have
inadvertently disabled the use of the scatter gather feature of
network cards for transmission of non-IP ethernet protocols like ATA
over Ethernet (AoE).  Below is a reference to the commit that
introduces a "harmonize_features" function that turns off scatter
gather when the NIC does not support hardware checksumming for the
ethernet protocol of an sk buff.

  commit f01a5236bd4b140198fbcc550f085e8361fd73fa
  Author: Jesse Gross <>
  Date:   Sun Jan 9 06:23:31 2011 +0000

      net offloading: Generalize netif_get_vlan_features().

The can_checksum_protocol function is not equipped to consider a
protocol that does not require checksumming.  Calling it for a
protocol that requires no checksum is inappropriate.

The patch below has harmonize_features call can_checksum_protocol when
the protocol needs a checksum, so that the network layer is not forced
to perform unnecessary skb linearization on the transmission of AoE
packets.  Unnecessary linearization results in decreased performance
and increased memory pressure, as reported here:

The problem has probably not been widely experienced yet, because
only recently has the aoe driver acquired the
ability to use payloads of over a page in size, with the patchset
recently included in the mm tree:

The aoe driver already could use payloads of
greater than a page in size, but its users generally do not use the
newest kernels.

Signed-off-by: Ed Cashin <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonetrom: copy_datagram_iovec can fail
Alan Cox [Tue, 4 Sep 2012 04:13:18 +0000 (04:13 +0000)]
netrom: copy_datagram_iovec can fail

[ Upstream commit 6cf5c951175abcec4da470c50565cc0afe6cd11d ]

Check for an error from this and if so bail properly.

Signed-off-by: Alan Cox <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agol2tp: fix a typo in l2tp_eth_dev_recv()
Eric Dumazet [Tue, 4 Sep 2012 19:54:55 +0000 (15:54 -0400)]
l2tp: fix a typo in l2tp_eth_dev_recv()

[ Upstream commit c0cc88a7627c333de50b07b7c60b1d49d9d2e6cc ]

While investigating l2tp bug, I hit a bug in eth_type_trans(),
because not enough bytes were pulled in skb head.

Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoipv6: mip6: fix mip6_mh_filter()
Eric Dumazet [Tue, 25 Sep 2012 20:01:28 +0000 (22:01 +0200)]
ipv6: mip6: fix mip6_mh_filter()

[ Upstream commit 96af69ea2a83d292238bdba20e4508ee967cf8cb ]

mip6_mh_filter() should not modify its input, or else its caller
would need to recompute ipv6_hdr() if skb->head is reallocated.

Use skb_header_pointer() instead of pskb_may_pull()

Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoipv6: raw: fix icmpv6_filter()
Eric Dumazet [Tue, 25 Sep 2012 07:03:40 +0000 (07:03 +0000)]
ipv6: raw: fix icmpv6_filter()

[ Upstream commit 1b05c4b50edbddbdde715c4a7350629819f6655e ]

icmpv6_filter() should not modify its input, or else its caller
would need to recompute ipv6_hdr() if skb->head is reallocated.

Use skb_header_pointer() instead of pskb_may_pull() and
change the prototype to make clear both sk and skb are const.

Also, if icmpv6 header cannot be found, do not deliver the packet,
as we do in IPv4.

Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agoipv4: raw: fix icmp_filter()
Eric Dumazet [Sat, 22 Sep 2012 00:08:29 +0000 (00:08 +0000)]
ipv4: raw: fix icmp_filter()

[ Upstream commit ab43ed8b7490cb387782423ecf74aeee7237e591 ]

icmp_filter() should not modify its input, or else its caller
would need to recompute ip_hdr() if skb->head is reallocated.

Use skb_header_pointer() instead of pskb_may_pull() and
change the prototype to make clear both sk and skb are const.

Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>
9 years agonet: guard tcp_set_keepalive() to tcp sockets
Eric Dumazet [Mon, 24 Sep 2012 07:00:11 +0000 (07:00 +0000)]
net: guard tcp_set_keepalive() to tcp sockets

[ Upstream commit 3e10986d1d698140747fcfc2761ec9cb64c1d582 ]

Its possible to use RAW sockets to get a crash in
tcp_set_keepalive() / sk_reset_timer()

Fix is to make sure socket is a SOCK_STREAM one.

Reported-by: Dave Jones <>
Signed-off-by: Eric Dumazet <>
Signed-off-by: David S. Miller <>
Signed-off-by: Ben Hutchings <>