summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2014-09-17drm/nouveau: Bump version from 1.1.1 to 1.1.2Mario Kleiner
commit 7820e5eef0faa4a5e10834296680827f7ce78a89 upstream. Linux 3.16 fixed multiple bugs in kms pageflip completion events and timestamping, which were originally introduced in Linux 3.13. These fixes have been backported to all stable kernels since 3.13. However, the userspace nouveau-ddx needs to be aware if it is running on a kernel on which these bugs are fixed, or not. Bump the patchlevel of the drm driver version to signal this, so backporting this patch to stable 3.13+ kernels will give the ddx the required info. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17drm/nouveau: Dis/Enable vblank irqs during suspend/resume.Mario Kleiner
commit 9cba5efab5a8145ae6c52ea273553f069c294482 upstream. Vblank irqs don't get disabled during suspend or driver unload, which causes irq delivery after "suspend" or driver unload, at least until the gpu is powered off. This could race with drm_vblank_cleanup() in the case of nouveau and cause a use-after-free bug if the driver is unloaded. More annoyingly during everyday use, at least on nv50 display engine (likely also others), vblank irqs are off after a resume from suspend, but the drm doesn't know this, so all vblank related functionality is dead after a resume. E.g., all windowed OpenGL clients will hang at swapbuffers time, as well as many fullscreen clients in many cases. This makes suspend/resume useless if one wants to use any OpenGL apps after the resume. In Linux 3.16, drm_vblank_on() was added, complementing the older drm_vblank_off() to solve these problems elegantly, so use those calls in nouveaus suspend/resume code. For kernels 3.8 - 3.15, we need to cherry-pick the drm_vblank_on() patch to support this patch. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17IB/srp: Fix deadlock between host removal and multipathdBart Van Assche
commit bcc05910359183b431da92713e98eed478edf83a upstream. If scsi_remove_host() is invoked after a SCSI device has been blocked, if the fast_io_fail_tmo or dev_loss_tmo work gets scheduled on the workqueue executing srp_remove_work() and if an I/O request is scheduled after the SCSI device had been blocked by e.g. multipathd then the following deadlock can occur: kworker/6:1 D ffff880831f3c460 0 195 2 0x00000000 Call Trace: [<ffffffff814aafd9>] schedule+0x29/0x70 [<ffffffff814aa0ef>] schedule_timeout+0x10f/0x2a0 [<ffffffff8105af6f>] msleep+0x2f/0x40 [<ffffffff8123b0ae>] __blk_drain_queue+0x4e/0x180 [<ffffffff8123d2d5>] blk_cleanup_queue+0x225/0x230 [<ffffffffa0010732>] __scsi_remove_device+0x62/0xe0 [scsi_mod] [<ffffffffa000ed2f>] scsi_forget_host+0x6f/0x80 [scsi_mod] [<ffffffffa0002eba>] scsi_remove_host+0x7a/0x130 [scsi_mod] [<ffffffffa07cf5c5>] srp_remove_work+0x95/0x180 [ib_srp] [<ffffffff8106d7aa>] process_one_work+0x1ea/0x6c0 [<ffffffff8106dd9b>] worker_thread+0x11b/0x3a0 [<ffffffff810758bd>] kthread+0xed/0x110 [<ffffffff814b972c>] ret_from_fork+0x7c/0xb0 multipathd D ffff880096acc460 0 5340 1 0x00000000 Call Trace: [<ffffffff814aafd9>] schedule+0x29/0x70 [<ffffffff814aa0ef>] schedule_timeout+0x10f/0x2a0 [<ffffffff814ab79b>] io_schedule_timeout+0x9b/0xf0 [<ffffffff814abe1c>] wait_for_completion_io_timeout+0xdc/0x110 [<ffffffff81244b9b>] blk_execute_rq+0x9b/0x100 [<ffffffff8124f665>] sg_io+0x1a5/0x450 [<ffffffff8124fd21>] scsi_cmd_ioctl+0x2a1/0x430 [<ffffffff8124fef2>] scsi_cmd_blk_ioctl+0x42/0x50 [<ffffffffa00ec97e>] sd_ioctl+0xbe/0x140 [sd_mod] [<ffffffff8124bd04>] blkdev_ioctl+0x234/0x840 [<ffffffff811cb491>] block_ioctl+0x41/0x50 [<ffffffff811a0df0>] do_vfs_ioctl+0x300/0x520 [<ffffffff811a1051>] SyS_ioctl+0x41/0x80 [<ffffffff814b9962>] tracesys+0xd0/0xd5 Fix this by scheduling removal work on another workqueue than the transport layer timers. Signed-off-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Sagi Grimberg <sagig@mellanox.com> Reviewed-by: David Dillow <dave@thedillows.org> Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17dm table: propagate QUEUE_FLAG_NO_SG_MERGEJeff Moyer
commit 200612ec33e555a356eebc717630b866ae2b694f upstream. Commit 05f1dd5 ("block: add queue flag for disabling SG merging") introduced a new queue flag: QUEUE_FLAG_NO_SG_MERGE. This gets set by default in blk_mq_init_queue for mq-enabled devices. The effect of the flag is to bypass the SG segment merging. Instead, the bio->bi_vcnt is used as the number of hardware segments. With a device mapper target on top of a device with QUEUE_FLAG_NO_SG_MERGE set, we can end up sending down more segments than a driver is prepared to handle. I ran into this when backporting the virtio_blk mq support. It triggerred this BUG_ON, in virtio_queue_rq: BUG_ON(req->nr_phys_segments + 2 > vblk->sg_elems); The queue's max is set here: blk_queue_max_segments(q, vblk->sg_elems-2); Basically, what happens is that a bio is built up for the dm device (which does not have the QUEUE_FLAG_NO_SG_MERGE flag set) using bio_add_page. That path will call into __blk_recalc_rq_segments, so what you end up with is bi_phys_segments being much smaller than bi_vcnt (and bi_vcnt grows beyond the maximum sg elements). Then, when the bio is submitted, it gets cloned. When the cloned bio is submitted, it will end up in blk_recount_segments, here: if (test_bit(QUEUE_FLAG_NO_SG_MERGE, &q->queue_flags)) bio->bi_phys_segments = bio->bi_vcnt; and now we've set bio->bi_phys_segments to a number that is beyond what was registered as queue_max_segments by the driver. The right way to fix this is to propagate the queue flag up the stack. The rules for propagating the flag are simple: - if the flag is set for any underlying device, it must be set for the upper device - consequently, if the flag is not set for any underlying device, it should not be set for the upper device. Signed-off-by: Jeff Moyer <jmoyer@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17mtd: nand: omap: Fix 1-bit Hamming code scheme, omap_calculate_ecc()Roger Quadros
commit 40ddbf5069bd4e11447c0088fc75318e0aac53f0 upstream. commit 65b97cf6b8de introduced in v3.7 caused a regression by using a reversed CS_MASK thus causing omap_calculate_ecc to always fail. As the NAND base driver never checks for .calculate()'s return value, the zeroed ECC values are used as is without showing any error to the user. However, this won't work and the NAND device won't be guarded by any error code. Fix the issue by using the correct mask. Code was tested on omap3beagle using the following procedure - flash the primary bootloader (MLO) from the kernel to the first NAND partition using nandwrite. - boot the board from NAND. This utilizes OMAP ROM loader that relies on 1-bit Hamming code ECC. Fixes: 65b97cf6b8de (mtd: nand: omap2: handle nand on gpmc) Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17mtd/ftl: fix the double free of the buffers allocated in build_maps()Kevin Hao
commit a152056c912db82860a8b4c23d0bd3a5aa89e363 upstream. I got the following panic on my fsl p5020ds board. Unable to handle kernel paging request for data at address 0x7375627379737465 Faulting instruction address: 0xc000000000100778 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=24 CoreNet Generic Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-next-20140613 #145 task: c0000000fe080000 ti: c0000000fe088000 task.ti: c0000000fe088000 NIP: c000000000100778 LR: c00000000010073c CTR: 0000000000000000 REGS: c0000000fe08aa00 TRAP: 0300 Not tainted (3.15.0-next-20140613) MSR: 0000000080029000 <CE,EE,ME> CR: 24ad2e24 XER: 00000000 DEAR: 7375627379737465 ESR: 0000000000000000 SOFTE: 1 GPR00: c0000000000c99b0 c0000000fe08ac80 c0000000009598e0 c0000000fe001d80 GPR04: 00000000000000d0 0000000000000913 c000000007902b20 0000000000000000 GPR08: c0000000feaae888 0000000000000000 0000000007091000 0000000000200200 GPR12: 0000000028ad2e28 c00000000fff4000 c0000000007abe08 0000000000000000 GPR16: c0000000007ab160 c0000000007aaf98 c00000000060ba68 c0000000007abda8 GPR20: c0000000007abde8 c0000000feaea6f8 c0000000feaea708 c0000000007abd10 GPR24: c000000000989370 c0000000008c6228 00000000000041ed c0000000fe00a400 GPR28: c00000000017c1cc 00000000000000d0 7375627379737465 c0000000fe001d80 NIP [c000000000100778] .__kmalloc_track_caller+0x70/0x168 LR [c00000000010073c] .__kmalloc_track_caller+0x34/0x168 Call Trace: [c0000000fe08ac80] [c00000000087e6b8] uevent_sock_list+0x0/0x10 (unreliable) [c0000000fe08ad20] [c0000000000c99b0] .kstrdup+0x44/0x90 [c0000000fe08adc0] [c00000000017c1cc] .__kernfs_new_node+0x4c/0x130 [c0000000fe08ae70] [c00000000017d7e4] .kernfs_new_node+0x2c/0x64 [c0000000fe08aef0] [c00000000017db00] .kernfs_create_dir_ns+0x34/0xc8 [c0000000fe08af80] [c00000000018067c] .sysfs_create_dir_ns+0x58/0xcc [c0000000fe08b010] [c0000000002c711c] .kobject_add_internal+0xc8/0x384 [c0000000fe08b0b0] [c0000000002c7644] .kobject_add+0x64/0xc8 [c0000000fe08b140] [c000000000355ebc] .device_add+0x11c/0x654 [c0000000fe08b200] [c0000000002b5988] .add_disk+0x20c/0x4b4 [c0000000fe08b2c0] [c0000000003a21d4] .add_mtd_blktrans_dev+0x340/0x514 [c0000000fe08b350] [c0000000003a3410] .mtdblock_add_mtd+0x74/0xb4 [c0000000fe08b3e0] [c0000000003a32cc] .blktrans_notify_add+0x64/0x94 [c0000000fe08b470] [c00000000039b5b4] .add_mtd_device+0x1d4/0x368 [c0000000fe08b520] [c00000000039b830] .mtd_device_parse_register+0xe8/0x104 [c0000000fe08b5c0] [c0000000003b8408] .of_flash_probe+0x72c/0x734 [c0000000fe08b750] [c00000000035ba40] .platform_drv_probe+0x38/0x84 [c0000000fe08b7d0] [c0000000003599a4] .really_probe+0xa4/0x29c [c0000000fe08b870] [c000000000359d3c] .__driver_attach+0x100/0x104 [c0000000fe08b900] [c00000000035746c] .bus_for_each_dev+0x84/0xe4 [c0000000fe08b9a0] [c0000000003593c0] .driver_attach+0x24/0x38 [c0000000fe08ba10] [c000000000358f24] .bus_add_driver+0x1c8/0x2ac [c0000000fe08bab0] [c00000000035a3a4] .driver_register+0x8c/0x158 [c0000000fe08bb30] [c00000000035b9f4] .__platform_driver_register+0x6c/0x80 [c0000000fe08bba0] [c00000000084e080] .of_flash_driver_init+0x1c/0x30 [c0000000fe08bc10] [c000000000001864] .do_one_initcall+0xbc/0x238 [c0000000fe08bd00] [c00000000082cdc0] .kernel_init_freeable+0x188/0x268 [c0000000fe08bdb0] [c0000000000020a0] .kernel_init+0x1c/0xf7c [c0000000fe08be30] [c000000000000884] .ret_from_kernel_thread+0x58/0xd4 Instruction dump: 41bd0010 480000c8 4bf04eb5 60000000 e94d0028 e93f0000 7cc95214 e8a60008 7fc9502a 2fbe0000 419e00c8 e93f0022 <7f7e482a> 39200000 88ed06b2 992d06b2 ---[ end trace b4c9a94804a42d40 ]--- It seems that the corrupted partition header on my mtd device triggers a bug in the ftl. In function build_maps() it will allocate the buffers needed by the mtd partition, but if something goes wrong such as kmalloc failure, mtd read error or invalid partition header parameter, it will free all allocated buffers and then return non-zero. In my case, it seems that partition header parameter 'NumTransferUnits' is invalid. And the ftl_freepart() is a function which free all the partition buffers allocated by build_maps(). Given the build_maps() is a self cleaning function, so there is no need to invoke this function even if build_maps() return with error. Otherwise it will causes the buffers to be freed twice and then weird things would happen. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17RDMA/iwcm: Use a default listen backlog if neededSteve Wise
commit 2f0304d21867476394cd51a54e97f7273d112261 upstream. If the user creates a listening cm_id with backlog of 0 the IWCM ends up not allowing any connection requests at all. The correct behavior is for the IWCM to pick a default value if the user backlog parameter is zero. Lustre from version 1.8.8 onward uses a backlog of 0, which breaks iwarp support without this fix. Signed-off-by: Steve Wise <swise@opengridcomputing.com> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17md/raid10: Fix memory leak when raid10 reshape completes.NeilBrown
commit b39685526f46976bcd13aa08c82480092befa46c upstream. When a raid10 commences a resync/recovery/reshape it allocates some buffer space. When a resync/recovery completes the buffer space is freed. But not when the reshape completes. This can result in a small memory leak. There is a subtle side-effect of this bug. When a RAID10 is reshaped to a larger array (more devices), the reshape is immediately followed by a "resync" of the new space. This "resync" will use the buffer space which was allocated for "reshape". This can cause problems including a "BUG" in the SCSI layer. So this is suitable for -stable. Fixes: 3ea7daa5d7fde47cd41f4d56c2deb949114da9d6 Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17md/raid10: fix memory leak when reshaping a RAID10.NeilBrown
commit ce0b0a46955d1bb389684a2605dbcaa990ba0154 upstream. raid10 reshape clears unwanted bits from a bio->bi_flags using a method which, while clumsy, worked until 3.10 when BIO_OWNS_VEC was added. Since then it clears that bit but shouldn't. This results in a memory leak. So change to used the approved method of clearing unwanted bits. As this causes a memory leak which can consume all of memory the fix is suitable for -stable. Fixes: a38352e0ac02dbbd4fa464dc22d1352b5fbd06fd Reported-by: mdraid.pkoch@dfgh.net (Peter Koch) Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17md/raid6: avoid data corruption during recovery of double-degraded RAID6NeilBrown
commit 9c4bdf697c39805078392d5ddbbba5ae5680e0dd upstream. During recovery of a double-degraded RAID6 it is possible for some blocks not to be recovered properly, leading to corruption. If a write happens to one block in a stripe that would be written to a missing device, and at the same time that stripe is recovering data to the other missing device, then that recovered data may not be written. This patch skips, in the double-degraded case, an optimisation that is only safe for single-degraded arrays. Bug was introduced in 2.6.32 and fix is suitable for any kernel since then. In an older kernel with separate handle_stripe5() and handle_stripe6() functions the patch must change handle_stripe6(). Fixes: 6c0069c0ae9659e3a91b68eaed06a5c6c37f45c8 Cc: Yuri Tikhonov <yur@emcraft.com> Cc: Dan Williams <dan.j.williams@intel.com> Reported-by: "Manibalan P" <pmanibalan@amiindia.co.in> Tested-by: "Manibalan P" <pmanibalan@amiindia.co.in> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1090423 Signed-off-by: NeilBrown <neilb@suse.de> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17md/raid5: avoid livelock caused by non-aligned writes.NeilBrown
commit a40687ff73a5b14909d6aa522f7d778b158911c5 upstream. If a stripe in a raid6 array received a write to each data block while the array is degraded, and if any of these writes to a missing device are not page-aligned, then a live-lock happens. In this case the P and Q blocks need to be read so that the part of the missing block which is *not* being updated by the write can be constructed. Due to a logic error, these blocks are not loaded, so the update cannot proceed and the stripe is 'handled' repeatedly in an infinite loop. This bug is unlikely as most writes are page aligned. However as it can lead to a livelock it is suitable for -stable. It was introduced in 3.16. Fixed: 67f455486d2ea20b2d94d6adf5b9b783d079e321 Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17md/raid1,raid10: always abort recover on write error.NeilBrown
commit 2446dba03f9dabe0b477a126cbeb377854785b47 upstream. Currently we don't abort recovery on a write error if the write error to the recovering device was triggerd by normal IO (as opposed to recovery IO). This means that for one bitmap region, the recovery might write to the recovering device for a few sectors, then not bother for subsequent sectors (as it never writes to failed devices). In this case the bitmap bit will be cleared, but it really shouldn't. The result is that if the recovering device fails and is then re-added (after fixing whatever hardware problem triggerred the failure), the second recovery won't redo the region it was in the middle of, so some of the device will not be recovered properly. If we abort the recovery, the region being processes will be cancelled (bit not cleared) and the whole region will be retried. As the bug can result in data corruption the patch is suitable for -stable. For kernels prior to 3.11 there is a conflict in raid10.c which will require care. Original-from: jiao hui <jiaohui@bwstor.com.cn> Reported-and-tested-by: jiao hui <jiaohui@bwstor.com.cn> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17rbd: rework rbd_request_fn()Ilya Dryomov
commit bc1ecc65a259fa9333dc8bd6a4ba0cf03b7d4bf8 upstream. While it was never a good idea to sleep in request_fn(), commit 34c6bc2c919a ("locking/mutexes: Add extra reschedule point") made it a *bad* idea. mutex_lock() since 3.15 may reschedule *before* putting task on the mutex wait queue, which for tasks in !TASK_RUNNING state means block forever. request_fn() may be called with !TASK_RUNNING on the way to schedule() in io_schedule(). Offload request handling to a workqueue, one per rbd device, to avoid calling blocking primitives from rbd_request_fn(). Fixes: http://tracker.ceph.com/issues/8818 Signed-off-by: Ilya Dryomov <ilya.dryomov@inktank.com> Tested-by: Eric Eastman <eric0e@aol.com> Tested-by: Greg Wilson <greg.wilson@keepertech.com> Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17Bluetooth: btmrvl: wait for HOST_SLEEP_ENABLE event in suspendChin-Ran Lo
commit 396e04f4bb9afefb0744715dc76d9abe18ee5fb0 upstream. After BT_CMD_HOST_SLEEP_ENABLE command finishes, driver should wait until getting BT_EVENT_HOST_SLEEP_ENABLE event to complete suspend procedure. Without this patch the suspend handler would return success earlier. By the time when the BT_EVENT_HOST_SLEEP_ENABLE event comes in the controller driver could have already turned off the bus clock. This causes kernel crash or system reboot eventually. Signed-off-by: Chin-Ran Lo <crlo@marvell.com> Signed-off-by: Jeff CF Chen <jeffc@marvell.com> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com> Signed-off-by: Bing Zhao <bzhao@marvell.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17xen/events/fifo: reset control block and local HEADs on resumeDavid Vrabel
commit c12784c3d14a2110468ec4d1383f60cfd2665576 upstream. When using the FIFO-based event channel ABI, if the control block or the local HEADs are not reset after resuming the guest may see stale HEAD values and will fail to traverse the FIFO correctly. This may prevent one or more VCPUs from receiving any events following a resume. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17ACPI / video: Disable native_backlight on HP ENVY 15 Notebook PCHans de Goede
commit 84c34858a85ecf9dabd72847d860c7d3fb7536e7 upstream. Link: https://bugs.freedesktop.org/show_bug.cgi?id=81515 Reported-and-tested-by: Hohahiu <rakothedin@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17ACPI / video: Add a disable_native_backlight quirkHans de Goede
commit 5f24079b021cd3147c8d24ba65833f7a0df7e80d upstream. Some laptops have a working acpi_video backlight control, and using native backlight on these causes a regression where backlight control does not work when userspace is not handling brightness key events. Disable native_backlight on these to fix this. Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691 Reported-and-tested-by: Andre Müller <andre.muller@web.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17ACPI / video: Fix use_native_backlight selection logicHans de Goede
commit 25294e9f00f03b2b4f4c56e913bc8c573972f33b upstream. Commit 751109aad583 ("ACPI / video: Change the default for video.use_native_backlight to 1") has changed the default for use_native_backlight from 0 to 1, but instead of changing use_native_backlight_dmi to true, and leaving use_native_backlight_param at -1, it has changed use_native_backlight_param to 1. This causes acpi_video_use_native_backlight() to always think that a value was specified through the param, making it impossible to add a dmi based quirk to force 0 now that the default is 1. This fixes this by restoring the use_native_backlight_param default to -1, and instead setting the use_native_backlight_dmi default to true. Fixes: 751109aad583 (ACPI / video: Change the default for video.use_native_backlight to 1) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17ACPI / cpuidle: fix deadlock between cpuidle_lock and cpu_hotplug.lockJiri Kosina
commit 6726655dfdd2dc60c035c690d9f10cb69d7ea075 upstream. There is a following AB-BA dependency between cpu_hotplug.lock and cpuidle_lock: 1) cpu_hotplug.lock -> cpuidle_lock enable_nonboot_cpus() _cpu_up() cpu_hotplug_begin() LOCK(cpu_hotplug.lock) cpu_notify() ... acpi_processor_hotplug() cpuidle_pause_and_lock() LOCK(cpuidle_lock) 2) cpuidle_lock -> cpu_hotplug.lock acpi_os_execute_deferred() workqueue ... acpi_processor_cst_has_changed() cpuidle_pause_and_lock() LOCK(cpuidle_lock) get_online_cpus() LOCK(cpu_hotplug.lock) Fix this by reversing the order acpi_processor_cst_has_changed() does thigs -- let it first execute the protection against CPU hotplug by calling get_online_cpus() and obtain the cpuidle lock only after that (and perform the symmentric change when allowing CPUs hotplug again and dropping cpuidle lock). Spotted by lockdep. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17ACPI / scan: not cache _SUN value in struct acpi_device_pnpYasuaki Ishimatsu
commit a383b68d9fe9864c4d3b86f67ad6488f58136435 upstream. The _SUN device indentification object is not guaranteed to return the same value every time it is executed, so we should not cache its return value, but rather execute it every time as needed. If it is cached, an incorrect stale value may be used in some situations. This issue was exposed by commit 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace). Fix it by avoiding to cache the return value of _SUN. Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17ACPI / EC: Add support to disallow QR_EC to be issued before completing ↵Lv Zheng
previous QR_EC commit 558e4736f2e1b0e6323adf7a5e4df77ed6cfc1a4 upstream. There is platform refusing to respond QR_EC when SCI_EVT isn't set which is Acer Aspire V5-573G. By disallowing QR_EC to be issued before the previous one has been completed we are able to reduce the possibilities to trigger issues on such platforms. Note that this fix can only reduce the occurrence rate of this issue, but this issue may still occur when such a platform doesn't clear SCI_EVT before or immediately after completing the previous QR_EC transaction. This patch cannot fix the CLEAR_ON_RESUME quirk which also relies on the assumption that the platforms are able to respond even when SCI_EVT isn't set. But this patch is still useful as it can help to reduce the number of scheduled QR_EC work items. Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't setLv Zheng
commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08 upstream. There is a platform refusing to respond QR_EC when SCI_EVT isn't set (Acer Aspire V5-573G). Currently, we rely on the behaviour that the EC firmware can respond something (for example, 0x00 to indicate "no outstanding events") to QR_EC even when SCI_EVT is not set, but the reporter has complained about AC/battery pluging/unpluging and video brightness change delay on that platform. This is because the work item that has issued QR_EC has to wait until timeout in this case, and the _Qxx method evaluation work item queued after QR_EC one is delayed. It sounds reasonable to fix this issue by: 1. Implementing SCI_EVT sanity check before issuing QR_EC in the EC driver's main state machine. 2. Moving QR_EC issuing out of the work queue used by _Qxx evaluation to a seperate IRQ handling thread. This patch fixes this issue using solution 1. By disallowing QR_EC to be issued when SCI_EVT isn't set, we are able to handle such platform in the EC driver's main state machine. This patch enhances the state machine in this way to survive with such malfunctioning EC firmware. Note that this patch can also fix CLEAR_ON_RESUME quirk which also relies on the assumption that the platforms are able to respond even when SCI_EVT isn't set. Fixes: c0d653412fc8 ACPI / EC: Fix race condition in ec_transaction_completed() Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Reported-and-tested-by: Alexander Mezin <mezin.alexander@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17ACPI / scan: Allow ACPI drivers to bind to PNP device objectsRafael J. Wysocki
commit fc2e0a8326d1b21d11ef8213298e5302867fed2c upstream. We generally don't allow ACPI drivers to bind to ACPI device objects that companion "physical" device objects are created for to avoid situations in which two different drivers may attempt to handle one device at the same time. Recent ACPI device enumeration rework extended that approach to ACPI PNP devices by starting to use a scan handler for enumerating them. However, we previously allowed ACPI drivers to bind to ACPI device objects with existing PNP device companions and changing that led to functional regressions on some systems. For this reason, add a special check for PNP devices in acpi_device_probe() so that ACPI drivers can bind to ACPI device objects having existing PNP device companions as before. Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration) Link: https://bugzilla.kernel.org/show_bug.cgi?id=81511 Link: https://bugzilla.kernel.org/show_bug.cgi?id=81971 Reported-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Reported-by: Dirk Griesbach <spamthis@freenet.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17ACPI: Run fixed event device notifications in process contextLan Tianyu
commit 236105db632c6279a020f78c83e22eaef746006b upstream. Currently, notify callbacks for fixed button events are run from interrupt context. That is not necessary and after commit 0bf6368ee8f2 (ACPI / button: Add ACPI Button event via netlink routine) it causes netlink routines to be called from interrupt context which is not correct. Also, that is different from non-fixed device events (including non-fixed button events) whose notify callbacks are all executed from process context. For the above reasons, make fixed button device notify callbacks run in process context which will avoid the deadlock when using netlink to report button events to user space. Fixes: 0bf6368ee8f2 (ACPI / button: Add ACPI Button event via netlink routine) Link: https://lkml.org/lkml/2014/8/21/606 Reported-by: Benjamin Block <bebl@mageta.org> Reported-by: Knut Petersen <Knut_Petersen@t-online.de> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> [rjw: Function names, subject and changelog.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17spi/pxa2xx: Add ACPI ID for Intel BraswellAlan Cox
commit aca26364689e00e3b2052072424682231bdae6ae upstream. The SPI host controller is the same as used in Baytrail, only the ACPI ID is different so add this new ID to the list. Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17ACPI / hotplug: Check scan handlers in acpi_scan_hot_remove()Tang Chen
commit dee1592638ab7ea35a32179b73f9284dead49c03 upstream. When ACPI_HOTPLUG_MEMORY is not configured, memory_device_handler.attach is not set. In acpi_scan_attach_handler(), the acpi_device->handler will not be initialized. In acpi_scan_hot_remove(), it doesn't check if acpi_device->handler is NULL. If we do memory hot-remove without ACPI_HOTPLUG_MEMORY configured, the kernel will panic. BUG: unable to handle kernel NULL pointer dereference at 0000000000000088 IP: [<ffffffff813e318f>] acpi_device_hotplug+0x1d7/0x4c4 PGD 0 Oops: 0000 [#1] SMP Modules linked in: sd_mod(E) sr_mod(E) cdrom(E) crc_t10dif(E) crct10dif_common(E) ata_piix(E) libata(E) CPU: 0 PID: 41 Comm: kworker/u2:1 Tainted: G E 3.16.0-rc7--3.16-rc7-tangchen+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Workqueue: kacpi_hotplug acpi_hotplug_work_fn task: ffff8800182436c0 ti: ffff880018254000 task.ti: ffff880018254000 RIP: 0010:[<ffffffff813e318f>] [<ffffffff813e318f>] acpi_device_hotplug+0x1d7/0x4c4 RSP: 0000:ffff880018257da8 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff88001cd8d800 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88001e40e6f8 RDI: 0000000000000246 RBP: ffff880018257df0 R08: 0000000000000096 R09: 00000000000011a0 R10: 63735f6970636120 R11: 725f746f685f6e61 R12: 0000000000000003 R13: ffff88001cc1c400 R14: ffff88001e062028 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff88001e400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000088 CR3: 000000001a9a2000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000 Stack: 00000000523cab58 ffff88001cd8d9f8 ffff88001852d480 00000000523cab58 ffff88001852d480 ffff880018221e40 ffff88001cc1c400 ffff88001cce2d00 0000000000000040 ffff880018257e08 ffffffff813dc31d ffff88001852d480 Call Trace: [<ffffffff813dc31d>] acpi_hotplug_work_fn+0x1e/0x29 [<ffffffff8108eefb>] process_one_work+0x17b/0x460 [<ffffffff8108f69d>] worker_thread+0x11d/0x5b0 [<ffffffff8108f580>] ? rescuer_thread+0x3a0/0x3a0 [<ffffffff81096811>] kthread+0xe1/0x100 [<ffffffff81096730>] ? kthread_create_on_node+0x1a0/0x1a0 [<ffffffff816cc6bc>] ret_from_fork+0x7c/0xb0 [<ffffffff81096730>] ? kthread_create_on_node+0x1a0/0x1a0 This patch fixes this problem by checking if acpi_device->handler is NULL in acpi_scan_hot_remove(). Fixes: d22ddcbc4fb7 (ACPI / hotplug: Add demand_offline hotplug profile flag) Signed-off-by: Tang Chen <tangchen@cn.fujitsu.com> [rjw: Subject] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17ACPICA: Namespace: Properly null terminate objects detached from a namespace ↵David E. Box
node commit e23d9b8297546c6ceb7e70771e4915f2a41733cd upstream. Fixes a bug exposed by an ACPICA unit test around the acpi_attach_data()/acpi_detach_data() APIs where the failure to null terminate a detached object led to the creation of a circular linked list (and infinite looping) when the object is reattached. Reported in acpica bugzilla #1063 Link: https://bugs.acpica.org/show_bug.cgi?id=1063 Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17ACPICA: Utilities: Fix memory leak in acpi_ut_copy_iobject_to_iobjectDavid E. Box
commit 8aa5e56eeb61a099ea6519eb30ee399e1bc043ce upstream. Adds return status check on copy routines to delete the allocated destination object if either copy fails. Reported by Colin Ian King on bugs.acpica.org, Bug 1087. The last applicable commit: Commit: 3371c19c294a4cb3649aa4e84606be8a1d999e61 Subject: ACPICA: Remove ACPI_GET_OBJECT_TYPE macro Link: https://bugs.acpica.org/show_bug.cgi?id=1087 Reported-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17bq2415x_charger: Fix Atomic Sleep BugSebastian Reichel
commit 3c0185046c0ee49a6e55c714612ef3bcd5385df3 upstream. Move sysfs_notify and i2c_transfer calls from bq2415x_notifier_call to bq2415x_timer_work to avoid sleeping in atomic context. This fixes the following bug: [ 7.667449] Workqueue: events power_supply_changed_work [ 7.673034] [<c0015c28>] (unwind_backtrace+0x0/0xe0) from [<c0011e1c>] (show_stack+0x10/0x14) [ 7.682098] [<c0011e1c>] (show_stack+0x10/0x14) from [<c052cdd0>] (dump_stack+0x78/0xac) [ 7.690704] [<c052cdd0>] (dump_stack+0x78/0xac) from [<c052a044>] (__schedule_bug+0x48/0x60) [ 7.699645] [<c052a044>] (__schedule_bug+0x48/0x60) from [<c053071c>] (__schedule+0x74/0x638) [ 7.708618] [<c053071c>] (__schedule+0x74/0x638) from [<c05301fc>] (schedule_timeout+0x1dc/0x24c) [ 7.718017] [<c05301fc>] (schedule_timeout+0x1dc/0x24c) from [<c05316ec>] (wait_for_common+0x138/0x17c) [ 7.727966] [<c05316ec>] (wait_for_common+0x138/0x17c) from [<c0362a70>] (omap_i2c_xfer+0x340/0x4a0) [ 7.737640] [<c0362a70>] (omap_i2c_xfer+0x340/0x4a0) from [<c035d928>] (__i2c_transfer+0x40/0x74) [ 7.747039] [<c035d928>] (__i2c_transfer+0x40/0x74) from [<c035e22c>] (i2c_transfer+0x6c/0x90) [ 7.756195] [<c035e22c>] (i2c_transfer+0x6c/0x90) from [<c037ad24>] (bq2415x_i2c_write+0x48/0x78) [ 7.765563] [<c037ad24>] (bq2415x_i2c_write+0x48/0x78) from [<c037ae60>] (bq2415x_set_weak_battery_voltage+0x4c/0x50) [ 7.776824] [<c037ae60>] (bq2415x_set_weak_battery_voltage+0x4c/0x50) from [<c037bce8>] (bq2415x_set_mode+0xdc/0x14c) [ 7.788085] [<c037bce8>] (bq2415x_set_mode+0xdc/0x14c) from [<c037bfb8>] (bq2415x_notifier_call+0xa8/0xb4) [ 7.798309] [<c037bfb8>] (bq2415x_notifier_call+0xa8/0xb4) from [<c005f228>] (notifier_call_chain+0x38/0x68) [ 7.808715] [<c005f228>] (notifier_call_chain+0x38/0x68) from [<c005f284>] (__atomic_notifier_call_chain+0x2c/0x3c) [ 7.819732] [<c005f284>] (__atomic_notifier_call_chain+0x2c/0x3c) from [<c005f2a8>] (atomic_notifier_call_chain+0x14/0x18) [ 7.831420] [<c005f2a8>] (atomic_notifier_call_chain+0x14/0x18) from [<c0378078>] (power_supply_changed_work+0x6c/0xb8) [ 7.842864] [<c0378078>] (power_supply_changed_work+0x6c/0xb8) from [<c00556c0>] (process_one_work+0x248/0x440) [ 7.853546] [<c00556c0>] (process_one_work+0x248/0x440) from [<c0055d6c>] (worker_thread+0x208/0x350) [ 7.863372] [<c0055d6c>] (worker_thread+0x208/0x350) from [<c005b0ac>] (kthread+0xc8/0xdc) [ 7.872131] [<c005b0ac>] (kthread+0xc8/0xdc) from [<c000e138>] (ret_from_fork+0x14/0x3c) Fixes: 32260308b4ca ("bq2415x_charger: Use power_supply notifier for automode") Signed-off-by: Sebastian Reichel <sre@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17bfa: Fix undefined bit shift on big-endian architectures with 32-bit DMA addressBen Hutchings
commit 03a6c3ff3282ee9fa893089304d951e0be93a144 upstream. bfa_swap_words() shifts its argument (assumed to be 64-bit) by 32 bits each way. In two places the argument type is dma_addr_t, which may be 32-bit, in which case the effect of the bit shift is undefined: drivers/scsi/bfa/bfa_fcpim.c: In function 'bfa_ioim_send_ioreq': drivers/scsi/bfa/bfa_fcpim.c:2497:4: warning: left shift count >= width of type [enabled by default] addr = bfa_sgaddr_le(sg_dma_address(sg)); ^ drivers/scsi/bfa/bfa_fcpim.c:2497:4: warning: right shift count >= width of type [enabled by default] drivers/scsi/bfa/bfa_fcpim.c:2509:4: warning: left shift count >= width of type [enabled by default] addr = bfa_sgaddr_le(sg_dma_address(sg)); ^ drivers/scsi/bfa/bfa_fcpim.c:2509:4: warning: right shift count >= width of type [enabled by default] Avoid this by adding casts to u64 in bfa_swap_words(). Compile-tested only. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Acked-by: Anil Gurumurthy <anil.gurumurthy@qlogic.com> Fixes: f16a17507b09 ('[SCSI] bfa: remove all OS wrappers') Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17SCSI: save command pool address of Scsi_HostJuergen Gross
commit f6105c0808880c2c432b79bc81b37cc244c300c8 upstream. If a scsi host driver specifies .cmd_len in it's scsi_host_template, a driver's private command pool is needed. scsi_find_host_cmd_pool() will locate it, but scsi_alloc_host_cmd_pool() isn't saving the pool address in the host template. This will result in an access error when the host is removed. Avoid the problem by saving the address of a new allocated command pool where it is expected. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> Fixes: 89d9a567952baec13e26ada3e438f1b642d66b6e Signed-off-by: James Bottomley <JBottomley@Parallels.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17scsi_transport_srp: Fix fast_io_fail_tmo=dev_loss_tmo=off behaviorBart Van Assche
commit cd53eb686d2418eda938aad3c9da42b7dfa9351f upstream. If scsi_remove_host() is called while an rport is in the blocked state then scsi_remove_host() will only finish if the rport is unblocked from inside a timer function. Make sure that an rport only enters the blocked state if a timer will be started that will unblock it. This avoids that unloading the ib_srp kernel module after having disconnected the initiator from the target system results in a deadlock if both the fast_io_fail_tmo and dev_loss_tmo parameters have been set to "off". Signed-off-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Sagi Grimberg <sagig@mellanox.com> Reviewed-by: David Dillow <dave@thedillows.org> Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17scsi: do not issue SCSI RSOC command to Promise Vtrak E610fJanusz Dziemidowicz
commit 0213436a2cc5e4a5ca2fabfaa4d3877097f3b13f upstream. Some devices don't like REPORT SUPPORTED OPERATION CODES and will simply timeout causing sd_mod init to take a very very long time. Introduce BLIST_NO_RSOC scsi scan flag, that stops RSOC from being issued. Add it to Promise Vtrak E610f entry in scsi scan blacklist. Fixes bug #79901 reported at https://bugzilla.kernel.org/show_bug.cgi?id=79901 Fixes: 98dcc2946adb ("SCSI: sd: Update WRITE SAME heuristics") Signed-off-by: Janusz Dziemidowicz <rraptorr@nails.eu.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17scsi: add a blacklist flag which enables VPD page inquiriesMartin K. Petersen
commit c1d40a527e885a40bb9ea6c46a1b1145d42b66a0 upstream. Despite supporting modern SCSI features some storage devices continue to claim conformance to an older version of the SPC spec. This is done for compatibility with legacy operating systems. Linux by default will not attempt to read VPD pages on devices that claim SPC-2 or older. Introduce a blacklist flag that can be used to trigger VPD page inquiries on devices that are known to support them. Reported-by: KY Srinivasan <kys@microsoft.com> Tested-by: KY Srinivasan <kys@microsoft.com> Reviewed-by: KY Srinivasan <kys@microsoft.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17scsi_scan: Restrict sequential scan to 256 LUNsHannes Reinecke
commit 22ffeb48b7584d6cd50f2a595ed6065d86a87459 upstream. Sequential scan for more than 256 LUNs is very fragile as LUNs might not be numbered sequentially after that point. SAM revisions later than SCSI-3 impose a structure on LUNs larger than 256, making LUN numbers between 256 and 16384 illegal. SCSI-3, however allows for plain 64-bit numbers with no internal structure. So restrict sequential LUN scan to 256 LUNs and add a new blacklist flag 'BLIST_SCSI3LUN' to scan up to max_lun devices. Signed-off-by: Hannes Reinecke <hare@suse.de> Reviewed-by: Ewan Milne <emilne@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17drivers: scsi: storvsc: Correctly handle TEST_UNIT_READY failureK. Y. Srinivasan
commit 3533f8603d28b77c62d75ec899449a99bc6b77a1 upstream. On some Windows hosts on FC SANs, TEST_UNIT_READY can return SRB_STATUS_ERROR. Correctly handle this. Note that there is sufficient sense information to support scsi error handling even in this case. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17drivers: scsi: storvsc: Set srb_flags in all casesK. Y. Srinivasan
commit f885fb73f64154690c2158e813de56363389ffec upstream. Correctly set SRB flags for all valid I/O directions. Some IHV drivers on the Windows host require this. The host validates the command and SRB flags prior to passing the command down to native driver stack. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17Drivers: scsi: storvsc: Fix a bug in handling VMBUS protocol versionK. Y. Srinivasan
commit adb6f9e1a8c6af1037232b59edb11277471537ea upstream. Based on the negotiated VMBUS protocol version, we adjust the size of the storage protocol messages. The two sizes we currently handle are pre-win8 and post-win8. In WS2012 R2, we are negotiating higher VMBUS protocol version than the win8 version. Make adjustments to correctly handle this. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17Drivers: scsi: storvsc: Set cmd_per_lun to reflect value supported by the HostK. Y. Srinivasan
commit 52f9614dd8294e95d2c0929c2d4f64b077ae486f upstream. Set cmd_per_lun to reflect value supported by the Host. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17Drivers: scsi: storvsc: Change the limits to reflect the values on the hostK. Y. Srinivasan
commit 4cd83ecdac20d30725b4f96e5d7814a1e290bc7e upstream. Hyper-V hosts can support multiple targets and multiple channels and larger number of LUNs per target. Update the code to reflect this. With this patch we can correctly enumerate all the paths in a multi-path storage environment. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17Drivers: scsi: storvsc: Filter commands based on the storage protocol versionK. Y. Srinivasan
commit 8caf92d80526f3d7cc96831ec18b384ebcaccdf0 upstream. Going forward it is possible that some of the commands that are not currently implemented will be implemented on future Windows hosts. Even if they are not implemented, we are told the host will corrrectly handle unsupported commands (by returning appropriate return code and sense information). Make command filtering depend on the host version. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17Drivers: scsi: storvsc: Implement a eh_timed_out handlerK. Y. Srinivasan
commit 56b26e69c8283121febedd12b3cc193384af46b9 upstream. On Azure, we have seen instances of unbounded I/O latencies. To deal with this issue, implement handler that can reset the timeout. Note that the host gaurantees that it will respond to each command that has been issued. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Reviewed-by: Hannes Reinecke <hare@suse.de> [hch: added a better comment explaining the issue] Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17scsi: use short driver name for per-driver cmd slab cachesJames Bottomley
commit 884ffee01ddde5af260c7a5d1359c658aa1f0a11 upstream. hostt->name might contain space, so use the ->proc_name short name instead when creating per-driver command slabs. Signed-off-by: James Bottomley <JBottomley@Parallels.com> Reported-by: poma <pomidorabelisima@gmail.com> Tested-by: poma <pomidorabelisima@gmail.com> Reviewed-by: Vladimir Davydov <vdavydov@parallels.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17powerpc/cpuidle: Fix parsing of idle state flags from device-treeVaidyanathan Srinivasan
commit 95707d852856aec1cbdad1873ff2dc5161a5cb91 upstream. Flags from device-tree need to be parsed with accessors for interpreting correct value in little-endian. Signed-off-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Reviewed-by: Preeti U. Murthy <preeti@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17regulator: tps65218: fix DCDC4 linear voltage rangeFelipe Balbi
commit 42ab0f3915f22728f54bb1f3c0dcf38ab2335b5b upstream. The second range of this particular regulator, starts at 1.60V, not as 1.55V as it was originally implied by code. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17regulator: arizona-ldo1: remove bypass functionalityNikesh Oswal
commit 5b919f3ebb533cbe400664837e24f66a0836b907 upstream. WM5110/8280 devices do not support bypass mode for LDO1 so remove the bypass callbacks registered with regulator core. Signed-off-by: Nikesh Oswal <nikesh@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17mfd: twl4030-power: Fix PM idle pin configuration to not conflict with ↵Tony Lindgren
regulators commit daebabd578647440d41fc9b48d8c7a88dc2f7ab5 upstream. Commit 43fef47f94a1 (mfd: twl4030-power: Add a configuration to turn off oscillator during off-idle) added support for configuring the PMIC to cut off resources during deeper idle states to save power. This however caused regression for n900 display power that needed the PMIC configuration to be disabled with commit d937678ab625 (ARM: dts: Revert enabling of twl configuration for n900). Turns out the root cause of the problem is that we must use TWL4030_RESCONFIG_UNDEF instead of DEV_GRP_NULL to avoid disabling regulators that may have been enabled before the init function for twl4030-power.c runs. With TWL4030_RESCONFIG_UNDEF we let the regulator framework control the regulators like it should. Here we need to only configure the sys_clken and sys_off_mode triggers for the regulators that cannot be done by the regulator framework as it's not running at that point. This allows us to enable the PMIC configuration for n900. Fixes: 43fef47f94a1 (mfd: twl4030-power: Add a configuration to turn off oscillator during off-idle) Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17drivers/mfd/rtsx_usb.c: export device tableJeff Mahoney
commit 1813908986e36119228c158aae1c6a0267c99e77 upstream. The rtsx_usb driver contains the table for the devices it supports but doesn't export it. As a result, no alias is generated and it doesn't get loaded automatically. Via https://bugzilla.novell.com/show_bug.cgi?id=890096 Signed-off-by: Jeff Mahoney <jeffm@suse.com> Reported-by: Marcel Witte <wittemar@googlemail.com> Cc: Roger Tseng <rogerable@realtek.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17mfd: omap-usb-host: Fix improper mask use.Michael Welling
commit 46de8ff8e80a6546aa3d2fdf58c6776666301a0c upstream. single-ulpi-bypass is a flag used for older OMAP3 silicon. The flag when set, can excite code that improperly uses the OMAP_UHH_HOSTCONFIG_UPLI_BYPASS define to clear the corresponding bit. Instead it clears all of the other bits disabling all of the ports in the process. Signed-off-by: Michael Welling <mwelling@emacinc.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17tpm: Properly clean sysfs entries in error pathStefan Berger
commit b49e1043c48dac23f64fba684d31c4a96c1ffaa0 upstream. Properly clean the sysfs entries in the error path Reported-by: Dmitry Kasatkin <dmitry.kasatkin@gmail.com> Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by: Peter Huewe <peterhuewe@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 13:50:44 +0000