summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2014-06-09dma: mv_xor: Flush descriptors before activating a channelEzequiel Garcia
commit 5a9a55bf9157d3490b0c8c4c81d4708602c26e07 upstream. We need to use writel() instead of writel_relaxed() when starting a channel, to ensure all the descriptors have been flushed before the activation. While at it, remove the unneeded read-modify-write and make the code simpler. Signed-off-by: Lior Amsalem <alior@marvell.com> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> [bwh: Backported to 3.2: it was using __raw_readl() and __raw_writel() which are just as wrong] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09can: peak_pci: prevent use after free at netdev removalStephane Grosjean
commit 0b5a958cf4df3a5cd578b861471e62138f55c85e upstream. As remarked by Christopher R. Baker in his post at http://marc.info/?l=linux-can&m=139707295706465&w=2 there's a possibility for an use after free condition at device removal. This simplified patch introduces an additional variable to prevent the issue. Thanks for catching this. Reported-by: Christopher R. Baker <cbaker@rec.ri.cmu.edu> Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09can: peak_pci: Fix the way channels are linked togetherStephane Grosjean
commit 29830406415c227a54af429d7b300aabd4754237 upstream. Change the way channels objects are linked together by peak_pci_probe() avoiding any kernel oops when driver is removed. Side effect is that the list is now browsed from last to first channel. Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09drm/radeon: handle non-VGA class pci devices with ATRMAlex Deucher
commit d8ade3526b2aa0505132c404c05a38b73ea15490 upstream. Newer PX systems have non-VGA pci class dGPUs. Update the ATRM fetch method to handle those cases. bug: https://bugzilla.kernel.org/show_bug.cgi?id=75401 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> [bwh: Backported to 3.2: s/ACPI_HANDLE()/DEVICE_ACPI_HANDLE()/] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09drm/radeon: also try GART for CPU accessed buffersChristian König
commit 544092596e8ac269f70e70961b5e9381909c9b1e upstream. Placing them exclusively into VRAM might not work all the time. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=78297 Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> [bwh: Backported to 3.2: ttm_bo_validate() takes an extra no_wait_reserve parameter; keep passing true] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09PCI: shpchp: Check bridge's secondary (not primary) bus speedMarcel Apfelbaum
commit 93fa9d32670f5592c8e56abc9928fc194e1e72fc upstream. When a new device is added below a hotplug bridge, the bridge's secondary bus speed and the device's bus speed must match. The shpchp driver previously checked the bridge's *primary* bus speed, not the secondary bus speed. This caused hot-add errors like: shpchp 0000:00:03.0: Speed of bus ff and adapter 0 mismatch Check the secondary bus speed instead. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=75251 Fixes: 3749c51ac6c1 ("PCI: Make current and maximum bus speeds part of the PCI core") Signed-off-by: Marcel Apfelbaum <marcel.a@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09i2c: s3c2410: resume race fixOlof Johansson
commit ce78cc071f5f541480e381cc0241d37590041a9d upstream. Don't unmark the device as suspended until after it's been re-setup. The main race would be w.r.t. an i2c driver that gets resumed at the same time (asyncronously), that is allowed to do a transfer since suspended is set to 0 before reinit, but really should have seen the -EIO return instead. Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Doug Anderson <dianders@chromium.org> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09i2c: designware: Mask all interrupts during i2c controller enableDu, Wenkai
commit 47bb27e78867997040a228328f2a631c3c7f2c82 upstream. There have been "i2c_designware 80860F41:00: controller timed out" errors on a number of Baytrail platforms. The issue is caused by incorrect value in Interrupt Mask Register (DW_IC_INTR_MASK) when i2c core is being enabled. This causes call to __i2c_dw_enable() to immediately start the transfer which leads to timeout. There are 3 failure modes observed: 1. Failure in S0 to S3 resume path The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start the first transaction after resuming from system sleep, TX_EMPTY interrupt is already unmasked because of the hardware default. 2. Failure in normal operational path This failure happens rarely and is hard to reproduce. Debug trace showed that DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant TX_EMPTY was unmasked. 3. Failure in S3 to S0 suspend path This failure also happens rarely and is hard to reproduce. Adding debug trace that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR call trace we could conclude TX_EMPTY was unmasked when problem occurred. The patch masks all interrupts before the controller is enabled to resolve the faulty DW_IC_INTR_MASK conditions. Signed-off-by: Wenkai Du <wenkai.du@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> [wsa: improved the comment and removed typo in commit msg] Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09V4L2: fix VIDIOC_CREATE_BUFS in 64- / 32-bit compatibility modeGuennadi Liakhovetski
commit 97d9d23dda6f37d90aefeec4ed619d52df525382 upstream. If a struct contains 64-bit fields, it is aligned on 64-bit boundaries within containing structs in 64-bit compilations. This is the case with struct v4l2_window, which contains pointers and is embedded into struct v4l2_format, and that one is embedded into struct v4l2_create_buffers. Unlike some other structs, used as a part of the kernel ABI as ioctl() arguments, that are packed, these structs aren't packed. This isn't a problem per se, but the ioctl-compat code for VIDIOC_CREATE_BUFS contains a bug, that triggers in such 64-bit builds. That code wrongly assumes, that in struct v4l2_create_buffers, struct v4l2_format immediately follows the __u32 memory field, which in fact isn't the case. This bug wasn't visible until now, because until recently hardly any applications used this ioctl() and mostly embedded 32-bit only drivers implemented it. This is changing now with addition of this ioctl() to some USB drivers, e.g. UVC. This patch fixes the bug by copying parts of struct v4l2_create_buffers separately. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09V4L2: ov7670: fix a wrong index, potentially Oopsing the kernel from user-spaceGuennadi Liakhovetski
commit cfece5857ca51d1dcdb157017aba226f594e9dcf upstream. Commit 75e2bdad8901a0b599e01a96229be922eef1e488 "ov7670: allow configuration of image size, clock speed, and I/O method" uses a wrong index to iterate an array. Apart from being wrong, it also uses an unchecked value from user-space, which can cause access to unmapped memory in the kernel, triggered by a normal desktop user with rights to use V4L2 devices. Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> [bwh: Backported to 3.2: - Adjust filename - win_sizes array is static, not per-device] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09hwmon: (emc1403) Support full range of known chip revision numbersJosef Gajdusek
commit 3a18e1398fc2dc9c32bbdc50664da3a77959a8d1 upstream. The datasheet for EMC1413/EMC1414, which is fully compatible to EMC1403/1404 and uses the same chip identification, references revision numbers 0x01, 0x03, and 0x04. Accept the full range of revision numbers from 0x01 to 0x04 to make sure none are missed. Signed-off-by: Josef Gajdusek <atx@atx.name> [Guenter Roeck: Updated headline and description] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09hwmon: (emc1403) fix inverted store_hyst()Josef Gajdusek
commit 17c048fc4bd95efea208a1920f169547d8588f1f upstream. Attempts to set the hysteresis value to a temperature below the target limit fails with "write error: Numerical result out of range" due to an inverted comparison. Signed-off-by: Josef Gajdusek <atx@atx.name> Reviewed-by: Jean Delvare <jdelvare@suse.de> [Guenter Roeck: Updated headline and description] Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09md: avoid possible spinning md thread at shutdown.NeilBrown
commit 0f62fb220aa4ebabe8547d3a9ce4a16d3c045f21 upstream. If an md array with externally managed metadata (e.g. DDF or IMSM) is in use, then we should not set safemode==2 at shutdown because: 1/ this is ineffective: user-space need to be involved in any 'safemode' handling, 2/ The safemode management code doesn't cope with safemode==2 on external metadata and md_check_recover enters an infinite loop. Even at shutdown, an infinite-looping process can be problematic, so this could cause shutdown to hang. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09Input: elantech - fix touchpad initialization on Gigabyte U2442Hans de Goede
commit 36189cc3cd57ab0f1cd75241f93fe01de928ac06 upstream. The hw_version 3 Elantech touchpad on the Gigabyte U2442 does not accept 0x0b as initialization value for r10, this stand-alone version of the driver: http://planet76.com/drivers/elantech/psmouse-elantech-v6.tar.bz2 Uses 0x03 which does work, so this means not setting bit 3 of r10 which sets: "Enable Real H/W Resolution In Absolute mode" Which will result in half the x and y resolution we get with that bit set, so simply not setting it everywhere is not a solution. We've been unable to find a way to identify touchpads where setting the bit will fail, so this patch uses a dmi based blacklist for this. https://bugzilla.kernel.org/show_bug.cgi?id=61151 Reported-by: Philipp Wolfer <ph.wolfer@gmail.com> Tested-by: Philipp Wolfer <ph.wolfer@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09HID: add NO_INIT_REPORTS quirk for Synaptics Touch Pad V 103SHans de Goede
commit 2f433083e854ec72c19dc9b0e1cebcc8e230fd75 upstream. This touchpad seriously dislikes init reports, not only timeing out, but also refusing to work after this. Reported-and-tested-by: Vincent Fortier <th0ma7@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09HID: usbhid: quirk for Synaptics Quad HD touchscreenAceLan Kao
commit 12f508aede4bda5d20a2dd3ff3deb16ef47a97e9 upstream. Add Synaptics HD touchscreen(06cb:1ac3) to no init report quirk Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09HID: usbhid: quirk for Synaptics HD touchscreenAceLan Kao
commit d8e2e7581d2521910398c4c80d7a3b78e84da7d5 upstream. Add Synaptics HD touchscreen(06cb:0ac3) to no init report quirk. Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09HID: usbhid: quirk for Synaptics Large TouchccreenAceLan Kao
commit 8171a67d587a09e14a4949a81e070345fedcf410 upstream. BugLink: http://bugs.launchpad.net/bugs/1180881 Synaptics large touchscreen doesn't support some of the report request while initializing. The unspoorted request will make the device unreachable, and will lead to the following usb_submit_urb() function call timeout. So, add the IDs into HID_QUIRK_NO_INIT_REPORTS quirk. Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> [bwh: Backported to 3.2: - Adjust context - Add definition of USB_VENDOR_ID_SYNAPTICS] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09USB: Nokia 5300 should be treated as unusual devDaniele Forsi
commit 6ed07d45d09bc2aa60e27b845543db9972e22a38 upstream. Signed-off-by: Daniele Forsi <dforsi@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09USB: Nokia 305 should be treated as unusual devVictor A. Santos
commit f0ef5d41792a46a1085dead9dfb0bdb2c574638e upstream. Signed-off-by: Victor A. Santos <victoraur.santos@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09drivers/tty/hvc: don't free hvc_console_setup after initTomoki Sekiyama
commit 501fed45b7e8836ee9373f4d31e2d85e3db6103a upstream. When 'console=hvc0' is specified to the kernel parameter in x86 KVM guest, hvc console is setup within a kthread. However, that will cause SEGV and the boot will fail when the driver is builtin to the kernel, because currently hvc_console_setup() is annotated with '__init'. This patch removes '__init' to boot the guest successfully with 'console=hvc0'. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09usb: storage: shuttle_usbat: fix discs being detected twiceDaniele Forsi
commit df602c2d2358f02c6e49cffc5b49b9daa16db033 upstream. Even if the USB-to-ATAPI converter supported multiple LUNs, this driver would always detect the same physical device or media because it doesn't use srb->device->lun in any way. Tested with an Hewlett-Packard CD-Writer Plus 8200e. Signed-off-by: Daniele Forsi <dforsi@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09drm/nouveau/acpi: allow non-optimus setups to load vbios from acpiIlia Mirkin
commit a3d0b1218d351c6e6f3cea36abe22236a08cb246 upstream. There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09media-device: fix infoleak in ioctl media_enum_entities()Salva Peiró
commit e6a623460e5fc960ac3ee9f946d3106233fd28d8 upstream. This fixes CVE-2014-1739. Signed-off-by: Salva Peiró <speiro@ai2.upv.es> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init()Ben Hutchings
commit 3234f5b06fc3094176a86772cc64baf3decc98fc upstream. Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs') Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust context]
2014-06-09rtlwifi: rtl8192cu: Fix too long disable of IRQsLarry Finger
commit a53268be0cb9763f11da4f6fe3fb924cbe3a7d4a upstream. In commit f78bccd79ba3cd9d9664981b501d57bdb81ab8a4 entitled "rtlwifi: rtl8192ce: Fix too long disable of IRQs", Olivier Langlois <olivier@trillion01.com> fixed a problem caused by an extra long disabling of interrupts. This patch makes the same fix for rtl8192cu. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09mpt2sas: Don't disable device twice at suspend.Tyler Stachecki
commit af61e27c3f77c7623b5335590ae24b6a5c323e22 upstream. On suspend, _scsih_suspend calls mpt2sas_base_free_resources, which in turn calls pci_disable_device if the device is enabled prior to suspending. However, _scsih_suspend also calls pci_disable_device itself. Thus, in the event that the device is enabled prior to suspending, pci_disable_device will be called twice. This patch removes the duplicate call to pci_disable_device in _scsi_suspend as it is both unnecessary and results in a kernel oops. Signed-off-by: Tyler Stachecki <tstache1@binghamton.edu> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09crypto: caam - add allocation failure handling in SPRINTFCAT macroHoria Geanta
commit 27c5fb7a84242b66bf1e0b2fe6bf40d19bcc5c04 upstream. GFP_ATOMIC memory allocation could fail. In this case, avoid NULL pointer dereference and notify user. Cc: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Horia Geanta <horia.geanta@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09Bluetooth: Add support for Lite-on [04ca:3007]Mohammed Habibulla
commit 1fb4e09a7e780b915dbd172592ae7e2a4c071065 upstream. Add support for the AR9462 chip T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3007 Rev= 0.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 E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by: Mohammed Habibulla <moch@chromium.org> Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09drm/vmwgfx: Make sure user-space can't DMA across buffer object boundaries v2Thomas Hellstrom
commit cbd75e97a525e3819c02dc18bc2d67aa544c9e45 upstream. We already check that the buffer object we're accessing is registered with the file. Now also make sure that we can't DMA across buffer object boundaries. v2: Code commenting update. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09Input: synaptics - add min/max quirk for ThinkPad Edge E431Hans de Goede
commit 27a38856a948c3e8de30dc71647ff9e1778c99fc upstream. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09rt2x00: fix beaconing on USBStanislaw Gruszka
commit 8834d3608cc516f13e2e510f4057c263f3d2ce42 upstream. When disable beaconing we clear register with beacon and newer set it back, what make we stop send beacons infinitely. Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09thinkpad-acpi: fix issuing duplicated key events for brightness up/downAlex Hung
commit ff413195e830541afeae469fc866ecd0319abd7e upstream. The tp_features.bright_acpimode will not be set correctly for brightness control because ACPI_VIDEO_HID will not be located in ACPI. As a result, a duplicated key event will always be sent. acpi_video_backlight_support() is sufficient to detect standard ACPI brightness control. Signed-off-by: Alex Hung <alex.hung@canonical.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09skb: Add inline helper for getting the skb end offset from headAlexander Duyck
[ Upstream commit ec47ea82477404631d49b8e568c71826c9b663ac ] With the recent changes for how we compute the skb truesize it occurs to me we are probably going to have a lot of calls to skb_end_pointer - skb->head. Instead of running all over the place doing that it would make more sense to just make it a separate inline skb_end_offset(skb) that way we can return the correct value without having gcc having to do all the optimization to cancel out skb->head - skb->head. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09macvlan: Don't propagate IFF_ALLMULTI changes on down interfaces.Peter Christensen
[ Upstream commit bbeb0eadcf9fe74fb2b9b1a6fea82cd538b1e556 ] Clearing the IFF_ALLMULTI flag on a down interface could cause an allmulti overflow on the underlying interface. Attempting the set IFF_ALLMULTI on the underlying interface would cause an error and the log message: "allmulti touches root, set allmulti failed." Signed-off-by: Peter Christensen <pch@ordbogen.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09Revert "macvlan : fix checksums error when we are in bridge mode"Vlad Yasevich
[ Upstream commit f114890cdf84d753f6b41cd0cc44ba51d16313da ] This reverts commit 12a2856b604476c27d85a5f9a57ae1661fc46019. The commit above doesn't appear to be necessary any more as the checksums appear to be correctly computed/validated. Additionally the above commit breaks kvm configurations where one VM is using a device that support checksum offload (virtio) and the other VM does not. In this case, packets leaving virtio device will have CHECKSUM_PARTIAL set. The packets is forwarded to a macvtap that has offload features turned off. Since we use CHECKSUM_UNNECESSARY, the host does does not update the checksum and thus a bad checksum is passed up to the guest. CC: Daniel Lezcano <daniel.lezcano@free.fr> CC: Patrick McHardy <kaber@trash.net> CC: Andrian Nord <nightnord@gmail.com> CC: Eric Dumazet <eric.dumazet@gmail.com> CC: Michael S. Tsirkin <mst@redhat.com> CC: Jason Wang <jasowang@redhat.com> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09tg3: update rx_jumbo_pending ring param only when jumbo frames are enabledIvan Vecera
commit ba67b510035141bd89b40bf65efa0a79834311ca upstream. The patch fixes a problem with dropped jumbo frames after usage of 'ethtool -G ... rx'. Scenario: 1. ip link set eth0 up 2. ethtool -G eth0 rx N # <- This zeroes rx-jumbo 3. ip link set mtu 9000 dev eth0 The ethtool command set rx_jumbo_pending to zero so any received jumbo packets are dropped and you need to use 'ethtool -G eth0 rx-jumbo N' to workaround the issue. The patch changes the logic so rx_jumbo_pending value is changed only if jumbo frames are enabled (MTU > 1500). Signed-off-by: Ivan Vecera <ivecera@redhat.com> Acked-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09bonding: Remove debug_fs files when module init failsThomas Richter
[ Upstream commit db29868653394937037d71dc3545768302dda643 ] Remove the bonding debug_fs entries when the module initialization fails. The debug_fs entries should be removed together with all other already allocated resources. Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com> Signed-off-by: Jay Vosburgh <j.vosburgh@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09tgafb: fix mode setting with fbsetMikulas Patocka
commit 624966589041deb32a2626ee2e176e8274581101 upstream. Mode setting in the TGA driver is broken for these reasons: - info->fix.line_length is set just once in tgafb_init_fix function. If we change videomode, info->fix.line_length is not recalculated - so the video mode is changed but the screen is corrupted because of wrong info->fix.line_length. - info->fix.smem_len is set in tgafb_init_fix to the size of the default video mode (640x480). If we set a higher resolution, info->fix.smem_len is smaller than the current screen size, preventing the userspace program from mapping the framebuffer. This patch fixes it: - info->fix.line_length initialization is moved to tgafb_set_par so that it is recalculated with each mode change. - info->fix.smem_len is set to a fixed value representing the real amount of video ram (the values are taken from xfree86 driver). - add a check to tgafb_check_var to prevent us from setting a videomode that doesn't fit into videoram. - in tgafb_register, tgafb_init_fix is moved upwards, to be called before fb_find_mode (because fb_find_mode already needs the videoram size set in tgafb_init_fix). Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vga.kernel.org Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09ACPI / EC: Process rather than discard events in acpi_ec_clearKieran Clancy
commit 3eba563e280101209bad27d40bfc83ddf1489234 upstream. Address a regression caused by commit ad332c8a4533: (ACPI / EC: Clear stale EC events on Samsung systems) After the earlier patch, there was found to be a race condition on some earlier Samsung systems (N150/N210/N220). The function acpi_ec_clear was sometimes discarding a new EC event before its GPE was triggered by the system. In the case of these systems, this meant that the "lid open" event was not registered on resume if that was the cause of the wake, leading to problems when attempting to close the lid to suspend again. After testing on a number of Samsung systems, both those affected by the previous EC bug and those affected by the race condition, it seemed that the best course of action was to process rather than discard the events. On Samsung systems which accumulate stale EC events, there does not seem to be any adverse side-effects of running the associated _Q methods. This patch adds an argument to the static function acpi_ec_sync_query so that it may be used within the acpi_ec_clear loop in place of acpi_ec_query_unlocked which was used previously. With thanks to Stefan Biereigel for reporting the issue, and for all the people who helped test the new patch on affected systems. Fixes: ad332c8a4533 (ACPI / EC: Clear stale EC events on Samsung systems) References: https://lkml.kernel.org/r/532FE3B2.9060808@biereigel-wb.de References: https://bugzilla.kernel.org/show_bug.cgi?id=44161#c173 Reported-by: Stefan Biereigel <stefan@biereigel.de> Signed-off-by: Kieran Clancy <clancy.kieran@gmail.com> Tested-by: Stefan Biereigel <stefan@biereigel.de> Tested-by: Dennis Jansen <dennis.jansen@web.de> Tested-by: Nicolas Porcel <nicolasporcel06@gmail.com> Tested-by: Maurizio D'Addona <mauritiusdadd@gmail.com> Tested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com> Tested-by: Giannis Koutsou <giannis.koutsou@gmail.com> Tested-by: Kieran Clancy <clancy.kieran@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-06-09ACPI / EC: Clear stale EC events on Samsung systemsKieran Clancy
commit ad332c8a45330d170bb38b95209de449b31cd1b4 upstream. A number of Samsung notebooks (530Uxx/535Uxx/540Uxx/550Pxx/900Xxx/etc) continue to log events during sleep (lid open/close, AC plug/unplug, battery level change), which accumulate in the EC until a buffer fills. After the buffer is full (tests suggest it holds 8 events), GPEs stop being triggered for new events. This state persists on wake or even on power cycle, and prevents new events from being registered until the EC is manually polled. This is the root cause of a number of bugs, including AC not being detected properly, lid close not triggering suspend, and low ambient light not triggering the keyboard backlight. The bug also seemed to be responsible for performance issues on at least one user's machine. Juan Manuel Cabo found the cause of bug and the workaround of polling the EC manually on wake. The loop which clears the stale events is based on an earlier patch by Lan Tianyu (see referenced attachment). This patch: - Adds a function acpi_ec_clear() which polls the EC for stale _Q events at most ACPI_EC_CLEAR_MAX (currently 100) times. A warning is logged if this limit is reached. - Adds a flag EC_FLAGS_CLEAR_ON_RESUME which is set to 1 if the DMI system vendor is Samsung. This check could be replaced by several more specific DMI vendor/product pairs, but it's likely that the bug affects more Samsung products than just the five series mentioned above. Further, it should not be harmful to run acpi_ec_clear() on systems without the bug; it will return immediately after finding no data waiting. - Runs acpi_ec_clear() on initialisation (boot), from acpi_ec_add() - Runs acpi_ec_clear() on wake, from acpi_ec_unblock_transactions() References: https://bugzilla.kernel.org/show_bug.cgi?id=44161 References: https://bugzilla.kernel.org/show_bug.cgi?id=45461 References: https://bugzilla.kernel.org/show_bug.cgi?id=57271 References: https://bugzilla.kernel.org/attachment.cgi?id=126801 Suggested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com> Signed-off-by: Kieran Clancy <clancy.kieran@gmail.com> Reviewed-by: Lan Tianyu <tianyu.lan@intel.com> Reviewed-by: Dennis Jansen <dennis.jansen@web.de> Tested-by: Kieran Clancy <clancy.kieran@gmail.com> Tested-by: Juan Manuel Cabo <juanmanuel.cabo@gmail.com> Tested-by: Dennis Jansen <dennis.jansen@web.de> Tested-by: Maurizio D'Addona <mauritiusdadd@gmail.com> Tested-by: San Zamoyski <san@plusnet.pl> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> [bwh: Backported to 3.2: - Adjust context - acpi_ec::mutex was called lock] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-05-18floppy: don't write kernel-only members to FDRAWCMD ioctl outputMatthew Daley
commit 2145e15e0557a01b9195d1c7199a1b92cb9be81f upstream. Do not leak kernel-only floppy_raw_cmd structure members to userspace. This includes the linked-list pointer and the pointer to the allocated DMA space. Signed-off-by: Matthew Daley <mattd@bugfuzz.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-05-18floppy: ignore kernel-only members in FDRAWCMD ioctl inputMatthew Daley
commit ef87dbe7614341c2e7bfe8d32fcb7028cc97442c upstream. Always clear out these floppy_raw_cmd struct members after copying the entire structure from userspace so that the in-kernel version is always valid and never left in an interdeterminate state. Signed-off-by: Matthew Daley <mattd@bugfuzz.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-05-18n_tty: Fix n_tty_write crash when echoing in raw modePeter Hurley
commit 4291086b1f081b869c6d79e5b7441633dc3ace00 upstream. The tty atomic_write_lock does not provide an exclusion guarantee for the tty driver if the termios settings are LECHO & !OPOST. And since it is unexpected and not allowed to call TTY buffer helpers like tty_insert_flip_string concurrently, this may lead to crashes when concurrect writers call pty_write. In that case the following two writers: * the ECHOing from a workqueue and * pty_write from the process race and can overflow the corresponding TTY buffer like follows. If we look into tty_insert_flip_string_fixed_flag, there is: int space = __tty_buffer_request_room(port, goal, flags); struct tty_buffer *tb = port->buf.tail; ... memcpy(char_buf_ptr(tb, tb->used), chars, space); ... tb->used += space; so the race of the two can result in something like this: A B __tty_buffer_request_room __tty_buffer_request_room memcpy(buf(tb->used), ...) tb->used += space; memcpy(buf(tb->used), ...) ->BOOM B's memcpy is past the tty_buffer due to the previous A's tb->used increment. Since the N_TTY line discipline input processing can output concurrently with a tty write, obtain the N_TTY ldisc output_lock to serialize echo output with normal tty writes. This ensures the tty buffer helper tty_insert_flip_string is not called concurrently and everything is fine. Note that this is nicely reproducible by an ordinary user using forkpty and some setup around that (raw termios + ECHO). And it is present in kernels at least after commit d945cb9cce20ac7143c2de8d88b187f62db99bdc (pty: Rework the pty layer to use the normal buffering logic) in 2.6.31-rc3. js: add more info to the commit log js: switch to bool js: lock unconditionally js: lock only the tty->ops->write call References: CVE-2014-0196 Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Jiri Slaby <jslaby@suse.cz> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: output_lock is a member of struct tty_struct] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-05-18rtl8192ce: Fix null dereference in watchdogBen Hutchings
Dmitry Semyonov reported that after upgrading from 3.2.54 to 3.2.57 the rtl8192ce driver will crash when its interface is brought up. The oops message shows: [ 1833.611397] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 1833.611455] IP: [<ffffffffa0410c6a>] rtl92ce_update_hal_rate_tbl+0x29/0x4db [rtl8192ce] ... [ 1833.613326] Call Trace: [ 1833.613346] [<ffffffffa02ad9c6>] ? rtl92c_dm_watchdog+0xd0b/0xec9 [rtl8192c_common] [ 1833.613391] [<ffffffff8105b5cf>] ? process_one_work+0x161/0x269 [ 1833.613425] [<ffffffff8105c598>] ? worker_thread+0xc2/0x145 [ 1833.613458] [<ffffffff8105c4d6>] ? manage_workers.isra.25+0x15b/0x15b [ 1833.613496] [<ffffffff8105f6d9>] ? kthread+0x76/0x7e [ 1833.613527] [<ffffffff81356b74>] ? kernel_thread_helper+0x4/0x10 [ 1833.613563] [<ffffffff8105f663>] ? kthread_worker_fn+0x139/0x139 [ 1833.613598] [<ffffffff81356b70>] ? gs_change+0x13/0x13 Disassembly of rtl92ce_update_hal_rate_tbl() shows that the 'sta' parameter was null. None of the changes to the rtlwifi family between 3.2.54 and 3.2.57 seem to directly cause this, and reverting commit f78bccd79ba3 ('rtlwifi: rtl8192ce: Fix too long disable of IRQs') doesn't fix it. rtl92c_dm_watchdog() calls rtl92ce_update_hal_rate_tbl() via rtl92c_dm_refresh_rate_adaptive_mask(), which does not appear in the call trace as it was inlined. That function has been completely removed upstream which may explain why this crash wasn't seen there. I'm not sure that it is sensible to completely remove rtl92c_dm_refresh_rate_adaptive_mask() without making other compensating changes elsewhere, so try to work around this for 3.2 by checking for a null pointer in rtl92c_dm_refresh_rate_adaptive_mask() and then skipping the call to rtl92ce_update_hal_rate_tbl(). References: https://bugs.debian.org/745137 References: https://bugs.debian.org/745462 Reported-by: Dmitry Semyonov <linulin@gmail.com> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: Larry Finger <Larry.Finger@lwfinger.net> Cc: Chaoming Li <chaoming_li@realsil.com.cn>
2014-05-18usb: option: add and update a number of CMOTech devicesBjørn Mork
commit 34f972d6156fe9eea2ab7bb418c71f9d1d5c8e7b upstream. A number of older CMOTech modems are based on Qualcomm chips. The blacklisted interfaces are QMI/wwan. Reported-by: Lars Melin <larsm17@gmail.com> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-05-18usb: option: add Alcatel L800MABjørn Mork
commit dd6b48ecec2ea7d15f28d5e5474388681899a5e1 upstream. Device interface layout: 0: ff/ff/ff - serial 1: ff/00/00 - serial AT+PPP 2: ff/ff/ff - QMI/wwan 3: 08/06/50 - storage Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-05-18usb: option: add Olivetti Olicard 500Bjørn Mork
commit 533b3994610f316e5cd61b56d0c4daa15c830f89 upstream. Device interface layout: 0: ff/ff/ff - serial 1: ff/ff/ff - serial AT+PPP 2: 08/06/50 - storage 3: ff/ff/ff - serial 4: ff/ff/ff - QMI/wwan Reported-by: Julio Araujo <julio.araujo@wllctel.com.br> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-05-18USB: io_ti: fix firmware download on big-endian machinesJohan Hovold
commit 5509076d1b4485ce9fb07705fcbcd2695907ab5b upstream. During firmware download the device expects memory addresses in big-endian byte order. As the wIndex parameter which hold the address is sent in little-endian byte order regardless of host byte order, we need to use swab16 rather than cpu_to_be16. Also make sure to handle the struct ti_i2c_desc size parameter which is returned in little-endian byte order. Reported-by: Ludovic Drolez <ldrolez@debian.org> Tested-by: Ludovic Drolez <ldrolez@debian.org> Signed-off-by: Johan Hovold <jhovold@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2014-05-18usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PMDavid Cohen
commit 01bb59ebffdec314da8da66266edf29529372f9b upstream. When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this warning: drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined but not used [-Wunused-function] Instead of creating nested #ifdefs, this patch fixes it by defining the xHCI PCI stubs as inline. This warning has been in since 3.2 kernel and was caused by commit 421aa841a134f6a743111cf44d0c6d3b45e3cf8c "usb/xhci: hide MSI code behind PCI bars", but wasn't noticed until 3.13 when a configuration with these options was tried Signed-off-by: David Cohen <david.a.cohen@linux.intel.com> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
generated by cgit v1.2.3 (git 2.0.4) at 2026-05-12 01:45:19 +0000