1. 05 Oct, 2014 13 commits
  2. 17 Sep, 2014 26 commits
    • Jason Gunthorpe's avatar
      tpm: Provide a generic means to override the chip returned timeouts · d64269e3
      Jason Gunthorpe authored
      commit 8e54caf407b98efa05409e1fee0e5381abd2b088 upstream.
      Some Atmel TPMs provide completely wrong timeouts from their
      TPM_CAP_PROP_TIS_TIMEOUT query. This patch detects that and returns
      new correct values via a DID/VID table in the TIS driver.
      Tested on ARM using an AT97SC3204T FW version 37.16
      [PHuewe: without this fix these 'broken' Atmel TPMs won't function on
      older kernels]
      Signed-off-by: default avatar"Berg, Christopher" <Christopher.Berg@atmel.com>
      Signed-off-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      [bwh: Backported to 3.10:
       - Adjust filename, context
       - s/chip->ops->/chip->vendor./]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Bart Van Assche's avatar
      IB/srp: Fix deadlock between host removal and multipathd · 70efec16
      Bart Van Assche authored
      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: default avatarBart Van Assche <bvanassche@acm.org>
      Reviewed-by: default avatarSagi Grimberg <sagig@mellanox.com>
      Reviewed-by: default avatarDavid Dillow <dave@thedillows.org>
      Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com>
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Roger Quadros's avatar
      mtd: nand: omap: Fix 1-bit Hamming code scheme, omap_calculate_ecc() · 6562c0cc
      Roger Quadros authored
      commit 40ddbf5069bd4e11447c0088fc75318e0aac53f0 upstream.
      commit 65b97cf6 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: 65b97cf6 (mtd: nand: omap2: handle nand on gpmc)
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Kevin Hao's avatar
      mtd/ftl: fix the double free of the buffers allocated in build_maps() · a9d28db6
      Kevin Hao authored
      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: default avatarKevin Hao <haokexin@gmail.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • NeilBrown's avatar
      md/raid1,raid10: always abort recover on write error. · b08633de
      NeilBrown authored
      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: default avatarjiao hui <jiaohui@bwstor.com.cn>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Steve Wise's avatar
      RDMA/iwcm: Use a default listen backlog if needed · 433d80d6
      Steve Wise authored
      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: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarRoland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • NeilBrown's avatar
      md/raid10: Fix memory leak when raid10 reshape completes. · 26584e18
      NeilBrown authored
      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: 3ea7daa5Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • NeilBrown's avatar
      md/raid10: fix memory leak when reshaping a RAID10. · 1075d2bd
      NeilBrown authored
      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: a38352e0
      Reported-by: mdraid.pkoch@dfgh.net (Peter Koch)
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • NeilBrown's avatar
      md/raid6: avoid data corruption during recovery of double-degraded RAID6 · 318a3d59
      NeilBrown authored
      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: 6c0069c0
      Cc: Yuri Tikhonov <yur@emcraft.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Reported-by: default avatar"Manibalan P" <pmanibalan@amiindia.co.in>
      Tested-by: default avatar"Manibalan P" <pmanibalan@amiindia.co.in>
      Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1090423Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Acked-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jiri Kosina's avatar
      ACPI / cpuidle: fix deadlock between cpuidle_lock and cpu_hotplug.lock · 4f6a1e62
      Jiri Kosina authored
      commit 6726655dfdd2dc60c035c690d9f10cb69d7ea075 upstream.
      There is a following AB-BA dependency between cpu_hotplug.lock and
      1) cpu_hotplug.lock -> cpuidle_lock
      2) cpuidle_lock -> cpu_hotplug.lock
      acpi_os_execute_deferred() workqueue
      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: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Lan Tianyu's avatar
      ACPI: Run fixed event device notifications in process context · c55d35d2
      Lan Tianyu authored
      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
      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/606Reported-by: default avatarBenjamin Block <bebl@mageta.org>
      Reported-by: default avatarKnut Petersen <Knut_Petersen@t-online.de>
      Signed-off-by: default avatarLan Tianyu <tianyu.lan@intel.com>
      [rjw: Function names, subject and changelog.]
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • David E. Box's avatar
      ACPICA: Utilities: Fix memory leak in acpi_ut_copy_iobject_to_iobject · b3e98f0c
      David E. Box authored
      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: 3371c19c
       Subject: ACPICA: Remove ACPI_GET_OBJECT_TYPE macro
      Link: https://bugs.acpica.org/show_bug.cgi?id=1087Reported-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid E. Box <david.e.box@linux.intel.com>
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Ben Hutchings's avatar
      bfa: Fix undefined bit shift on big-endian architectures with 32-bit DMA address · db065663
      Ben Hutchings authored
      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: default avatarBen Hutchings <ben@decadent.org.uk>
      Reviewed-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Acked-by: default avatarAnil Gurumurthy <anil.gurumurthy@qlogic.com>
      Fixes: f16a1750 ('[SCSI] bfa: remove all OS wrappers')
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • K. Y. Srinivasan's avatar
      drivers: scsi: storvsc: Correctly handle TEST_UNIT_READY failure · 8ce6d81a
      K. Y. Srinivasan authored
      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: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • K. Y. Srinivasan's avatar
      Drivers: scsi: storvsc: Implement a eh_timed_out handler · 7afc3ac1
      K. Y. Srinivasan authored
      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: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      [hch: added a better comment explaining the issue]
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Nikesh Oswal's avatar
      regulator: arizona-ldo1: remove bypass functionality · b2102aa9
      Nikesh Oswal authored
      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: default avatarNikesh Oswal <nikesh@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Michael Welling's avatar
      mfd: omap-usb-host: Fix improper mask use. · 2c34d0d0
      Michael Welling authored
      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: default avatarMichael Welling <mwelling@emacinc.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Jarkko Sakkinen's avatar
      tpm: missing tpm_chip_put in tpm_get_random() · d4281c33
      Jarkko Sakkinen authored
      commit 3e14d83ef94a5806a865b85b513b4e891923c19b upstream.
      Regression in 41ab999c. Call to tpm_chip_put is missing. This
      will cause TPM device driver not to unload if tmp_get_random()
      is called.
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarPeter Huewe <peterhuewe@gmx.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Guenter Roeck's avatar
      firmware: Do not use WARN_ON(!spin_is_locked()) · 79943632
      Guenter Roeck authored
      commit aee530cfecf4f3ec83b78406bac618cec35853f8 upstream.
      spin_is_locked() always returns false for uniprocessor configurations
      in several architectures, so do not use WARN_ON with it.
      Use lockdep_assert_held() instead to also reduce overhead in
      non-debug kernels.
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mark A. Greer's avatar
      spi: omap2-mcspi: Configure hardware when slave driver changes mode · abcc94f8
      Mark A. Greer authored
      commit 97ca0d6cc118716840ea443e010cb3d5f2d25eaf upstream.
      Commit id 2bd16e3e23d9df41592c6b257c59b6860a9cc3ea
      (spi: omap2-mcspi: Do not configure the controller
      on each transfer unless needed) does its job too
      well so omap2_mcspi_setup_transfer() isn't called
      even when an SPI slave driver changes 'spi->mode'.
      The result is that the mode requested by the SPI
      slave driver never takes effect.
      Fix this by adding the 'mode' member to the
      omap2_mcspi_cs structure which holds the mode
      value that the hardware is configured for.
      When the SPI slave driver changes 'spi->mode'
      it will be different than the value of this new
      member and the SPI master driver will know that
      the hardware must be reconfigured (by calling
      Fixes: 2bd16e3e23 (spi: omap2-mcspi: Do not configure the controller on each transfer unless needed)
      Signed-off-by: default avatarMark A. Greer <mgreer@animalcreek.com>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Thomas Petazzoni's avatar
      spi: orion: fix incorrect handling of cell-index DT property · bd090374
      Thomas Petazzoni authored
      commit e06871cd2c92e5c65d7ca1d32866b4ca5dd4ac30 upstream.
      In commit f814f9ac ("spi/orion: add device tree binding"), Device
      Tree support was added to the spi-orion driver. However, this commit
      reads the "cell-index" property, without taking into account the fact
      that DT properties are big-endian encoded.
      Since most of the platforms using spi-orion with DT have apparently
      not used anything but cell-index = <0>, the problem was not
      visible. But as soon as one starts using cell-index = <1>, the problem
      becomes clearly visible, as the master->bus_num gets a wrong value
      (actually it gets the value 0, which conflicts with the first bus that
      has cell-index = <0>).
      This commit fixes that by using of_property_read_u32() to read the
      property value, which does the appropriate endianness conversion when
      Fixes: f814f9ac ("spi/orion: add device tree binding")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Acked-by: default avatarSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
      Signed-off-by: default avatarMark Brown <broonie@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Joerg Roedel's avatar
      iommu/amd: Fix cleanup_domain for mass device removal · b15dba93
      Joerg Roedel authored
      commit 9b29d3c6510407d91786c1cf9183ff4debb3473a upstream.
      When multiple devices are detached in __detach_device, they
      are also removed from the domains dev_list. This makes it
      unsafe to use list_for_each_entry_safe, as the next pointer
      might also not be in the list anymore after __detach_device
      returns. So just repeatedly remove the first element of the
      list until it is empty.
      Tested-by: default avatarMarti Raudsepp <marti@juffo.org>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Salva Peiró's avatar
      media: media-device: Remove duplicated memset() in media_enum_entities() · 01d29ff7
      Salva Peiró authored
      commit f8ca6ac00d2ba24c5557f08f81439cd3432f0802 upstream.
      After the zeroing the whole struct struct media_entity_desc u_ent,
      it is no longer necessary to memset(0) its u_ent.name field.
      Signed-off-by: default avatarSalva Peiró <speiro@ai2.upv.es>
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mauro Carvalho Chehab's avatar
      media: au0828: Only alt setting logic when needed · f3e8f271
      Mauro Carvalho Chehab authored
      commit 64ea37bbd8a5815522706f0099ad3f11c7537e15 upstream.
      It seems that there's a bug at au0828 hardware/firmware
      related to alternate setting: when the device is already at
      alt 5, a further call causes the URBs to receive -ESHUTDOWN.
      I found two different encarnations of this issue:
      1) at qv4l2, it fails the second time we try to open the
      video screen;
      2) at xawtv, when audio underrun occurs, with is very
      frequent, at least on my test machine.
      The fix is simple: just check if alt=5 before calling
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mauro Carvalho Chehab's avatar
      media: xc4000: Fix get_frequency() · d2b8c8c9
      Mauro Carvalho Chehab authored
      commit 4c07e32884ab69574cfd9eb4de3334233c938071 upstream.
      The programmed frequency on xc4000 is not the middle
      frequency, but the initial frequency on the bandwidth range.
      However, the DVB API works with the middle frequency.
      This works fine on set_frontend, as the device calculates
      the needed offset. However, at get_frequency(), the returned
      value is the initial frequency. That's generally not a big
      problem on most drivers, however, starting with changeset
      6fe1099c, the frequency drift is taken into account at
      dib7000p driver.
      This broke support for PCTV 340e, with uses dib7000p demod and
      xc4000 tuner.
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Mauro Carvalho Chehab's avatar
      media: xc5000: Fix get_frequency() · ce1c89d4
      Mauro Carvalho Chehab authored
      commit a3eec916cbc17dc1aaa3ddf120836cd5200eb4ef upstream.
      The programmed frequency on xc5000 is not the middle
      frequency, but the initial frequency on the bandwidth range.
      However, the DVB API works with the middle frequency.
      Signed-off-by: default avatarMauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. 05 Sep, 2014 1 commit