summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
...
* gpu: ipu-v3: Do not bail out on missing optional port nodesPhilipp Zabel2016-03-161-9/+12
| | | | | | | | | | | | | commit 17e0521750399205f432966e602e125294879cdd upstream. The port nodes are documented as optional, treat them accordingly. Reported-by: Martin Fuzzey <mfuzzey@parkeon.com> Reported-by: Chris Healy <Chris.Healy@zii.aero> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Fixes: 304e6be652e2 ("gpu: ipu-v3: Assign of_node of child platform devices to corresponding ports") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iwlwifi: mvm: inc pending frames counter also when txing non-staLiad Kaufman2016-03-161-0/+9
| | | | | | | | | | | | | | | | | | | | | commit fb896c44f88a75843a072cd6961b1615732f7811 upstream. Until this patch, when TXing non-sta the pending_frames counter wasn't increased, but it WAS decreased in iwl_mvm_rx_tx_cmd_single(), what makes it negative in certain conditions. This in turn caused much trouble when we need to remove the station since we won't be waiting forever until pending_frames gets 0. In certain cases, we were exhausting the station table even in BSS mode, because we had a lot of stale stations. Increase the counter also in iwl_mvm_tx_skb_non_sta() after a successful TX to avoid this outcome. Signed-off-by: Liad Kaufman <liad.kaufman@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* can: gs_usb: fixed disconnect bug by removing erroneous use of kfree()Maximilain Schneider2016-03-161-13/+11
| | | | | | | | | | | | | | | | | | | commit e9a2d81b1761093386a0bb8a4f51642ac785ef63 upstream. gs_destroy_candev() erroneously calls kfree() on a struct gs_can *, which is allocated through alloc_candev() and should instead be freed using free_candev() alone. The inappropriate use of kfree() causes the kernel to hang when gs_destroy_candev() is called. Only the struct gs_usb * which is allocated through kzalloc() should be freed using kfree() when the device is disconnected. Signed-off-by: Maximilian Schneider <max@schneidersoft.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* dmaengine: at_xdmac: fix residue computationLudovic Desroches2016-03-161-3/+39
| | | | | | | | | | | | | | | | | | | | commit 25c5e9626ca4d40928dc9c44f009ce2ed0a739e7 upstream. When computing the residue we need two pieces of information: the current descriptor and the remaining data of the current descriptor. To get that information, we need to read consecutively two registers but we can't do it in an atomic way. For that reason, we have to check manually that current descriptor has not changed. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Suggested-by: Cyrille Pitchen <cyrille.pitchen@atmel.com> Reported-by: David Engraf <david.engraf@sysgo.com> Tested-by: David Engraf <david.engraf@sysgo.com> Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel eXtended DMA Controller driver") Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* s390/dasd: fix diag 0x250 inline assemblyHeiko Carstens2016-03-161-2/+7
| | | | | | | | | | | | | | | | | | | | | | | commit ce0c12b633846a47e103842149a5bac2e5d261ec upstream. git commit 1ec2772e0c3c ("s390/diag: add a statistic for diagnose calls") added function calls to gather diagnose statistics. In case of the dasd diag driver the function call was added between a register asm statement which initialized register r2 and the inline assembly itself. The function call clobbers the contents of register r2 and therefore the diag 0x250 call behaves in a more or less random way. Fix this by extracting the function call into a separate function like we do everywhere else. Fixes: 1ec2772e0c3c ("s390/diag: add a statistic for diagnose calls") Reported-and-tested-by: Stefan Haberland <sth@linux.vnet.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* PCI: Allow a NULL "parent" pointer in pci_bus_assign_domain_nr()Krzysztof Hałasa2016-03-161-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 54c6e2dd00c313d0add58e5befe62fe6f286d03b upstream. pci_create_root_bus() passes a "parent" pointer to pci_bus_assign_domain_nr(). When CONFIG_PCI_DOMAINS_GENERIC is defined, pci_bus_assign_domain_nr() dereferences that pointer. Many callers of pci_create_root_bus() supply a NULL "parent" pointer, which leads to a NULL pointer dereference error. 7c674700098c ("PCI: Move domain assignment from arm64 to generic code") moved the "parent" dereference from arm64 to generic code. Only arm64 used that code (because only arm64 defined CONFIG_PCI_DOMAINS_GENERIC), and it always supplied a valid "parent" pointer. Other arches supplied NULL "parent" pointers but didn't defined CONFIG_PCI_DOMAINS_GENERIC, so they used a no-op version of pci_bus_assign_domain_nr(). 8c7d14746abc ("ARM/PCI: Move to generic PCI domains") defined CONFIG_PCI_DOMAINS_GENERIC on ARM, and many ARM platforms use pci_common_init(), which supplies a NULL "parent" pointer. These platforms (cns3xxx, dove, footbridge, iop13xx, etc.) crash with a NULL pointer dereference like this while probing PCI: Unable to handle kernel NULL pointer dereference at virtual address 000000a4 PC is at pci_bus_assign_domain_nr+0x10/0x84 LR is at pci_create_root_bus+0x48/0x2e4 Kernel panic - not syncing: Attempted to kill init! [bhelgaas: changelog, add "Reported:" and "Fixes:" tags] Reported: http://forum.doozan.com/read.php?2,17868,22070,quote=1 Fixes: 8c7d14746abc ("ARM/PCI: Move to generic PCI domains") Fixes: 7c674700098c ("PCI: Move domain assignment from arm64 to generic code") Signed-off-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amdgpu: fix topaz/tonga gmc assignment in 4.4 stableAlex Deucher2016-03-091-6/+6
| | | | | | | | | | | | | When upstream commit 429c45deae6e57f1bb91bfb05b671063fb0cef60 was applied to 4.4 as d60703ca942e8d044d61360bc9792fcab54b95d0 it applied incorrectly to the tonga_ip_blocks array rather than the topaz_ip_blocks array. Fix that up here. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=113951 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/i915: refine qemu south bridge detectionGerd Hoffmann2016-03-091-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | commit f2e305108faba0c85eb4ba4066599decb675117e upstream. The test for the qemu q35 south bridge added by commit "39bfcd52 drm/i915: more virtual south bridge detection" also matches on real hardware. Having the check for virtual systems last in the list is not enough to avoid that ... Refine the check by additionally verifying the pci subsystem id to see whenever it *really* is qemu. [ v2: fix subvendor tyops ] Reported-and-tested-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Bruno Wolff III <bruno@wolff.to> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1453719748-10944-1-git-send-email-kraxel@redhat.com (cherry picked from commit 1e859111c128265f8d62b39ff322e42b1ddb5a20) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/i915: more virtual south bridge detectionGerd Hoffmann2016-03-092-1/+3
| | | | | | | | | | | | | commit 39bfcd5235e07e95ad3e70eab8e0b85db181de9e upstream. Commit "30c964a drm/i915: Detect virtual south bridge" detects and handles the southbridge emulated by vmware esx. Add the ich9 south bridge emulated by 'qemu -M q35'. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amdgpu: Use drm_calloc_large for VM page_tables arrayMichel Dänzer2016-03-091-4/+3
| | | | | | | | | | | | | | | commit 9571e1d84042f5670df9fabdcbe7dd5da3abe43e upstream. It can be big, depending on the VM address space size, which is tunable via the vm_size module parameter. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93721 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* thermal: cpu_cooling: fix out of bounds access in time_in_idleJavi Merino2016-03-091-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | commit a53b8394ec3c67255928df6ee9cc99dd1cd452e3 upstream. In __cpufreq_cooling_register() we allocate the arrays for time_in_idle and time_in_idle_timestamp to be as big as the number of cpus in this cpufreq device. However, in get_load() we access this array using the cpu number as index, which can result in an out of bound access. Index time_in_idle{,_timestamp} using the index in the cpufreq_device's allowed_cpus mask, as we do for the load_cpu array in cpufreq_get_requested_power() Reported-by: Nicolas Boichat <drinkcat@chromium.org> Cc: Amit Daniel Kachhap <amit.kachhap@gmail.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Javi Merino <javi.merino@arm.com> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* i2c: brcmstb: allocate correct amount of memory for regmapWolfram Sang2016-03-091-2/+1
| | | | | | | | | | | | | | | commit 7314d22a2f5bd40468d57768be368c3d9b4bd726 upstream. We want the size of the struct, not of a pointer to it. To be future proof, just dereference the pointer to get the desired type. Fixes: dd1aa2524bc5 ("i2c: brcmstb: Add Broadcom settop SoC i2c controller driver") Acked-by: Gregory Fong <gregory.0xf0@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Kamal Dasu <kdasu.kdev@gmail.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ubi: Fix out of bounds write in volume update codeRichard Weinberger2016-03-091-1/+1
| | | | | | | | | | | | | commit e4f6daac20332448529b11f09388f1d55ef2084c upstream. ubi_start_leb_change() allocates too few bytes. ubi_more_leb_change_data() will write up to req->upd_bytes + ubi->min_io_size bytes. Signed-off-by: Richard Weinberger <richard@nod.at> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* cxl: Fix PSL timebase synchronization detectionFrederic Barrat2016-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | commit 923adb1646d5ba739d2a1e63ee20d60574d9da8e upstream. The PSL timebase synchronization is seemingly failing for configuration not including VIRT_CPU_ACCOUNTING_NATIVE. The driver shows the following trace in dmesg: PSL: Timebase sync: giving up! The PSL timebase register is actually syncing correctly, but the cxl driver is not detecting it. Fix is to use the proper timebase-to-time conversion. Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Acked-by: Michael Neuling <mikey@neuling.org> Reviewed-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Acked-by: Ian Munsie <imunsie@au1.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: serial: option: add support for Quectel UC20Yegor Yefremov2016-03-091-0/+2
| | | | | | | | | | | | commit c0992d0f54847d0d1d85c60fcaa054f175ab1ccd upstream. Add support for Quectel UC20 and blacklist the QMI interface. Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com> [johan: amend commit message ] Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: serial: option: add support for Telit LE922 PID 0x1045Daniele Palmas2016-03-091-0/+3
| | | | | | | | | | | commit 5deef5551c77e488922cc4bf4bc76df63be650d0 upstream. This patch adds support for 0x1045 PID of Telit LE922. Signed-off-by: Daniele Palmas <dnlplm@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: qcserial: add Sierra Wireless EM74xx device IDBjørn Mork2016-03-091-2/+4
| | | | | | | | | | | | commit 04fdbc825ffc02fb098964b92de802fff44e73fd upstream. The MC74xx and EM74xx modules use different IDs by default, according to the Lenovo EM7455 driver for Windows. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: qcserial: add Dell Wireless 5809e Gobi 4G HSPA+ (rev3)Patrik Halfar2016-03-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 013dd239d6220a4e0dfdf0d45a82c34f1fd73deb upstream. New revision of Dell Wireless 5809e Gobi 4G HSPA+ Mobile Broadband Card has new idProduct. Bus 002 Device 006: ID 413c:81b3 Dell Computer Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x413c Dell Computer Corp. idProduct 0x81b3 bcdDevice 0.06 iManufacturer 1 Sierra Wireless, Incorporated iProduct 2 Dell Wireless 5809e Gobi™ 4G HSPA+ Mobile Broadband Card iSerial 3 bNumConfigurations 2 Signed-off-by: Patrik Halfar <patrik_halfar@halfarit.cz> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* USB: cp210x: Add ID for Parrot NMEA GPS Flight RecorderVittorio Alfieri2016-03-091-0/+1
| | | | | | | | | | | | | | | | commit 3c4c615d70c8cbdc8ba8c79ed702640930652a79 upstream. The Parrot NMEA GPS Flight Recorder is a USB composite device consisting of hub, flash storage, and cp210x usb to serial chip. It is an accessory to the mass-produced Parrot AR Drone 2. The device emits standard NMEA messages which make the it compatible with NMEA compatible software. It was tested using gpsd version 3.11-3 as an NMEA interpreter and using the official Parrot Flight Recorder. Signed-off-by: Vittorio Alfieri <vittorio88@gmail.com> Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* usb: chipidea: otg: change workqueue ci_otg as freezablePeter Chen2016-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit d144dfea8af7108f613139623e63952ed7e69c0c upstream. If we use USB ID pin as wakeup source, and there is a USB block device on this USB OTG (ID) cable, the system will be deadlock after system resume. The root cause for this problem is: the workqueue ci_otg may try to remove hcd before the driver resume has finished, and hcd will disconnect the device on it, then, it will call device_release_driver, and holds the device lock "dev->mutex", but it is never unlocked since it waits workqueue writeback to run to flush the block information, but the workqueue writeback is freezable, it is not thawed before driver resume has finished. When the driver (device: sd 0:0:0:0:) resume goes to dpm_complete, it tries to get its device lock "dev->mutex", but it can't get it forever, then the deadlock occurs. Below call stacks show the situation. So, in order to fix this problem, we need to change workqueue ci_otg as freezable, then the work item in this workqueue will be run after driver's resume, this workqueue will not be blocked forever like above case since the workqueue writeback has been thawed too. Tested at: i.mx6qdl-sabresd and i.mx6sx-sdb. [ 555.178869] kworker/u2:13 D c07de74c 0 826 2 0x00000000 [ 555.185310] Workqueue: ci_otg ci_otg_work [ 555.189353] Backtrace: [ 555.191849] [<c07de4fc>] (__schedule) from [<c07dec6c>] (schedule+0x48/0xa0) [ 555.198912] r10:ee471ba0 r9:00000000 r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4 [ 555.206867] r4:ee470000 [ 555.209453] [<c07dec24>] (schedule) from [<c07e2fc4>] (schedule_timeout+0x15c/0x1e0) [ 555.217212] r4:7fffffff r3:edc2b000 [ 555.220862] [<c07e2e68>] (schedule_timeout) from [<c07df6c8>] (wait_for_common+0x94/0x144) [ 555.229140] r8:00000000 r7:00000002 r6:ee470000 r5:ee471ba4 r4:7fffffff [ 555.235980] [<c07df634>] (wait_for_common) from [<c07df790>] (wait_for_completion+0x18/0x1c) [ 555.244430] r10:00000001 r9:c0b5563c r8:c0042e48 r7:ef086000 r6:eea4372c r5:ef131b00 [ 555.252383] r4:00000000 [ 555.254970] [<c07df778>] (wait_for_completion) from [<c0043cb8>] (flush_work+0x19c/0x234) [ 555.263177] [<c0043b1c>] (flush_work) from [<c0043fac>] (flush_delayed_work+0x48/0x4c) [ 555.271106] r8:ed5b5000 r7:c0b38a3c r6:eea439cc r5:eea4372c r4:eea4372c [ 555.277958] [<c0043f64>] (flush_delayed_work) from [<c00eae18>] (bdi_unregister+0x84/0xec) [ 555.286236] r4:eea43520 r3:20000153 [ 555.289885] [<c00ead94>] (bdi_unregister) from [<c02c2154>] (blk_cleanup_queue+0x180/0x29c) [ 555.298250] r5:eea43808 r4:eea43400 [ 555.301909] [<c02c1fd4>] (blk_cleanup_queue) from [<c0417914>] (__scsi_remove_device+0x48/0xb8) [ 555.310623] r7:00000000 r6:20000153 r5:ededa950 r4:ededa800 [ 555.316403] [<c04178cc>] (__scsi_remove_device) from [<c0415e90>] (scsi_forget_host+0x64/0x68) [ 555.325028] r5:ededa800 r4:ed5b5000 [ 555.328689] [<c0415e2c>] (scsi_forget_host) from [<c0409828>] (scsi_remove_host+0x78/0x104) [ 555.337054] r5:ed5b5068 r4:ed5b5000 [ 555.340709] [<c04097b0>] (scsi_remove_host) from [<c04cdfcc>] (usb_stor_disconnect+0x50/0xb4) [ 555.349247] r6:ed5b56e4 r5:ed5b5818 r4:ed5b5690 r3:00000008 [ 555.355025] [<c04cdf7c>] (usb_stor_disconnect) from [<c04b3bc8>] (usb_unbind_interface+0x78/0x25c) [ 555.363997] r8:c13919b4 r7:edd3c000 r6:edd3c020 r5:ee551c68 r4:ee551c00 r3:c04cdf7c [ 555.371892] [<c04b3b50>] (usb_unbind_interface) from [<c03dc248>] (__device_release_driver+0x8c/0x118) [ 555.381213] r10:00000001 r9:edd90c00 r8:c13919b4 r7:ee551c68 r6:c0b546e0 r5:c0b5563c [ 555.389167] r4:edd3c020 [ 555.391752] [<c03dc1bc>] (__device_release_driver) from [<c03dc2fc>] (device_release_driver+0x28/0x34) [ 555.401071] r5:edd3c020 r4:edd3c054 [ 555.404721] [<c03dc2d4>] (device_release_driver) from [<c03db304>] (bus_remove_device+0xe0/0x110) [ 555.413607] r5:edd3c020 r4:ef17f04c [ 555.417253] [<c03db224>] (bus_remove_device) from [<c03d8128>] (device_del+0x114/0x21c) [ 555.425270] r6:edd3c028 r5:edd3c020 r4:ee551c00 r3:00000000 [ 555.431045] [<c03d8014>] (device_del) from [<c04b1560>] (usb_disable_device+0xa4/0x1e8) [ 555.439061] r8:edd3c000 r7:eded8000 r6:00000000 r5:00000001 r4:ee551c00 [ 555.445906] [<c04b14bc>] (usb_disable_device) from [<c04a8e54>] (usb_disconnect+0x74/0x224) [ 555.454271] r9:edd90c00 r8:ee551000 r7:ee551c68 r6:ee551c9c r5:ee551c00 r4:00000001 [ 555.462156] [<c04a8de0>] (usb_disconnect) from [<c04a8fb8>] (usb_disconnect+0x1d8/0x224) [ 555.470259] r10:00000001 r9:edd90000 r8:ee471e2c r7:ee551468 r6:ee55149c r5:ee551400 [ 555.478213] r4:00000001 [ 555.480797] [<c04a8de0>] (usb_disconnect) from [<c04ae5ec>] (usb_remove_hcd+0xa0/0x1ac) [ 555.488813] r10:00000001 r9:ee471eb0 r8:00000000 r7:ef3d9500 r6:eded810c r5:eded80b0 [ 555.496765] r4:eded8000 [ 555.499351] [<c04ae54c>] (usb_remove_hcd) from [<c04d4158>] (host_stop+0x28/0x64) [ 555.506847] r6:eeb50010 r5:eded8000 r4:eeb51010 [ 555.511563] [<c04d4130>] (host_stop) from [<c04d09b8>] (ci_otg_work+0xc4/0x124) [ 555.518885] r6:00000001 r5:eeb50010 r4:eeb502a0 r3:c04d4130 [ 555.524665] [<c04d08f4>] (ci_otg_work) from [<c00454f0>] (process_one_work+0x194/0x420) [ 555.532682] r6:ef086000 r5:eeb502a0 r4:edc44480 [ 555.537393] [<c004535c>] (process_one_work) from [<c00457b0>] (worker_thread+0x34/0x514) [ 555.545496] r10:edc44480 r9:ef086000 r8:c0b1a100 r7:ef086034 r6:00000088 r5:edc44498 [ 555.553450] r4:ef086000 [ 555.556032] [<c004577c>] (worker_thread) from [<c004bab4>] (kthread+0xdc/0xf8) [ 555.563268] r10:00000000 r9:00000000 r8:00000000 r7:c004577c r6:edc44480 r5:eddc15c0 [ 555.571221] r4:00000000 [ 555.573804] [<c004b9d8>] (kthread) from [<c000fef0>] (ret_from_fork+0x14/0x24) [ 555.581040] r7:00000000 r6:00000000 r5:c004b9d8 r4:eddc15c0 [ 553.429383] sh D c07de74c 0 694 691 0x00000000 [ 553.435801] Backtrace: [ 553.438295] [<c07de4fc>] (__schedule) from [<c07dec6c>] (schedule+0x48/0xa0) [ 553.445358] r10:edd3c054 r9:edd3c078 r8:edddbd50 r7:edcbbc00 r6:c1377c34 r5:60000153 [ 553.453313] r4:eddda000 [ 553.455896] [<c07dec24>] (schedule) from [<c07deff8>] (schedule_preempt_disabled+0x10/0x14) [ 553.464261] r4:edd3c058 r3:0000000a [ 553.467910] [<c07defe8>] (schedule_preempt_disabled) from [<c07e0bbc>] (mutex_lock_nested+0x1a0/0x3e8) [ 553.477254] [<c07e0a1c>] (mutex_lock_nested) from [<c03e927c>] (dpm_complete+0xc0/0x1b0) [ 553.485358] r10:00561408 r9:edd3c054 r8:c0b4863c r7:edddbd90 r6:c0b485d8 r5:edd3c020 [ 553.493313] r4:edd3c0d0 [ 553.495896] [<c03e91bc>] (dpm_complete) from [<c03e9388>] (dpm_resume_end+0x1c/0x20) [ 553.503652] r9:00000000 r8:c0b1a9d0 r7:c1334ec0 r6:c1334edc r5:00000003 r4:00000010 [ 553.511544] [<c03e936c>] (dpm_resume_end) from [<c0079894>] (suspend_devices_and_enter+0x158/0x504) [ 553.520604] r4:00000000 r3:c1334efc [ 553.524250] [<c007973c>] (suspend_devices_and_enter) from [<c0079e74>] (pm_suspend+0x234/0x2cc) [ 553.532961] r10:00561408 r9:ed6b7300 r8:00000004 r7:c1334eec r6:00000000 r5:c1334ee8 [ 553.540914] r4:00000003 [ 553.543493] [<c0079c40>] (pm_suspend) from [<c0078a6c>] (state_store+0x6c/0xc0) [ 555.703684] 7 locks held by kworker/u2:13/826: [ 555.708140] #0: ("%s""ci_otg"){++++.+}, at: [<c0045484>] process_one_work+0x128/0x420 [ 555.716277] #1: ((&ci->work)){+.+.+.}, at: [<c0045484>] process_one_work+0x128/0x420 [ 555.724317] #2: (usb_bus_list_lock){+.+.+.}, at: [<c04ae5e4>] usb_remove_hcd+0x98/0x1ac [ 555.732626] #3: (&dev->mutex){......}, at: [<c04a8e28>] usb_disconnect+0x48/0x224 [ 555.740403] #4: (&dev->mutex){......}, at: [<c04a8e28>] usb_disconnect+0x48/0x224 [ 555.748179] #5: (&dev->mutex){......}, at: [<c03dc2f4>] device_release_driver+0x20/0x34 [ 555.756487] #6: (&shost->scan_mutex){+.+.+.}, at: [<c04097d0>] scsi_remove_host+0x20/0x104 Cc: Jun Li <jun.li@nxp.com> Signed-off-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* adv7604: fix tx 5v detect regressionHans Verkuil2016-03-091-2/+1
| | | | | | | | | | | | | | commit 0ba4581c84cfb39fd527f6b3457f1c97f6356c04 upstream. The 5 volt detect functionality broke in 3.14: the code reads IO register 0x70 again after it has already been cleared. Instead it should use the cached irq_reg_0x70 value and the io_write to 0x71 to clear 0x70 can be dropped since this has already been done. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* dmaengine: pxa_dma: fix cyclic transfersRobert Jarzmik2016-03-091-1/+7
| | | | | | | | | | | | | | | | | | | | | | commit f16921275cc3c2442d0b95225785a601603b990f upstream. While testing audio with pxa2xx-ac97, underrun were happening while the user application was correctly feeding the music. Debug proved that the cyclic transfer is not cyclic, ie. the last descriptor did not loop on the first. Another issue is that the descriptor length was always set to 8192, because of an trivial operator issue. This was tested on a pxa27x platform. Fixes: a57e16cf0333 ("dmaengine: pxa: add pxa dmaengine driver") Reported-by: Vasily Khoruzhick <anarsoul@gmail.com> Tested-by: Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* pata-rb532-cf: get rid of the irq_to_gpio() callGabor Juhos2016-03-091-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 018361767a21fb2d5ebd3ac182c04baf8a8b4e08 upstream. The RB532 platform specific irq_to_gpio() implementation has been removed with commit 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h"). Now the platform uses the generic stub which causes the following error: pata-rb532-cf pata-rb532-cf: no GPIO found for irq149 pata-rb532-cf: probe of pata-rb532-cf failed with error -2 Drop the irq_to_gpio() call and get the GPIO number from platform data instead. After this change, the driver works again: scsi host0: pata-rb532-cf ata1: PATA max PIO4 irq 149 ata1.00: CFA: CF 1GB, 20080820, max MWDMA4 ata1.00: 1989792 sectors, multi 0: LBA ata1.00: configured for PIO4 scsi 0:0:0:0: Direct-Access ATA CF 1GB 0820 PQ: 0\ ANSI: 5 sd 0:0:0:0: [sda] 1989792 512-byte logical blocks: (1.01 GB/971 MiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't\ support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h") Cc: Alban Bedel <albeu@free.fr> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Gabor Juhos <juhosg@openwrt.org> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* ata: ahci: don't mark HotPlugCapable Ports as external/removableManuel Lauss2016-03-091-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | commit dc8b4afc4a04fac8ee55a19b59f2356a25e7e778 upstream. The HPCP bit is set by bioses for on-board sata ports either because they think sata is hotplug capable in general or to allow Windows to display a "device eject" icon on ports which are routed to an external connector bracket. However in Redhat Bugzilla #1310682, users report that with kernel 4.4, where this bit test first appeared, a lot of partitions on sata drives are now mounted automatically. This patch should fix redhat and a lot of other distros which unconditionally automount all devices which have the "removable" bit set. Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: 8a3e33cf92c7 ("ata: ahci: find eSATA ports and flag them as removable" changes userspace behavior) Link: http://lkml.kernel.org/g/56CF35FA.1070500@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Adding Intel Lewisburg device IDs for SATAAlexandra Yates2016-03-091-0/+6
| | | | | | | | | | | | commit f5bdd66c705484b4bc77eb914be15c1b7881fae7 upstream. This patch complements the list of device IDs previously added for lewisburg sata. Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* libata: fix HDIO_GET_32BIT ioctlArnd Bergmann2016-03-091-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 287e6611ab1eac76c2c5ebf6e345e04c80ca9c61 upstream. As reported by Soohoon Lee, the HDIO_GET_32BIT ioctl does not work correctly in compat mode with libata. I have investigated the issue further and found multiple problems that all appeared with the same commit that originally introduced HDIO_GET_32BIT handling in libata back in linux-2.6.8 and presumably also linux-2.4, as the code uses "copy_to_user(arg, &val, 1)" to copy a 'long' variable containing either 0 or 1 to user space. The problems with this are: * On big-endian machines, this will always write a zero because it stores the wrong byte into user space. * In compat mode, the upper three bytes of the variable are updated by the compat_hdio_ioctl() function, but they now contain uninitialized stack data. * The hdparm tool calling this ioctl uses a 'static long' variable to store the result. This means at least the upper bytes are initialized to zero, but calling another ioctl like HDIO_GET_MULTCOUNT would fill them with data that remains stale when the low byte is overwritten. Fortunately libata doesn't implement any of the affected ioctl commands, so this would only happen when we query both an IDE and an ATA device in the same command such as "hdparm -N -c /dev/hda /dev/sda" * The libata code for unknown reasons started using ATA_IOC_GET_IO32 and ATA_IOC_SET_IO32 as aliases for HDIO_GET_32BIT and HDIO_SET_32BIT, while the ioctl commands that were added later use the normal HDIO_* names. This is harmless but rather confusing. This addresses all four issues by changing the code to use put_user() on an 'unsigned long' variable in HDIO_GET_32BIT, like the IDE subsystem does, and by clarifying the names of the ioctl commands. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reported-by: Soohoon Lee <Soohoon.Lee@f5.com> Tested-by: Soohoon Lee <Soohoon.Lee@f5.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amdgpu: return from atombios_dp_get_dpcd only when errorArindam Nath2016-03-091-1/+1
| | | | | | | | | | | | | | | | | | commit 0b39c531cfa12dad54eac238c2e303b994df1ef7 upstream. In amdgpu_connector_hotplug(), we need to start DP link training only after we have received DPCD. The function amdgpu_atombios_dp_get_dpcd() returns non-zero value only when an error condition is met, otherwise returns zero. So in case the function encounters an error, we need to skip rest of the code and return from amdgpu_connector_hotplug() immediately. Only when we are successfull in reading DPCD pin, we should carry on with turning-on the monitor. Signed-off-by: Arindam Nath <arindam.nath@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amdgpu/gfx8: specify which engine to wait before vm flushChunming Zhou2016-03-091-1/+2
| | | | | | | | | | | | commit 9cac537332f5502c103415b25609548c276a09f8 upstream. Select between me and pfp properly. Signed-off-by: Chunming Zhou <David1.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amdgpu: apply gfx_v8 fixes to gfx_v7 as wellChristian König2016-03-091-0/+13
| | | | | | | | | | | commit feebe91aa9a9d99d9ec157612a614fadb79beb99 upstream. We never ported that back to CIK, so we could run into VM faults here. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amdgpu/pm: update current crtc info after setting the powerstateAlex Deucher2016-03-091-3/+3
| | | | | | | | | | | | | | | | commit eda1d1cf8d18383f19cd2b752f786120efa4768f upstream. On CI, we need to see if the number of crtcs changes to determine whether or not we need to upload the mclk table again. In practice we don't currently upload the mclk table again after the initial load. The only reason you would would be to add new states, e.g., for arbitrary mclk setting which is not currently supported. Acked-by: Jordan Lazare <Jordan.Lazare@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/radeon/pm: update current crtc info after setting the powerstateAlex Deucher2016-03-091-4/+4
| | | | | | | | | | | | | | | commit 5e031d9fe8b0741f11d49667dfc3ebf5454121fd upstream. On CI, we need to see if the number of crtcs changes to determine whether or not we need to upload the mclk table again. In practice we don't currently upload the mclk table again after the initial load. The only reason you would would be to add new states, e.g., for arbitrary mclk setting which is not currently supported. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/ast: Fix incorrect register check for DRAM widthTimothy Pearson2016-03-091-1/+1
| | | | | | | | | | | | | | | commit 2d02b8bdba322b527c5f5168ce1ca10c2d982a78 upstream. During DRAM initialization on certain ASpeed devices, an incorrect bit (bit 10) was checked in the "SDRAM Bus Width Status" register to determine DRAM width. Query bit 6 instead in accordance with the Aspeed AST2050 datasheet v1.05. Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* target: Fix WRITE_SAME/DISCARD conversion to linux 512b sectorsMike Christie2016-03-093-62/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 8a9ebe717a133ba7bc90b06047f43cc6b8bcb8b3 upstream. In a couple places we are not converting to/from the Linux block layer 512 bytes sectors. 1. The request queue values and what we do are a mismatch of things: max_discard_sectors - This is in linux block layer 512 byte sectors. We are just copying this to max_unmap_lba_count. discard_granularity - This is in bytes. We are converting it to Linux block layer 512 byte sectors. discard_alignment - This is in bytes. We are just copying this over. The problem is that the core LIO code exports these values in spc_emulate_evpd_b0 and we use them to test request arguments in sbc_execute_unmap, but we never convert to the block size we export to the initiator. If we are not using 512 byte sectors then we are exporting the wrong values or are checks are off. And, for the discard_alignment/bytes case we are just plain messed up. 2. blkdev_issue_discard's start and number of sector arguments are supposed to be in linux block layer 512 byte sectors. We are currently passing in the values we get from the initiator which might be based on some other sector size. There is a similar problem in iblock_execute_write_same where the bio functions want values in 512 byte sectors but we are passing in what we got from the initiator. Signed-off-by: Mike Christie <mchristi@redhat.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> [ kamal: backport to 4.4-stable: no unmap_zeroes_data ] Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iommu/vt-d: Use BUS_NOTIFY_REMOVED_DEVICE in hotplug pathJoerg Roedel2016-03-092-4/+5
| | | | | | | | | | | | | | | | | | commit e6a8c9b337eed56eb481e1b4dd2180c25a1e5310 upstream. In the PCI hotplug path of the Intel IOMMU driver, replace the usage of the BUS_NOTIFY_DEL_DEVICE notifier, which is executed before the driver is unbound from the device, with BUS_NOTIFY_REMOVED_DEVICE, which runs after that. This fixes a kernel BUG being triggered in the VT-d code when the device driver tries to unmap DMA buffers and the VT-d driver already destroyed all mappings. Reported-by: Stefani Seibold <stefani@seibold.net> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iommu/amd: Fix boot warning when device 00:00.0 is not iommu coveredSuravee Suthikulpanit2016-03-091-12/+22
| | | | | | | | | | | | | | | | | commit 38e45d02ea9f194b89d6bf41e52ccafc8e2c2b47 upstream. The setup code for the performance counters in the AMD IOMMU driver tests whether the counters can be written. It tests to setup a counter for device 00:00.0, which fails on systems where this particular device is not covered by the IOMMU. Fix this by not relying on device 00:00.0 but only on the IOMMU being present. Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iommu/amd: Apply workaround for ATS write permission checkJay Cornwall2016-03-091-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | commit 358875fd52ab8f00f66328cbf1a1d2486f265829 upstream. The AMD Family 15h Models 30h-3Fh (Kaveri) BIOS and Kernel Developer's Guide omitted part of the BIOS IOMMU L2 register setup specification. Without this setup the IOMMU L2 does not fully respect write permissions when handling an ATS translation request. The IOMMU L2 will set PTE dirty bit when handling an ATS translation with write permission request, even when PTE RW bit is clear. This may occur by direct translation (which would cause a PPR) or by prefetch request from the ATC. This is observed in practice when the IOMMU L2 modifies a PTE which maps a pagecache page. The ext4 filesystem driver BUGs when asked to writeback these (non-modified) pages. Enable ATS write permission check in the Kaveri IOMMU L2 if BIOS has not. Signed-off-by: Jay Cornwall <jay@jcornwall.me> Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* vfio: fix ioctl error handlingMichael S. Tsirkin2016-03-093-8/+16
| | | | | | | | | | | | | | | | | | | | commit 8160c4e455820d5008a1116d2dca35f0363bb062 upstream. Calling return copy_to_user(...) in an ioctl will not do the right thing if there's a pagefault: copy_to_user returns the number of bytes not copied in this case. Fix up vfio to do return copy_to_user(...)) ? -EFAULT : 0; everywhere. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* fbcon: set a default value to blink intervalJean-Philippe Brucker2016-03-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit a1e533ec07d583d01349ef13c0c965b8633e1b91 upstream. Since commit 27a4c827c34ac4256a190cc9d24607f953c1c459 fbcon: use the cursor blink interval provided by vt two attempts have been made at fixing a possible hang caused by cursor_timer_handler. That function registers a timer to be triggered at "jiffies + fbcon_ops.cur_blink_jiffies". A new case had been encountered during initialisation of clcd-pl11x: fbcon_fb_registered do_fbcon_takeover -> do_register_con_driver fbcon_startup (A) add_cursor_timer (with cur_blink_jiffies = 0) -> do_bind_con_driver visual_init fbcon_init (B) cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms); If we take an softirq anywhere between A and B (and we do), cursor_timer_handler executes indefinitely. Instead of patching all possible paths that lead to this case one at a time, fix the issue at the source and initialise cur_blink_jiffies to 200ms when allocating fbcon_ops. This was its default value before aforesaid commit. fbcon_cursor or fbcon_init will refine this value downstream. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Tested-by: Scot Doyle <lkml14@scotdoyle.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* PCI: keystone: Fix MSI code that retrieves struct pcie_port pointerMurali Karicheri2016-03-091-8/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 79e3f4a853ed161cd4c06d84b50beebf961a47c6 upstream. Commit cbce7900598c ("PCI: designware: Make driver arch-agnostic") changed the host bridge sysdata pointer from the ARM pci_sys_data to the DesignWare pcie_port structure, and changed pcie-designware.c to reflect that. But it did not change the corresponding code in pci-keystone-dw.c, so it caused crashes on Keystone: Unable to handle kernel NULL pointer dereference at virtual address 00000030 pgd = c0003000 [00000030] *pgd=80000800004003, *pmd=00000000 Internal error: Oops: 206 [#1] PREEMPT SMP ARM CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.2-00139-gb74f926 #2 Hardware name: Keystone PC is at ks_dw_pcie_msi_irq_unmask+0x24/0x58 Change pci-keystone-dw.c to expect sysdata to be the struct pcie_port pointer. [bhelgaas: changelog] Fixes: cbce7900598c ("PCI: designware: Make driver arch-agnostic") Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Zhou Wang <wangzhou1@hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/amdgpu: mask out WC from BO on unsupported archesOded Gabbay2016-03-091-0/+8
| | | | | | | | | | | commit a187f17f0e15a046aa5d7263b35df55230d92779 upstream. Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drivers: sh: Restore legacy clock domain on SuperH platformsGeert Uytterhoeven2016-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | commit 0378ba4899d5fbd8494ed6580cbc81d7b44dbac6 upstream. CONFIG_ARCH_SHMOBILE is not only enabled for Renesas ARM platforms (which are DT based and multi-platform), but also on a select set of Renesas SuperH platforms (SH7722/SH7723/SH7724/SH7343/SH7366). Hence since commit 0ba58de231066e47 ("drivers: sh: Get rid of CONFIG_ARCH_SHMOBILE_MULTI"), the legacy clock domain is no longer installed on these SuperH platforms, and module clocks may not be enabled when needed, leading to driver failures. To fix this, add an additional check for CONFIG_OF. Fixes: 0ba58de231066e47 ("drivers: sh: Get rid of CONFIG_ARCH_SHMOBILE_MULTI"). Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iwlwifi: mvm: don't allow sched scans without matches to be startedLuca Coelho2016-03-031-0/+4
| | | | | | | | | | | | | | | | | commit 5e56276e7555b34550d51459a801ff75eca8b907 upstream. The firmware can perform a scheduled scan with not matchsets passed, but it can't send notification that results were found. Since the userspace then cannot know when we got new results and the firmware wouldn't trigger a wake in case we are sleeping, it's better not to allow scans without matchsets. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=110831 Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iwlwifi: update and fix 7265 series PCI IDsOren Givon2016-03-031-2/+3
| | | | | | | | | | | commit 006bda75d81fd27a583a3b310e9444fea2aa6ef2 upstream. Update and fix some 7265 PCI IDs entries. Signed-off-by: Oren Givon <oren.givon@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iwlwifi: pcie: properly configure the debug buffer size for 8000Emmanuel Grumbach2016-03-031-3/+12
| | | | | | | | | | | | | | | | | commit 62d7476d958ce06d7a10b02bdb30006870286fe2 upstream. 8000 device family has a new debug engine that needs to be configured differently than 7000's. The debug engine's DMA works in chunks of memory and the size of the buffer really means the start of the last chunk. Since one chunk is 256-byte long, we should configure the device to write to buffer_size - 256. This fixes a situation were the device would write to memory it is not allowed to access. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* iwlwifi: dvm: fix WoWLANEmmanuel Grumbach2016-03-031-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | commit a1cdb1c59c8c203de2731fc6910598ed19c97e41 upstream. My commit below introduced a mutex in the transport to prevent concurrent operations. To do so, it added a flag (is_down) to make sure the transport is in the right state. This uncoverred an bug that didn't cause any harm until now: iwldvm calls stop_device and then starts the firmware without calling start_hw in between. While this flow is fine from the device configuration point of view (register, etc...), it is now forbidden by the new is_down flag. This led to this error to appear: iwlwifi 0000:05:00.0: Can't start_fw since the HW hasn't been started and the suspend would fail. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=109591 Reported-by: Bogdan Bogush <bogdan.s.bogush@gmail.com> Fixes=fa9f3281cbb1 ("iwlwifi: pcie: lock start_hw / start_fw / stop_device") Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* IB/cma: Fix RDMA port validation for iWarpMatan Barak2016-03-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | commit 649367735ee5dedb128d9fac0b86ba7e0fe7ae3b upstream. cma_validate_port wrongly assumed that Ethernet devices are RoCE devices and thus their ndev should be matched in the GID table. This broke the iWarp support. Fixing that matching the ndev only if we work on a RoCE port. Cc: <stable@vger.kernel.org> # 4.4.x- Fixes: abae1b71dd37 ('IB/cma: cma_validate_port should verify the port and netdevice') Reported-by: Hariprasad Shenai <hariprasad@chelsio.com> Tested-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: Matan Barak <matanb@mellanox.com> Reviewed-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Doug Ledford <dledford@redhat.com> Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xen/pcifront: Fix mysterious crashes when NUMA locality information was ↵Konrad Rzeszutek Wilk2016-03-031-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | extracted. commit 4d8c8bd6f2062c9988817183a91fe2e623c8aa5e upstream. Occasionaly PV guests would crash with: pciback 0000:00:00.1: Xen PCI mapped GSI0 to IRQ16 BUG: unable to handle kernel paging request at 0000000d1a8c0be0 .. snip.. <ffffffff8139ce1b>] find_next_bit+0xb/0x10 [<ffffffff81387f22>] cpumask_next_and+0x22/0x40 [<ffffffff813c1ef8>] pci_device_probe+0xb8/0x120 [<ffffffff81529097>] ? driver_sysfs_add+0x77/0xa0 [<ffffffff815293e4>] driver_probe_device+0x1a4/0x2d0 [<ffffffff813c1ddd>] ? pci_match_device+0xdd/0x110 [<ffffffff81529657>] __device_attach_driver+0xa7/0xb0 [<ffffffff815295b0>] ? __driver_attach+0xa0/0xa0 [<ffffffff81527622>] bus_for_each_drv+0x62/0x90 [<ffffffff8152978d>] __device_attach+0xbd/0x110 [<ffffffff815297fb>] device_attach+0xb/0x10 [<ffffffff813b75ac>] pci_bus_add_device+0x3c/0x70 [<ffffffff813b7618>] pci_bus_add_devices+0x38/0x80 [<ffffffff813dc34e>] pcifront_scan_root+0x13e/0x1a0 [<ffffffff817a0692>] pcifront_backend_changed+0x262/0x60b [<ffffffff814644c6>] ? xenbus_gather+0xd6/0x160 [<ffffffff8120900f>] ? put_object+0x2f/0x50 [<ffffffff81465c1d>] xenbus_otherend_changed+0x9d/0xa0 [<ffffffff814678ee>] backend_changed+0xe/0x10 [<ffffffff81463a28>] xenwatch_thread+0xc8/0x190 [<ffffffff810f22f0>] ? woken_wake_function+0x10/0x10 which was the result of two things: When we call pci_scan_root_bus we would pass in 'sd' (sysdata) pointer which was an 'pcifront_sd' structure. However in the pci_device_add it expects that the 'sd' is 'struct sysdata' and sets the dev->node to what is in sd->node (offset 4): set_dev_node(&dev->dev, pcibus_to_node(bus)); __pcibus_to_node(const struct pci_bus *bus) { const struct pci_sysdata *sd = bus->sysdata; return sd->node; } However our structure was pcifront_sd which had nothing at that offset: struct pcifront_sd { int domain; /* 0 4 */ /* XXX 4 bytes hole, try to pack */ struct pcifront_device * pdev; /* 8 8 */ } That is an hole - filled with garbage as we used kmalloc instead of kzalloc (the second problem). This patch fixes the issue by: 1) Use kzalloc to initialize to a well known state. 2) Put 'struct pci_sysdata' at the start of 'pcifront_sd'. That way access to the 'node' will access the right offset. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xen/pciback: Save the number of MSI-X entries to be copied later.Konrad Rzeszutek Wilk2016-03-031-1/+5
| | | | | | | | | | | | | | | | | | | commit d159457b84395927b5a52adb72f748dd089ad5e5 upstream. Commit 8135cf8b092723dbfcc611fe6fdcb3a36c9951c5 (xen/pciback: Save xen_pci_op commands before processing it) broke enabling MSI-X because it would never copy the resulting vectors into the response. The number of vectors requested was being overwritten by the return value (typically zero for success). Save the number of vectors before processing the op, so the correct number of vectors are copied afterwards. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xen/pciback: Check PF instead of VF for PCI_COMMAND_MEMORYKonrad Rzeszutek Wilk2016-03-031-1/+2
| | | | | | | | | | | | | | | | | commit 8d47065f7d1980dde52abb874b301054f3013602 upstream. Commit 408fb0e5aa7fda0059db282ff58c3b2a4278baa0 (xen/pciback: Don't allow MSI-X ops if PCI_COMMAND_MEMORY is not set) prevented enabling MSI-X on passed-through virtual functions, because it checked the VF for PCI_COMMAND_MEMORY but this is not a valid bit for VFs. Instead, check the physical function for PCI_COMMAND_MEMORY. Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* xen/scsiback: correct frontend countingJuergen Gross2016-03-031-5/+5
| | | | | | | | | | | | | | | commit f285aa8db7cc4432c1a03f8b55ff34fe96317c11 upstream. When adding a new frontend to xen-scsiback don't decrement the number of active frontends in case of no error. Doing so results in a failure when trying to remove the xen-pvscsi nexus even if no domain is using it. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.46.0) at 2025-04-24 20:15:25 +0000