aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2012-01-25iwlegacy: 3945: fix hw passive scan on radar channelsStanislaw Gruszka
commit 68acc4afb040d98ddfd2cae0de09e2f4e1ee127f upstream. Patch fix firmware error on "iw dev wlan0 scan passive" for hardware scanning (with disable_hw_scan=0 module parameter). iwl3945 0000:03:00.0: Microcode SW error detected. Restarting 0x82000008. iwl3945 0000:03:00.0: Loaded firmware version: 15.32.2.9 iwl3945 0000:03:00.0: Start IWL Error Log Dump: iwl3945 0000:03:00.0: Status: 0x0002A2E4, count: 1 iwl3945 0000:03:00.0: Desc Time asrtPC blink2 ilink1 nmiPC Line iwl3945 0000:03:00.0: SYSASSERT (0x5) 0041263900 0x13756 0x0031C 0x00000 764 iwl3945 0000:03:00.0: Error Reply type 0x000002FC cmd C_SCAN (0x80) seq 0x443E ser 0x00340000 iwl3945 0000:03:00.0: Command C_SCAN failed: FW Error iwl3945 0000:03:00.0: Can't stop Rx DMA. We have disable ability to change passive scanning to active on particular channel when traffic is detected on that channel. Otherwise firmware will report error, when we try to do passive scan on radar channels. Reported-and-debugged-by: Pedro Francisco <pedrogfrancisco@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25iwlagn: check for SMPS modeWey-Yi Guy
commit b2ccccdca46273c7b321ecf5041c362cd950da20 upstream. Check and report WARN only when its invalid Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=42621 https://bugzilla.redhat.com/show_bug.cgi?id=766071 Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25i2c-eg20t: modified the setting of transfer rate.Toshiharu Okada
commit ff35e8b18984ad2a82cbd259fc07f0be4b34b1aa upstream. This patch modified the setting value of I2C Bus Transfer Rate Setting Counter regisrer. Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com> Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25rt2800pci: fix spurious interrupts generationStanislaw Gruszka
commit dfd00c4c8f3dfa1fd7cec45f83d98b2a49743dcd upstream. Same devices can generate interrupt without properly setting bit in INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line will be disabled by interrupts controller driver. We discovered that clearing INT_MASK_CSR stops such behaviour. We previously first read that register, and then clear all know interrupt sources bits and do not touch reserved bits. After this patch, we write to all register content (I believe writing to reserved bits on that register will not cause any problems, I tested that on my rt2800pci device). This fix very bad performance problem, practically making device unusable (since worked without interrupts), reported in: https://bugzilla.redhat.com/show_bug.cgi?id=658451 We previously tried to workaround that issue in commit 4ba7d9997869d25bd223dea7536fc1ce9fab3b3b "rt2800pci: handle spurious interrupts", but it was reverted in commit 82e5fc2a34fa9ffea38f00c4066b7e600a0ca5e6 as thing, that will prevent to detect real spurious interrupts. Reported-and-tested-by: Amir Hedayaty <hedayaty@gmail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25ath9k_hw: fix interpretation of the rx KeyMiss flagFelix Fietkau
commit 7a532fe7131216a02c81a6c1b1f8632da1195a58 upstream. Documentation states that the KeyMiss flag is only valid if RxFrameOK is unset, however empirical evidence has shown that this is false. When KeyMiss is set (and RxFrameOK is 1), the hardware passes a valid frame which has not been decrypted. The driver then falsely marks the frame as decrypted, and when using CCMP this corrupts the rx CCMP PN, leading to connection hangs. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25I2C: OMAP: correct SYSC register offset for OMAP4Alexander Aring
commit 2727b1753934e154931d6b3bdf20c9b2398457a2 upstream. Correct OMAP_I2C_SYSC_REG offset in omap4 register map. Offset 0x20 is reserved and OMAP_I2C_SYSC_REG has 0x10 as offset. Signed-off-by: Alexander Aring <a.aring@phytec.de> [khilman@ti.com: minor changelog edits] Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25cx88: fix: don't duplicate xc4000 entry for radioMiroslav Slugen
commit b6854e3f31402476bcc9d2f41570389fa491de17 upstream. All radio tuners in cx88 driver using same address for radio and tuner, so there is no need to probe it twice for same tuner and we can use radio_type UNSET, this also fix broken radio since kernel 2.6.39-rc1 for those tuners. Signed-off-by: Miroslav Slugen <thunder.mmm@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25cx23885-dvb: check if dvb_attach() succededMiroslav Slugen
commit a7c8aadad39428b64d26c3971d967f8314e2397d upstream. Fix possible null dereference for Leadtek DTV 3200H XC4000 tuner when no firmware file available. Signed-off-by: Miroslav Slugen <thunder.mmm@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25bcma: invalidate the mapped core over suspend/resumeRafał Miłecki
commit 28e7d218da975f6ae1751e293aed938952c55c98 upstream. This clears the currently mapped core when suspending, to force re-mapping after resume. Without that we were touching default core registers believing some other core is mapped. Such a behaviour resulted in lockups on some machines. Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25target: Set additional sense length field in sense dataRoland Dreier
commit 895f3022523361e9b383cf48f51feb1f7d5e7e53 upstream. The target code was not setting the additional sense length field in the sense data it returned, which meant that at least the Linux stack ignored the ASC/ASCQ fields. For example, without this patch, on a tcm_loop device: # sg_raw -v /dev/sda 2 0 0 0 0 0 gives cdb to send: 02 00 00 00 00 00 SCSI Status: Check Condition Sense Information: Fixed format, current; Sense key: Illegal Request Raw sense data (in hex): 70 00 05 00 00 00 00 00 while after the patch we correctly get the following (which matches what a regular disk returns): cdb to send: 02 00 00 00 00 00 SCSI Status: Check Condition Sense Information: Fixed format, current; Sense key: Illegal Request Additional sense: Invalid command operation code Raw sense data (in hex): 70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25target: Set response format in INQUIRY responseRoland Dreier
commit ce136176fea522fc8f4c16dcae7e8ed1d890ca39 upstream. Current SCSI specs say that the "response format" field in the standard INQUIRY response should be set to 2, and all the real SCSI devices I have do put 2 here. So let's do that too. Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25sym53c8xx: Fix NULL pointer dereference in slave_destroyStratos Psomadakis
commit cced5041ed5a2d1352186510944b0ddfbdbe4c0b upstream. sym53c8xx_slave_destroy unconditionally assumes that sym53c8xx_slave_alloc has succesesfully allocated a sym_lcb. This can lead to a NULL pointer dereference (exposed by commit 4e6c82b). Signed-off-by: Stratos Psomadakis <psomas@gentoo.org> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25ACPI: processor: fix acpi_get_cpuid for UP processorLin Ming
commit d640113fe80e45ebd4a5b420b220d3f6bf37f682 upstream. For UP processor, it is likely that no _MAT method or MADT table defined. So currently acpi_get_cpuid(...) always return -1 for UP processor. This is wrong. It should return valid value for CPU0. In the other hand, BIOS may define multiple CPU handles even for UP processor, for example Scope (_PR) { Processor (CPU0, 0x00, 0x00000410, 0x06) {} Processor (CPU1, 0x01, 0x00000410, 0x06) {} Processor (CPU2, 0x02, 0x00000410, 0x06) {} Processor (CPU3, 0x03, 0x00000410, 0x06) {} } We should only return valid value for CPU0's acpi handle. And return invalid value for others. http://marc.info/?t=132329819900003&r=1&w=2 Reported-and-tested-by: wallak@free.fr Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25ACPICA: Put back the call to acpi_os_validate_addressLin Ming
commit da4d8b287abe783d30e968155614531a0937d090 upstream. The call to acpi_os_validate_address in acpi_ds_get_region_arguments was removed by mistake in commit 9ad19ac(ACPICA: Split large dsopcode and dsload.c files). Put it back. Reported-and-bisected-by: Luca Tettamanti <kronos.it@gmail.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25ACPI: Store SRAT table revisionKurt Garloff
commit 8df0eb7c9d96f9e82f233ee8b74e0f0c8471f868 upstream. In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides 32bits for these. The new fields were reserved before. According to the ACPI spec, the OS must disregrard reserved fields. In order to know whether or not, we must know what version the SRAT table has. This patch stores the SRAT table revision for later consumption by arch specific __init functions. Signed-off-by: Kurt Garloff <kurt@garloff.de> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25intel_idle: fix API misuseShaohua Li
commit 39a74fdedd1c1461d6fb6d330b5266886513c98f upstream. smp_call_function() only lets all other CPUs execute a specific function, while we expect all CPUs do in intel_idle. Without the fix, we could have one cpu which has auto_demotion enabled or has no broadcast timer setup. Usually we don't see impact because auto demotion just harms power and the intel_idle init is called in CPU 0, where boradcast timer delivers interrupt, but this still could be a problem. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25intel idle: Make idle driver more robustThomas Renninger
commit 5c2a9f06a9cd7194f884cdc88144866235dec07d upstream. kvm -cpu host passes the original cpuid info to the guest. Latest kvm version seem to return true for mwait_leaf cpuid function on recent Intel CPUs. But it does not return mwait C-states (mwait_substates), instead zero is returned. While real CPUs seem to always return non-zero values, the intel idle driver should not get active in kvm (mwait_substates == 0) case and bail out. Otherwise a Null pointer exception will happen later when the cpuidle subsystem tries to get active: [0.984807] BUG: unable to handle kernel NULL pointer dereference at (null) [0.984807] IP: [<(null)>] (null) ... [0.984807][<ffffffff8143cf34>] ? cpuidle_idle_call+0xb4/0x340 [0.984807][<ffffffff8159e7bc>] ? __atomic_notifier_call_chain+0x4c/0x70 [0.984807][<ffffffff81001198>] ? cpu_idle+0x78/0xd0 Reference: https://bugzilla.novell.com/show_bug.cgi?id=726296 Signed-off-by: Thomas Renninger <trenn@suse.de> CC: Bruno Friedmann <bruno@ioda-net.ch> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25dm: do not forward ioctls from logical volumes to the underlying devicePaolo Bonzini
commit ec8013beddd717d1740cfefb1a9b900deef85462 upstream. A logical volume can map to just part of underlying physical volume. In this case, it must be treated like a partition. Based on a patch from Alasdair G Kergon. Cc: Alasdair G Kergon <agk@redhat.com> Cc: dm-devel@redhat.com Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25block: fail SCSI passthrough ioctls on partition devicesPaolo Bonzini
commit 0bfc96cb77224736dfa35c3c555d37b3646ef35e upstream. [ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl and -ENOIOCTLCMD from sd_compat_ioctl. ] Linux allows executing the SG_IO ioctl on a partition or LVM volume, and will pass the command to the underlying block device. This is well-known, but it is also a large security problem when (via Unix permissions, ACLs, SELinux or a combination thereof) a program or user needs to be granted access only to part of the disk. This patch lets partitions forward a small set of harmless ioctls; others are logged with printk so that we can see which ioctls are actually sent. In my tests only CDROM_GET_CAPABILITY actually occurred. Of course it was being sent to a (partition on a) hard disk, so it would have failed with ENOTTY and the patch isn't changing anything in practice. Still, I'm treating it specially to avoid spamming the logs. In principle, this restriction should include programs running with CAP_SYS_RAWIO. If for example I let a program access /dev/sda2 and /dev/sdb, it still should not be able to read/write outside the boundaries of /dev/sda2 independent of the capabilities. However, for now programs with CAP_SYS_RAWIO will still be allowed to send the ioctls. Their actions will still be logged. This patch does not affect the non-libata IDE driver. That driver however already tests for bd != bd->bd_contains before issuing some ioctl; it could be restricted further to forbid these ioctls even for programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO. Cc: linux-scsi@vger.kernel.org Cc: Jens Axboe <axboe@kernel.dk> Cc: James Bottomley <JBottomley@parallels.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [ Make it also print the command name when warning - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25block: add and use scsi_blk_cmd_ioctlPaolo Bonzini
commit 577ebb374c78314ac4617242f509e2f5e7156649 upstream. Introduce a wrapper around scsi_cmd_ioctl that takes a block device. The function will then be enhanced to detect partition block devices and, in that case, subject the ioctls to whitelisting. Cc: linux-scsi@vger.kernel.org Cc: Jens Axboe <axboe@kernel.dk> Cc: James Bottomley <JBottomley@parallels.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25HID: hid-multitouch: add support 9 new Xiroku devicesMasatoshi Hoshikawa
commit 11576c6114c3b6505aea2e0c988bedb856a0e20c upstream. This patch adds support for the Xiroku Inc. panels (SPX/MPX/CSR/etc.). Signed-off-by: Masatoshi Hoshikawa <hoshikawa@xiroku.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25HID: multitouch: add support for 3M 32"Benjamin Tissoires
commit c4fad877cd0efb51d8180ae2eaa791c99c92051c upstream. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Acked-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25HID: multitouch: add support of Atmel multitouch panelsBenjamin Tissoires
commit b105712469d957cf1ab223c1ea72b7ba88edb926 upstream. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Acked-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25HID: hid-multitouch: add support for new Hanvon panelsBenjamin Tissoires
commit 545803651da8dde248eeb8ce3ed1e547e9e4ac0a upstream. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr> Acked-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25HID: multitouch: add support for the MSI Windpad 110WBenjamin Tissoires
commit 66f06127f34ad6e8a1b24a2c03144b694d19f99f upstream. Just another eGalax device. Please note that adding this device to have_special_driver in hid-core.c is not required anymore. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25HID: multitouch: Add egalax ID for Acer Iconia W500Marek Vasut
commit bb9ff21072043634f147c05ac65dbf8185d4af6d upstream. This patch adds USB ID for the touchpanel in Acer Iconia W500. The panel supports up to five fingers, therefore the need for a new addition of panel types. Signed-off-by: Marek Vasut <marek.vasut@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25HID: multitouch: cleanup with eGalax PID definitionsBenjamin Tissoires
commit e36f690b37945e0a9bb1554e1546eeec93f7d1f6 upstream. This is just a renaming of USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH{N} to USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_{PID} to handle more eGalax devices. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@enac.fr> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25HID: hid-multitouch - add another eGalax idChris Bagwell
commit 1fd8f047490dd0ec4e4db710fcbc1bd4798d944c upstream. This allows ASUS Eee Slate touchscreens to work. Signed-off-by: Chris Bagwell <chris@cnpbagwell.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25uvcvideo: Fix integer overflow in uvc_ioctl_ctrl_map()Haogang Chen
commit 806e23e95f94a27ee445022d724060b9b45cb64a upstream. There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a large xmap->menu_count is passed from the userspace, the subsequent call to kmalloc() will allocate a buffer smaller than expected. map->menu_count and map->menu_info would later be used in a loop (e.g. in uvc_query_v4l2_ctrl), which leads to out-of-bound access. The patch checks the ioctl argument and returns -EINVAL for zero or too large values in xmap->menu_count. Signed-off-by: Haogang Chen <haogangchen@gmail.com> [laurent.pinchart@ideasonboard.com Prevent excessive memory consumption] Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()Dan Carpenter
commit 6c06108be53ca5e94d8b0e93883d534dd9079646 upstream. If ctrls->count is too high the multiplication could overflow and array_size would be lower than expected. Mauro and Hans Verkuil suggested that we cap it at 1024. That comes from the maximum number of controls with lots of room for expantion. $ grep V4L2_CID include/linux/videodev2.h | wc -l 211 Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25mmc: sd: Fix SDR12 timing regressionAlexander Elbs
commit dd8df17fe83483d7ea06ff229895e35a42071599 upstream. This patch fixes a failure to recognize SD cards reported on a Dell Vostro with O2 Micro SD card reader. Patch 49c468f ("mmc: sd: add support for uhs bus speed mode selection") caused the problem, by setting the SDHCI_CTRL_HISPD flag even for legacy timings. Signed-off-by: Alexander Elbs <alex@segv.de> Acked-by: Philip Rakity <prakity@marvell.com> Acked-by: Arindam Nath <arindam.nath@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25mmc: sdhci: Fix tuning timer incorrect setting when suspending hostAaron Lu
commit c6ced0db08010ed75df221a2946c5228454b38d5 upstream. When suspending host, the tuning timer shoule be deactivated. And the HOST_NEEDS_TUNING flag should be set after tuning timer is deactivated. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Aaron Lu <aaron.lu@amd.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25mmc: core: Fix voltage select in DDR modeGirish K S
commit 913047e9e5787a90696533a9f109552b7694ecc9 upstream. This patch fixes the wrong comparison before setting the interface voltage in DDR mode. The assignment to the variable ddr before comaprison is either ddr = MMC_1_2V_DDR_MODE; or ddr == MMC_1_8V_DDR_MODE. But the comparison is done with the extended csd value if ddr == EXT_CSD_CARD_TYPE_DDR_1_2V. Signed-off-by: Girish K S <girish.shivananjappa@linaro.org> Acked-by: Subhash Jadavani <subhashj@codeaurora.org> Acked-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25i2c: Fix error value returned by several bus driversJean Delvare
commit 7c1f59c9d5caf3a84f35549b5d58f3c055a68da5 upstream. When adding checks for ACPI resource conflicts to many bus drivers, not enough attention was paid to the error paths, and for several drivers this causes 0 to be returned on error in some cases. Fix this by properly returning a non-zero value on every error. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25UBI: make vid_hdr non-staticRichard Weinberger
commit 6bdccffe8c4268d02f71873102131fb6ed37ed9a upstream. Remove 'static' modifier from the 'vid_hdr' local variable. I do not know how it slipped in, but this is a bug and will break UBI if someone attaches 2 UBI volumes at the same time. Artem: amended teh commit message, added -stable. Signed-off-by: Richard Weinberger <rw@linutronix.de> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25UBI: fix debugging messagesArtem Bityutskiy
commit 72f0d453d81d35087b1d3ad7c8285628c2be6e1d upstream. Patch ab50ff684707031ed4bad2fdd313208ae392e5bb broke UBI debugging messages: before that commit when UBI debugging was enabled, users saw few useful debugging messages after attaching an MTD device. However, that patch turned 'dbg_msg()' into 'pr_debug()', so to enable the debugging messages users have to enable them first via /sys/kernel/debug/dynamic_debug/control, which is very impractical. This commit makes 'dbg_msg()' to use 'printk()' instead of 'pr_debug()', just as it was before the breakage. Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25UBI: fix nameless volumes handlingRichard Weinberger
commit 4a59c797a18917a5cf3ff7ade296b46134d91e6a upstream. Currently it's possible to create a volume without a name. E.g: ubimkvol -n 32 -s 2MiB -t static /dev/ubi0 -N "" After that vtbl_check() will always fail because it does not permit empty strings. Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25ath9k: Fix regression in channelwidth switch at the same channelRajkumar Manoharan
commit 1a19f77f3642b8194ad9cf55548cc5d92e841766 upstream. The commit "ath9k: Fix invalid noisefloor reading due to channel update" preserves the current channel noisefloor readings before updating channel type at the same channel index. It is also updating the curchan pointer. As survey updation is also referring curchan pointer to fetch the appropriate index, which might leads to invalid memory access. This patch partially reverts the change and stores the noise floor history buffer before updating channel type w/o updating curchan. Cc: Gary Morain <gmorain@google.com> Cc: Paul Stewart <pstew@google.com> Reported-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com> Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25rtl8192se: Fix BUG caused by failure to check skb allocationLarry Finger
commit d90db4b12bc1b9b8a787ef28550fdb767ee25a49 upstream. When downloading firmware into the device, the driver fails to check the return when allocating an skb. When the allocation fails, a BUG can be generated, as seen in https://bugzilla.redhat.com/show_bug.cgi?id=771656. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25asix: fix setting custom MAC address on Asix 88772 devicesJussi Kivilinna
commit 8ef66bdc4bda6aac2dae73b84d79dc8c2db33637 upstream. In kernel v3.2 initialization sequence for Asix 88772 devices was changed so that hardware is reseted on every time interface is brought up (ifconfig up), instead just at USB probe time. This causes problem with setting custom MAC address to device as ax88772_reset causes reload of MAC address from EEPROM. This patch fixes the issue by rewriting MAC address at end of ax88772_reset. Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Acked-by: Grant Grundler <grundler@chromium.org> Cc: Allan Chou <allan@asix.com.tw> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25asix: fix setting custom MAC address on Asix 88178 devicesJussi Kivilinna
commit 71bc5d94061516c4e70303570128797bcf768b10 upstream. In kernel v3.2 initialization sequence for Asix 88178 devices was changed so that hardware is reseted on every time interface is brought up (ifconfig up), instead just at USB probe time. This causes problem with setting custom MAC address to device as ax88178_reset causes reload of MAC address from EEPROM. This patch fixes the issue by rewriting MAC address at end of ax88178_reset. Signed-off-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi> Acked-by: Grant Grundler <grundler@chromium.org> Cc: Allan Chou <allan@asix.com.tw> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25PNP: work around Dell 1536/1546 BIOS MMCONFIG bug that breaks USBBjorn Helgaas
commit eb31aae8cb5eb54e234ed2d857ddac868195d911 upstream. Some Dell BIOSes have MCFG tables that don't report the entire MMCONFIG area claimed by the chipset. If we move PCI devices into that claimed-but-unreported area, they don't work. This quirk reads the AMD MMCONFIG MSRs and adds PNP0C01 resources as needed to cover the entire area. Example problem scenario: BIOS-e820: 00000000cfec5400 - 00000000d4000000 (reserved) Fam 10h mmconf [d0000000, dfffffff] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xd0000000-0xd3ffffff] (base 0xd0000000) pnp 00:0c: [mem 0xd0000000-0xd3ffffff] pci 0000:00:12.0: reg 10: [mem 0xffb00000-0xffb00fff] pci 0000:00:12.0: no compatible bridge window for [mem 0xffb00000-0xffb00fff] pci 0000:00:12.0: BAR 0: assigned [mem 0xd4000000-0xd40000ff] Reported-by: Lisa Salimbas <lisa.salimbas@canonical.com> Reported-by: <thuban@singularity.fr> Tested-by: dann frazier <dann.frazier@canonical.com> References: https://bugzilla.kernel.org/show_bug.cgi?id=31602 References: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/647043 References: https://bugzilla.redhat.com/show_bug.cgi?id=770308 Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25md/raid1: perform bad-block tests for WriteMostly devices too.NeilBrown
commit 307729c8bc5b5a41361af8af95906eee7552acb1 upstream. We normally try to avoid reading from write-mostly devices, but when we do we really have to check for bad blocks and be sure not to try reading them. With the current code, best_good_sectors might not get set and that causes zero-length read requests to be send down which is very confusing. This bug was introduced in commit d2eb35acfdccbe2 and so the patch is suitable for 3.1.x and 3.2.x Reported-and-tested-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Reported-and-tested-by: Art -kwaak- van Breemen <ard@telegraafnet.nl> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25xen/xenbus: Reject replies with payload > XENSTORE_PAYLOAD_MAX.Ian Campbell
commit 9e7860cee18241633eddb36a4c34c7b61d8cecbc upstream. Haogang Chen found out that: There is a potential integer overflow in process_msg() that could result in cross-domain attack. body = kmalloc(msg->hdr.len + 1, GFP_NOIO | __GFP_HIGH); When a malicious guest passes 0xffffffff in msg->hdr.len, the subsequent call to xb_read() would write to a zero-length buffer. The other end of this connection is always the xenstore backend daemon so there is no guest (malicious or otherwise) which can do this. The xenstore daemon is a trusted component in the system. However this seem like a reasonable robustness improvement so we should have it. And Ian when read the API docs found that: The payload length (len field of the header) is limited to 4096 (XENSTORE_PAYLOAD_MAX) in both directions. If a client exceeds the limit, its xenstored connection will be immediately killed by xenstored, which is usually catastrophic from the client's point of view. Clients (particularly domains, which cannot just reconnect) should avoid this. so this patch checks against that instead. This also avoids a potential integer overflow pointed out by Haogang Chen. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Haogang Chen <haogangchen@gmail.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25SCSI: mpt2sas : Fix for memory allocation error for large host creditsnagalakshmi.nandigama@lsi.com
commit aff132d95ffe14eca96cab90597cdd010b457af7 upstream. The amount of memory required for tracking chain buffers is rather large, and when the host credit count is big, memory allocation failure occurs inside __get_free_pages. The fix is to limit the number of chains to 100,000. In addition, the number of host credits is limited to 30,000 IOs. However this limitation can be overridden this using the command line option max_queue_depth. The algorithm for calculating the reply_post_queue_depth is changed so that it is equal to (reply_free_queue_depth + 16), previously it was (reply_free_queue_depth * 2). Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25SCSI: mpt2sas: Release spinlock for the raid device list before blocking itnagalakshmi.nandigama@lsi.com
commit 30c43282f3d347f47f9e05199d2b14f56f3f2837 upstream. Added code to release the spinlock that is used to protect the raid device list before calling a function that can block. The blocking was causing a reschedule, and subsequently it is tried to acquire the same lock, resulting in a panic (NMI Watchdog detecting a CPU lockup). Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com> Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25PCI: msi: Disable msi interrupts when we initialize a pci deviceEric W. Biederman
commit a776c491ca5e38c26d9f66923ff574d041e747f4 upstream. I traced a nasty kexec on panic boot failure to the fact that we had screaming msi interrupts and we were not disabling the msi messages at kernel startup. The booting kernel had not enabled those interupts so was not prepared to handle them. I can see no reason why we would ever want to leave the msi interrupts enabled at boot if something else has enabled those interrupts. The pci spec specifies that msi interrupts should be off by default. Drivers are expected to enable the msi interrupts if they want to use them. Our interrupt handling code reprograms the interrupt handlers at boot and will not be be able to do anything useful with an unexpected interrupt. This patch applies cleanly all of the way back to 2.6.32 where I noticed the problem. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25UBI: fix use-after-free on error pathArtem Bityutskiy
commit e57e0d8e818512047fe379157c3f77f1b9fabffb upstream. When we fail to erase a PEB, we free the corresponding erase entry object, but then re-schedule this object if the error code was something like -EAGAIN. Obviously, it is a bug to use the object after we have freed it. Reported-by: Emese Revfy <re.emese@gmail.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25UBI: fix missing scrub when there is a bit-flipBhavesh Parekh
commit e801e128b2200c40a0ec236cf2330b2586b6e05a upstream. Under some cases, when scrubbing the PEB if we did not get the lock on the PEB it fails to scrub. Add that PEB again to the scrub list Artem: minor amendments. Signed-off-by: Bhavesh Parekh <bparekh@nvidia.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2012-01-25HID: wiimote: Select INPUT_FF_MEMLESSDavid Herrmann
commit ef6f41157f3864d9bf42671b2ed66062dcafb72e upstream. We depend on memless force-feedback support, therefore correctly select the related config options. Reported-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>