commit 07a4483ba67329c38a57b30060b598ba388f8a93 Author: Greg Kroah-Hartman Date: Mon Apr 2 10:32:52 2012 -0700 Linux 3.3.1 commit bc67f4a645796ad57ccd10f2814d0cb5ddd8fb4b Author: Matthew Garrett Date: Tue Mar 27 10:17:41 2012 -0400 ASPM: Fix pcie devices with non-pcie children commit c9651e70ad0aa499814817cbf3cc1d0b806ed3a1 upstream. Since 3.2.12 and 3.3, some systems are failing to boot with a BUG\_ON. Some other systems using the pata\_jmicron driver fail to boot because no disks are detected. Passing pcie\_aspm=force on the kernel command line works around it. The cause: commit 4949be16822e ("PCI: ignore pre-1.1 ASPM quirking when ASPM is disabled") changed the behaviour of pcie\_aspm\_sanity\_check() to always return 0 if aspm is disabled, in order to avoid cases where we changed ASPM state on pre-PCIe 1.1 devices. This skipped the secondary function of pcie\_aspm\_sanity\_check which was to avoid us enabling ASPM on devices that had non-PCIe children, causing trouble later on. Move the aspm\_disabled check so we continue to honour that scenario. Addresses https://bugzilla.kernel.org/show\_bug.cgi?id=42979 and http://bugs.debian.org/665420 Reported-by: Romain Francoise # kernel panic Reported-by: Chris Holland # disk detection trouble Signed-off-by: Matthew Garrett Tested-by: Hatem Masmoudi # Dell Latitude E5520 Tested-by: janek # pata\_jmicron with JMB362/JMB363 \[jn: with more symptoms in log message\] Signed-off-by: Jonathan Nieder Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6b9256f587c31719bb43ee7beb4468b0c7ff6fd5 Author: Yoshii Takashi Date: Wed Mar 14 16:14:43 2012 +0900 serial: sh-sci: fix a race of DMA submit\_tx on transfer commit 49d4bcaddca977fffdea8b0b71f6e5da96dac78e upstream. When DMA is enabled, sh-sci transfer begins with uart\_start() sci\_start\_tx() if (cookie\_tx < 0) schedule\_work() Then, starts DMA when wq scheduled, -- (A) process\_one\_work() work\_fn\_rx() cookie\_tx = desc->submit\_tx() And finishes when DMA transfer ends, -- (B) sci\_dma\_tx\_complete() async\_tx\_ack() cookie\_tx = -EINVAL (possible another schedule\_work()) This A to B sequence is not reentrant, since controlling variables (for example, cookie\_tx above) are not queues nor lists. So, they must be invoked as A B A B..., otherwise results in kernel crash. To ensure the sequence, sci\_start\_tx() seems to test if cookie\_tx < 0 (represents "not used") to call schedule\_work(). But cookie\_tx will not be set (to a cookie, also means "used") until in the middle of work queue scheduled function work\_fn\_tx(). This gap between the test and set allows the breakage of the sequence under the very frequently call of uart\_start(). Another gap between async\_tx\_ack() and another schedule\_work() results in the same issue, too. This patch introduces a new condition "cookie\_tx == 0" just to mark it is "busy" and assign it within spin-locked region to fill the gaps. Signed-off-by: Takashi Yoshii Reviewed-by: Guennadi Liakhovetski Signed-off-by: Paul Mundt Signed-off-by: Greg Kroah-Hartman commit 6de1fa5c309239effe67bfed34a20a901dc7983d Author: Stephen Warren Date: Mon Mar 19 13:57:13 2012 -0600 ARM: tegra: Fix device tree AUXDATA for USB/EHCI commit 8c3ec84102d171a24f050a086bfc546e9de93f9f upstream. Commit 4a53f4e "USB: ehci-tegra: add probing through device tree" added AUXDATA for Tegra's USB/EHCI controller. However, it pointed the platform data at a location containing the address of the intended platform data, rather than the platform data itself. This change fixes that. Signed-off-by: Stephen Warren Signed-off-by: Greg Kroah-Hartman commit 7b6b691420ef8ec6f1531b60b5a4a6319096a29c Author: Dan Carpenter Date: Wed Jan 18 12:56:02 2012 +0300 nfsd: don't allow zero length strings in cache\_parse() commit 6d8d17499810479eabd10731179c04b2ca22152f upstream. There is no point in passing a zero length string here and quite a few of that cache\_parse() implementations will Oops if count is zero. Signed-off-by: Dan Carpenter Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 70068b59149237c8b27178b082e83005521204cb Author: John Stultz Date: Tue Mar 6 17:16:09 2012 -0800 rtc: Provide flag for rtc devices that don't support UIE commit 4a649903f91232d02284d53724b0a45728111767 upstream. Richard Weinberger noticed that on some RTC hardware that doesn't support UIE mode, due to coarse granular alarms (like 1minute resolution), the current virtualized RTC support doesn't properly error out when UIE is enabled. Instead the current code queues an alarm for the next second, but it won't fire until up to a miniute later. This patch provides a generic way to flag this sort of hardware and fixes the issue on the mpc5121 where Richard noticed the problem. Reported-by: Richard Weinberger Tested-by: Richard Weinberger Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit a54ca770b33c0cb30da29ac6affa2e0ab8aea056 Author: Chris Metcalf Date: Mon Mar 26 16:26:12 2012 -0400 compat: use sys\_sendfile64() implementation for sendfile syscall commit 1631fcea8399da5e80a80084b3b8c5bfd99d21e7 upstream. was set up to use sys\_sendfile() for the 32-bit compat API instead of sys\_sendfile64(), but in fact the right thing to do is to use sys\_sendfile64() in all cases. The 32-bit sendfile64() API in glibc uses the sendfile64 syscall, so it has to be capable of doing full 64-bit operations. But the sys\_sendfile() kernel implementation has a MAX\_NON\_LFS test in it which explicitly limits the offset to 2^32. So, we need to use the sys\_sendfile64() implementation in the kernel for this case. Acked-by: Arnd Bergmann Signed-off-by: Chris Metcalf Signed-off-by: Greg Kroah-Hartman commit d66ffda478cd1d96e25d94866baed2eb8bce79e4 Author: Dan Carpenter Date: Sat Mar 24 10:52:50 2012 +0300 x86, tls: Off by one limit check commit 8f0750f19789cf352d7e24a6cc50f2ab1b4f1372 upstream. These are used as offsets into an array of GDT\_ENTRY\_TLS\_ENTRIES members so GDT\_ENTRY\_TLS\_ENTRIES is one past the end of the array. Signed-off-by: Dan Carpenter Link: http://lkml.kernel.org/r/20120324075250.GA28258@elgon.mountain Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit e5ff2be53c7c25a50893e7b32a6b96922a9ae904 Author: Alok Kataria Date: Tue Feb 21 18:19:55 2012 -0800 x86, tsc: Skip refined tsc calibration on systems with reliable TSC commit 57779dc2b3b75bee05ef5d1ada47f615f7a13932 upstream. While running the latest Linux as guest under VMware in highly over-committed situations, we have seen cases when the refined TSC algorithm fails to get a valid tsc\_start value in tsc\_refine\_calibration\_work from multiple attempts. As a result the kernel keeps on scheduling the tsc\_irqwork task for later. Subsequently after several attempts when it gets a valid start value it goes through the refined calibration and either bails out or uses the new results. Given that the kernel originally read the TSC frequency from the platform, which is the best it can get, I don't think there is much value in refining it. So for systems which get the TSC frequency from the platform we should skip the refined tsc algorithm. We can use the TSC\_RELIABLE cpu cap flag to detect this, right now it is set only on VMware and for Moorestown Penwell both of which have there own TSC calibration methods. Signed-off-by: Alok N Kataria Cc: John Stultz Cc: Dirk Brandewie Cc: Alan Cox \[jstultz: Reworked to simply not schedule the refining work, rather then scheduling the work and bombing out later\] Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit 523ae2b6f47f9451952c5d7c104c94a5d4765291 Author: NeilBrown Date: Tue Feb 7 15:35:42 2012 +1100 lockd: fix arg parsing for grace\_period and timeout. commit de5b8e8e047534aac6bc9803f96e7257436aef9c upstream. If you try to set grace\_period or timeout via a module parameter to lockd, and do this on a big-endian machine where sizeof(int) != sizeof(unsigned long) it won't work. This number given will be effectively shifted right by the difference in those two sizes. So cast kp->arg properly to get correct result. Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman commit 7731184bff478c662868361f275c640d16fd3ef0 Author: Eric Dumazet Date: Tue Mar 27 09:53:52 2012 +0000 net: fix a potential rcu\_read\_lock() imbalance in rt6\_fill\_node() \[ Upstream commit 94f826b8076e2cb92242061e92f21b5baa3eccc2 \] Commit f2c31e32b378 (net: fix NULL dereferences in check\_peer\_redir() ) added a regression in rt6\_fill\_node(), leading to rcu\_read\_lock() imbalance. Thats because NLA\_PUT() can make a jump to nla\_put\_failure label. Fix this by using nla\_put() Many thanks to Ben Greear for his help Reported-by: Ben Greear Reported-by: Dave Jones Signed-off-by: Eric Dumazet Tested-by: Ben Greear Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 145eb310bda7e0d583b8c44e7b5fbaae7be2db24 Author: Steffen Klassert Date: Wed Mar 21 23:36:13 2012 +0000 xfrm: Access the replay notify functions via the registered callbacks \[ Upstream commit 1265fd616782ef03b98fd19f65c2b47fcd4ea11f \] We call the wrong replay notify function when we use ESN replay handling. This leads to the fact that we don't send notifications if we use ESN. Fix this by calling the registered callbacks instead of xfrm\_replay\_notify(). Signed-off-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 119dfa93adeb693546528b850547fc1334d666fa Author: stephen hemminger Date: Wed Mar 21 05:32:05 2012 +0000 sky2: override for PCI legacy power management \[ Upstream commit 5676cc7bfe1e388e87843f71daa229610385b41e \] Some BIOS's don't setup power management correctly (what else is new) and don't allow use of PCI Express power control. Add a special exception module parameter to allow working around this issue. Based on slightly different patch by Knut Petersen. Reported-by: Arkadiusz Miskiewicz Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 52efe5ed4eed36082fb4fc95601a5e9cc49ec868 Author: Eric Dumazet Date: Wed Mar 21 06:58:03 2012 +0000 net: fix napi\_reuse\_skb() skb reserve \[ Upstream commit 2a2a459eeeff48640dc557548ce576d666ab06ed \] napi->skb is allocated in napi\_get\_frags() using netdev\_alloc\_skb\_ip\_align(), with a reserve of NET\_SKB\_PAD + NET\_IP\_ALIGN bytes. However, when such skb is recycled in napi\_reuse\_skb(), it ends with a reserve of NET\_IP\_ALIGN which is suboptimal. Signed-off-by: Eric Dumazet Cc: Herbert Xu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dcc799d3484f7b85bb5220cdab294e10fbe26c5b Author: Benjamin LaHaise Date: Tue Mar 20 03:57:54 2012 +0000 Fix pppol2tp getsockname() \[ Upstream commit bbdb32cb5b73597386913d052165423b9d736145 \] While testing L2TP functionality, I came across a bug in getsockname(). The IP address returned within the pppol2tp\_addr's addr memember was not being set to the IP address in use. This bug is caused by using inet\_sk() on the wrong socket (the L2TP socket rather than the underlying UDP socket), and was likely introduced during the addition of L2TPv3 support. Signed-off-by: Benjamin LaHaise Signed-off-by: James Chapman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 82cda2b280f4b97c883a4e1666ad1502c3bff3c7 Author: Dave Jones Date: Mon Mar 19 13:01:07 2012 +0000 Remove printk from rds\_sendmsg \[ Upstream commit a6506e1486181975d318344143aca722b2b91621 \] no socket layer outputs a message for this error and neither should rds. Signed-off-by: Dave Jones Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1545fb60f0c05b65060913e78bf8ae2b3c629818 Author: Gao feng Date: Mon Mar 19 22:36:10 2012 +0000 ipv6: fix incorrent ipv6 ipsec packet fragment \[ Upstream commit 1f85851e17b64cabd089a8a8839dddebc627948c \] Since commit 299b0767(ipv6: Fix IPsec slowpath fragmentation problem) In func ip6\_append\_data,after call skb\_put(skb, fraglen + dst\_exthdrlen) the skb->len contains dst\_exthdrlen,and we don't reduce dst\_exthdrlen at last This will make fraggap>0 in next "while cycle",and cause the size of skb incorrent Fix this by reserve headroom for dst\_exthdrlen. Signed-off-by: Gao feng Acked-by: Steffen Klassert Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b8828d5eb9f31e40359e7c9d7998e54e6bd2fac1 Author: Eric Dumazet Date: Sun Mar 18 02:40:48 2012 +0000 net: bpf\_jit: fix BPF\_S\_LDX\_B\_MSH compilation \[ Upstream commit dc72d99dabb870ca5bd6d9fff674be853bb4a88d \] Matt Evans spotted that x86 bpf\_jit was incorrectly handling negative constant offsets in BPF\_S\_LDX\_B\_MSH instruction. We need to abort JIT compilation like we do in common\_load so that filter uses the interpreter code and can call \_\_load\_pointer() Reference: http://lists.openwall.net/netdev/2011/07/19/11 Thanks to Indan Zupancic to bring back this issue. Reported-by: Matt Evans Reported-by: Indan Zupancic Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8aff97e587de738baccdd9b6f3bf9902fad8fa63 Author: Dave Airlie Date: Wed Mar 28 10:48:49 2012 +0100 drm/i915: suspend fbdev device around suspend/hibernate commit 3fa016a0b5c5237e9c387fc3249592b2cb5391c6 upstream. Looking at hibernate overwriting I though it looked like a cursor, so I tracked down this missing piece to stop the cursor blink timer. I've no idea if this is sufficient to fix the hibernate problems people are seeing, but please test it. Both radeon and nouveau have done this for a long time. I've run this personally all night hib/resume cycles with no fails. Reviewed-by: Keith Packard Reported-by: Petr Tesarik Reported-by: Stanislaw Gruszka Reported-by: Lots of misc segfaults after hibernate across the world. Bugzilla: https://bugzilla.kernel.org/show\_bug.cgi?id=37142 Tested-by: Dave Airlie Tested-by: Bojan Smojver Tested-by: Andreas Hartmann Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit eee11e2142c6de001ea5fa3425eb5a33e7c7f1ff Author: Sasha Levin Date: Mon Jan 30 23:07:22 2012 -0500 module: Remove module size limit commit f946eeb9313ff1470758e171a60fe7438a2ded3f upstream. Module size was limited to 64MB, this was legacy limitation due to vmalloc() which was removed a while ago. Limiting module size to 64MB is both pointless and affects real world use cases. Cc: Tim Abbott Signed-off-by: Sasha Levin Signed-off-by: Rusty Russell Signed-off-by: Greg Kroah-Hartman commit 0d4a2605688aa7dc5b70ce0135ff45547c8e0825 Author: Trond Myklebust Date: Tue Mar 27 18:22:19 2012 -0400 NFSv4.1: Fix layoutcommit error handling commit e59d27e05a6435f8c04d5ad843f37fa795f2eaaa upstream. Firstly, task->tk\_status will always return negative error values, so the current tests for 'NFS4ERR\_DELEG\_REVOKED' etc. are all being ignored. Secondly, clean up the code so that we only need to test task->tk\_status once! Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 8633c0f77dae2f0aae7fb38782402b32734e9675 Author: Trond Myklebust Date: Tue Mar 27 18:13:02 2012 -0400 NFSv4: Fix two infinite loops in the mount code commit 05e9cfb408b24debb3a85fd98edbfd09dd148881 upstream. We can currently loop forever in nfs4\_lookup\_root() and in nfs41\_proc\_secinfo\_no\_name(), if the first iteration returns a NFS4ERR\_DELAY or something else that causes exception.retry to get set. Reported-by: Weston Andros Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 110fe37c1fe381d3d1f9fcef189445a813f2a4ae Author: Christoph Lameter Date: Tue Jan 17 09:27:31 2012 -0600 slub: Do not hold slub\_lock when calling sysfs\_slab\_add() commit 66c4c35c6bc5a1a452b024cf0364635b28fd94e4 upstream. sysfs\_slab\_add() calls various sysfs functions that actually may end up in userspace doing all sorts of things. Release the slub\_lock after adding the kmem\_cache structure to the list. At that point the address of the kmem\_cache is not known so we are guaranteed exlusive access to the following modifications to the kmem\_cache structure. If the sysfs\_slab\_add fails then reacquire the slub\_lock to remove the kmem\_cache structure from the list. Reported-by: Sasha Levin Acked-by: Eric Dumazet Signed-off-by: Christoph Lameter Signed-off-by: Pekka Enberg Signed-off-by: Greg Kroah-Hartman commit 1335e5befcbfab5419977f187c25917b7390a3e1 Author: Jan Kara Date: Thu Mar 15 09:34:02 2012 +0000 xfs: Fix oops on IO error during xlog\_recover\_process\_iunlinks() commit d97d32edcd732110758799ae60af725e5110b3dc upstream. When an IO error happens during inode deletion run from xlog\_recover\_process\_iunlinks() filesystem gets shutdown. Thus any subsequent attempt to read buffers fails. Code in xlog\_recover\_process\_iunlinks() does not count with the fact that read of a buffer which was read a while ago can really fail which results in the oops on agi = XFS\_BUF\_TO\_AGI(agibp); Fix the problem by cleaning up the buffer handling in xlog\_recover\_process\_iunlinks() as suggested by Dave Chinner. We release buffer lock but keep buffer reference to AG buffer. That is enough for buffer to stay pinned in memory and we don't have to call xfs\_read\_agi() all the time. Signed-off-by: Jan Kara Reviewed-by: Dave Chinner Signed-off-by: Ben Myers Signed-off-by: Greg Kroah-Hartman commit 35409afc749a6fd9c45ced6349f7ddb20e67d1a0 Author: Masanari Iida Date: Wed Mar 28 14:42:56 2012 -0700 backlight: fix typo in tosa\_lcd.c commit 8da00edc1069f01c34510fa405dc15d96c090a3f upstream. Fix typo in drivers/video/backlight/tosa\_lcd.c "tosa\_lcd\_reume" should be "tosa\_lcd\_resume". Signed-off-by: Masanari Iida Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 31f54d49f9550f8e80836cf6d41f38343fb49128 Author: Joe Thornber Date: Wed Mar 28 18:41:23 2012 +0100 dm thin: fix stacked bi\_next usage commit 6f94a4c45a6f744383f9f695dde019998db3df55 upstream. Avoid using the bi\_next field for the holder of a cell when deferring bios because a stacked device below might change it. Store the holder in a new field in struct cell instead. When a cell is created, the bio that triggered creation (the holder) was added to the same bio list as subsequent bios. In some cases we pass this holder bio directly to devices underneath. If those devices use the bi\_next field there will be trouble... This also simplifies some code that had to work out which bio was the holder. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit d4c95712f2d94b5098fc5ed53cceeb4d63103bdf Author: Joe Thornber Date: Wed Mar 28 18:41:23 2012 +0100 dm persistent data: fix btree rebalancing after remove commit b0988900bae9ecf968a8a8d086a9eec671a9517a upstream. When we remove an entry from a node we sometimes rebalance with it's two neighbours. This wasn't being done correctly; in some cases entries have to move all the way from the right neighbour to the left neighbour, or vice versa. This patch pretty much re-writes the balancing code to fix it. This code is barely used currently; only when you delete a thin device, and then only if you have hundreds of them in the same pool. Once we have discard support, which removes mappings, this will be used much more heavily. Signed-off-by: Joe Thornber Signed-off-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 8d36b8eda13aef286e7646a67553067b2234c4ea Author: Andrei Warkentin Date: Wed Mar 28 18:41:22 2012 +0100 dm exception store: fix init error path commit aadbe266f2f89ccc68b52f4effc7b3a8b29521ef upstream. Call the correct exit function on failure in dm\_exception\_store\_init. Signed-off-by: Andrei Warkentin Acked-by: Mike Snitzer Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 3201310a00874dc9dbfc4e9d6cc61428fd8727a6 Author: Mikulas Patocka Date: Wed Mar 28 18:41:22 2012 +0100 dm crypt: add missing error handling commit 72c6e7afc43e19f68a31dea204fc366624d6eee9 upstream. Always set io->error to -EIO when an error is detected in dm-crypt. There were cases where an error code would be set only if we finish processing the last sector. If there were other encryption operations in flight, the error would be ignored and bio would be returned with success as if no error happened. This bug is present in kcryptd\_crypt\_write\_convert, kcryptd\_crypt\_read\_convert and kcryptd\_async\_done. Signed-off-by: Mikulas Patocka Reviewed-by: Milan Broz Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit 9b68da438894596a2653eb6958d066fedf78c413 Author: Mikulas Patocka Date: Wed Mar 28 18:41:22 2012 +0100 dm crypt: fix mempool deadlock commit aeb2deae2660a1773c83d3c6e9e6575daa3855d6 upstream. This patch fixes a possible deadlock in dm-crypt's mempool use. Currently, dm-crypt reserves a mempool of MIN\_BIO\_PAGES reserved pages. It allocates first MIN\_BIO\_PAGES with non-failing allocation (the allocation cannot fail and waits until the mempool is refilled). Further pages are allocated with different gfp flags that allow failing. Because allocations may be done in parallel, this code can deadlock. Example: There are two processes, each tries to allocate MIN\_BIO\_PAGES and the processes run simultaneously. It may end up in a situation where each process allocates (MIN\_BIO\_PAGES / 2) pages. The mempool is exhausted. Each process waits for more pages to be freed to the mempool, which never happens. To avoid this deadlock scenario, this patch changes the code so that only the first page is allocated with non-failing gfp mask. Allocation of further pages may fail. Signed-off-by: Mikulas Patocka Signed-off-by: Milan Broz Signed-off-by: Alasdair G Kergon Signed-off-by: Greg Kroah-Hartman commit a1e1b0fc33709534fc2983500328fcb416127b8e Author: Alex Deucher Date: Fri Mar 23 14:44:47 2012 -0400 drm/radeon/kms/atom: force bpc to 8 for now commit 017d213f649c6775e4a4349e50a5631a4e4c7308 upstream. Using the bpc (bits per color) specified by the monitor can cause problems in some cases. Until we get a better handle on how to deal with those cases, just use a bpc of 8. Reported-by: Lennert Buytenhek Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 49fb980ccf05caf4abb5390b41bd027d0acc82f4 Author: Mark Brown Date: Mon Feb 20 21:32:32 2012 +0000 mfd: Test for jack detection when deciding if wm8994 should suspend commit d2cb87c23e8514ca49c85adc5924999927bb9494 upstream. The jack detection on WM1811 is often required during system suspend, add it as another check when deciding if we should suspend. Signed-off-by: Mark Brown Signed-off-by: Samuel Ortiz Signed-off-by: Greg Kroah-Hartman commit 6e67144857714a198569d42587a880b913e1c4ea Author: Sekhar Nori Date: Sun Mar 11 18:16:12 2012 +0530 gpio/davinci: fix enabling unbanked GPIO IRQs commit 81b279d80a63628e580c71a31d30a8c3b3047ad4 upstream. Unbanked GPIO IRQ handling code made a copy of just the irq\_chip structure for GPIO IRQ lines which caused problems after the generic IRQ chip conversion because there was no valid irq\_chip\_type structure with the right "regs" populated. irq\_gc\_mask\_set\_bit() was therefore accessing random addresses. Fix it by making a copy of irq\_chip\_type structure instead. This will ensure sane register offsets. Reported-by: Jon Povey Tested-by: Jon Povey Signed-off-by: Sekhar Nori Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman commit fa58ba311e86cf7cf3e68a8f2c57f2e4e82eef89 Author: Sekhar Nori Date: Sun Mar 11 18:16:11 2012 +0530 gpio/davinci: fix oops on unbanked gpio irq request commit ab2dde9924dd1ddb791fa8b14aa52e1df681e20c upstream. Unbanked GPIO irq setup code was overwriting chip\_data leading to the following oops on request\_irq() Unable to handle kernel paging request at virtual address febfffff pgd = c22dc000 \[febfffff\] \*pgd=00000000 Internal error: Oops: 801 \[#1\] PREEMPT Modules linked in: mcu(+) edmak irqk cmemk CPU: 0 Not tainted (3.0.0-rc7+ #93) PC is at irq\_gc\_mask\_set\_bit+0x68/0x7c LR is at vprintk+0x22c/0x484 pc : \[\] lr : \[\] psr: 60000093 sp : c33e3ba0 ip : c33e3af0 fp : c33e3bc4 r10: c04555bc r9 : c33d4340 r8 : 60000013 r7 : 0000002d r6 : c04555bc r5 : fec67010 r4 : 00000000 r3 : c04734c8 r2 : fec00000 r1 : ffffffff r0 : 00000026 Flags: nZCv IRQs off FIQs on Mode SVC\_32 ISA ARM Segment user Control: 0005317f Table: 822dc000 DAC: 00000015 Process modprobe (pid: 526, stack limit = 0xc33e2270) Stack: (0xc33e3ba0 to 0xc33e4000) 3ba0: 00000000 c007d3d4 c33e3bcc c04555bc c04555bc c33d4340 c33e3bdc c33e3bc8 3bc0: c007f5f8 c0080bb4 00000000 c04555bc c33e3bf4 c33e3be0 c007f654 c007f5c0 3be0: 00000000 c04555bc c33e3c24 c33e3bf8 c007e6e8 c007f618 c01f2284 c0350af8 3c00: c0405214 bf016c98 00000001 00000000 c33dc008 0000002d c33e3c54 c33e3c28 3c20: c007e888 c007e408 00000001 c23ef880 c33dc000 00000000 c33dc080 c25caa00 3c40: c0487498 bf017078 c33e3c94 c33e3c58 bf016b44 c007e7d4 bf017078 c33dc008 3c60: c25caa08 c33dc008 c33e3c84 bf017484 c25caa00 c25caa00 c01f5f48 c25caa08 3c80: c0496d60 bf017484 c33e3ca4 c33e3c98 c022a698 bf01692c c33e3cd4 c33e3ca8 3ca0: c01f5d88 c022a688 00000000 bf017484 c25caa00 c25caa00 c01f5f48 c25caa08 3cc0: c0496d60 00000000 c33e3cec c33e3cd8 c01f5f8c c01f5d10 00000000 c33e3cf0 3ce0: c33e3d14 c33e3cf0 c01f5210 c01f5f58 c303cb48 c25ecf94 c25caa00 c25caa00 3d00: c25caa34 c33e3dd8 c33e3d34 c33e3d18 c01f6044 c01f51b8 c0496d3c c25caa00 3d20: c044e918 c33e3dd8 c33e3d44 c33e3d38 c01f4ff4 c01f5fcc c33e3d94 c33e3d48 3d40: c01f3d10 c01f4fd8 00000000 c044e918 00000000 00000000 c01f52c0 c034d570 3d60: c33e3d84 c33e3d70 c022bf84 c25caa00 00000000 c044e918 c33e3dd8 c25c2e00 3d80: c0496d60 bf01763c c33e3db4 c33e3d98 c022b1a0 c01f384c c25caa00 c33e3dd8 3da0: 00000000 c33e3dd8 c33e3dd4 c33e3db8 c022b27c c022b0e8 00000000 bf01763c 3dc0: c0451c80 c33e3dd8 c33e3e34 c33e3dd8 bf016f60 c022b210 5f75636d 746e6f63 3de0: 006c6f72 00000000 00000000 00000000 00000000 00000000 00000000 bf0174bc 3e00: 00000000 00989680 00000000 00000020 c0451c80 c0451c80 bf0174dc c01f5eb0 3e20: c33f0f00 bf0174dc c33e3e44 c33e3e38 c01f72f4 bf016e2c c33e3e74 c33e3e48 3e40: c01f5d88 c01f72e4 00000000 c0451c80 c0451cb4 bf0174dc c01f5eb0 c33f0f00 3e60: c0473100 00000000 c33e3e94 c33e3e78 c01f5f44 c01f5d10 00000000 c33e3e98 3e80: bf0174dc c01f5eb0 c33e3ebc c33e3e98 c01f5534 c01f5ec0 c303c038 c3061c30 3ea0: 00003cd8 00098258 bf0174dc c0462ac8 c33e3ecc c33e3ec0 c01f5bec c01f54dc 3ec0: c33e3efc c33e3ed0 c01f4d30 c01f5bdc bf0173a0 c33e2000 00003cd8 00098258 3ee0: bf0174dc c33e2000 c00301a4 bf019000 c33e3f1c c33e3f00 c01f6588 c01f4c8c 3f00: 00003cd8 00098258 00000000 c33e2000 c33e3f2c c33e3f20 c01f777c c01f6524 3f20: c33e3f3c c33e3f30 bf019014 c01f7740 c33e3f7c c33e3f40 c002f3ec bf019010 3f40: 00000000 00003cd8 00098258 bf017518 00000000 00003cd8 00098258 bf017518 3f60: 00000000 c00301a4 c33e2000 00000000 c33e3fa4 c33e3f80 c007b934 c002f3c4 3f80: c00b307c c00b2f48 00003cd8 00000000 00000003 00000080 00000000 c33e3fa8 3fa0: c0030020 c007b8b8 00003cd8 00000000 00098288 00003cd8 00098258 00098240 3fc0: 00003cd8 00000000 00000003 00000080 00098008 00098028 00098288 00000001 3fe0: be892998 be892988 00013d7c 40178740 60000010 00098288 09089041 00200845 Backtrace: \[\] (irq\_gc\_mask\_set\_bit+0x0/0x7c) from \[\] (irq\_enable+0x48/0x58) r6:c33d4340 r5:c04555bc r4:c04555bc \[\] (irq\_enable+0x0/0x58) from \[\] (irq\_startup+0x4c/0x54) r5:c04555bc r4:00000000 \[\] (irq\_startup+0x0/0x54) from \[\] (\_\_setup\_irq+0x2f0/0x3cc) r5:c04555bc r4:00000000 \[\] (\_\_setup\_irq+0x0/0x3cc) from \[\] (request\_threaded\_irq+0xc4/0x110) r8:0000002d r7:c33dc008 r6:00000000 r5:00000001 r4:bf016c98 \[\] (request\_threaded\_irq+0x0/0x110) from \[\] (mcu\_spi\_probe+0x228/0x37c \[mcu\]) \[\] (mcu\_spi\_probe+0x0/0x37c \[mcu\]) from \[\] (spi\_drv\_probe+0x20/0x24) \[\] (spi\_drv\_probe+0x0/0x24) from \[\] (driver\_probe\_device+0x88/0x1b0) \[\] (driver\_probe\_device+0x0/0x1b0) from \[\] (\_\_device\_attach+0x44/0x48) \[\] (\_\_device\_attach+0x0/0x48) from \[\] (bus\_for\_each\_drv+0x68/0x94) r5:c33e3cf0 r4:00000000 \[\] (bus\_for\_each\_drv+0x0/0x94) from \[\] (device\_attach+0x88/0xa0) r7:c33e3dd8 r6:c25caa34 r5:c25caa00 r4:c25caa00 \[\] (device\_attach+0x0/0xa0) from \[\] (bus\_probe\_device+0x2c/0x4c) r7:c33e3dd8 r6:c044e918 r5:c25caa00 r4:c0496d3c \[\] (bus\_probe\_device+0x0/0x4c) from \[\] (device\_add+0x4d4/0x648) \[\] (device\_add+0x0/0x648) from \[\] (spi\_add\_device+0xc8/0x128) \[\] (spi\_add\_device+0x0/0x128) from \[\] (spi\_new\_device+0x7c/0xb4) r7:c33e3dd8 r6:00000000 r5:c33e3dd8 r4:c25caa00 \[\] (spi\_new\_device+0x0/0xb4) from \[\] (mcu\_probe+0x144/0x224 \[mcu\]) r7:c33e3dd8 r6:c0451c80 r5:bf01763c r4:00000000 \[\] (mcu\_probe+0x0/0x224 \[mcu\]) from \[\] (platform\_drv\_probe+0x20/0x24) \[\] (platform\_drv\_probe+0x0/0x24) from \[\] (driver\_probe\_device+0x88/0x1b0) \[\] (driver\_probe\_device+0x0/0x1b0) from \[\] (\_\_driver\_attach+0x94/0x98) \[\] (\_\_driver\_attach+0x0/0x98) from \[\] (bus\_for\_each\_dev+0x68/0x94) r7:c01f5eb0 r6:bf0174dc r5:c33e3e98 r4:00000000 \[\] (bus\_for\_each\_dev+0x0/0x94) from \[\] (driver\_attach+0x20/0x28) r7:c0462ac8 r6:bf0174dc r5:00098258 r4:00003cd8 \[\] (driver\_attach+0x0/0x28) from \[\] (bus\_add\_driver+0xb4/0x258) \[\] (bus\_add\_driver+0x0/0x258) from \[\] (driver\_register+0x74/0x158) \[\] (driver\_register+0x0/0x158) from \[\] (platform\_driver\_register+0x4c/0x60) r7:c33e2000 r6:00000000 r5:00098258 r4:00003cd8 \[\] (platform\_driver\_register+0x0/0x60) from \[\] (mcu\_init+0x14/0x20 \[mcu\]) \[\] (mcu\_init+0x0/0x20 \[mcu\]) from \[\] (do\_one\_initcall+0x38/0x170) \[\] (do\_one\_initcall+0x0/0x170) from \[\] (sys\_init\_module+0x8c/0x1a4) \[\] (sys\_init\_module+0x0/0x1a4) from \[\] (ret\_fast\_syscall+0x0/0x2c) r7:00000080 r6:00000003 r5:00000000 r4:00003cd8 Code: e1844003 e585400c e596300c e5932064 (e7814002) Fix the issue. Reported-by: Jon Povey Signed-off-by: Sekhar Nori Signed-off-by: Grant Likely Signed-off-by: Greg Kroah-Hartman commit 9adc58441cea57b2adf663772afd5947181fde4a Author: Tarun Kanti DebBarma Date: Fri Nov 25 15:27:37 2011 +0530 gpio/omap: fix \_set\_gpio\_irqenable implementation commit 8276536cec38bc6bde30d0aa67716f22b9b9705a upstream. This function should be capable of both enabling and disabling interrupts based upon the \*enable\* parameter. Right now the function only enables the interrupt and \*enable\* is not used at all. So add the interrupt disable capability also using the parameter. Signed-off-by: Tarun Kanti DebBarma Reviewed-by: Santosh Shilimkar Acked-by: Felipe Balbi Reviewed-by: Kevin Hilman Signed-off-by: Kevin Hilman Signed-off-by: Greg Kroah-Hartman commit acfb7dd4141db85969e75d97a4f9f4250678c557 Author: Stephen Warren Date: Tue Feb 14 13:39:39 2012 -0700 ARM: tegra: select required CPU and L2 errata options commit f35b431dde39fb40944d1024f08d88fbf04a3193 upstream. The ARM IP revisions in Tegra are: Tegra20: CPU r1p1, PL310 r2p0 Tegra30: CPU A01=r2p7/>=A02=r2p9, NEON r2p3-50, PL310 r3p1-50 Based on work by Olof Johansson, although the actual list of errata is somewhat different here, since I added a bunch more and removed one PL310 erratum that doesn't seem applicable. Signed-off-by: Stephen Warren Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman commit 403ce368af5b5484c5880715bfd2a765835f05b9 Author: Michel Lespinasse Date: Mon Mar 26 17:32:44 2012 -0700 vfs: fix d\_ancestor() case in d\_materialize\_unique commit b18dafc86bb879d2f38a1743985d7ceb283c2f4d upstream. In d\_materialise\_unique() there are 3 subcases to the 'aliased dentry' case; in two subcases the inode i\_lock is properly released but this does not occur in the -ELOOP subcase. This seems to have been introduced by commit 1836750115f2 ("fix loop checks in d\_materialise\_unique()"). Signed-off-by: Michel Lespinasse \[ Added a comment, and moved the unlock to where we generate the -ELOOP, which seems to be more natural. You probably can't actually trigger this without a buggy network file server - d\_materialize\_unique() is for finding aliases on non-local filesystems, and the d\_ancestor() case is for a hardlinked directory loop. But we should be robust in the case of such buggy servers anyway. \] Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 786be162a8f2e92d72fa3c4e66e6f7fe497a0f9d Author: Theodore Ts'o Date: Sun Mar 11 23:30:16 2012 -0400 ext4: check for zero length extent commit 31d4f3a2f3c73f279ff96a7135d7202ef6833f12 upstream. Explicitly test for an extent whose length is zero, and flag that as a corrupted extent. This avoids a kernel BUG\_ON assertion failure. Tested: Without this patch, the file system image found in tests/f\_ext\_zero\_len/image.gz in the latest e2fsprogs sources causes a kernel panic. With this patch, an ext4 file system error is noted instead, and the file system is marked as being corrupted. https://bugzilla.kernel.org/show\_bug.cgi?id=42859 Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 2cb2d68b88999a013ab781ebd9a1e1382b150fc6 Author: Jeff Moyer Date: Mon Mar 5 10:29:52 2012 -0500 ext4: fix race between sync and completed io work commit 491caa43639abcffaa645fbab372a7ef4ce2975c upstream. The following command line will leave the aio-stress process unkillable on an ext4 file system (in my case, mounted on /mnt/test): aio-stress -t 20 -s 10 -O -S -o 2 -I 1000 /mnt/test/aiostress.3561.4 /mnt/test/aiostress.3561.4.20 /mnt/test/aiostress.3561.4.19 /mnt/test/aiostress.3561.4.18 /mnt/test/aiostress.3561.4.17 /mnt/test/aiostress.3561.4.16 /mnt/test/aiostress.3561.4.15 /mnt/test/aiostress.3561.4.14 /mnt/test/aiostress.3561.4.13 /mnt/test/aiostress.3561.4.12 /mnt/test/aiostress.3561.4.11 /mnt/test/aiostress.3561.4.10 /mnt/test/aiostress.3561.4.9 /mnt/test/aiostress.3561.4.8 /mnt/test/aiostress.3561.4.7 /mnt/test/aiostress.3561.4.6 /mnt/test/aiostress.3561.4.5 /mnt/test/aiostress.3561.4.4 /mnt/test/aiostress.3561.4.3 /mnt/test/aiostress.3561.4.2 This is using the aio-stress program from the xfstests test suite. That particular command line tells aio-stress to do random writes to 20 files from 20 threads (one thread per file). The files are NOT preallocated, so you will get writes to random offsets within the file, thus creating holes and extending i\_size. It also opens the file with O\_DIRECT and O\_SYNC. On to the problem. When an I/O requires unwritten extent conversion, it is queued onto the completed\_io\_list for the ext4 inode. Two code paths will pull work items from this list. The first is the ext4\_end\_io\_work routine, and the second is ext4\_flush\_completed\_IO, which is called via the fsync path (and O\_SYNC handling, as well). There are two issues I've found in these code paths. First, if the fsync path beats the work routine to a particular I/O, the work routine will free the io\_end structure! It does not take into account the fact that the io\_end may still be in use by the fsync path. I've fixed this issue by adding yet another IO\_END flag, indicating that the io\_end is being processed by the fsync path. The second problem is that the work routine will make an assignment to io->flag outside of the lock. I have witnessed this result in a hang at umount. Moving the flag setting inside the lock resolved that problem. The problem was introduced by commit b82e384c7b ("ext4: optimize locking for end\_io extent conversion"), which first appeared in 3.2. As such, the fix should be backported to that release (probably along with the unwritten extent conversion race fix). Signed-off-by: Jeff Moyer Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 2a45b2e1c6ed5e030e58fa6fbcb6dbc04d1dad64 Author: Jeff Moyer Date: Mon Feb 20 17:59:24 2012 -0500 ext4: fix race between unwritten extent conversion and truncate commit 266991b13890049ee1a6bb95b9817f06339ee3d7 upstream. The following comment in ext4\_end\_io\_dio caught my attention: /\* XXX: probably should move into the real I/O completion handler \*/ inode\_dio\_done(inode); The truncate code takes i\_mutex, then calls inode\_dio\_wait. Because the ext4 code path above will end up dropping the mutex before it is reacquired by the worker thread that does the extent conversion, it seems to me that the truncate can happen out of order. Jan Kara mentioned that this might result in error messages in the system logs, but that should be the extent of the "damage." The fix is pretty straight-forward: don't call inode\_dio\_done until the extent conversion is complete. Reviewed-by: Jan Kara Signed-off-by: Jeff Moyer Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 9dacb0fb008d3042a41889e4f9e21d6f1afc20c0 Author: Lukas Czerner Date: Mon Feb 20 17:53:00 2012 -0500 ext4: ignore EXT4\_INODE\_JOURNAL\_DATA flag with delalloc commit 3d2b158262826e8b75bbbfb7b97010838dd92ac7 upstream. Ext4 does not support data journalling with delayed allocation enabled. We even do not allow to mount the file system with delayed allocation and data journalling enabled, however it can be set via FS\_IOC\_SETFLAGS so we can hit the inode with EXT4\_INODE\_JOURNAL\_DATA set even on file system mounted with delayed allocation (default) and that's where problem arises. The easies way to reproduce this problem is with the following set of commands: mkfs.ext4 /dev/sdd mount /dev/sdd /mnt/test1 dd if=/dev/zero of=/mnt/test1/file bs=1M count=4 chattr +j /mnt/test1/file dd if=/dev/zero of=/mnt/test1/file bs=1M count=4 conv=notrunc chattr -j /mnt/test1/file Additionally it can be reproduced quite reliably with xfstests 272 and 269. In fact the above reproducer is a part of test 272. To fix this we should ignore the EXT4\_INODE\_JOURNAL\_DATA inode flag if the file system is mounted with delayed allocation. This can be easily done by fixing ext4\_should\_\*\_data() functions do ignore data journal flag when delalloc is set (suggested by Ted). We also have to set the appropriate address space operations for the inode (again, ignoring data journal flag if delalloc enabled). Additionally this commit introduces ext4\_inode\_journal\_mode() function because ext4\_should\_\*\_data() has already had a lot of common code and this change is putting it all into one function so it is easier to read. Successfully tested with xfstests in following configurations: delalloc + data=ordered delalloc + data=writeback data=journal nodelalloc + data=ordered nodelalloc + data=writeback nodelalloc + data=journal Signed-off-by: Lukas Czerner Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 7da65e2c13ad21640c9003f78104fadfed6302b8 Author: Eric Sandeen Date: Mon Feb 20 17:53:01 2012 -0500 jbd2: clear BH\_Delay & BH\_Unwritten in journal\_unmap\_buffer commit 15291164b22a357cb211b618adfef4fa82fc0de3 upstream. journal\_unmap\_buffer()'s zap\_buffer: code clears a lot of buffer head state ala discard\_buffer(), but does not touch \_Delay or \_Unwritten as discard\_buffer() does. This can be problematic in some areas of the ext4 code which assume that if they have found a buffer marked unwritten or delay, then it's a live one. Perhaps those spots should check whether it is mapped as well, but if jbd2 is going to tear down a buffer, let's really tear it down completely. Without this I get some fsx failures on sub-page-block filesystems up until v3.2, at which point 4e96b2dbbf1d7e81f22047a50f862555a6cb87cb and 189e868fa8fdca702eb9db9d8afc46b5cb9144c9 make the failures go away, because buried within that large change is some more flag clearing. I still think it's worth doing in jbd2, since ->invalidatepage leads here directly, and it's the right place to clear away these flags. Signed-off-by: Eric Sandeen Signed-off-by: "Theodore Ts'o" Signed-off-by: Greg Kroah-Hartman commit 7ca476a690a89202e0693948c4df0f9a34a566b1 Author: Srivatsa S. Bhat Date: Fri Feb 17 23:39:51 2012 +0100 PM / Hibernate: Enable usermodehelpers in hibernate() error path commit 05b4877f6a4f1ba4952d1222213d262bf8c132b7 upstream. If create\_basic\_memory\_bitmaps() fails, usermodehelpers are not re-enabled before returning. Fix this. And while at it, reword the goto labels so that they look more meaningful. Signed-off-by: Srivatsa S. Bhat Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f8fbfe8809d64f3d3aabbaabe85c8571b754b9bd Author: Trond Myklebust Date: Mon Mar 12 18:01:48 2012 -0400 NFSv4: Rate limit the state manager warning messages commit 9a3ba432330e504ac61ff0043dbdaba7cea0e35a upstream. Prevent the state manager from filling up system logs when recovery fails on the server. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 2d11e9dbfde8babe45fc7855a445f120c102345e Author: Larry Finger Date: Thu Feb 9 16:37:17 2012 -0600 staging: r8712u: Add missing initialization and remove configuration parameter CONFIG\_R8712\_AP commit 073863432f7eaa23c7c09733414d4be2eabf5eef upstream. When this driver was upgraded to the vendor 20100831 version in commit 93c55dda092c7 et al,, one listhead initialization was missed. This broke complete operation of the driver whenever AP mode was enabled. This fixes https://bugs.archlinux.org/task/27996. The configuration parameter R8712\_AP is misleading as the driver cannot function as an AP without a heavily hacked version of hostapd. Thus, it makes sense to remove the parameter; however the code and data configured for the option is left in. Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman commit f5ba9c849e393be3b3a220248b596cebcabe6999 Author: Larry Finger Date: Mon Jan 30 09:54:49 2012 -0600 rtlwifi: Convert to asynchronous firmware load commit b0302aba812bcc39291cdab9ad7e37008f352a91 upstream. This patch addresses a kernel bugzilla report and two recent mail threads. The kernel bugzilla report is https://bugzilla.kernel.org/show\_bug.cgi?id=42632, which reports a udev timeout on boot. The first mail thread, which was on LKML (http://lkml.indiana.edu/hypermail/ linux/kernel/1112.3/00965.html) was for a WARNING that occurs after a suspend/resume cycle for rtl8192cu. The scond mail thread (http://marc.info/?l=linux-wireless&m=132655490826766&w=2) concerned changes in udev that break drivers that delay while firmware is loaded on modprobe. This patch converts all rtlwifi-based drivers to use the asynchronous firmware loading mechanism. Drivers rtl8192ce, rtl8192cu and rtl8192de share a common callback routine. Driver rtl8192se needs different handling of the firmware, thus it has its own code. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 7564963150c0cf52d3d47add3d422f3ade202699 Author: Rafael J. Wysocki Date: Mon Mar 26 23:27:33 2012 +0200 PM / shmobile: Make MTU2 driver use pm\_genpd\_dev\_always\_on() Commit 57d13370cfaf6017c68981e66ff5b3bf20a2705c upstream. Make the MTU2 clocksource driver mark its device as "always on" using pm\_genpd\_dev\_always\_on() to protect it from surprise power removals. Signed-off-by: Rafael J. Wysocki Tested-by: Simon Horman Acked-by: Paul Mundt Signed-off-by: Greg Kroah-Hartman commit 77bba980b91a26a942d3d0395eab64ce7fdd5cd0 Author: Rafael J. Wysocki Date: Mon Mar 26 23:26:53 2012 +0200 PM / shmobile: Make CMT driver use pm\_genpd\_dev\_always\_on() Commit 615a445f7f8a077c145e737864ae59a4d8717882 upstream. Make the CMT clocksource driver mark its device as "always on" using pm\_genpd\_dev\_always\_on() to protect it from surprise power removals. Signed-off-by: Rafael J. Wysocki Tested-by: Simon Horman Acked-by: Paul Mundt Signed-off-by: Greg Kroah-Hartman commit 14dbd9a0e642ff89604ee177cd08c7809b323f1f Author: Rafael J. Wysocki Date: Mon Mar 26 23:26:10 2012 +0200 PM / shmobile: Make TMU driver use pm\_genpd\_dev\_always\_on() Commit 2ee619f9487c2acc1efdf2c78e68e2bd51b635fa upstream. Make the TMU clocksource driver mark its device as "always on" using pm\_genpd\_dev\_always\_on() to protect it from surprise power removals and make sh7372\_add\_standard\_devices() add TMU devices on sh7372 to the A4R power domain so that their "always on" flags are taken into account as appropriate. Signed-off-by: Rafael J. Wysocki Tested-by: Simon Horman Acked-by: Paul Mundt Signed-off-by: Greg Kroah-Hartman commit 166a1687a4d1ad2fa237452355a5ec018dc68cc5 Author: Rafael J. Wysocki Date: Mon Mar 26 23:25:24 2012 +0200 PM / Domains: Introduce "always on" device flag This is a backport of mainline commit 1e78a0c7fc92aee076965d516cf54475c39e9894. The TMU device on the Mackerel board belongs to the A4R power domain and loses power when the domain is turned off. Unfortunately, the TMU driver is not prepared to cope with such situations and crashes the system when that happens. To work around this problem introduce a new helper function, pm\_genpd\_dev\_always\_on(), allowing a device driver to mark its device as "always on" in case it belongs to a PM domain, which will make the generic PM domains core code avoid powering off the domain containing the device, both at run time and during system suspend. Signed-off-by: Rafael J. Wysocki Tested-by: Simon Horman Acked-by: Paul Mundt Signed-off-by: Greg Kroah-Hartman commit fd0682d1b4f47792cfe668c7979d73f168e9f1aa Author: Rafael J. Wysocki Date: Mon Mar 26 23:24:40 2012 +0200 PM / Domains: Check domain status during hibernation restore of devices This is a backport of mainline commit 18dd2ece3cde14cfd42e95a89eb14016699a5f15. Power domains that were off before hibernation shouldn't be turned on during device restore, so prevent that from happening. This change fixed up mainline commit 65533bbf63b4f37723fdfedc73d0653958973323 PM / Domains: Fix hibernation restore of devices, v2 that didn't include it by mistake. Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 8119557d5627c7a823641a7c5c307f709e2d5b04 Author: Rafael J. Wysocki Date: Mon Mar 26 23:23:59 2012 +0200 PM / Domains: Fix hibernation restore of devices, v2 This is a backport of mainline commit 65533bbf63b4f37723fdfedc73d0653958973323. During resume from hibernation pm\_genpd\_restore\_noirq() should only power off domains whose suspend\_power\_off flags are set once and not every time it is called for a device in the given domain. Moreover, it shouldn't decrement genpd->suspended\_count, because that field is not touched during device freezing and therefore it is always equal to 0 when pm\_genpd\_restore\_noirq() runs for the first device in the given domain. This means pm\_genpd\_restore\_noirq() may use genpd->suspended\_count to determine whether or not it it has been called for the domain in question already in this cycle (it only needs to increment that field every time it runs for this purpose) and whether or not it should check if the domain needs to be powered off. For that to work, though, pm\_genpd\_prepare() has to clear genpd->suspended\_count when it runs for the first device in the given domain (in which case that flag need not be cleared during domain initialization). Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 6c9be40dfde282de8a0098612ace80dacc50ae4f Author: Michael Krufky Date: Sun Mar 18 14:35:57 2012 -0300 mxl111sf: fix error on stream stop in mxl111sf\_ep6\_streaming\_ctrl() commit 3be5bb71fbf18f83cb88b54a62a78e03e5a4f30a upstream. Remove unnecessary register access in mxl111sf\_ep6\_streaming\_ctrl() This code breaks driver operation in kernel 3.3 and later, although it works properly in 3.2 Disable register access to 0x12 for now. Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 4be95e37708d70cd8883501017677b38267d9116 Author: Michael Krufky Date: Tue Feb 7 13:28:33 2012 -0300 pvrusb2: fix 7MHz & 8MHz DVB-T tuner support for HVR1900 rev D1F5 commit 9ab2393fc3e460cd2040de1483918eb17abb822f upstream. The D1F5 revision of the WinTV HVR-1900 uses a tda18271c2 tuner instead of a tda18271c1 tuner as used in revision D1E9. To account for this, we must hardcode the frontend configuration to use the same IF frequency configuration for both revisions of the device. 6MHz DVB-T is unaffected by this issue, as the recommended IF Frequency configuration for 6MHz DVB-T is the same on both c1 and c2 revisions of the tda18271 tuner. Signed-off-by: Michael Krufky Cc: Mike Isely Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 3c55383f313b3c28a074f5881272c800f0d3ee47 Author: Michael Krufky Date: Mon Mar 12 17:07:22 2012 -0300 au8522: bug-fix: enable modulation AFTER tune (instead of before tuning) commit ef3d2dc366c8c32d58dbbf9898cfd4f853ff8fe0 upstream. The au8522 driver programs the tuner after programming the demodulator, but the tuner should be programmed first. This patch fixes this behavior. EDIT: Apparantly Devin created a similar patch some time ago, but hasn't submitted it for merge. I never saw his patch, but I thank him anyhow for his efforts. In addition, Devin pointed out a flaw in my patch: This newly generated patch takes Devin's comments into account. Thanks-to: Devin Heitmueller Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 5af11ec1e3215db83ee131fd70663ad720b91708 Author: Antti Palosaari Date: Mon Mar 12 18:21:20 2012 -0300 tda10071: fix the delivery system commit 2b49fad59513b07f976c9711b99f93ae74d081c5 upstream. Commit b2a29b578d9c21b2e5c88020f830d3c42115c51d sets accidentally supported delivery systems as DVB-T/T2 whilst it should be DVB-S/S2. Due to that frontend cannot be used at all. Reported-by: Jiří Zelenka Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit cec36b365455da46cc3f796cec210fc84627c912 Author: Gianluca Gennari Date: Tue Mar 6 09:47:45 2012 -0300 as102: add \_\_packed attribute to structs defined inside packed structs commit abf9d005375d6c6160cc9c17e5dcac32e412c8dc upstream. This patch fixes a regression in kernel 3.3 due to this patch: http://patchwork.linuxtv.org/patch/8332/ That patch changes "#pragma pack(1)" with "\_\_packed" attributes, but it is not complete. In fact, in the as102 driver there are a lot of structs/unions defined inside other structs/unions. When the "\_\_packed" attribute is applied only on the external struct, it will not affect the internal struct definitions. So the regression is fixed by specifiying the "\_\_packed" attribute also on the internal structs. This patch should go into 3.3, as it fixes a regression introduced in the new kernel version. Signed-off-by: Gianluca Gennari Signed-off-by: Ryley Angus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 7b1402c9c93cf483adb38ff530b9e186020212ce Author: Xi Wang Date: Tue Feb 14 14:32:41 2012 -0300 lgdt330x: fix signedness error in i2c\_read\_demod\_bytes() commit 34817174fca0c5512c2d5b6ea0fc37a0337ce1d8 upstream. The error handling in lgdt3303\_read\_status() and lgdt330x\_read\_ucblocks() doesn't work, because i2c\_read\_demod\_bytes() returns a u8 and (err < 0) is always false. err = i2c\_read\_demod\_bytes(state, 0x58, buf, 1); if (err < 0) return err; Change the return type of i2c\_read\_demod\_bytes() to int. Also change the return value on error to -EIO to make (err < 0) work. Signed-off-by: Xi Wang Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 485c2abc886cbff1dd4ffb9f2488fd703ebe8a6e Author: Andreas Herrmann Date: Fri Mar 23 10:02:17 2012 +0100 hwmon: (fam15h\_power) Correct sign extension of running\_avg\_capture commit fc0900cbda9243957d812cd6b4cc87965f9fe75f upstream. Wrong bit was used for sign extension which caused wrong end results. Thanks to Andre for spotting this bug. Reported-by: Andre Przywara Signed-off-by: Andreas Herrmann Acked-by: Guenter Roeck Signed-off-by: Jean Delvare Signed-off-by: Greg Kroah-Hartman commit dc2497862281e7e171c350bfae92033cd40ad1b6 Author: Lucas De Marchi Date: Thu Mar 22 14:42:22 2012 -0700 sysctl: protect poll() in entries that may go away commit 4e474a00d7ff746ed177ddae14fa8b2d4bad7a00 upstream. Protect code accessing ctl\_table by grabbing the header with grab\_header() and after releasing with sysctl\_head\_finish(). This is needed if poll() is called in entries created by modules: currently only hostname and domainname support poll(), but this bug may be triggered when/if modules use it and if user called poll() in a file that doesn't support it. Dave Jones reported the following when using a syscall fuzzer while hibernating/resuming: RIP: 0010:\[\] \[\] proc\_sys\_poll+0x4e/0x90 RAX: 0000000000000145 RBX: ffff88020cab6940 RCX: 0000000000000000 RDX: ffffffff81233df0 RSI: 6b6b6b6b6b6b6b6b RDI: ffff88020cab6940 \[ ... \] Code: 00 48 89 fb 48 89 f1 48 8b 40 30 4c 8b 60 e8 b8 45 01 00 00 49 83 7c 24 28 00 74 2e 49 8b 74 24 30 48 85 f6 74 24 48 85 c9 75 32 <8b> 16 b8 45 01 00 00 48 63 d2 49 39 d5 74 10 8b 06 48 98 48 89 If an entry goes away while we are polling() it, ctl\_table may not exist anymore. Reported-by: Dave Jones Signed-off-by: Lucas De Marchi Cc: Al Viro Cc: Linus Torvalds Cc: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Eric W. Biederman Signed-off-by: Greg Kroah-Hartman commit e01f0322c7dad6c79157b84439537bc1306a2ac3 Author: Joerg Roedel Date: Thu Mar 15 16:29:47 2012 +0100 iommu/amd: Make sure IOMMU interrupts are re-enabled on resume commit 9ddd592a191b32f2ee6c4b6ed2bd52665c3a49f5 upstream. Unfortunatly the interrupts for the event log and the peripheral page-faults are only enabled at boot but not re-enabled at resume. Fix that. Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit ae8000857757d9ae51149e324f5c64edd1b64b1c Author: Steffen Persvold Date: Thu Mar 15 15:20:29 2012 +0100 iommu/amd: Fix section warning for prealloc\_protection\_domains commit cebd5fa4d3046d5b43ce1836a0120612822a7fb0 upstream. Fix the following section warning in drivers/iommu/amd\_iommu.c : WARNING: vmlinux.o(.text+0x526e77): Section mismatch in reference from the function prealloc\_protection\_domains() to the function .init.text:alloc\_passthrough\_domain() The function prealloc\_protection\_domains() references the function \_\_init alloc\_passthrough\_domain(). This is often because prealloc\_protection\_domains lacks a \_\_init annotation or the annotation of alloc\_passthrough\_domain is wrong. Signed-off-by: Steffen Persvold Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 812e7c2263ffd318340d008854012e7975df73df Author: Pravin B Shelar Date: Fri Mar 23 15:02:55 2012 -0700 proc-ns: use d\_set\_d\_op() API to set dentry ops in proc\_ns\_instantiate(). commit 1b26c9b334044cff6d1d2698f2be41bc7d9a0864 upstream. The namespace cleanup path leaks a dentry which holds a reference count on a network namespace. Keeping that network namespace from being freed when the last user goes away. Leaving things like vlan devices in the leaked network namespace. If you use ip netns add for much real work this problem becomes apparent pretty quickly. It light testing the problem hides because frequently you simply don't notice the leak. Use d\_set\_d\_op() so that DCACHE\_OP\_\* flags are set correctly. This issue exists back to 3.0. Acked-by: "Eric W. Biederman" Reported-by: Justin Pettit Signed-off-by: Pravin B Shelar Signed-off-by: Jesse Gross Cc: David Miller Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 950f7b8601ca2cf421644b2ca94b97adbdbdda9e Author: Dmitry Adamushko Date: Thu Mar 22 21:39:25 2012 +0100 x86-32: Fix endless loop when processing signals for kernel tasks commit 29a2e2836ff9ea65a603c89df217f4198973a74f upstream. The problem occurs on !CONFIG\_VM86 kernels \[1\] when a kernel-mode task returns from a system call with a pending signal. A real-life scenario is a child of 'khelper' returning from a failed kernel\_execve() in \_\_\_\_call\_usermodehelper() \[ kernel/kmod.c \]. kernel\_execve() fails due to a pending SIGKILL, which is the result of "kill -9 -1" (at least, busybox's init does it upon reboot). The loop is as follows: \* syscall\_exit\_work: - work\_pending: // start\_of\_the\_loop - work\_notify\_sig: - do\_notify\_resume() - do\_signal() - if (!user\_mode(regs)) return; - resume\_userspace // TIF\_SIGPENDING is still set - work\_pending // so we call work\_pending => goto // start\_of\_the\_loop More information can be found in another LKML thread: http://www.serverphorums.com/read.php?12,457826 \[1\] the problem was also seen on MIPS. Signed-off-by: Dmitry Adamushko Link: http://lkml.kernel.org/r/1332448765.2299.68.camel@dimm Cc: Oleg Nesterov Cc: Roland McGrath Cc: Andrew Morton Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 4141a94694efc7d6c58e81bc55717161438d7816 Author: Thierry Reding Date: Wed Mar 21 22:50:08 2012 +0100 x86-32: Fix typo for mq\_getsetattr in syscall table commit 13354dc412c36fe554f9904a92f1268c74af7e87 upstream. Syscall 282 was mistakenly named mq\_getsetaddr instead of mq\_getsetattr. When building uClibc against the Linux kernel this would result in a shared library that doesn't provide the mq\_getattr() and mq\_setattr() functions. Signed-off-by: Thierry Reding Link: http://lkml.kernel.org/r/1332366608-2695-2-git-send-email-thierry.reding@avionic-design.de Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 7554abe5f1333ed5a0ebe269f60a218456e2cc52 Author: tom.leiming@gmail.com Date: Thu Mar 22 03:22:38 2012 +0000 usbnet: don't clear urb->dev in tx\_complete commit 5d5440a835710d09f0ef18da5000541ec98b537a upstream. URB unlinking is always racing with its completion and tx\_complete may be called before or during running usb\_unlink\_urb, so tx\_complete must not clear urb->dev since it will be used in unlink path, otherwise invalid memory accesses or usb device leak may be caused inside usb\_unlink\_urb. Cc: Alan Stern Cc: Oliver Neukum Signed-off-by: Ming Lei Acked-by: Greg Kroah-Hartman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e46b91af06a359af8b3610a6da5c85fcaa4dc4be Author: tom.leiming@gmail.com Date: Thu Mar 22 03:22:18 2012 +0000 usbnet: increase URB reference count before usb\_unlink\_urb commit 0956a8c20b23d429e79ff86d4325583fc06f9eb4 upstream. Commit 4231d47e6fe69f061f96c98c30eaf9fb4c14b96d(net/usbnet: avoid recursive locking in usbnet\_stop()) fixes the recursive locking problem by releasing the skb queue lock, but it makes usb\_unlink\_urb racing with defer\_bh, and the URB to being unlinked may be freed before or during calling usb\_unlink\_urb, so use-after-free problem may be triggerd inside usb\_unlink\_urb. The patch fixes the use-after-free problem by increasing URB reference count with skb queue lock held before calling usb\_unlink\_urb, so the URB won't be freed until return from usb\_unlink\_urb. Cc: Sebastian Andrzej Siewior Cc: Alan Stern Cc: Oliver Neukum Reported-by: Dave Jones Signed-off-by: Ming Lei Acked-by: Greg Kroah-Hartman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 253c9b383d67e9c3d049e3c4616ef7c9e1deb30a Author: Trond Myklebust Date: Mon Mar 19 13:39:35 2012 -0400 SUNRPC: We must not use list\_for\_each\_entry\_safe() in rpc\_wake\_up() commit 540a0f7584169651f485e8ab67461fcb06934e38 upstream. The problem is that for the case of priority queues, we have to assume that \_\_rpc\_remove\_wait\_queue\_priority will move new elements from the tk\_wait.links lists into the queue->tasks\[\] list. We therefore cannot use list\_for\_each\_entry\_safe() on queue->tasks\[\], since that will skip these new tasks that \_\_rpc\_remove\_wait\_queue\_priority is adding. Without this fix, rpc\_wake\_up and rpc\_wake\_up\_status will both fail to wake up all functions on priority wait queues, which can result in some nasty hangs. Reported-by: Andy Adamson Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 055746f0be1c06f412f12ef6051eefded6b39df5 Author: Artem Bityutskiy Date: Wed Mar 7 19:08:36 2012 +0200 UBI: fix eraseblock picking criteria commit 7eb3aa65853e1b223bfc786b023b702018cb76c0 upstream. The 'find\_wl\_entry()' function expects the maximum difference as the second argument, not the maximum absolute value. So the "unknown" eraseblock picking was incorrect, as Shmulik Ladkani spotted. This patch fixes the issue. Reported-by: Shmulik Ladkani Signed-off-by: Artem Bityutskiy Reviewed-by: Shmulik Ladkani Signed-off-by: Greg Kroah-Hartman commit 57af7b5f6f14d13d38ca0462a9461cb335c97297 Author: Richard Weinberger Date: Mon Jan 30 18:20:13 2012 +0100 UBI: fix error handling in ubi\_scan() commit a29852be492d61001d86c6ebf5fff9b93d7b4be9 upstream. Two bad things can happen in ubi\_scan(): 1. If kmem\_cache\_create() fails we jump to out\_si and call ubi\_scan\_destroy\_si() which calls kmem\_cache\_destroy(). But si->scan\_leb\_slab is NULL. 2. If process\_eb() fails we jump to out\_vidh, call kmem\_cache\_destroy() and ubi\_scan\_destroy\_si() which calls again kmem\_cache\_destroy(). Signed-off-by: Richard Weinberger Signed-off-by: Artem Bityutskiy Signed-off-by: Greg Kroah-Hartman commit a9f67ccd865caae489bf3f000fbac2004e43ba3e Author: Pavel Shilovsky Date: Sat Mar 17 09:46:55 2012 +0300 CIFS: Fix a spurious error in cifs\_push\_posix\_locks commit ce85852b90a214cf577fc1b4f49d99fd7e98784a upstream. Signed-off-by: Pavel Shilovsky Reviewed-by: Jeff Layton Reported-by: Ben Hutchings Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit f743834c464b22ed1636b94b8601f92a87afba57 Author: Jeff Layton Date: Wed Mar 21 06:30:40 2012 -0400 cifs: fix issue mounting of DFS ROOT when redirecting from one domain controller to the next commit 1daaae8fa4afe3df78ca34e724ed7e8187e4eb32 upstream. This patch fixes an issue when cifs\_mount receives a STATUS\_BAD\_NETWORK\_NAME error during cifs\_get\_tcon but is able to continue after an DFS ROOT referral. In this case, the return code variable is not reset prior to trying to mount from the system referred to. Thus, is\_path\_accessible is not executed and the final DFS referral is not performed causing a mount error. Use case: In DNS, example.com resolves to the secondary AD server ad2.example.com Our primary domain controller is ad1.example.com and has a DFS redirection set up from \\\\ad1\\share\\Users to \\\\files\\share\\Users. Mounting \\\\example.com\\share\\Users fails. Regression introduced by commit 724d9f1. Reviewed-by: Pavel Shilovsky Signed-off-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit ffb07758cafb009b64fc7db20a26d0561496c112 Author: Pavel Shilovsky Date: Tue Mar 20 12:55:09 2012 +0300 CIFS: Respect negotiated MaxMpxCount commit 10b9b98e41ba248a899f6175ce96ee91431b6194 upstream. Some servers sets this value less than 50 that was hardcoded and we lost the connection if when we exceed this limit. Fix this by respecting this value - not sending more than the server allows. Reviewed-by: Jeff Layton Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 16223d0d61330c85276e84e0ce8e26addcbf00d7 Author: Dave Chinner Date: Wed Mar 7 04:50:25 2012 +0000 xfs: fix inode lookup race commit f30d500f809eca67a21704347ab14bb35877b5ee upstream. When we get concurrent lookups of the same inode that is not in the per-AG inode cache, there is a race condition that triggers warnings in unlock\_new\_inode() indicating that we are initialising an inode that isn't in a the correct state for a new inode. When we do an inode lookup via a file handle or a bulkstat, we don't serialise lookups at a higher level through the dentry cache (i.e. pathless lookup), and so we can get concurrent lookups of the same inode. The race condition is between the insertion of the inode into the cache in the case of a cache miss and a concurrently lookup: Thread 1 Thread 2 xfs\_iget() xfs\_iget\_cache\_miss() xfs\_iread() lock radix tree radix\_tree\_insert() rcu\_read\_lock radix\_tree\_lookup lock inode flags XFS\_INEW not set igrab() unlock inode flags rcu\_read\_unlock use uninitialised inode ..... lock inode flags set XFS\_INEW unlock inode flags unlock radix tree xfs\_setup\_inode() inode flags = I\_NEW unlock\_new\_inode() WARNING as inode flags != I\_NEW This can lead to inode corruption, inode list corruption, etc, and is generally a bad thing to occur. Fix this by setting XFS\_INEW before inserting the inode into the radix tree. This will ensure any concurrent lookup will find the new inode with XFS\_INEW set and that forces the lookup to wait until the XFS\_INEW flag is removed before allowing the lookup to succeed. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Signed-off-by: Ben Myers Signed-off-by: Greg Kroah-Hartman commit db72f825726d610bfe17451750cb7572ddbd3094 Author: Trond Myklebust Date: Wed Mar 7 16:39:06 2012 -0500 NFSv4: Return the delegation if the server returns NFS4ERR\_OPENMODE commit 3114ea7a24d3264c090556a2444fc6d2c06176d4 upstream. If a setattr() fails because of an NFS4ERR\_OPENMODE error, it is probably due to us holding a read delegation. Ensure that the recovery routines return that delegation in this case. Reported-by: Miklos Szeredi Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 87ff507d31bdc8f235e2e066f163ff4958696615 Author: Trond Myklebust Date: Mon Mar 5 19:56:44 2012 -0500 NFS: Properly handle the case where the delegation is revoked commit a1d0b5eebc4fd6e0edb02688b35f17f67f42aea5 upstream. If we know that the delegation stateid is bad or revoked, we need to remove that delegation as soon as possible, and then mark all the stateids that relied on that delegation for recovery. We cannot use the delegation as part of the recovery process. Also note that NFSv4.1 uses a different error code (NFS4ERR\_DELEG\_REVOKED) to indicate that the delegation was revoked. Finally, ensure that setlk() and setattr() can both recover safely from a revoked delegation. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 8b78ac2e73df00822504ee8d091c4640b5ea5045 Author: Mel Gorman Date: Wed Mar 21 16:34:00 2012 -0700 mm: vmscan: forcibly scan highmem if there are too many buffer\_heads pinning highmem commit cc715d99e529d470dde2f33a6614f255adea71f3 upstream. Stuart Foster reported on bugzilla that copying large amounts of data from NTFS caused an OOM kill on 32-bit X86 with 16G of memory. Andrew Morton correctly identified that the problem was NTFS was using 512 blocks meaning each page had 8 buffer\_heads in low memory pinning it. In the past, direct reclaim used to scan highmem even if the allocating process did not specify \_\_GFP\_HIGHMEM but not any more. kswapd no longer will reclaim from zones that are above the high watermark. The intention in both cases was to minimise unnecessary reclaim. The downside is on machines with large amounts of highmem that lowmem can be fully consumed by buffer\_heads with nothing trying to free them. The following patch is based on a suggestion by Andrew Morton to extend the buffer\_heads\_over\_limit case to force kswapd and direct reclaim to scan the highmem zone regardless of the allocation request or watermarks. Addresses https://bugzilla.kernel.org/show\_bug.cgi?id=42578 \[hughd@google.com: move buffer\_heads\_over\_limit check up\] \[akpm@linux-foundation.org: buffer\_heads\_over\_limit is unlikely\] Reported-by: Stuart Foster Tested-by: Stuart Foster Signed-off-by: Mel Gorman Signed-off-by: Hugh Dickins Cc: Johannes Weiner Cc: Rik van Riel Cc: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 34275dabcc4c4e04be91700bb1194953ac2c62ca Author: Clemens Ladisch Date: Mon Mar 12 21:45:47 2012 +0100 firewire: ohci: fix too-early completion of IR multichannel buffers commit 0c0efbacab8d70700d13301e0ae7975783c0cb0a upstream. handle\_ir\_buffer\_fill() assumed that a completed descriptor would be indicated by a non-zero transfer\_status (as in most other descriptors). However, this field is written by the controller as soon as (the end of) the first packet has been written into the buffer. As a consequence, if we happen to run into such a descriptor when the interrupt handler is executed after such a packet has completed, the descriptor would be taken out of the list of active descriptors as soon as the buffer had been partially filled, so the event for the buffer being completely filled would never be sent. To fix this, handle descriptors only when they have been completely filled, i.e., when res\_count == 0. (This also matches the condition that is reported by the controller with an interrupt.) Signed-off-by: Clemens Ladisch Signed-off-by: Stefan Richter Signed-off-by: Greg Kroah-Hartman commit 54aa05c61f9cc429d7e56d1dc7e88ef308d362bd Author: Sergei Shtylyov Date: Thu Jan 19 19:09:56 2012 +0300 pata\_legacy: correctly mask recovery field for HT6560B commit 9716387311c790de381214c03e7f1b72b91a8189 upstream. According to the HT6560H datasheet, the recovery timing field is 4-bit wide, with a value of 0 meaning 16 cycles. Correct obvious thinko in the recovery field mask. Signed-off-by: Sergei Shtylyov Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit a9758dd522160885657ea98137b6e8a3205597e6 Author: Brian Norris Date: Tue Feb 21 10:38:44 2012 -0800 ahci\_platform: add STRICT\_AHCI platform type commit d408e2b14fba4fa214fa5bc24b7baae8a55e563c upstream. Some platforms need to make use of the AHCI\_HFLAG\_DELAY\_ENGINE flag. Signed-off-by: Brian Norris Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 690ea068bfa1b5c208153334a81a0f2afe18fded Author: Brian Norris Date: Tue Feb 21 10:38:43 2012 -0800 ahci: move AHCI\_HFLAGS() macro to ahci.h commit 55d5ec316627b64c3764e4c1b4b8e1988e272c1f upstream. We will need this macro in both ahci.c and ahci\_platform.c, so just move it to the header. Signed-off-by: Brian Norris Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit a89a313bb2408370e260e749e68a6ae104d83287 Author: Brian Norris Date: Tue Feb 21 10:38:42 2012 -0800 ahci: add AHCI\_HFLAG\_DELAY\_ENGINE host flag commit 66583c9fa63d05d5580e409f9a58d3cad6d76d17 upstream. The following commit was intended to fix problems with specific AHCI controller(s) that would become bricks if the AHCI specification was not followed strictly (that is, if ahci\_start\_engine() was called while the controller was in the wrong state): commit 7faa33da9b7add01db9f1ad92c6a5d9145e940a7 ahci: start engine only during soft/hard resets However, some devices currently have issues with that fix, so we must implement a flag that delays the ahci\_start\_engine() call only for specific controllers. This commit simply introduces the flag, without enabling it in any driver. Note that even when AHCI\_HFLAG\_DELAY\_ENGINE is not enabled, this patch does not constitue a full revert to commit 7faa33da; there is still a change in behavior to the ahci\_port\_suspend() failure path. Signed-off-by: Brian Norris Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit e6378bcdcd97ec7378080c9eb64d744993ad8bcd Author: Keng-Yu Lin Date: Mon Jan 30 14:25:45 2012 +0800 HID: add more hotkeys in Asus AIO keyboards commit 6c30d5a53229aad22bb675e0bd6eb518ecaa4316 upstream. Add support for the camera key. The hotkey for Asus S.H.E(Super Hybrid Engine) mode is mapped to KEY\_KEY\_PROG1 just for notifying the userspace. Signed-off-by: Keng-Yu Lin Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 11d172fdf5a7ef15c491807617e904a83893ea92 Author: Keng-Yu Lin Date: Thu Feb 2 10:31:26 2012 +0100 HID: add extra hotkeys in Asus AIO keyboards commit 3596bb929f2abd3433c2eaa5755fad48ac207af1 upstream. The Asus All-In-One PC has a wireless keyboard with wifi toggle, brightness up, brightness down and display off hotkeys. This patch adds suppoort for these hotkeys. Signed-off-by: Keng-Yu Lin Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 8cfaf23a993dfbfbc2e6794b327f607fffa4be54 Author: Keng-Yu Lin Date: Wed Nov 30 18:32:37 2011 +0800 Bluetooth: Add AR30XX device ID on Asus laptops commit 6b6ba88b5bb8779156b21bb957520a448c3642e2 upstream. The ID is found on Asus K54HR and K53U. Blacklist the AR3011-based device ID \[0489:e03d\] and add to ath3k.c for firmware loading. Below is the output of usb-devices script: Before the fiwmware loading: T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0489 ProdID=e03d Rev=00.01 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 After the fiwmware loading: T: Bus=01 Lev=02 Prnt=02 Port=00 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=0cf3 ProdID=3005 Rev=00.01 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: Keng-Yu Lin Signed-off-by: Gustavo F. Padovan Signed-off-by: Johan Hedberg Signed-off-by: Greg Kroah-Hartman commit 527a832cda6dbe7ac3a38dcceb7fe422a7980e13 Author: Roland Dreier Date: Thu Feb 23 17:22:12 2012 -0800 target: Fix 16-bit target ports for SET TARGET PORT GROUPS emulation commit 33395fb8a13731c7ef7b175dbf5a4d8a6738fe6c upstream. The old code did (MSB << 8) & 0xff, which always evaluates to 0. Just use get\_unaligned\_be16() so we don't have to worry about whether our open-coded version is correct or not. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 3b5e7a259c88befb754607dcabd14b4f01bef212 Author: Jörn Engel Date: Wed Feb 15 16:52:11 2012 -0500 target: prevent NULL pointer dereference in target\_report\_luns commit 47f1b8803e1e358ebbf4f82bfdb98971c912a2c3 upstream. transport\_kmap\_data\_sg can return NULL. I never saw this trigger, but returning -ENOMEM seems better than a crash. Also removes a pointless case while at it. Signed-off-by: Joern Engel Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 1459484eea1cb844a9977b6fe49009dd2668c44a Author: Jörn Engel Date: Wed Feb 15 16:51:32 2012 -0500 target: fix use after free in target\_report\_luns commit 382436f8804fe1cb20b9a2a811a10eb2d8554721 upstream. Fix possible NULL pointer dereference in target\_report\_luns failure path. Signed-off-by: Joern Engel Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit bda489461f3d0ae38b92ef9a8f8afc82a73945de Author: Roland Dreier Date: Mon Feb 13 16:18:16 2012 -0800 target: Don't set WBUS16 or SYNC bits in INQUIRY response commit effc6cc8828257c32c37635e737f14fd6e19ecd7 upstream. SPC-4 says about the WBUS16 and SYNC bits: The meanings of these fields are specific to SPI-5 (see 6.4.3). For SCSI transport protocols other than the SCSI Parallel Interface, these fields are reserved. We don't have a SPI fabric module, so we should never set these bits. (The comment was misleading, since it only mentioned Sync but the actual code set WBUS16 too). Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 3eaca04b3a19f230bf97ffa393aab2987aa8e2a0 Author: Roland Dreier Date: Mon Feb 13 16:18:15 2012 -0800 target: Set peripheral device type consistently in INQUIRY response commit 089461dda1770c10fea0b988ff74519a9be81d7e upstream. Current code sets the peripheral device type to 0x3f == "not present unknown" for virtual LUN 0 for standard INQUIRY commands, but leaves it as 0 == "connected direct access block" for VPD INQUIRY commands. This is just because the check for LUN 0 only happens in some code paths. Make our peripheral device type consistent by moving the LUN 0 check into the common emulate\_inquiry() code. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 65b45ddcdb7757d13daea218c49ff5dfb655079f Author: Roland Dreier Date: Mon Feb 13 16:18:14 2012 -0800 target: Fix up handling of short INQUIRY buffers commit d95b82461c56a6ff8ff248b101049a69ebb20278 upstream. If the initiator sends us an INQUIRY command with an allocation length that's shorter than what we want to return, we're simply supposed to truncate our response and return what the initiator gave us space for, without signaling any error. Current target code has various tests that don't fill out the full response if the buffer is too short and sometimes return errors incorrectly. Fix this up by allocating a bounce buffer for INQUIRY responses if we need to, ie if we have cmd->data\_length too small as well as SCF\_PASSTHROUGH\_SG\_TO\_MEM\_NOALLOC set in cmd->se\_cmd\_flags -- for most fabrics, we always allocate at least a full page, but for tcm\_loop we may have a small buffer coming directly from the SCSI stack. This lets us delete a lot of cmd->data\_length checking, and also makes our INQUIRY handling correct per SPC in a lot more cases. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 9b5e6cedebb86c341ec5ee55f2ee317fba788844 Author: Alex Deucher Date: Fri Mar 16 12:22:10 2012 -0400 drm/radeon/kms: add connector quirk for Fujitsu D3003-S2 board commit 4c1b2d2da3451f5c8dd59bd7e05bd9729d2aee05 upstream. vbios lists DVI-I port as VGA and DVI-D. Fixes: https://bugs.freedesktop.org/show\_bug.cgi?id=47007 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 10c69ed6ba89d906a367b843a0943f0ff51a653b Author: Alex Deucher Date: Fri Mar 16 12:22:09 2012 -0400 drm/radeon/kms: fix analog load detection on DVI-I connectors commit e00e8b5e760cbbe9067daeae5454d67c44c8d035 upstream. We digital encoders have a detect function as well (for DP to VGA bridges), so we make sure we choose the analog one here. Fixes: https://bugs.freedesktop.org/show\_bug.cgi?id=47007 Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 094599e150bde9b5c9bc69a31132753a32d0cafe Author: Michel Dänzer Date: Wed Mar 14 17:12:41 2012 +0100 drm/radeon: Restrict offset for legacy hardware cursor. commit c4353016dac10133fa5d8535af83f0c4845a2915 upstream. The hardware only takes 27 bits for the offset, so larger offsets are truncated, and the hardware cursor shows random bits other than the intended ones. Bugzilla: https://bugs.freedesktop.org/show\_bug.cgi?id=46796 Signed-off-by: Michel Dänzer Reviewed-by: Alex Deucher Signed-off-by: Dave Airlie commit e1eea76bbbab9389903aeb04dcb852ab15a3d6ae Author: Chris Wilson Date: Wed Dec 14 13:57:23 2011 +0100 drm/i915: Only clear the GPU domains upon a successful finish commit c501ae7f332cdaf42e31af30b72b4b66cbbb1604 upstream. By clearing the GPU read domains before waiting upon the buffer, we run the risk of the wait being interrupted and the domains prematurely cleared. The next time we attempt to wait upon the buffer (after userspace handles the signal), we believe that the buffer is idle and so skip the wait. There are a number of bugs across all generations which show signs of an overly haste reuse of active buffers. Such as: https://bugs.freedesktop.org/show\_bug.cgi?id=29046 https://bugs.freedesktop.org/show\_bug.cgi?id=35863 https://bugs.freedesktop.org/show\_bug.cgi?id=38952 https://bugs.freedesktop.org/show\_bug.cgi?id=40282 https://bugs.freedesktop.org/show\_bug.cgi?id=41098 https://bugs.freedesktop.org/show\_bug.cgi?id=41102 https://bugs.freedesktop.org/show\_bug.cgi?id=41284 https://bugs.freedesktop.org/show\_bug.cgi?id=42141 A couple of those pre-date i915\_gem\_object\_finish\_gpu(), so may be unrelated (such as a wild write from a userspace command buffer), but this does look like a convincing cause for most of those bugs. Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter Reviewed-by: Eugeni Dodonov Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman commit 9a4d77ce349485b9a9c2aa52265917ce4328789d Author: NeilBrown Date: Mon Mar 19 12:46:41 2012 +1100 md: fix clearing of the 'changed' flags for the bad blocks list. commit d0962936bff659d20522555b517582a2715fd23f upstream. In super\_1\_sync (the first hunk) we need to clear 'changed' before checking read\_seqretry(), otherwise we might race with other code adding a bad block and so won't retry later. In md\_update\_sb (the second hunk), in the case where there is no metadata (neither persistent nor external), we treat any bad blocks as an error. However we need to clear the 'changed' flag before calling md\_ack\_all\_badblocks, else it won't do anything. This patch is suitable for -stable release 3.0 and later. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 8d79f898e169e1ef01cec78234ee48f0dd7dfb1e Author: NeilBrown Date: Mon Mar 19 12:46:38 2012 +1100 md/raid1,raid10: avoid deadlock during resync/recovery. commit d6b42dcb995e6acd7cc276774e751ffc9f0ef4bf upstream. If RAID1 or RAID10 is used under LVM or some other stacking block device, it is possible to enter a deadlock during resync or recovery. This can happen if the upper level block device creates two requests to the RAID1 or RAID10. The first request gets processed, blocks recovery and queue requests for underlying requests in current->bio\_list. A resync request then starts which will wait for those requests and block new IO. But then the second request to the RAID1/10 will be attempted and it cannot progress until the resync request completes, which cannot progress until the underlying device requests complete, which are on a queue behind that second request. So allow that second request to proceed even though there is a resync request about to start. This is suitable for any -stable kernel. Reported-by: Ray Morris Tested-by: Ray Morris Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit ed1b69c5592d1fcb4e3151fd5900e22772f22919 Author: NeilBrown Date: Mon Mar 19 12:46:37 2012 +1100 md: don't set md arrays to readonly on shutdown. commit c744a65c1e2d59acc54333ce80a5b0702a98010b upstream. It seems that with recent kernel, writeback can still be happening while shutdown is happening, and consequently data can be written after the md reboot notifier switches all arrays to read-only. This causes a BUG. So don't switch them to read-only - just mark them clean and set 'safemode' to '2' which mean that immediately after any write the array will be switch back to 'clean'. This could result in the shutdown happening when array is marked dirty, thus forcing a resync on reboot. However if you reboot without performing a "sync" first, you get to keep both halves. This is suitable for any stable kernel (though there might be some conflicts with obvious fixes in earlier kernels). Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 87567f2eb2ef89fca77d97b36d854d34cb565ca0 Author: NeilBrown Date: Mon Mar 19 12:46:37 2012 +1100 md/bitmap: ensure to load bitmap when creating via sysfs. commit 4474ca42e2577563a919fd3ed782e2ec55bf11a2 upstream. When commit 69e51b449d383e (md/bitmap: separate out loading a bitmap...) created bitmap\_load, it missed calling it after bitmap\_create when a bitmap is created through the sysfs interface. So if a bitmap is added this way, we don't allocate memory properly and can crash. This is suitable for any -stable release since 2.6.35. Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit dd0ae302075807d9cea7dfe03b7db59aabb0acca Author: Nicholas Bellinger Date: Sat Mar 17 20:12:36 2012 -0700 ib\_srpt: Fix srpt\_handle\_cmd send\_ioctx->ioctx\_kref leak on exception commit 187e70a554e0f0717a65998bc9199945cbbd4692 upstream. This patch addresses a bug in srpt\_handle\_cmd() failure handling where send\_ioctx->kref is being leaked with the local extra reference after init, causing the expected kref\_put() in srpt\_handle\_send\_comp() to not be the final call to invoke srpt\_put\_send\_ioctx\_kref() -> transport\_generic\_free\_cmd() and perform se\_cmd descriptor memory release. It also fixes a SCF\_SCSI\_RESERVATION\_CONFLICT handling bug where this code is incorrectly falling through to transport\_handle\_cdb\_direct() after invoking srpt\_queue\_status() to send SAM\_STAT\_RESERVATION\_CONFLICT status. Note this patch is for >= v3.3 mainline code, and current lio-core.git code has already been converted to target\_submit\_cmd() + se\_cmd->cmd\_kref usage, and internal ioctx->kref usage has been removed. I'm including this patch now into target-pending/for-next with a CC' for v3.3 stable. Cc: Bart Van Assche Cc: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 72ab3d92feff3cf388ad74395b1f49050fa9186d Author: Nicholas Bellinger Date: Fri Mar 9 23:45:38 2012 -0800 tcm\_fc: Fix fc\_exch memory leak in ft\_send\_resp\_status commit 031ed4d565b31880a4136bb7366bc89f5b1dba7d upstream. This patch fixes a bug in tcm\_fc where fc\_exch memory from fc\_exch\_mgr->ep\_pool is currently being leaked by ft\_send\_resp\_status() usage. Following current code in ft\_queue\_status() response path, using lport->tt.seq\_send() needs to be followed by a lport->tt.exch\_done() in order to release fc\_exch memory back into libfc\_em kmem\_cache. ft\_send\_resp\_status() code is currently used in pre submit se\_cmd ft\_send\_work() error exceptions, TM request setup exceptions, and main TM response callback path in ft\_queue\_tm\_resp(). This bugfix addresses the leak in these cases. Cc: Mark D Rustad Cc: Kiran Patil Cc: Robert Love Cc: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit a8a9b9379344c4d1d67877d6798ea0a3ca46d066 Author: Kay Sievers Date: Sat Jan 28 19:57:46 2012 +0000 udlfb: remove sysfs framebuffer device with USB .disconnect() commit ce880cb860f36694d2cdebfac9e6ae18176fe4c4 upstream. The USB graphics card driver delays the unregistering of the framebuffer device to a workqueue, which breaks the userspace visible remove uevent sequence. Recent userspace tools started to support USB graphics card hotplug out-of-the-box and rely on proper events sent by the kernel. The framebuffer device is a direct child of the USB interface which is removed immediately after the USB .disconnect() callback. But the fb device in /sys stays around until its final cleanup, at a time where all the parent devices have been removed already. To work around that, we remove the sysfs fb device directly in the USB .disconnect() callback and leave only the cleanup of the internal fb data to the delayed work. Before: add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb) add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb) add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb0 (graphics) remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb) remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb) remove /2-1.2:1.0/graphics/fb0 (graphics) After: add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb) add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb) add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics) remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics) remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb) remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb) Tested-by: Bernie Thompson Acked-by: Bernie Thompson Signed-off-by: Kay Sievers Signed-off-by: Florian Tobias Schandinat Signed-off-by: Greg Kroah-Hartman commit da6c2c22bb0e9abbe8293ebea33371e8f4c94e13 Author: Yoichi Yuasa Date: Thu Mar 15 14:50:16 2012 +0000 gma500: Fix mmap frambuffer commit 1278f7de7fa5606ed513a5271f7fb63910ef1b8b upstream. It cannot map correctly if page fault begins from a intermediate address. \[The driver prefaults the mapping, so we need to work from the correct base address not the faulting address otherwise the map appears offset by the fault offset\] Signed-off-by: Yoichi Yuasa Signed-off-by: Alan Cox Signed-off-by: Dave Airlie Signed-off-by: Greg Kroah-Hartman commit 4e6a69464c389da6179cf3cad0365d72e78614be Author: Lothar Waßmann Date: Sun Mar 11 15:08:46 2012 +0100 usb gadget: fix a section mismatch when compiling g\_ffs with CONFIG\_USB\_FUNCTIONFS\_ETH commit 8d0698428822ce63f7269e7fe81fc4580807b9ac upstream. commit 28824b18ac4705e876a282a15ea0de8fc957551f: |Author: Michal Nazarewicz |Date: Wed May 5 12:53:13 2010 +0200 | | USB: gadget: \_\_init and \_\_exit tags removed | | \_\_init, \_\_initdata and \_\_exit tags have have been removed from | various files to make it possible for gadgets that do not use | the \_\_init/\_\_exit tags to use those. obviously missed (at least) this case leading to a section mismatch in g\_ffs.c when compiling with CONFIG\_USB\_FUNCTIONFS\_ETH enabled. Signed-off-by: Lothar Waßmann Acked-by: Michal Nazarewicz Signed-off-by: Greg Kroah-Hartman commit 0a86aeed32e7badc3a8e695c797c67d2c396cb62 Author: Anssi Hannula Date: Tue Mar 13 17:43:02 2012 +0200 ALSA: hda - fix printing of high HDMI sample rates commit 25dc16f69892182192b1234594fd3cf342ad4195 upstream. A previous commit af65cbf296 (ALSA: hdmi: fix printout of SAD sampling rates) fixed the sample rates shown in /proc/asound/cardX/eldY and kernel log to not be entirely wrong. However, a missing rate from the array added in the patch causes HDMI rates 88.2 kHz, 96 kHz, 176.4 kHz, and 192 kHz to be shown as 96 kHz, 176.4 kHz, 192 kHz, and 384 kHz, respectively. Fix the reporting by adding the ALSA rate 64 kHz into the conversion array between 48 kHz and 88.2 kHz. Signed-off-by: Anssi Hannula Cc: Pierre-Louis Bossart Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3b8dd72a8a7aec8720488972397308b8677a2563 Author: Nicholas Bellinger Date: Sun Feb 26 22:16:07 2012 -0800 iscsi-target: Fix dynamic -> explict NodeACL pointer reference commit d06283341aee9e48eff1b068779d340785c635ce upstream. This patch fixes a free after use in lio\_target\_make\_nodeacl() where iscsi\_node\_acl was referenced from the original se\_nacl\_new allocation, instead of from core\_tpg\_add\_initiator\_node\_acl() in the case of dynamic -> explict NodeACL conversion. Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit ffcdcd3e773363344d94d5ec78507f89d957c5cd Author: Nicholas Bellinger Date: Thu Feb 23 17:28:43 2012 -0800 iscsi-target: Fix iscsit\_alloc\_buffs() failure cases commit d335e6054db616bce3f040e659fa38440518ad1d upstream. Make iscsit\_alloc\_buffs() failure case for page\_alloc\_failed use correct \_\_free\_page() SGL pointer, and return -ENOMEM for iscsit\_allocate\_iovecs failure to push se\_cmd->t\_mem\_sg release into iscsit\_release\_cmd() callback during iscsit\_add\_reject\_from\_cmd() connection reset. Also drop cmd->t\_mem\_sg = NULL assignment from page\_alloc\_failed failure case. Reported-by: Roland Dreier Cc: Andy Grover Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 4fd071e66117d24b116c80263321d9610489844d Author: Mike Christie Date: Thu Jan 26 21:13:09 2012 -0600 SCSI: iscsi: fix setting of pid from netlink skb commit df1c7baba1b7b3053950f3845a6575aca47ba9ce upstream. NETLINK\_CREDS's pid now returns 0, so I guess we are supposed to be using NETLINK\_CB. This changed while the patch to export the pid was getting merged upstream, so it was not noticed until both the network and iscsi changes were in the same tree. Signed-off-by: Mike Christie Signed-off-by: James Bottomley Signed-off-by: Greg Kroah-Hartman commit a239fc40f72471dcff819dfd0d2a6371bb8c3ad8 Author: Roland Dreier Date: Tue Feb 14 15:30:31 2012 -0800 tcm\_loop: Set residual field for SCSI commands commit 6cf3fa6918baab0c447f1206f1cef9166ad04864 upstream. If the target core signals an over- or under-run, tcm\_loop should call scsi\_set\_resid() to tell the SCSI midlayer about the residual data length. The difference can be seen by doing something like strace -eioctl sg\_raw -r 1024 /dev/sda 8 0 0 0 1 0 > /dev/null and looking at the "resid=" part of the SG\_IO ioctl -- after this patch, the field is correctly reported as 512. Signed-off-by: Roland Dreier Signed-off-by: Nicholas Bellinger Signed-off-by: Greg Kroah-Hartman commit 67e5208f9495212fdcffcce64fbc9a970faade6b Author: Daniel Mack Date: Mon Mar 19 09:12:53 2012 +0100 ASoC: pxa-ssp: atomically set stream active masks commit 273b72c8ce6b28df6b49423d775c3e59072c73c5 upstream. PXA's SSP engine fails to take its current channel phase into account when enabling a stream while the engine is already running. This results in randomly swapped left/right channels on either the record or the playback side, depending on which one was enabled first. The following patch fixes this by factoring out the bit field modifications in question to a separate function that pauses the engine temporarily, modifies the bits and kicks it off again afterwards. Appearantly, a transition of SSCR0\_SSE syncs both directions properly. The patch has been rolled out to quite a number of devices over the last weeks and seems to fix the issue reliably. Signed-off-by: Daniel Mack Reported-and-tested-by: Sven Neumann Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit e7e9f000debc0128d1bc91b3a08e3f9013187d7a Author: Timur Tabi Date: Fri Mar 16 16:32:52 2012 -0500 ASoC: fsl: p1022ds: tell the WM8776 codec driver that it's the master commit 70ac07bb633dee75ac554195b9a4d69adfa7803c upstream. The WM8776 codec driver requires the machine driver to set one of the SND\_SOC\_DAIFMT\_CBx\_xxx values. The P1022DS machine driver should be setting SND\_SOC\_DAIFMT\_CBM\_CFM, but since that value was zero, no one noticed. Commit 75d9ac46 ("ASoC: Allow DAI formats to be specified in the dai\_link"), however, changed the value of SND\_SOC\_DAIFMT\_CBM\_CFM from zero to a non-zero value, which means that it now needs to be specifically set by the machine driver. We also set SND\_SOC\_DAIFMT\_NB\_NF, for the same reason. Signed-off-by: Timur Tabi Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a3d921898eac98a977061da4ab364e518d85dd8a Author: Aneesh Kumar K.V Date: Wed Mar 21 16:34:08 2012 -0700 hugetlbfs: avoid taking i\_mutex from hugetlbfs\_read() commit a05b0855fd15504972dba2358e5faa172a1e50ba upstream. Taking i\_mutex in hugetlbfs\_read() can result in deadlock with mmap as explained below Thread A: read() on hugetlbfs hugetlbfs\_read() called i\_mutex grabbed hugetlbfs\_read\_actor() called \_\_copy\_to\_user() called page fault is triggered Thread B, sharing address space with A: mmap() the same file ->mmap\_sem is grabbed on task\_B->mm->mmap\_sem hugetlbfs\_file\_mmap() is called attempt to grab ->i\_mutex and block waiting for A to give it up Thread A: pagefault handled blocked on attempt to grab task\_A->mm->mmap\_sem, which happens to be the same thing as task\_B->mm->mmap\_sem. Block waiting for B to give it up. AFAIU the i\_mutex locking was added to hugetlbfs\_read() as per http://lkml.indiana.edu/hypermail/linux/kernel/0707.2/3066.html to take care of the race between truncate and read. This patch fixes this by looking at page->mapping under lock\_page() (find\_lock\_page()) to ensure that the inode didn't get truncated in the range during a parallel read. Ideally we can extend the patch to make sure we don't increase i\_size in mmap. But that will break userspace, because applications will now have to use truncate(2) to increase i\_size in hugetlbfs. Based on the original patch from Hillf Danton. Signed-off-by: Aneesh Kumar K.V Cc: Hillf Danton Cc: KAMEZAWA Hiroyuki Cc: Al Viro Cc: Hugh Dickins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1a453d965ab45b8bb44c3dff10ea4085447c363d Author: Nishanth Aravamudan Date: Wed Mar 21 16:34:07 2012 -0700 bootmem/sparsemem: remove limit constraint in alloc\_bootmem\_section commit f5bf18fa22f8c41a13eb8762c7373eb3a93a7333 upstream. While testing AMS (Active Memory Sharing) / CMO (Cooperative Memory Overcommit) on powerpc, we tripped the following: kernel BUG at mm/bootmem.c:483! cpu 0x0: Vector: 700 (Program Check) at \[c000000000c03940\] pc: c000000000a62bd8: .alloc\_bootmem\_core+0x90/0x39c lr: c000000000a64bcc: .sparse\_early\_usemaps\_alloc\_node+0x84/0x29c sp: c000000000c03bc0 msr: 8000000000021032 current = 0xc000000000b0cce0 paca = 0xc000000001d80000 pid = 0, comm = swapper kernel BUG at mm/bootmem.c:483! enter ? for help \[c000000000c03c80\] c000000000a64bcc .sparse\_early\_usemaps\_alloc\_node+0x84/0x29c \[c000000000c03d50\] c000000000a64f10 .sparse\_init+0x12c/0x28c \[c000000000c03e20\] c000000000a474f4 .setup\_arch+0x20c/0x294 \[c000000000c03ee0\] c000000000a4079c .start\_kernel+0xb4/0x460 \[c000000000c03f90\] c000000000009670 .start\_here\_common+0x1c/0x2c This is BUG\_ON(limit && goal + size > limit); and after some debugging, it seems that goal = 0x7ffff000000 limit = 0x80000000000 and sparse\_early\_usemaps\_alloc\_node -> sparse\_early\_usemaps\_alloc\_pgdat\_section calls return alloc\_bootmem\_section(usemap\_size() \* count, section\_nr); This is on a system with 8TB available via the AMS pool, and as a quirk of AMS in firmware, all of that memory shows up in node 0. So, we end up with an allocation that will fail the goal/limit constraints. In theory, we could "fall-back" to alloc\_bootmem\_node() in sparse\_early\_usemaps\_alloc\_node(), but since we actually have HOTREMOVE defined, we'll BUG\_ON() instead. A simple solution appears to be to unconditionally remove the limit condition in alloc\_bootmem\_section, meaning allocations are allowed to cross section boundaries (necessary for systems of this size). Johannes Weiner pointed out that if alloc\_bootmem\_section() no longer guarantees section-locality, we need check\_usemap\_section\_nr() to print possible cross-dependencies between node descriptors and the usemaps allocated through it. That makes the two loops in sparse\_early\_usemaps\_alloc\_node() identical, so re-factor the code a bit. \[akpm@linux-foundation.org: code simplification\] Signed-off-by: Nishanth Aravamudan Cc: Dave Hansen Cc: Anton Blanchard Cc: Paul Mackerras Cc: Ben Herrenschmidt Cc: Robert Jennings Acked-by: Johannes Weiner Acked-by: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a4538d45e9cae29742c27f6e83ddb1f209afea46 Author: Rafael J. Wysocki Date: Tue Mar 13 22:39:31 2012 +0100 PM / Domains: Fix handling of wakeup devices during system resume commit cc85b20780562d404e18a47b9b55b4a5102ae53e upstream. During system suspend pm\_genpd\_suspend\_noirq() checks if the given device is in a wakeup path (i.e. it appears to be needed for one or more wakeup devices to work or is a wakeup device itself) and if it needs to be "active" for wakeup to work. If that is the case, the function returns 0 without incrementing the device domain's counter of suspended devices and without executing genpd\_stop\_dev() for the device. In consequence, the device is not stopped (e.g. its clock isn't disabled) and power is always supplied to its domain in the resulting system sleep state. However, pm\_genpd\_resume\_noirq() doesn't repeat that check and it runs genpd\_start\_dev() and decrements the domain's counter of suspended devices even for the wakeup device that weren't stopped by pm\_genpd\_suspend\_noirq(). As a result, the start callback may be run unnecessarily for them and their domains' counters of suspended devices may become negative. Both outcomes aren't desirable, so fix pm\_genpd\_resume\_noirq() to look for wakeup devices that might not be stopped by during system suspend. Signed-off-by: Rafael J. Wysocki Tested-by: Simon Horman Signed-off-by: Greg Kroah-Hartman commit 82bd67b9cde53fbc7142f293f0b85091b054b960 Author: Tim Gardner Date: Tue Dec 6 11:29:20 2011 -0700 TPM: Zero buffer whole after copying to userspace commit 3ab1aff89477dafb1aaeafe8c8669114a02b7226 upstream. Commit 3321c07ae5068568cd61ac9f4ba749006a7185c9 correctly clears the TPM buffer if the user specified read length is >= the TPM buffer length. However, if the user specified read length is < the TPM buffer length, then part of the TPM buffer is left uncleared. Reported-by: Seth Forshee Cc: Debora Velarde Cc: Rajiv Andrade Cc: Marcel Selhorst Cc: tpmdd-devel@lists.sourceforge.net Signed-off-by: Tim Gardner Signed-off-by: Rajiv Andrade Signed-off-by: Greg Kroah-Hartman commit 4a1d704194a441bf83c636004a479e01360ec850 Author: Andrea Arcangeli Date: Wed Mar 21 16:33:42 2012 -0700 mm: thp: fix pmd\_bad() triggering in code paths holding mmap\_sem read mode commit 1a5a9906d4e8d1976b701f889d8f35d54b928f25 upstream. In some cases it may happen that pmd\_none\_or\_clear\_bad() is called with the mmap\_sem hold in read mode. In those cases the huge page faults can allocate hugepmds under pmd\_none\_or\_clear\_bad() and that can trigger a false positive from pmd\_bad() that will not like to see a pmd materializing as trans huge. It's not khugepaged causing the problem, khugepaged holds the mmap\_sem in write mode (and all those sites must hold the mmap\_sem in read mode to prevent pagetables to go away from under them, during code review it seems vm86 mode on 32bit kernels requires that too unless it's restricted to 1 thread per process or UP builds). The race is only with the huge pagefaults that can convert a pmd\_none() into a pmd\_trans\_huge(). Effectively all these pmd\_none\_or\_clear\_bad() sites running with mmap\_sem in read mode are somewhat speculative with the page faults, and the result is always undefined when they run simultaneously. This is probably why it wasn't common to run into this. For example if the madvise(MADV\_DONTNEED) runs zap\_page\_range() shortly before the page fault, the hugepage will not be zapped, if the page fault runs first it will be zapped. Altering pmd\_bad() not to error out if it finds hugepmds won't be enough to fix this, because zap\_pmd\_range would then proceed to call zap\_pte\_range (which would be incorrect if the pmd become a pmd\_trans\_huge()). The simplest way to fix this is to read the pmd in the local stack (regardless of what we read, no need of actual CPU barriers, only compiler barrier needed), and be sure it is not changing under the code that computes its value. Even if the real pmd is changing under the value we hold on the stack, we don't care. If we actually end up in zap\_pte\_range it means the pmd was not none already and it was not huge, and it can't become huge from under us (khugepaged locking explained above). All we need is to enforce that there is no way anymore that in a code path like below, pmd\_trans\_huge can be false, but pmd\_none\_or\_clear\_bad can run into a hugepmd. The overhead of a barrier() is just a compiler tweak and should not be measurable (I only added it for THP builds). I don't exclude different compiler versions may have prevented the race too by caching the value of \*pmd on the stack (that hasn't been verified, but it wouldn't be impossible considering pmd\_none\_or\_clear\_bad, pmd\_bad, pmd\_trans\_huge, pmd\_none are all inlines and there's no external function called in between pmd\_trans\_huge and pmd\_none\_or\_clear\_bad). if (pmd\_trans\_huge(\*pmd)) { if (next-addr != HPAGE\_PMD\_SIZE) { VM\_BUG\_ON(!rwsem\_is\_locked(&tlb->mm->mmap\_sem)); split\_huge\_page\_pmd(vma->vm\_mm, pmd); } else if (zap\_huge\_pmd(tlb, vma, pmd, addr)) continue; /\* fall through \*/ } if (pmd\_none\_or\_clear\_bad(pmd)) Because this race condition could be exercised without special privileges this was reported in CVE-2012-1179. The race was identified and fully explained by Ulrich who debugged it. I'm quoting his accurate explanation below, for reference. ====== start quote ======= mapcount 0 page\_mapcount 1 kernel BUG at mm/huge\_memory.c:1384! At some point prior to the panic, a "bad pmd ..." message similar to the following is logged on the console: mm/memory.c:145: bad pmd ffff8800376e1f98(80000000314000e7). The "bad pmd ..." message is logged by pmd\_clear\_bad() before it clears the page's PMD table entry. 143 void pmd\_clear\_bad(pmd\_t \*pmd) 144 { -> 145 pmd\_ERROR(\*pmd); 146 pmd\_clear(pmd); 147 } After the PMD table entry has been cleared, there is an inconsistency between the actual number of PMD table entries that are mapping the page and the page's map count (\_mapcount field in struct page). When the page is subsequently reclaimed, \_\_split\_huge\_page() detects this inconsistency. 1381 if (mapcount != page\_mapcount(page)) 1382 printk(KERN\_ERR "mapcount %d page\_mapcount %d\\n", 1383 mapcount, page\_mapcount(page)); -> 1384 BUG\_ON(mapcount != page\_mapcount(page)); The root cause of the problem is a race of two threads in a multithreaded process. Thread B incurs a page fault on a virtual address that has never been accessed (PMD entry is zero) while Thread A is executing an madvise() system call on a virtual address within the same 2 MB (huge page) range. virtual address space .---------------------. | | | | .-|---------------------| | | | | | |<-- B(fault) | | | 2 MB | |/////////////////////|-. huge < |/////////////////////| > A(range) page | |/////////////////////|-' | | | | | | '-|---------------------| | | | | '---------------------' - Thread A is executing an madvise(..., MADV\_DONTNEED) system call on the virtual address range "A(range)" shown in the picture. sys\_madvise // Acquire the semaphore in shared mode. down\_read(¤t->mm->mmap\_sem) ... madvise\_vma switch (behavior) case MADV\_DONTNEED: madvise\_dontneed zap\_page\_range unmap\_vmas unmap\_page\_range zap\_pud\_range zap\_pmd\_range // // Assume that this huge page has never been accessed. // I.e. content of the PMD entry is zero (not mapped). // if (pmd\_trans\_huge(\*pmd)) { // We don't get here due to the above assumption. } // // Assume that Thread B incurred a page fault and .---------> // sneaks in here as shown below. | // | if (pmd\_none\_or\_clear\_bad(pmd)) | { | if (unlikely(pmd\_bad(\*pmd))) | pmd\_clear\_bad | { | pmd\_ERROR | // Log "bad pmd ..." message here. | pmd\_clear | // Clear the page's PMD entry. | // Thread B incremented the map count | // in page\_add\_new\_anon\_rmap(), but | // now the page is no longer mapped | // by a PMD entry (-> inconsistency). | } | } | v - Thread B is handling a page fault on virtual address "B(fault)" shown in the picture. ... do\_page\_fault \_\_do\_page\_fault // Acquire the semaphore in shared mode. down\_read\_trylock(&mm->mmap\_sem) ... handle\_mm\_fault if (pmd\_none(\*pmd) && transparent\_hugepage\_enabled(vma)) // We get here due to the above assumption (PMD entry is zero). do\_huge\_pmd\_anonymous\_page alloc\_hugepage\_vma // Allocate a new transparent huge page here. ... \_\_do\_huge\_pmd\_anonymous\_page ... spin\_lock(&mm->page\_table\_lock) ... page\_add\_new\_anon\_rmap // Here we increment the page's map count (starts at -1). atomic\_set(&page->\_mapcount, 0) set\_pmd\_at // Here we set the page's PMD entry which will be cleared // when Thread A calls pmd\_clear\_bad(). ... spin\_unlock(&mm->page\_table\_lock) The mmap\_sem does not prevent the race because both threads are acquiring it in shared mode (down\_read). Thread B holds the page\_table\_lock while the page's map count and PMD table entry are updated. However, Thread A does not synchronize on that lock. ====== end quote ======= \[akpm@linux-foundation.org: checkpatch fixes\] Reported-by: Ulrich Obergfell Signed-off-by: Andrea Arcangeli Acked-by: Johannes Weiner Cc: Mel Gorman Cc: Hugh Dickins Cc: Dave Jones Acked-by: Larry Woodman Acked-by: Rik van Riel Cc: Mark Salter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a998dc2fa76f496d2944f0602b920d1d10d7467d Author: Suresh Siddha Date: Mon Mar 12 11:36:33 2012 -0700 x86/ioapic: Add register level checks to detect bogus io-apic entries commit 73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream. With the recent changes to clear\_IO\_APIC\_pin() which tries to clear remoteIRR bit explicitly, some of the users started to see "Unable to reset IRR for apic .." messages. Close look shows that these are related to bogus IO-APIC entries which return's all 1's for their io-apic registers. And the above mentioned error messages are benign. But kernel should have ignored such io-apic's in the first place. Check if register 0, 1, 2 of the listed io-apic are all 1's and ignore such io-apic. Reported-by: Álvaro Castillo Tested-by: Jon Dufresne Signed-off-by: Suresh Siddha Cc: yinghai@kernel.org Cc: kernel-team@fedoraproject.org Cc: Josh Boyer Link: http://lkml.kernel.org/r/1331577393.31585.94.camel@sbsiddha-desk.sc.intel.com \[ Performed minor cleanup of affected code. \] Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 47fdf7dd7b6ed994c433274a147453561de850d5 Author: Fabio Estevam Date: Thu Jan 5 12:49:54 2012 -0200 ima: fix Kconfig dependencies commit f4a0391dfa91155bd961673b31eb42d9d45c799d upstream. Fix the following build warning: warning: (IMA) selects TCG\_TPM which has unmet direct dependencies (HAS\_IOMEM && EXPERIMENTAL) Suggested-by: Rajiv Andrade Signed-off-by: Fabio Estevam Signed-off-by: Rajiv Andrade Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 4c880f51157f5a09a5eb72bb90871086634c7601 Author: Roland Dreier Date: Sun Feb 26 01:48:12 2012 -0800 mlx4\_core: Fix one more static exported function commit e10903b087e425298fb86c6ad4b1a88735480db7 upstream. Commit 22c8bff6face ("mlx4\_core: Exported functions can't be static") fixed most of this up, but forgot about mlx4\_is\_slave\_active(). Fix this one too. Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 7a0f751655648341690f817771a594c497ab7541 Author: Or Gerlitz Date: Mon Mar 5 18:21:44 2012 +0200 IB/iser: Post initial receive buffers before sending the final login request commit 89e984e2c2cd14f77ccb26c47726ac7f13b70ae8 upstream. An iser target may send iscsi NO-OP PDUs as soon as it marks the iSER iSCSI session as fully operative. This means that there is window where there are no posted receive buffers on the initiator side, so it's possible for the iSER RC connection to break because of RNR NAK / retry errors. To fix this, rely on the flags bits in the login request to have FFP (0x3) in the lower nibble as a marker for the final login request, and post an initial chunk of receive buffers before sending that login request instead of after getting the login response. Signed-off-by: Or Gerlitz Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit 31e95f8b13b90d12a208525705c605e43b8ff106 Author: Greg Rose Date: Wed Feb 8 00:45:00 2012 +0000 rtnetlink: Fix VF IFLA policy commit 48752f6513012a1b078da08b145d5c40a644f058 upstream. Add VF spoof check to IFLA policy. The original patch I submitted to add the spoof checking feature to rtnl failed to add the proper policy rule that identifies the data type and len. This patch corrects that oversight. No bugs have been reported against this but it may cause some problem for the netlink message parsing that uses the policy table. Signed-off-by: Greg Rose Tested-by: Sibai Li Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 361e5342d8ef0c08e3df26de6d021f94f20d8529 Author: Max Filippov Date: Thu Mar 1 00:40:08 2012 +0400 p54spi: Release GPIO lines and IRQ on error in p54spi\_probe commit 62ebeed8d00aef75eac4fd6c161cae75a41965ca upstream. This makes it possible to reload driver if insmod has failed due to missing firmware. Signed-off-by: Max Filippov Acked-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 80b9f23fd371822f7cc4f8d1ca8bd7f995c6c71e Author: Rabin Vincent Date: Tue Nov 22 11:03:14 2011 +0100 rtc: Disable the alarm in the hardware (v2) commit 41c7f7424259ff11009449f87c95656f69f9b186 upstream. Currently, the RTC code does not disable the alarm in the hardware. This means that after a sequence such as the one below (the files are in the RTC sysfs), the box will boot up after 2 minutes even though we've asked for the alarm to be turned off. # echo $((\`cat since\_epoch\`)+120) > wakealarm # echo 0 > wakealarm # poweroff Fix this by disabling the alarm when there are no timers to run. The original version of this patch was reverted. This version disables the irq directly instead of setting a disabled timer in the future. Cc: John Stultz Signed-off-by: Rabin Vincent \[Merged in the second revision from Rabin\] Signed-off-by: John Stultz Signed-off-by: Greg Kroah-Hartman commit a65dcdb33aed68ed3841703453fb659cbb997aec Author: Alexander Gordeev Date: Fri Mar 9 14:59:13 2012 +0100 genirq: Fix incorrect check for forced IRQ thread handler commit 540b60e24f3f4781d80e47122f0c4486a03375b8 upstream. We do not want a bitwise AND between boolean operands Signed-off-by: Alexander Gordeev Cc: Oleg Nesterov Link: http://lkml.kernel.org/r/20120309135912.GA2114@dhcp-26-207.brq.redhat.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 74f8c989469845decd6b2b062c83eb5ad3b125ca Author: Russell King Date: Mon Mar 5 15:07:25 2012 -0800 genirq: Fix long-term regression in genirq irq\_set\_irq\_type() handling commit a09b659cd68c10ec6a30cb91ebd2c327fcd5bfe5 upstream. In 2008, commit 0c5d1eb77a8be ("genirq: record trigger type") modified the way set\_irq\_type() handles the 'no trigger' condition. However, this has an adverse effect on PCMCIA support on Intel StrongARM and probably PXA platforms. PCMCIA has several status signals on the socket which can trigger interrupts; some of these status signals depend on the card's mode (whether it is configured in memory or IO mode). For example, cards have a 'Ready/IRQ' signal: in memory mode, this provides an indication to PCMCIA that the card has finished its power up initialization. In IO mode, it provides the device interrupt signal. Other status signals switch between on-board battery status and loud speaker output. In classical PCMCIA implementations, where you have a specific socket controller, the controller provides a method to mask interrupts from the socket, and importantly ignore any state transitions on the pins which correspond with interrupts once masked. This masking prevents unwanted events caused by the removal and application of socket power being forwarded. However, on platforms where there is no socket controller, the PCMCIA status and interrupt signals are routed to standard edge-triggered GPIOs. These GPIOs can be configured to interrupt on rising edge, falling edge, or never. This is where the problems start. Edge triggered interrupts are required to record events while disabled via the usual methods of {free,request,disable,enable}\_irq() to prevent problems with dropped interrupts (eg, the 8390 driver uses disable\_irq() to defer the delivery of interrupts). As a result, these interfaces can not be used to implement the desired behaviour. The side effect of this is that if the 'Ready/IRQ' GPIO is disabled via disable\_irq() on suspend, and enabled via enable\_irq() after resume, we will record the state transitions caused by powering events as valid interrupts, and foward them to the card driver, which may attempt to access a card which is not powered up. This leads delays resume while drivers spin in their interrupt handlers, and complaints from drivers before they realize what's happened. Moreover, in the case of the 'Ready/IRQ' signal, this is requested and freed by the card driver itself; the PCMCIA core has no idea whether the interrupt is requested, and, therefore, whether a call to disable\_irq() would be valid. (We tried this around 2.4.17 / 2.5.1 kernel era, and ended up throwing it out because of this problem.) Therefore, it was decided back in around 2002 to disable the edge triggering instead, resulting in all state transitions on the GPIO being ignored. That's what we actually need the hardware to do. The commit above changes this behaviour; it explicitly prevents the 'no trigger' state being selected. The reason that request\_irq() does not accept the 'no trigger' state is for compatibility with existing drivers which do not provide their desired triggering configuration. The set\_irq\_type() function is 'new' and not used by non-trigger aware drivers. Therefore, revert this change, and restore previously working platforms back to their former state. Signed-off-by: Russell King Cc: linux@arm.linux.org.uk Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 8247c5b75057188e90aee29fc907a2b2ac9d405f Author: Andrew Vagin Date: Wed Mar 7 14:49:56 2012 +0400 uevent: send events in correct order according to seqnum (v3) commit 7b60a18da393ed70db043a777fd9e6d5363077c4 upstream. The queue handling in the udev daemon assumes that the events are ordered. Before this patch uevent\_seqnum is incremented under sequence\_lock, than an event is send uner uevent\_sock\_mutex. I want to say that code contained a window between incrementing seqnum and sending an event. This patch locks uevent\_sock\_mutex before incrementing uevent\_seqnum. v2: delete sequence\_lock, uevent\_seqnum is protected by uevent\_sock\_mutex v3: unlock the mutex before the goto exit Thanks for Kay for the comments. Signed-off-by: Andrew Vagin Tested-By: Kay Sievers Signed-off-by: Greg Kroah-Hartman commit b2af31bf80a9c38d9ade24e44aa269807b4f592c Author: Sasha Levin Date: Thu Mar 15 12:36:14 2012 -0400 ntp: Fix integer overflow when setting time commit a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33 upstream. 'long secs' is passed as divisor to div\_s64, which accepts a 32bit divisor. On 64bit machines that value is trimmed back from 8 bytes back to 4, causing a divide by zero when the number is bigger than (1 << 32) - 1 and all 32 lower bits are 0. Use div64\_long() instead. Signed-off-by: Sasha Levin Cc: johnstul@us.ibm.com Link: http://lkml.kernel.org/r/1331829374-31543-2-git-send-email-levinsasha928@gmail.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit bd7a318433d1b69aa81392df40c10958a587f82d Author: Sasha Levin Date: Thu Mar 15 12:36:13 2012 -0400 math: Introduce div64\_long commit f910381a55cdaa097030291f272f6e6e4380c39a upstream. Add a div64\_long macro which is used to devide a 64bit number by a long (which can be 4 bytes on 32bit systems and 8 bytes on 64bit systems). Suggested-by: Thomas Gleixner Signed-off-by: Sasha Levin Cc: johnstul@us.ibm.com Link: http://lkml.kernel.org/r/1331829374-31543-1-git-send-email-levinsasha928@gmail.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit db6a6a78d8602964c9dfb1d8ce18daefd92da0a7 Author: Felix Fietkau Date: Sat Mar 10 13:57:04 2012 +0100 ath9k: fix going to full-sleep on PS idle commit c1afdaff90538ef085b756454f12b29575411214 upstream. The check for PS\_WAIT\_FOR\_TX\_ACK was inverted, the hardware should only go to full sleep if no tx is pending. Reported-by: Sujith Manoharan Signed-off-by: Felix Fietkau Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit b095ac6bb999e75e7e032881ceb950fe2e33cf66 Author: Johannes Berg Date: Sun Mar 4 08:50:46 2012 -0800 iwlwifi: always monitor for stuck queues commit 342bbf3fee2fa9a18147e74b2e3c4229a4564912 upstream. If we only monitor while associated, the following can happen: - we're associated, and the queue stuck check runs, setting the queue "touch" time to X - we disassociate, stopping the monitoring, which leaves the time set to X - almost 2s later, we associate, and enqueue a frame - before the frame is transmitted, we monitor for stuck queues, and find the time set to X, although it is now later than X + 2000ms, so we decide that the queue is stuck and erroneously restart the device It happens more with P2P because there we can go between associated/unassociated frequently. Reported-by: Ben Cahill Signed-off-by: Johannes Berg Signed-off-by: Wey-Yi Guy Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 65c0d88c73b35940e757d94160c3ac30c022b8e4 Author: Jingjun Wu Date: Fri Mar 2 20:52:14 2012 -0600 rtlwifi: rtl8192ce: Fix loss of receive performance commit a9b89e2567c743483e6354f64d7a7e3a8c101e9e upstream. Driver rtl8192ce when used with the RTL8188CE device would start at about 20 Mbps on a 54 Mbps connection, but quickly drop to 1 Mbps. One of the symptoms is that the AP would need to retransmit each packet 4 of 5 times before the driver would acknowledge it. Recovery is possible only by unloading and reloading the driver. This problem was reported at https://bugzilla.redhat.com/show\_bug.cgi?id=770207. The problem is due to a missing update of the gain setting. Signed-off-by: Jingjun Wu Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 985f1729c3be24774673d3fc09ae5959c3db65e8 Author: Larry Finger Date: Fri Mar 2 15:23:36 2012 -0600 rtlwifi: rtl8192c: Prevent sleeping from invalid context in rtl8192cu commit ebecdcc12fed5d3c81853dea61a0a78a5aefab52 upstream. When driver rtl8192cu is used with the debug level set to 3 or greater, the result is "sleeping function called from invalid context" due to an rcu\_read\_lock() call in the DM refresh routine in driver rtl8192c. This lock is not necessary as the USB driver does not use the struct being protected, thus the lock is set only when a PCI interface is active. This bug is reported in https://bugzilla.kernel.org/show\_bug.cgi?id=42775. Reported-by: Ronald Wahl Tested-by: Ronald Wahl Signed-off-by: Larry Finger Cc: Ronald Wahl Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 68b3290b853c504ef12b9483c2d89e744d255ebc Author: Simon Graham Date: Tue Feb 7 18:07:38 2012 -0600 rtlwifi: Handle previous allocation failures when freeing device memory commit 7f66c2f93e5779625c10d262c84537427a2673ca upstream. Handle previous allocation failures when freeing device memory Signed-off-by: Simon Graham Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit b41c92b278bca642b12be17e4e01359dfd84dec5 Author: Larry Finger Date: Sat Jan 7 20:46:40 2012 -0600 rtlwifi: rtl8192c\_common: rtl8192de: Check for allocation failures commit 76a92be537f1c8c259e393632301446257ca3ea9 upstream. In https://bugzilla.redhat.com/show\_bug.cgi?id=771656, a kernel bug was triggered due to a failed skb allocation that was not checked. This event lead to an audit of all memory allocations in the complete rtlwifi family of drivers. This patch fixes the rest. Signed-off-by: Larry Finger Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 9702690fb8cbb98b3a590d15a6d7111f0e822fde Author: Gertjan van Wingerde Date: Sat Feb 11 21:58:09 2012 +0100 rt2x00: Add support for D-Link DWA-127 to rt2800usb. commit d42a179b941a9e4cc6cf41d0f3cbadd75fc48a89 upstream. This is an RT3070 based device. Reported-by: Mikhail Kryshen Signed-off-by: Gertjan van Wingerde Acked-by: Ivo van Doorn Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit eca4b1f5f26def46d2ec1bfc060b5afca7fc03d6 Author: Donald Lee Date: Wed Mar 14 15:26:33 2012 +0800 USB: serial: mos7840: Fixed MCS7820 device attach problem commit 093ea2d3a766cb8a4c4de57efec6c0a127a58792 upstream. A MCS7820 device supports two serial ports and a MCS7840 device supports four serial ports. Both devices use the same driver, but the attach function in driver was unable to correctly handle the port numbers for MCS7820 device. This problem has been fixed in this patch and this fix has been verified on x86 Linux kernel 3.2.9 with both MCS7820 and MCS7840 devices. Signed-off-by: Donald Lee Signed-off-by: Greg Kroah-Hartman commit 39b0a012f7fad219a0b072b5749ee00734e293f4 Author: Preston Fick Date: Fri Feb 24 13:42:39 2012 -0600 usb: cp210x: Update to support CP2105 and multiple interface devices commit a5360a53a7ccad5ed9ccef210b94fef13c6e5529 upstream. This patch updates the cp210x driver to support CP210x multiple interface devices devices from Silicon Labs. The existing driver always sends control requests to interface 0, which is hardcoded in the usb\_control\_msg function calls. This only allows for single interface devices to be used, and causes a bug when using ports on an interface other than 0 in the multiple interface devices. Here are the changes included in this patch: - Updated the device list to contain the Silicon Labs factory default VID/PID for multiple interface CP210x devices - Created a cp210x\_port\_private struct created for each port on startup, this struct holds the interface number - Added a cp210x\_release function to clean up the cp210x\_port\_private memory created on startup - Modified usb\_get\_config and usb\_set\_config to get a pointer to the cp210x\_port\_private struct, and use the interface number there in the usb\_control\_message wIndex param Signed-off-by: Preston Fick Signed-off-by: Greg Kroah-Hartman commit 3f2ce819b522ecfc34b4315c74adee520a7c2a34 Author: Scott Dial Date: Fri Feb 24 19:04:09 2012 -0500 usb-serial: Add support for the Sealevel SeaLINK+8 2038-ROHS device commit 6d161b99f875269ad4ffa44375e1e54bca6fd02e upstream. This patch adds new device IDs to the ftdi\_sio module to support the new Sealevel SeaLINK+8 2038-ROHS device. Signed-off-by: Scott Dial Signed-off-by: Greg Kroah-Hartman commit 8061f8a13bad35508405253e5afacff2db67dc0c Author: Dan Williams Date: Fri Feb 24 13:08:43 2012 -0600 USB: qcserial: don't grab QMI port on Gobi 1000 devices commit c192c8e71a2ded01170c1a992cd21aaedc822756 upstream. Gobi 1000 devices have a different port layout, which wasn't respected by the current driver, and thus it grabbed the QMI/net port. In the near future we'll be attaching another driver to the QMI/net port for these devices (cdc-wdm and qmi\_wwan) so make sure the qcserial driver doesn't claim them. This patch also prevents qcserial from binding to interfaces 0 and 1 on 1K devices because those interfaces do not respond. Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 39743546904440d48792444ab50db081f72a8be9 Author: Josh Boyer Date: Mon Feb 20 15:34:34 2012 -0500 USB: ums\_realtek: do not use stack memory for DMA in \_\_do\_config\_autodelink commit 4898e07174b79013afd2b422ef6c4336ef8e6783 upstream. \_\_do\_config\_autodelink passes the data variable to the transport function. If the calling functions pass a stack variable, this will eventually trigger a DMA-API debug backtrace for mapping stack memory in the DMA buffer. Fix this by calling kmemdup for the passed data instead. Signed-off-by: Josh Boyer Signed-off-by: Greg Kroah-Hartman commit e424058e1d48695eb6aeb48037f89e28995e5a0b Author: Peter Chen Date: Thu Feb 16 09:41:52 2012 +0800 usb: Fix build error due to dma\_mask is not at pdev\_archdata at ARM commit e90fc3cb087ce5c5f81e814358222cd6d197b5db upstream. When build i.mx platform with imx\_v6\_v7\_defconfig, and after adding USB Gadget support, it has below build error: CC drivers/usb/host/fsl-mph-dr-of.o drivers/usb/host/fsl-mph-dr-of.c: In function 'fsl\_usb2\_device\_register': drivers/usb/host/fsl-mph-dr-of.c:97: error: 'struct pdev\_archdata' has no member named 'dma\_mask' It has discussed at: http://www.spinics.net/lists/linux-usb/msg57302.html For PowerPC, there is dma\_mask at struct pdev\_archdata, but there is no dma\_mask at struct pdev\_archdata for ARM. The pdev\_archdata is related to specific platform, it should NOT be accessed by cross platform drivers, like USB. The code for pdev\_archdata should be useless, as for PowerPC, it has already gotten the value for pdev->dev.dma\_mask at function arch\_setup\_pdev\_archdata of arch/powerpc/kernel/setup-common.c. Tested-by: Ramneek Mehresh Signed-off-by: Peter Chen Signed-off-by: Greg Kroah-Hartman commit 89469a5e4603f6e648add57e312c69704ff42617 Author: Peter Chen Date: Thu Feb 16 09:36:25 2012 +0800 usb: fsl\_udc\_core: Fix scheduling while atomic dump message commit c5cc5ed86667d4ae74fe40ee4ed893f4b46aba05 upstream. When loading g\_ether gadget, there is below message: Backtrace: \[<80012248>\] (dump\_backtrace+0x0/0x10c) from \[<803cb42c>\] (dump\_stack+0x18/0x1c) r7:00000000 r6:80512000 r5:8052bef8 r4:80513f30 \[<803cb414>\] (dump\_stack+0x0/0x1c) from \[<8000feb4>\] (show\_regs+0x44/0x50) \[<8000fe70>\] (show\_regs+0x0/0x50) from \[<8004c840>\] (\_\_schedule\_bug+0x68/0x84) r5:8052bef8 r4:80513f30 \[<8004c7d8>\] (\_\_schedule\_bug+0x0/0x84) from \[<803cd0e4>\] (\_\_schedule+0x4b0/0x528) r5:8052bef8 r4:809aad00 \[<803ccc34>\] (\_\_schedule+0x0/0x528) from \[<803cd214>\] (\_cond\_resched+0x44/0x58) \[<803cd1d0>\] (\_cond\_resched+0x0/0x58) from \[<800a9488>\] (dma\_pool\_alloc+0x184/0x250) r5:9f9b4000 r4:9fb4fb80 \[<800a9304>\] (dma\_pool\_alloc+0x0/0x250) from \[<802a8ad8>\] (fsl\_req\_to\_dtd+0xac/0x180) \[<802a8a2c>\] (fsl\_req\_to\_dtd+0x0/0x180) from \[<802a8ce4>\] (fsl\_ep\_queue+0x138/0x274) \[<802a8bac>\] (fsl\_ep\_queue+0x0/0x274) from \[<7f004328>\] (composite\_setup+0x2d4/0xfac \[g\_ether\]) \[<7f004054>\] (composite\_setup+0x0/0xfac \[g\_ether\]) from \[<802a9bb4>\] (fsl\_udc\_irq+0x8dc/0xd38) \[<802a92d8>\] (fsl\_udc\_irq+0x0/0xd38) from \[<800704f8>\] (handle\_irq\_event\_percpu+0x54/0x188) \[<800704a4>\] (handle\_irq\_event\_percpu+0x0/0x188) from \[<80070674>\] (handle\_irq\_event+0x48/0x68) \[<8007062c>\] (handle\_irq\_event+0x0/0x68) from \[<800738ec>\] (handle\_level\_irq+0xb4/0x138) r5:80514f94 r4:80514f40 \[<80073838>\] (handle\_level\_irq+0x0/0x138) from \[<8006ffa4>\] (generic\_handle\_irq+0x38/0x44) r7:00000012 r6:80510b1c r5:80529860 r4:80512000 \[<8006ff6c>\] (generic\_handle\_irq+0x0/0x44) from \[<8000f4c4>\] (handle\_IRQ+0x54/0xb4) \[<8000f470>\] (handle\_IRQ+0x0/0xb4) from \[<800085b8>\] (tzic\_handle\_irq+0x64/0x94) r9:412fc085 r8:00000000 r7:80513f30 r6:00000001 r5:00000000 r4:00000000 \[<80008554>\] (tzic\_handle\_irq+0x0/0x94) from \[<8000e680>\] (\_\_irq\_svc+0x40/0x60) The reason of above dump message is calling dma\_poll\_alloc with can-schedule mem\_flags at atomic context. To fix this problem, below changes are made: - fsl\_req\_to\_dtd doesn't need to be protected by spin\_lock\_irqsave, as struct usb\_request can be access at process context. Move lock to beginning of hardware visit (fsl\_queue\_td). - Change the memory flag which using to allocate dTD descriptor buffer, the memory flag can be from gadget layer. It is tested at i.mx51 bbg board with g\_mass\_storage, g\_ether, g\_serial. Signed-off-by: Peter Chen Acked-by: Li Yang Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 078ed3398254fa4217ac8b79265b6f3772ba193e Author: Ben Hutchings Date: Sun Feb 12 06:02:43 2012 +0000 cdc-wdm: Don't clear WDM\_READ unless entire read buffer is emptied commit b7a205545345578712611106b371538992e142ff upstream. The WDM\_READ flag is cleared later iff desc->length is reduced to 0. Signed-off-by: Ben Hutchings Tested-by: Bjørn Mork Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit dd47107e8aff416f9a91ec710c9f3241199adb10 Author: Ben Hutchings Date: Sun Feb 12 06:00:41 2012 +0000 cdc-wdm: Fix more races on the read path commit 711c68b3c0f7a924ffbee4aa962d8f62b85188ff upstream. We must not allow the input buffer length to change while we're shuffling the buffer contents. We also mustn't clear the WDM\_READ flag after more data might have arrived. Therefore move both of these into the spinlocked region at the bottom of wdm\_read(). When reading desc->length without holding the iuspin lock, use ACCESS\_ONCE() to ensure the compiler doesn't re-read it with inconsistent results. Signed-off-by: Ben Hutchings Tested-by: Bjørn Mork Cc: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit 272ca2f1a3750a39991c73e8ddddf977d5aec846 Author: Johan Hovold Date: Fri Feb 10 13:20:49 2012 +0100 USB: serial: fix console error reporting commit 548dd4b6da8a8e428453d55f7fa7b8a46498d147 upstream. Do not report errors in write path if port is used as a console as this may trigger the same error (and error report) resulting in a loop. Reported-by: Stephen Hemminger Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ff1f5193fa906fbb93a7641232d40c1f40c6d918 Author: Liz Clark Date: Thu Mar 15 10:33:29 2012 -0700 TTY: Wrong unicode value copied in con\_set\_unimap() commit 4a4c61b7ce26bfc9d49ea4bd121d52114bad9f99 upstream. Bugzilla 40012: PIO\_UNIMAP bug: error updating Unicode-to-font map https://bugzilla.kernel.org/show\_bug.cgi?id=40012 The unicode font map for the virtual console is a 32x32x64 table which allocates rows dynamically as entries are added. The unicode value increases sequentially and should count all entries even in empty rows. The defect is when copying the unicode font map in con\_set\_unimap(), the unicode value is not incremented properly. The wrong unicode value is entered in the new font map. Signed-off-by: Liz Clark Signed-off-by: Greg Kroah-Hartman commit d3abff4f339019cd208ebefa35ab9b7fcaad93b1 Author: Dan Carpenter Date: Wed Mar 7 13:05:00 2012 +0300 tty: moxa: fix bit test in moxa\_start() commit 58112dfbfe02d803566a2c6c8bd97b5fa3c62cdc upstream. This is supposed to be doing a shift before the comparison instead of just doing a bitwise AND directly. The current code means the start() just returns without doing anything. Signed-off-by: Dan Carpenter Acked-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman commit e484ce645b87df21fcaf8a22453ecff0cb664c09 Author: Cousson, Benoit Date: Tue Feb 28 18:22:12 2012 +0100 tty: serial: OMAP: Fix oops due to NULL pdata in DT boot commit a5f43138da9beddc46b00ec31d167143a7176683 upstream. The following commit: be4b0281956c5cae4f63f31f11d07625a6988766 (tty: serial: OMAP: block idle while the UART is transferring data in PIO mode), is introducing an oops if OMAP is booted using device tree blob because the pdata will not be initialized. Check if pdata is set before de-referencing it. Signed-off-by: Benoit Cousson Reviewed-by: Paul Walmsley Signed-off-by: Greg Kroah-Hartman commit 296dd34283b5e5c51b654ccb600e0c1a84c6e22b Author: Masami Ichikawa Date: Tue Feb 21 07:43:50 2012 +0900 sysfs: Fix memory leak in sysfs\_sd\_setsecdata(). commit 93518dd2ebafcc761a8637b2877008cfd748c202 upstream. This patch fixies follwing two memory leak patterns that reported by kmemleak. sysfs\_sd\_setsecdata() is called during sys\_lsetxattr() operation. It checks sd->s\_iattr is NULL or not. Then if it is NULL, it calls sysfs\_init\_inode\_attrs() to allocate memory. That code is this. iattrs = sd->s\_iattr; if (!iattrs) iattrs = sysfs\_init\_inode\_attrs(sd); The iattrs recieves sysfs\_init\_inode\_attrs()'s result, but sd->s\_iattr doesn't know the address. so it needs to set correct address to sd->s\_iattr to free memory in other function. unreferenced object 0xffff880250b73e60 (size 32): comm "systemd", pid 1, jiffies 4294683888 (age 94.553s) hex dump (first 32 bytes): 73 79 73 74 65 6d 5f 75 3a 6f 62 6a 65 63 74 5f system\_u:object\_ 72 3a 73 79 73 66 73 5f 74 3a 73 30 00 00 00 00 r:sysfs\_t:s0.... backtrace: \[\] kmemleak\_alloc+0x73/0x98 \[\] \_\_kmalloc+0x100/0x12c \[\] context\_struct\_to\_string+0x106/0x210 \[\] security\_sid\_to\_context\_core+0x10b/0x129 \[\] security\_sid\_to\_context+0x10/0x12 \[\] selinux\_inode\_getsecurity+0x7d/0xa8 \[\] selinux\_inode\_getsecctx+0x22/0x2e \[\] security\_inode\_getsecctx+0x16/0x18 \[\] sysfs\_setxattr+0x96/0x117 \[\] \_\_vfs\_setxattr\_noperm+0x73/0xd9 \[\] vfs\_setxattr+0x83/0xa1 \[\] setxattr+0xcf/0x101 \[\] sys\_lsetxattr+0x6a/0x8f \[\] system\_call\_fastpath+0x16/0x1b \[\] 0xffffffffffffffff unreferenced object 0xffff88024163c5a0 (size 96): comm "systemd", pid 1, jiffies 4294683888 (age 94.553s) hex dump (first 32 bytes): 00 00 00 00 ed 41 00 00 00 00 00 00 00 00 00 00 .....A.......... 00 00 00 00 00 00 00 00 0c 64 42 4f 00 00 00 00 .........dBO.... backtrace: \[\] kmemleak\_alloc+0x73/0x98 \[\] kmem\_cache\_alloc\_trace+0xc4/0xee \[\] sysfs\_init\_inode\_attrs+0x2a/0x83 \[\] sysfs\_setxattr+0xbf/0x117 \[\] \_\_vfs\_setxattr\_noperm+0x73/0xd9 \[\] vfs\_setxattr+0x83/0xa1 \[\] setxattr+0xcf/0x101 \[\] sys\_lsetxattr+0x6a/0x8f \[\] system\_call\_fastpath+0x16/0x1b \[\] 0xffffffffffffffff \` Signed-off-by: Masami Ichikawa Signed-off-by: Greg Kroah-Hartman commit 0a5ced57efbd5a9551ee676284cf14bbe3cf9d96 Author: Thomas Gleixner Date: Wed Feb 15 12:08:34 2012 +0100 futex: Cover all PI opcodes with cmpxchg enabled check commit 59263b513c11398cd66a52d4c5b2b118ce1e0359 upstream. Some of the newer futex PI opcodes do not check the cmpxchg enabled variable and call unconditionally into the handling functions. Cover all PI opcodes in a separate check. Signed-off-by: Thomas Gleixner Cc: Peter Zijlstra Cc: Darren Hart Signed-off-by: Greg Kroah-Hartman commit a41390f5657a1de04acb4c99c089a678030aede5 Author: Orjan Friberg Date: Wed Mar 7 17:16:14 2012 +0100 USB: gadget: Make g\_hid device class conform to spec. commit 33d2832ab0149a26418d360af3c444969a63fb28 upstream. HID devices should specify this in their interface descriptors, not in the device descriptor. This fixes a "missing hardware id" bug under Windows 7 with a VIA VL800 (3.0) controller. Signed-off-by: Orjan Friberg Cc: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 5c9e6ce0ca99917cda4a9a07b5442c793f98cfea Author: Thomas Faber Date: Fri Mar 2 09:41:50 2012 +0100 usb: gadgetfs: return number of bytes on ep0 read request commit 85b4b3c8c189e0159101f7628a71411af072ff69 upstream. A read from GadgetFS endpoint 0 during the data stage of a control request would always return 0 on success (as returned by wait\_event\_interruptible) despite having written data into the user buffer. This patch makes it correctly set the return value to the number of bytes read. Signed-off-by: Thomas Faber Signed-off-by: Greg Kroah-Hartman commit 6d59824b8c2ea2b64e6b532628e1a5bdcd3c6487 Author: Kuninori Morimoto Date: Mon Feb 20 17:35:50 2012 -0800 usb: renesas\_usbhs: bugfix: add .release function to gpriv->gadget.dev commit 3b2a2e47174cd978258bbb0fdf2e2b1b5ec2144c upstream. This patch fixup below warning on device\_unregister() renesas\_usbhs renesas\_usbhs.1: host probed renesas\_usbhs renesas\_usbhs.1: gadget probed renesas\_usbhs renesas\_usbhs.1: irq request err ------------\[ cut here \]------------ WARNING: at ${LINUX}/drivers/base/core.c:1) Device 'gadget' does not have a release() function, it is broken and must be fi. Modules linked in: \[\] (unwind\_backtrace+0x0/0xe4) from \[\] (warn\_slowpath\_commo) \[\] (warn\_slowpath\_common+0x4c/0x64) from \[\] (warn\_slowpath\_) \[\] (warn\_slowpath\_fmt+0x2c/0x3c) from \[\] (device\_release+0x) \[\] (device\_release+0x70/0x84) from \[\] (kobject\_cleanup+0x58) \[\] (kobject\_cleanup+0x58/0x6c) from \[\] (usbhs\_mod\_gadget\_re) \[\] (usbhs\_mod\_gadget\_remove+0x3c/0x6c) from \[\] (usbhs\_mod\_p) \[\] (usbhs\_mod\_probe+0x68/0x80) from \[\] (usbhs\_probe+0x1cc/0) ... Signed-off-by: Kuninori Morimoto Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 528169bfacc07e1536bdabdc1ef42deaa5c6ae60 Author: Ido Shayevitz Date: Wed Feb 8 13:56:48 2012 +0200 usb: gadget: Clear usb\_endpoint\_descriptor inside the struct usb\_ep on disable commit f9c56cdd3905c96c600456203637bd7ec8ec6383 upstream. This fix a bug in f\_serial, which expect the ep->desc to be NULL after disabling an endpoint. Signed-off-by: Ido Shayevitz Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 441a59b9855439ef181654638ec9fd9e12a2f694 Author: Supriya Karanth Date: Fri Feb 17 14:54:52 2012 +0530 usb: musb: Reselect index reg in interrupt context commit 39287076e46d2c19aaceaa6f0a44168ae4d257ec upstream. musb INDEX register is getting modified/corrupted during temporary un-locking in a SMP system. Set this register with proper value after re-acquiring the lock Scenario: --------- CPU1 is handling a data transfer completion interrupt received for the CLASS1 EP CPU2 is handling a CLASS2 thread which is queuing data to musb for transfer Below is the error sequence: CPU1 | CPU2 -------------------------------------------------------------------- Data transfer completion inter- | rupt recieved. | | musb INDEX reg set to CLASS1 EP | | musb LOCK is acquired. | | | CLASS2 thread queues data. | | CLASS2 thread tries to acquire musb | LOCK but lock is already taken by | CLASS1, so CLASS2 thread is | spinning. | From Interrupt Context musb | giveback function is called | | The giveback function releases | CLASS2 thread now acquires LOCK LOCK | | ClASS1 Request's completion cal-| ClASS2 schedules the data transfer and lback is called | sets the MUSB INDEX to Class2 EP number | Interrupt handler for CLASS1 EP | tries to acquire LOCK and is | spinning | | Interrupt for Class1 EP acquires| Class2 completes the scheduling etc and the MUSB LOCK | releases the musb LOCK | Interrupt for Class1 EP schedul-| es the next data transfer | but musb INDEX register is still| set to CLASS2 EP | Since the MUSB INDEX register is set to a different endpoint, we read and modify the wrong registers. Hence data transfer will not happen properly. This results in unpredictable behavior So, the MUSB INDEX register is set to proper value again when interrupt re-acquires the lock Signed-off-by: Supriya Karanth Signed-off-by: Praveena Nadahally Reviewed-by: srinidhi kasagar Signed-off-by: Felipe Balbi commit efc73b799002f9e3686f614c6cbdfaa64b3a59df Author: Gerard Snitselaar Date: Thu Mar 15 01:50:39 2012 -0700 staging: vme: fix section mismatches in linux-next 20120314 commit bf3a85be67068a0f55804349e6e1dce80008c45c upstream. pio2\_gpio\_init() annotated with \_\_init, but called by pio2\_probe() which is annotated \_\_devinit. pio2\_gpio\_exit() is annotated \_\_exit, but is called by pio2\_probe() and by pio2\_remove() which is annotated \_\_devexit. Signed-off-by: Gerard Snitselaar Signed-off-by: Greg Kroah-Hartman commit 002f07da0d6005aa62c48b41ef05ad439aded029 Author: Anton Tikhomirov Date: Thu Feb 23 15:38:46 2012 +0900 usb: dwc3: use proper function for setting endpoint name commit 27a78d6a283d6782438f72306746afe4bf44c215 upstream. It's wrong to use the size of array as an argument for strncat. Memory corruption is possible. strlcat is exactly what we need here. Signed-off-by: Anton Tikhomirov Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 6b6cf9641fea221749940b7ebffb99bae646e544 Author: Paul Zimmerman Date: Fri Feb 17 14:10:16 2012 -0800 usb: dwc3: fix bogus test in dwc3\_gadget\_start\_isoc commit 9bafa56c7cee5c6fa68de5924220abb220c7e229 upstream. Zero is a valid value for a microframe number. So remove the bogus test for non-zero in dwc3\_gadget\_start\_isoc(). Signed-off-by: Paul Zimmerman Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 80ce60a3505bbe720b866d0018c06f6e7d6b33b9 Author: Paul Zimmerman Date: Wed Feb 15 13:35:06 2012 +0200 usb: dwc3: gadget: don't wrap around the TRB poll on non-ISOC commit 8d62cd65d74d0e241b3a152f7347bb66126b705b upstream. If we have a non-ISOC endpoint, we will not have a Link TRB pointing to the beginning of the TRB pool. On such endpoints, we don't want to let the driver wrap around the TRB pool otherwise controller will hang waiting for a valid TRB. Signed-off-by: Paul Zimmerman Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 23ed051089a3b1ec7e3865a4084438a201a23c03 Author: Dan Carpenter Date: Sat Feb 4 16:37:14 2012 +0300 usb: dwc3: make dwc3\_get\_device\_id() return the id commit 075cd14d2a8d35afc39ad28fc7b968275881266b upstream. We always return zero instead of the id we found. Signed-off-by: Dan Carpenter Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman commit 04a641c88adf765ab7c0951076c50866477c6883 Author: Larry Finger Date: Sun Feb 26 22:08:36 2012 -0600 staging: r8712u: Fix regression in signal level after commit c6dc001 commit da3e6ec2f443ac00aa623c5921e3521f5f38efe4 upstream. In commit c6dc001 "staging: r8712u: Merging Realtek's latest (v2.6.6). Various fixes", the returned qual.qual member of the iw\_statistics struct was changed. For strong signals, this change made no difference; however for medium and weak signals it results in a low signal that shows considerable fluctuation, When using wicd for a medium-strength AP, the value reported in the status line is reduced from 100% to 60% by this bug. This problem is reported in https://bugzilla.kernel.org/show\_bug.cgi?id=42826. Reported-and-tested-by: Robert Crawford Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman commit 4b59aa365b15c209f0b05cfcf9a72f2258b22db4 Author: Larry Finger Date: Sat Feb 25 18:10:20 2012 -0600 staging: r8712u: Fix regression introduced by commit a5ee652 commit 9f4bc8cf3fe750ed093856a5f5d41c11cc12ad22 upstream. In commit a5ee652 "staging: r8712u: Interface-state not fully tracked", the private boolean "bup" was set false when the interface was brought down, as that seemed appropriate. This change has not caused any problems when using NetworkManager or manual control of the device; however, when wicd control is used, there is a locking problem in wpa\_supplicant, as shown in https://bugzilla.kernel.org/show\_bug.cgi?id=42818. This fix reverts the only code change in commit a5ee652. My analysis is that "bup" is badly named. In its present form, it seems to indicate the up/down state of the device, but its usage is more consistent with an initialized/uninitialized state. That problem will be addressed in a later patch. Note: Commit 8c213fa, which introdued asynchronous firmware loading for this driver, exposed this bug to a greater extent. That bug is addressed in the next patch in this series. This bug is also responsible for the bug in https://bugzilla.kernel.org/show\_bug.cgi?id=42815. and this bug is also part of the problems discussed at https://bugs.archlinux.org/task/27996#comment89950. Tested-by: Alberto Lago Ballesteros Tested-by: Adrian Signed-off-by: Larry Finger Signed-off-by: Greg Kroah-Hartman commit 7464cb3047268eb2f08b41c403c5cf49e9309e5d Author: Shengzhou Liu Date: Thu Feb 16 18:02:20 2012 +0800 powerpc/usb: fix bug of kernel hang when initializing usb commit 28c56ea1431421dec51b7b229369e991481453df upstream. If USB UTMI PHY is not enable, writing to portsc register will lead to kernel hang during boot up. Signed-off-by: Shengzhou Liu Reported-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman commit 32842596453b639b34ddad67c5a44633ab478216 Author: Michał Wróbel Date: Thu Mar 15 17:24:04 2012 +0100 USB: ftdi\_sio: new PID: LUMEL PD12 commit 57e596f3af88ef52dea9640ed5e34ecd38893a02 upstream. Signed-off-by: Michał Wróbel Signed-off-by: Greg Kroah-Hartman commit 4edc5aa67b273975609c0554683193dee5608bb3 Author: Jim Paris Date: Wed Mar 14 17:54:25 2012 -0400 USB: ftdi\_sio: add support for FT-X series devices commit dc0827c128c0ee5a58b822b99d662b59f4b8e970 upstream. Add PID 0x6015, corresponding to the new series of FT-X chips (FT220XD, FT201X, FT220X, FT221X, FT230X, FT231X, FT240X). They all appear as serial devices, and seem indistinguishable except for the default product string stored in their EEPROM. The baudrate generation matches FT232RL devices. Tested with a FT201X and FT230X at various baudrates (100 - 3000000). Sample dmesg: ftdi\_sio: v1.6.0:USB FTDI Serial Converters Driver usb 2-1: new full-speed USB device number 6 using ohci\_hcd usb 2-1: New USB device found, idVendor=0403, idProduct=6015 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 2-1: Product: FT230X USB Half UART usb 2-1: Manufacturer: FTDI usb 2-1: SerialNumber: DC001WI6 ftdi\_sio 2-1:1.0: FTDI USB Serial Device converter detected drivers/usb/serial/ftdi\_sio.c: ftdi\_sio\_port\_probe drivers/usb/serial/ftdi\_sio.c: ftdi\_determine\_type: bcdDevice = 0x1000, bNumInterfaces = 1 usb 2-1: Detected FT-X usb 2-1: Number of endpoints 2 usb 2-1: Endpoint 1 MaxPacketSize 64 usb 2-1: Endpoint 2 MaxPacketSize 64 usb 2-1: Setting MaxPacketSize 64 drivers/usb/serial/ftdi\_sio.c: read\_latency\_timer drivers/usb/serial/ftdi\_sio.c: write\_latency\_timer: setting latency timer = 1 drivers/usb/serial/ftdi\_sio.c: create\_sysfs\_attrs drivers/usb/serial/ftdi\_sio.c: sysfs attributes for FT-X usb 2-1: FTDI USB Serial Device converter now attached to ttyUSB0 Signed-off-by: Jim Paris Signed-off-by: Greg Kroah-Hartman commit 71d4df2bd96a9d4ac504e49767ee5c754008fe24 Author: Michał Wróbel Date: Fri Mar 9 14:40:18 2012 +0100 USB: ftdi\_sio: new PID: Distortec JTAG-lock-pick commit 47594d5528f28a4c025c2955c68104c75815637c upstream. Signed-off-by: Michał Wróbel Signed-off-by: Greg Kroah-Hartman commit 2aa058b861742f92f8c1d7be3e8e63111b8722e0 Author: Bruno Thomsen Date: Sun Mar 4 15:19:14 2012 +0100 USB: Microchip VID mislabeled as Hornby VID in ftdi\_sio. commit c1cee1d84001815a1b4321c49b995254c0df3100 upstream. Microchip VID (0x04d8) was mislabeled as Hornby VID according to USB-IDs. A Full Speed USB Demo Board PID (0x000a) was mislabeled as Hornby Elite (an Digital Command Controller Console for model railways). Most likely the Hornby based their design on PIC18F87J50 Full Speed USB Demo Board. Signed-off-by: Bruno Thomsen Signed-off-by: Greg Kroah-Hartman commit 9aa7539973b0282e83319c4f388f1a2d47fe27dc Author: Peter Korsgaard Date: Wed Feb 29 10:05:37 2012 +0100 USB: ftdi\_sio: add support for BeagleBone rev A5+ commit 444aa7fa9bd752d19ce472d3e02558b987c3cc67 upstream. BeagleBone changed to the default FTDI 0403:6010 id in rev A5 to make life easier for Windows users, so we need a similar workaround as the Calao board to support it. Signed-off-by: Peter Korsgaard Signed-off-by: Greg Kroah-Hartman commit f3d30caa9579a07abc37ba0faf6f16eefc887919 Author: Greg Kroah-Hartman Date: Tue Feb 28 09:20:09 2012 -0800 USB: ftdi\_sio: fix problem when the manufacture is a NULL string commit 656d2b3964a9d0f9864d472f8dfa2dd7dd42e6c0 upstream. On some misconfigured ftdi\_sio devices, if the manufacturer string is NULL, the kernel will oops when the device is plugged in. This patch fixes the problem. Reported-by: Wojciech M Zabolotny Tested-by: Wojciech M Zabolotny Signed-off-by: Greg Kroah-Hartman commit 2a8003111dc4b1ffaa5058ed908b10ea9fe9498d Author: David Daney Date: Thu Feb 23 11:19:31 2012 -0800 staging/octeon: Fix PHY binding in octeon-ethernet driver. commit b5c19ca8014aa5151712274d5e70c3666a8918c1 upstream. Commit d6c25be (mdio-octeon: use an unique MDIO bus name.) changed the names used to refer to MDIO buses. The ethernet driver must be changed to match, so that the PHY drivers can be attached. Signed-off-by: David Daney Acked-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman commit 7e6373b36698068f2b0bb81ba4bdbf73c60096c5 Author: Andrea Righi Date: Mon Feb 20 13:11:49 2012 +0100 staging: zcache: avoid AB-BA deadlock condition commit cfbc6a92212e74b07aa76c9e2f20c542e36077fb upstream. Commit 9256a47 fixed a deadlock condition, being sure that the buddy list spinlock is always taken before the page spinlock. However in zbud\_free\_and\_delist() locking order is the opposite (page lock -> list lock). Possible unsafe locking scenario (reported by lockdep): CPU0 CPU1 ---- ---- lock(&(&zbpg->lock)->rlock); lock(zbud\_budlists\_spinlock); lock(&(&zbpg->lock)->rlock); lock(zbud\_budlists\_spinlock); Fix by grabbing the locks in opposite order in zbud\_free\_and\_delist(). Signed-off-by: Andrea Righi Signed-off-by: Greg Kroah-Hartman commit dc8e82a35a704d43778657008b0aed4087c1c9ab Author: Paul E. McKenney Date: Wed Mar 7 17:54:00 2012 +0400 staging: android/lowmemorykiller: Don't unregister notifier from atomic context commit 1eda5166c7640092f512138be6899d050c3d62ed upstream. The lowmemorykiller registers an atomic notifier for notfication of when the task is freed. From this atomic notifier callback, it removes the atomic notifier via task\_free\_unregister(). This is incorrect because atomic\_notifier\_chain\_unregister() calls syncronize\_rcu(), which can sleep, which shouldn't be done from an atomic notifier. Fix this by registering the notifier during init, and only unregister it if the lowmemorykiller is unloaded. Rebased to -next by Paul E. McKenney. Rebased to -next again by Anton Vorontsov. Signed-off-by: Rabin Vincent Signed-off-by: Christian Bejram Signed-off-by: Paul E. McKenney Reported-by: John Stultz Signed-off-by: Anton Vorontsov Signed-off-by: Greg Kroah-Hartman commit 408fae5e53fb7861121fce5d0ee316a750178002 Author: Bjørn Mork Date: Fri Mar 16 15:41:26 2012 +0100 USB: option: add ZTE MF820D commit 5889d3d4209c1050b4a3c96c41faf6c0976a4acf upstream. This device presents a total of 5 interfaces with ff/ff/ff class/subclass/protocol. The last one of these is verified to be a QMI/wwan combined interface which should be handled by the qmi\_wwan driver, so we blacklist it here. Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 5137c924b6e442749e3f1871c5c6bb31f70a48b5 Author: Bjørn Mork Date: Fri Mar 16 12:56:44 2012 +0100 USB: option: make interface blacklist work again commit 963940cf472d76eca2d36296e461202cc6997352 upstream. commit 0d905fd "USB: option: convert Huawei K3765, K4505, K4605 reservered interface to blacklist" accidentally ANDed two blacklist tests by leaving out a return. This was not noticed because the two consecutive bracketless if statements made it syntactically correct. Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 233f38e477668cbc2c41b7307fcca792d876c206 Author: Daniele Palmas Date: Wed Feb 29 15:32:05 2012 +0100 USB: option driver: adding support for Telit CC864-SINGLE, CC864-DUAL and DE910-DUAL modems commit 7204cf584836c24b4b06e4ad4a8e6bb8ea84908e upstream. Adding PID for Telit CC864-SINGLE, CC864-DUAL and DE910-DUAL modems Signed-off-by: Daniele Palmas Signed-off-by: Greg Kroah-Hartman commit 2c154877a1bbeaaec5b842d5eb7825373f1e7b3a Author: Meng Zhang Date: Mon Feb 27 08:24:19 2012 +0100 USB: option: Add MediaTek MT6276M modem&app interfaces commit 0d8520a1d7f43328bc7085d4244d93c595064157 upstream. Add MEDIATEK products to Option driver Signed-off-by: Meng Zhang Signed-off-by: Matthias Urlichs Signed-off-by: Greg Kroah-Hartman

Tag

#bios