commit cc8605070a58f12b79c62f369a0446d89a7ca337 Author: Greg Kroah-Hartman Date: Mon Dec 17 11:14:54 2012 -0800 Linux 3.7.1 commit 53730b4c10781998bb872fce768f578ab4e09aec Author: Kevin McKinney Date: Mon Nov 12 22:20:30 2012 -0500 Staging: bcm: Add two products and remove an existing product. commit 4f29ef050848245f7c180b95ccf67dfcd76b1fd8 upstream. This patch adds two new products and modifies the device id table to include them. In addition, product of 0xbccd - BCM_USB_PRODUCT_ID_SM250 is removed because Beceem, ZTE, Sprint use this id for block devices. Reported-by: Muhammad Minhazul Haque Signed-off-by: Kevin McKinney Signed-off-by: Greg Kroah-Hartman commit 5ebf81ae05c971619ab8a71504b47a4bc30efbb2 Author: Eric Dumazet Date: Thu Oct 18 04:55:36 2012 -0700 rcu: Fix batch-limit size problem commit 878d7439d0f45a95869e417576774673d1fa243f upstream. Commit 29c00b4a1d9e27 (rcu: Add event-tracing for RCU callback invocation) added a regression in rcu_do_batch() Under stress, RCU is supposed to allow to process all items in queue, instead of a batch of 10 items (blimit), but an integer overflow makes the effective limit being 1. So, unless there is frequent idle periods (during which RCU ignores batch limits), RCU can be forced into a state where it cannot keep up with the callback-generation rate, eventually resulting in OOM. This commit therefore converts a few variables in rcu_do_batch() from int to long to fix this problem, along with the module parameters controlling the batch limits. Signed-off-by: Eric Dumazet Signed-off-by: Paul E. McKenney Signed-off-by: Greg Kroah-Hartman commit 2083ca13781c4e88049b530c954dd48b3f30ddf2 Author: Alan Stern Date: Thu Nov 8 10:17:01 2012 -0500 USB: EHCI: bugfix: urb->hcpriv should not be NULL commit 2656a9abcf1ec8dd5fee6a75d6997a0f2fa0094e upstream. This patch (as1632b) fixes a bug in ehci-hcd. The USB core uses urb->hcpriv to determine whether or not an URB is active; host controller drivers are supposed to set this pointer to a non-NULL value when an URB is queued. However ehci-hcd sets it to NULL for isochronous URBs, which defeats the check in usbcore. In itself this isn't a big deal. But people have recently found that certain sequences of actions will cause the snd-usb-audio driver to reuse URBs without waiting for them to complete. In the absence of proper checking by usbcore, the URBs get added to their endpoint list twice. This leads to list corruption and a system freeze. The patch makes ehci-hcd assign a meaningful value to urb->hcpriv for isochronous URBs. Improving robustness always helps. Signed-off-by: Alan Stern Reported-by: Artem S. Tashkinov Reported-by: Christof Meerwald Signed-off-by: Greg Kroah-Hartman commit 9eb7f6942b507dc7f94ae380e025cd610d2de269 Author: Zheng Liu Date: Thu Nov 8 16:58:46 2012 -0800 perf test: fix a build error on builtin-test commit 12f8f74b2a4d26c4facfa7ef99487cf0930f6ef7 upstream. Recently I build perf and get a build error on builtin-test.c. The error is as following: $ make CC perf.o CC builtin-test.o cc1: warnings being treated as errors builtin-test.c: In function ‘sched__get_first_possible_cpu’: builtin-test.c:977: warning: implicit declaration of function ‘CPU_ALLOC’ builtin-test.c:977: warning: nested extern declaration of ‘CPU_ALLOC’ builtin-test.c:977: warning: assignment makes pointer from integer without a cast builtin-test.c:978: warning: implicit declaration of function ‘CPU_ALLOC_SIZE’ builtin-test.c:978: warning: nested extern declaration of ‘CPU_ALLOC_SIZE’ builtin-test.c:979: warning: implicit declaration of function ‘CPU_ZERO_S’ builtin-test.c:979: warning: nested extern declaration of ‘CPU_ZERO_S’ builtin-test.c:982: warning: implicit declaration of function ‘CPU_FREE’ builtin-test.c:982: warning: nested extern declaration of ‘CPU_FREE’ builtin-test.c:992: warning: implicit declaration of function ‘CPU_ISSET_S’ builtin-test.c:992: warning: nested extern declaration of ‘CPU_ISSET_S’ builtin-test.c:998: warning: implicit declaration of function ‘CPU_CLR_S’ builtin-test.c:998: warning: nested extern declaration of ‘CPU_CLR_S’ make: *** [builtin-test.o] Error 1 This problem is introduced in 3e7c439a. CPU_ALLOC and related macros are missing in sched__get_first_possible_cpu function. In 54489c18, commiter mentioned that CPU_ALLOC has been removed. So CPU_ALLOC calls in this function are removed to let perf to be built. Signed-off-by: Vinson Lee Signed-off-by: Zheng Liu Cc: David Ahern Cc: Frederic Weisbecker Cc: Mike Galbraith Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Vinson Lee Cc: Zheng Liu Link: http://lkml.kernel.org/r/1352422726-31114-1-git-send-email-vlee@twitter.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 45d6c5dd9615c481066d3377ad35edc681393fac Author: Dan Williams Date: Thu Nov 8 12:47:41 2012 -0600 cdc-acm: implement TIOCSSERIAL to avoid blocking close(2) commit ba2d8ce9db0a61505362bb17b8899df3d3326146 upstream. Some devices (ex Nokia C7) simply don't respond at all when data is sent to some of their USB interfaces. The data gets stuck in the TTYs queue and sits there until close(2), which them blocks because closing_wait defaults to 30 seconds (even though the fd is O_NONBLOCK). This is rarely desired. Implement the standard mechanism to adjust closing_wait and let applications handle it how they want to. See also 02303f73373aa1da19dbec510ec5a4e2576f9610 for usb_wwan.c. Signed-off-by: Dan Williams Acked-by: Oliver Neukum Tested-by: Aleksander Morgado Signed-off-by: Greg Kroah-Hartman commit f99b4b46d8e4a98fc1c4386a78f5a94296b6ebb0 Author: Steven Rostedt Date: Thu Nov 29 22:31:16 2012 -0500 ring-buffer: Fix race between integrity check and readers commit 9366c1ba13fbc41bdb57702e75ca4382f209c82f upstream. The function rb_check_pages() was added to make sure the ring buffer's pages were sane. This check is done when the ring buffer size is modified as well as when the iterator is released (closing the "trace" file), as that was considered a non fast path and a good place to do a sanity check. The problem is that the check does not have any locks around it. If one process were to read the trace file, and another were to read the raw binary file, the check could happen while the reader is reading the file. The issues with this is that the check requires to clear the HEAD page before doing the full check and it restores it afterward. But readers require the HEAD page to exist before it can read the buffer, otherwise it gives a nasty warning and disables the buffer. By adding the reader lock around the check, this keeps the race from happening. Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 7c3432b14e30e1aebb7a19ea52a05928b383b272 Author: Steven Rostedt Date: Thu Nov 29 22:27:22 2012 -0500 ring-buffer: Fix NULL pointer if rb_set_head_page() fails commit 54f7be5b831254199522523ccab4c3d954bbf576 upstream. The function rb_set_head_page() searches the list of ring buffer pages for a the page that has the HEAD page flag set. If it does not find it, it will do a WARN_ON(), disable the ring buffer and return NULL, as this should never happen. But if this bug happens to happen, not all callers of this function can handle a NULL pointer being returned from it. That needs to be fixed. Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 5bab98768136ee54b82ef6dd7fc0ec1c41ef8431 Author: Dan Carpenter Date: Sat Jun 9 19:10:27 2012 +0300 ftrace: Clear bits properly in reset_iter_read() commit 70f77b3f7ec010ff9624c1f2e39a81babc9e2429 upstream. There is a typo here where '&' is used instead of '|' and it turns the statement into a noop. The original code is equivalent to: iter->flags &= ~((1 << 2) & (1 << 4)); Link: http://lkml.kernel.org/r/20120609161027.GD6488@elgon.mountain Signed-off-by: Dan Carpenter Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 5338f92b421c257ff09d0ef65fde4447eccb0c95 Author: Sarah Sharp Date: Wed Oct 17 13:44:06 2012 -0700 xhci: Extend Fresco Logic MSI quirk. commit bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 upstream. Ali reports that plugging a device into the Fresco Logic xHCI host with PCI device ID 1400 produces an IRQ error: do_IRQ: 3.176 No irq handler for vector (irq -1) Other early Fresco Logic host revisions don't support MSI, even though their PCI config space claims they do. Extend the quirk to disabling MSI to this chipset revision. Also enable the short transfer quirk, since it's likely this revision also has that quirk, and it should be harmless to enable. 04:00.0 0c03: 1b73:1400 (rev 01) (prog-if 30 [XHCI]) Subsystem: 1d5c:1000 Physical Slot: 3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Reported-by: A Sh Tested-by: A Sh Signed-off-by: Greg Kroah-Hartman commit efda03ca0a93fb485723ae3178b75e59af362474 Author: Alan Stern Date: Mon Nov 26 12:36:21 2012 -0500 USB: OHCI: workaround for hardware bug: retired TDs not added to the Done Queue commit 50ce5c0683aa83eb161624ea89daa5a9eee0c2ce upstream. This patch (as1636) is a partial workaround for a hardware bug affecting OHCI controllers by NVIDIA at least, maybe others too. When the controller retires a Transfer Descriptor, it is supposed to add the TD onto the Done Queue. But sometimes this doesn't happen, with the result that ohci-hcd never realizes the corresponding transfer has finished. Symptoms can vary; a typical result is that USB audio stops working after a while. The patch works around the problem by recognizing that TDs are always processed in order. Therefore, if a later TD is found on the Done Queue than all the earlier TDs for the same endpoint must be finished as well. Unfortunately this won't solve the problem in cases where the missing TD is the last one in the endpoint's queue. A complete fix would require a signficant amount of change to the driver. Signed-off-by: Alan Stern Tested-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit efcda31e6023a8593ba93c556fe134023b77ba56 Author: Lan Tianyu Date: Fri Nov 30 13:02:50 2012 +0100 ACPI / video: Add "Asus UL30VT" to ACPI video detect blacklist commit d0c2ce16bec0afa6013b4c5220ca4c9c67210215 upstream. The ACPI video driver can't control backlight correctly on Asus UL30VT. Vendor driver (asus-laptop) can work. This patch is to add "Asus UL30VT" to ACPI video detect blacklist in order to use asus-laptop for video control on the "Asus UL30VT" rather than ACPI video driver. References: https://bugzilla.kernel.org/show_bug.cgi?id=32592 Reported-by: Alex Williamson Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 77dfd2e6c6d83aa806e56e297b8c9cc122a3b0e4 Author: Zhang Rui Date: Tue Dec 4 23:30:19 2012 +0100 ACPI / video: ignore BIOS initial backlight value for HP Folio 13-2000 commit 129ff8f8d58297b04f47b5d6fad81aa2d08404e1 upstream. Or else the laptop will boot with a dimmed screen. References: https://bugzilla.kernel.org/show_bug.cgi?id=51141 Tested-by: Stefan Nagy Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9c3f6f654da8dc484dabaa4c8805f70d64d7b000 Author: Rafael J. Wysocki Date: Fri Nov 30 13:05:05 2012 +0100 ACPI / PNP: Do not crash due to stale pointer use during system resume commit a6b5e88c0e42093b9057856f35770966c8c591e3 upstream. During resume from system suspend the 'data' field of struct pnp_dev in pnpacpi_set_resources() may be a stale pointer, due to removal of the associated ACPI device node object in the previous suspend-resume cycle. This happens, for example, if a dockable machine is booted in the docking station and then suspended and resumed and suspended again. If that happens, pnpacpi_build_resource_template() called from pnpacpi_set_resources() attempts to use that pointer and crashes. However, pnpacpi_set_resources() actually checks the device's ACPI handle, attempts to find the ACPI device node object attached to it and returns an error code if that fails, so in fact it knows what the correct value of dev->data should be. Use this observation to update dev->data with the correct value if necessary and dump a call trace if that's the case (once). We still need to fix the root cause of this issue, but preventing systems from crashing because of it is an improvement too. Reported-and-tested-by: Zdenek Kabelac References: https://bugzilla.kernel.org/show_bug.cgi?id=51071 Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 87f8b7c1928dac3cd0df0d1e6682edb29c8c5c78 Author: Lan Tianyu Date: Wed Nov 21 23:12:12 2012 +0100 ACPI / PM: Add Sony Vaio VPCEB1S1E to nonvs blacklist. commit 876ab79055019e248508cfd0dee7caa3c0c831ed upstream. Sony Vaio VPCEB1S1E does not resume correctly without acpi_sleep=nonvs, so add it to the ACPI sleep blacklist. References: https://bugzilla.kernel.org/show_bug.cgi?id=48781 Reported-by: Sébastien Wilmet Signed-off-by: Lan Tianyu Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 90e760ae6415d828b729700c2da254a2266ffdb1 Author: Kamil Iskra Date: Fri Nov 16 22:28:58 2012 +0100 ACPI / battery: Correct battery capacity values on Thinkpads commit 4000e626156935dfb626321ce09cae2c833eabbb upstream. Add a quirk to correctly report battery capacity on 2010 and 2011 Lenovo Thinkpad models. The affected models that I tested (x201, t410, t410s, and x220) exhibit a problem where, when battery capacity reporting unit is mAh, the values being reported are wrong. Pre-2010 and 2012 models appear to always report in mWh and are thus unaffected. Also, in mid-2012 Lenovo issued a BIOS update for the 2011 models that fixes the issue (tested on x220 with a post-1.29 BIOS). No such update is available for the 2010 models, so those still need this patch. Problem description: for some reason, the affected Thinkpads switch the reporting unit between mAh and mWh; generally, mAh is used when a laptop is plugged in and mWh when it's unplugged, although a suspend/resume or rmmod/modprobe is needed for the switch to take effect. The values reported in mAh are *always* wrong. This does not appear to be a kernel regression; I believe that the values were never reported correctly. I tested back to kernel 2.6.34, with multiple machines and BIOS versions. Simply plugging a laptop into mains before turning it on is enough to reproduce the problem. Here's a sample /proc/acpi/battery/BAT0/info from Thinkpad x220 (before a BIOS update) with a 4-cell battery: present: yes design capacity: 2886 mAh last full capacity: 2909 mAh battery technology: rechargeable design voltage: 14800 mV design capacity warning: 145 mAh design capacity low: 13 mAh cycle count: 0 capacity granularity 1: 1 mAh capacity granularity 2: 1 mAh model number: 42T4899 serial number: 21064 battery type: LION OEM info: SANYO Once the laptop switches the unit to mWh (unplug from mains, suspend, resume), the output changes to: present: yes design capacity: 28860 mWh last full capacity: 29090 mWh battery technology: rechargeable design voltage: 14800 mV design capacity warning: 1454 mWh design capacity low: 200 mWh cycle count: 0 capacity granularity 1: 1 mWh capacity granularity 2: 1 mWh model number: 42T4899 serial number: 21064 battery type: LION OEM info: SANYO Can you see how the values for "design capacity", etc., differ by a factor of 10 instead of 14.8 (the design voltage of this battery)? On the battery itself it says: 14.8V, 1.95Ah, 29Wh, so clearly the values reported in mWh are correct and the ones in mAh are not. My guess is that this problem has been around ever since those machines were released, but because the most common Thinkpad batteries are rated at 10.8V, the error (8%) is small enough that it simply hasn't been noticed or at least nobody could be bothered to look into it. My patch works around the problem by adjusting the incorrectly reported mAh values by "10000 / design_voltage". The patch also has code to figure out if it should be activated or not. It only activates on Lenovo Thinkpads, only when the unit is mAh, and, as an extra precaution, only when the battery capacity reported through ACPI does not match what is reported through DMI (I've never encountered a machine where the first two conditions would be true but the last would not, but better safe than sorry). I've been using this patch for close to a year on several systems without any problems. References: https://bugzilla.kernel.org/show_bug.cgi?id=41062 Acked-by: Henrique de Moraes Holschuh Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit ef984b4cd5baa2f202adcc77e03ff2953cc71df9 Author: Greg Kroah-Hartman Date: Wed Nov 28 10:19:16 2012 -0800 USB: mark uas driver as BROKEN commit fb37ef98015f864d22be223a0e0d93547cd1d4ef upstream. As reported https://bugzilla.kernel.org/show_bug.cgi?id=51031, the UAS driver causes problems and has been asked to be not built into any of the major distributions. To prevent users from running into problems with it, and for distros that were not notified, just mark the whole thing as broken. Acked-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman commit bf9694fb59594c92d791bc728b5aa13dab06a15a Author: Markus Becker Date: Thu Nov 22 09:41:23 2012 +0100 USB: cp210x: add Virtenio Preon32 device id commit 356fe44f4b8ece867bdb9876b1854d7adbef9de2 upstream. Signed-off-by: Markus Becker Signed-off-by: Greg Kroah-Hartman commit bf9a2254ff6fd799df438f5b392c3e884fd03177 Author: Peter Korsgaard Date: Thu Nov 22 16:30:46 2012 +0100 usb: ftdi_sio: fixup BeagleBone A5+ quirk commit 1a88d5eee2ef2ad1d3c4e32043e9c4c5347d4fc1 upstream. BeagleBone A5+ devices ended up getting shipped with the 'BeagleBone/XDS100V2' product string, and not XDS100 like it was agreed, so adjust the quirk to match. For details, see the thread on the beagle list: https://groups.google.com/forum/#!msg/beagleboard/zrFPew9_Wvo/ibWr1-eE8JwJ Signed-off-by: Peter Korsgaard Signed-off-by: Greg Kroah-Hartman commit 0b23bbd5a7070e0ba00de1d742c1f3269413ea9c Author: Martin Teichmann Date: Wed Nov 21 16:45:07 2012 +0100 USB: ftdi_sio: Add support for Newport AGILIS motor drivers commit d7e14b375b40c04cd735b115713043b69a2c68ac upstream. The Newport AGILIS model AG-UC8 compact piezo motor controller (http://search.newport.com/?q=*&x2=sku&q2=AG-UC8) is yet another device using an FTDI USB-to-serial chip. It works fine with the ftdi_sio driver when adding options ftdi-sio product=0x3000 vendor=0x104d to modprobe.d. udevadm reports "Newport" as the manufacturer, and "Agilis" as the product name. Signed-off-by: Martin Teichmann Signed-off-by: Greg Kroah-Hartman commit a634f92ce1b353f2f3ddd9b331a943414fd50f31 Author: Bjørn Mork Date: Sun Nov 25 17:05:10 2012 +0100 USB: option: blacklist network interface on Huawei E173 commit f36446cf9bbebaa03a80d95cfeeafbaf68218249 upstream. The Huawei E173 will normally appear as 12d1:1436 in Linux. But the modem has another mode with different device ID and a slightly different set of descriptors. This is the mode used by Windows like this: 3Modem: USB\VID_12D1&PID_140C&MI_00\6&3A1D2012&0&0000 Networkcard: USB\VID_12D1&PID_140C&MI_01\6&3A1D2012&0&0001 Appli.Inter: USB\VID_12D1&PID_140C&MI_02\6&3A1D2012&0&0002 PC UI Inter: USB\VID_12D1&PID_140C&MI_03\6&3A1D2012&0&0003 All interfaces have the same ff/ff/ff class codes in this mode. Blacklisting the network interface to allow it to be picked up by the network driver. Reported-by: Thomas Schäfer Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 673531802c45aaccb2dec0c6ed2fe6013d155d50 Author: li.rui27@zte.com.cn Date: Tue Nov 20 14:31:47 2012 +0800 USB: add new zte 3g-dongle's pid to option.c commit 31b6a1048b7292efff8b5b53ae3d9d29adde385e upstream. Signed-off-by: Rui li Signed-off-by: Greg Kroah-Hartman commit a305b4e87b0e4dca16ec8856bf5d1d44ddbd4763 Author: Jan Beulich Date: Fri Nov 2 14:02:40 2012 +0000 x86: hpet: Fix masking of MSI interrupts commit 6acf5a8c931da9d26c8dd77d784daaf07fa2bff0 upstream. HPET_TN_FSB is not a proper mask bit; it merely toggles between MSI and legacy interrupt delivery. The proper mask bit is HPET_TN_ENABLE, so use both bits when (un)masking the interrupt. Signed-off-by: Jan Beulich Link: http://lkml.kernel.org/r/5093E09002000078000A60E6@nat28.tlf.novell.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit dc96e8023d0803688f1e56a9f52f7213bb2a8204 Author: Rene Buergel Date: Thu Nov 22 19:10:50 2012 +0100 ezusb: add dependency to USB commit 9db72fe6c943852032d9ed863c87e8c02d3cb9da upstream. This fixes an error during modpost, when ezusb is built into the kernel while USB is built as module. Signed-off-by: René Bürgel Cc: Jeff Mahoney Signed-off-by: Greg Kroah-Hartman commit 83c9bff26b4445bfaebbe9317d4ad73f69c68fe6 Author: Dan Carpenter Date: Mon Dec 3 22:05:12 2012 +0300 telephony: ijx: buffer overflow in ixj_write_cid() [Not needed in 3.8 or newer as this driver is removed there. - gregkh] We get this from user space and nothing has been done to ensure that these strings are NUL terminated. Reported-by: Chen Gang Signed-off-by: Dan Carpenter Signed-off-by: Greg Kroah-Hartman commit ec92de46a243f6d014c8c42276b4b0cd72c4c9c5 Author: Boris Ostrovsky Date: Wed Dec 5 06:12:42 2012 -0500 x86,AMD: Power driver support for AMD's family 16h processors commit 22e32f4f57778ebc6e17812fa3008361c05d64f9 upstream. Add family 16h PCI ID to AMD's power driver to allow it report power consumption on these processors. Signed-off-by: Boris Ostrovsky Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 5a11e1dcbc8b64bc76dde2a8c96646bab5e41d6a Author: Linus Walleij Date: Tue Nov 27 20:15:20 2012 +0100 clk: ux500: fix bit error commit 2630b17b6ee47ac79b4f5120ac49105027f644ea upstream. This fixes a bit error in the U8500 clock implementation: the unused p2_pclk12 registered at bit 12 in periphereral group 6 was defined as using bit 11 rather than bit 12. When walking over and disabling the unused clocks in the tree at late init time, p2_pclk12 was disabled, by effectively clearing the but for p2_pclk11 instead of bit 12 as it should have, thus disabling gpio block 6 and 7. Reported-by: Lee Jones Acked-by: Ulf Hansson Cc: Philippe Begnic Signed-off-by: Linus Walleij Signed-off-by: Mike Turquette Signed-off-by: Greg Kroah-Hartman commit 13a4fcec5484b83b61926d5304d86349e5530027 Author: Marek Szyprowski Date: Wed Nov 7 15:37:07 2012 +0100 mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls commit 387870f2d6d679746020fa8e25ef786ff338dc98 upstream. dmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag, regardless the flags provided by the caller. This causes excessive pruning of emergency memory pools without any good reason. Additionaly, on ARM architecture any driver which is using dmapools will sooner or later trigger the following error: "ERROR: 256 KiB atomic DMA coherent pool is too small! Please increase it with coherent_pool= kernel parameter!". Increasing the coherent pool size usually doesn't help much and only delays such error, because all GFP_ATOMIC DMA allocations are always served from the special, very limited memory pool. This patch changes the dmapool code to correctly use gfp flags provided by the dmapool caller. Reported-by: Soeren Moch Reported-by: Thomas Petazzoni Signed-off-by: Marek Szyprowski Tested-by: Andrew Lunn Tested-by: Soeren Moch Signed-off-by: Greg Kroah-Hartman