1. 22 Aug, 2016 21 commits
    • Adrian Hunter's avatar
      mmc: mmc: Fix partition switch timeout for some eMMCs · 2d1bbf04
      Adrian Hunter authored
      commit 1c447116 upstream.
      
      Some eMMCs set the partition switch timeout too low.
      
      Now typically eMMCs are considered a critical component (e.g. because
      they store the root file system) and consequently are expected to be
      reliable.  Thus we can neglect the use case where eMMCs can't switch
      reliably and we might want a lower timeout to facilitate speedy
      recovery.
      
      Although we could employ a quirk for the cards that are affected (if
      we could identify them all), as described above, there is little
      benefit to having a low timeout, so instead simply set a minimum
      timeout.
      
      The minimum is set to 300ms somewhat arbitrarily - the examples that
      have been seen had a timeout of 10ms but were sometimes taking 60-70ms.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      2d1bbf04
    • Vik Heyndrickx's avatar
      sched/loadavg: Fix loadavg artifacts on fully idle and on fully loaded systems · 245d83e3
      Vik Heyndrickx authored
      commit 20878232 upstream.
      
      Systems show a minimal load average of 0.00, 0.01, 0.05 even when they
      have no load at all.
      
      Uptime and /proc/loadavg on all systems with kernels released during the
      last five years up until kernel version 4.6-rc5, show a 5- and 15-minute
      minimum loadavg of 0.01 and 0.05 respectively. This should be 0.00 on
      idle systems, but the way the kernel calculates this value prevents it
      from getting lower than the mentioned values.
      
      Likewise but not as obviously noticeable, a fully loaded system with no
      processes waiting, shows a maximum 1/5/15 loadavg of 1.00, 0.99, 0.95
      (multiplied by number of cores).
      
      Once the (old) load becomes 93 or higher, it mathematically can never
      get lower than 93, even when the active (load) remains 0 forever.
      This results in the strange 0.00, 0.01, 0.05 uptime values on idle
      systems.  Note: 93/2048 = 0.0454..., which rounds up to 0.05.
      
      It is not correct to add a 0.5 rounding (=1024/2048) here, since the
      result from this function is fed back into the next iteration again,
      so the result of that +0.5 rounding value then gets multiplied by
      (2048-2037), and then rounded again, so there is a virtual "ghost"
      load created, next to the old and active load terms.
      
      By changing the way the internally kept value is rounded, that internal
      value equivalent now can reach 0.00 on idle, and 1.00 on full load. Upon
      increasing load, the internally kept load value is rounded up, when the
      load is decreasing, the load value is rounded down.
      
      The modified code was tested on nohz=off and nohz kernels. It was tested
      on vanilla kernel 4.6-rc5 and on centos 7.1 kernel 3.10.0-327. It was
      tested on single, dual, and octal cores system. It was tested on virtual
      hosts and bare hardware. No unwanted effects have been observed, and the
      problems that the patch intended to fix were indeed gone.
      Tested-by: default avatarDamien Wyart <damien.wyart@free.fr>
      Signed-off-by: default avatarVik Heyndrickx <vik.heyndrickx@veribox.net>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Doug Smythies <dsmythies@telus.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 0f004f5a ("sched: Cure more NO_HZ load average woes")
      Link: http://lkml.kernel.org/r/e8d32bff-d544-7748-72b5-3c86cc71f09f@veribox.netSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [bwh: Backported to 3.2: adjust filename]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      245d83e3
    • Michael Ellerman's avatar
      powerpc/mm/hash64: Fix subpage protection with 4K HPTE config · 45a50dee
      Michael Ellerman authored
      commit aac55d75 upstream.
      
      With Linux page size of 64K and hardware only supporting 4K HPTE, if we
      use subpage protection, we always fail for the subpage 0 as shown
      below (using the selftest subpage_prot test):
      
        520175565:  (4520111850): Failed at 0x3fffad4b0000 (p=13,sp=0,w=0), want=fault, got=pass !
        4520890210: (4520826495): Failed at 0x3fffad5b0000 (p=29,sp=0,w=0), want=fault, got=pass !
        4521574251: (4521510536): Failed at 0x3fffad6b0000 (p=45,sp=0,w=0), want=fault, got=pass !
        4522258324: (4522194609): Failed at 0x3fffad7b0000 (p=61,sp=0,w=0), want=fault, got=pass !
      
      This is because hash preload wrongly inserts the HPTE entry for subpage
      0 without looking at the subpage protection information.
      
      Fix it by teaching should_hash_preload() not to preload if we have
      subpage protection configured for that range.
      
      It appears this has been broken since it was introduced in 2008.
      
      Fixes: fa28237c ("[POWERPC] Provide a way to protect 4k subpages when using 64k pages")
      Signed-off-by: default avatarAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      [mpe: Rework into should_hash_preload() to avoid build fails w/SLICES=n]
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      45a50dee
    • Michael Ellerman's avatar
      powerpc/mm/hash64: Factor out hash preload psize check · b9b441d1
      Michael Ellerman authored
      commit 8bbc9b7b upstream.
      
      Currently we have a check in hash_preload() against the psize, which is
      only included when CONFIG_PPC_MM_SLICES is enabled. We want to expand
      this check in a subsequent patch, so factor it out to allow that. As a
      bonus it removes the #ifdef in the C code.
      
      Unfortunately we can't put this in the existing CONFIG_PPC_MM_SLICES
      block because it would require a forward declaration.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b9b441d1
    • Mans Rullgard's avatar
      ata: sata_dwc_460ex: remove incorrect locking · b7581238
      Mans Rullgard authored
      commit 55e610cd upstream.
      
      This lock is already taken in ata_scsi_queuecmd() a few levels up the
      call stack so attempting to take it here is an error.  Moreover, it is
      pointless in the first place since it only protects a single, atomic
      assignment.
      
      Enabling lock debugging gives the following output:
      
      =============================================
      [ INFO: possible recursive locking detected ]
      4.4.0-rc5+ #189 Not tainted
      ---------------------------------------------
      kworker/u2:3/37 is trying to acquire lock:
       (&(&host->lock)->rlock){-.-...}, at: [<90283294>] sata_dwc_exec_command_by_tag.constprop.14+0x44/0x8c
      
      but task is already holding lock:
       (&(&host->lock)->rlock){-.-...}, at: [<902761ac>] ata_scsi_queuecmd+0x2c/0x330
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&host->lock)->rlock);
        lock(&(&host->lock)->rlock);
      
       *** DEADLOCK ***
       May be due to missing lock nesting notation
      
      4 locks held by kworker/u2:3/37:
       #0:  ("events_unbound"){.+.+.+}, at: [<9003a0a4>] process_one_work+0x12c/0x430
       #1:  ((&entry->work)){+.+.+.}, at: [<9003a0a4>] process_one_work+0x12c/0x430
       #2:  (&bdev->bd_mutex){+.+.+.}, at: [<9011fd54>] __blkdev_get+0x50/0x380
       #3:  (&(&host->lock)->rlock){-.-...}, at: [<902761ac>] ata_scsi_queuecmd+0x2c/0x330
      
      stack backtrace:
      CPU: 0 PID: 37 Comm: kworker/u2:3 Not tainted 4.4.0-rc5+ #189
      Workqueue: events_unbound async_run_entry_fn
      Stack : 90b38e30 00000021 00000003 9b2a6040 00000000 9005f3f0 904fc8dc 00000025
              906b96e4 00000000 90528648 9b3336c4 904fc8dc 9009bf18 00000002 00000004
              00000000 00000000 9b3336c4 9b3336e4 904fc8dc 9003d074 00000000 90500000
              9005e738 00000000 00000000 00000000 00000000 00000000 00000000 00000000
              6e657665 755f7374 756f626e 0000646e 00000000 00000000 9b00ca00 9b025000
                ...
      Call Trace:
      [<90009d6c>] show_stack+0x88/0xa4
      [<90057744>] __lock_acquire+0x1ce8/0x2154
      [<900583e4>] lock_acquire+0x64/0x8c
      [<9045ff10>] _raw_spin_lock_irqsave+0x54/0x78
      [<90283294>] sata_dwc_exec_command_by_tag.constprop.14+0x44/0x8c
      [<90283484>] sata_dwc_qc_issue+0x1a8/0x24c
      [<9026b39c>] ata_qc_issue+0x1f0/0x410
      [<90273c6c>] ata_scsi_translate+0xb4/0x200
      [<90276234>] ata_scsi_queuecmd+0xb4/0x330
      [<9025800c>] scsi_dispatch_cmd+0xd0/0x128
      [<90259934>] scsi_request_fn+0x58c/0x638
      [<901a3e50>] __blk_run_queue+0x40/0x5c
      [<901a83d4>] blk_queue_bio+0x27c/0x28c
      [<901a5914>] generic_make_request+0xf0/0x188
      [<901a5a54>] submit_bio+0xa8/0x194
      [<9011adcc>] submit_bh_wbc.isra.23+0x15c/0x17c
      [<9011c908>] block_read_full_page+0x3e4/0x428
      [<9009e2e0>] do_read_cache_page+0xac/0x210
      [<9009fd90>] read_cache_page+0x18/0x24
      [<901bbd18>] read_dev_sector+0x38/0xb0
      [<901bd174>] msdos_partition+0xb4/0x5c0
      [<901bcb8c>] check_partition+0x140/0x274
      [<901bba60>] rescan_partitions+0xa0/0x2b0
      [<9011ff68>] __blkdev_get+0x264/0x380
      [<901201ac>] blkdev_get+0x128/0x36c
      [<901b9378>] add_disk+0x3c0/0x4bc
      [<90268268>] sd_probe_async+0x100/0x224
      [<90043a44>] async_run_entry_fn+0x50/0x124
      [<9003a11c>] process_one_work+0x1a4/0x430
      [<9003a4f4>] worker_thread+0x14c/0x4fc
      [<900408f4>] kthread+0xd0/0xe8
      [<90004338>] ret_from_kernel_thread+0x14/0x1c
      
      Fixes: 62936009 ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex")
      Tested-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: default avatarMans Rullgard <mans@mansr.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b7581238
    • Arnd Bergmann's avatar
      gcov: disable tree-loop-im to reduce stack usage · defacd21
      Arnd Bergmann authored
      commit c87bf431 upstream.
      
      Enabling CONFIG_GCOV_PROFILE_ALL produces us a lot of warnings like
      
      lib/lz4/lz4hc_compress.c: In function 'lz4_compresshcctx':
      lib/lz4/lz4hc_compress.c:514:1: warning: the frame size of 1504 bytes is larger than 1024 bytes [-Wframe-larger-than=]
      
      After some investigation, I found that this behavior started with gcc-4.9,
      and opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69702.
      A suggested workaround for it is to use the -fno-tree-loop-im
      flag that turns off one of the optimization stages in gcc, so the
      code runs a little slower but does not use excessive amounts
      of stack.
      
      We could make this conditional on the gcc version, but I could not
      find an easy way to do this in Kbuild and the benefit would be
      fairly small, given that most of the gcc version in production are
      affected now.
      
      I'm marking this for 'stable' backports because it addresses a bug
      with code generation in gcc that exists in all kernel versions
      with the affected gcc releases.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarPeter Oberparleiter <oberpar@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      defacd21
    • Joshua Kinard's avatar
      MIPS: Adjust set_pte() SMP fix to handle R10000_LLSC_WAR · a5254486
      Joshua Kinard authored
      commit 12863939 upstream.
      
      Update the recent changes to set_pte() that were added in 46011e6e
      to handle R10000_LLSC_WAR, and format the assembly to match other areas
      of the MIPS tree using the same WAR.
      
      This also incorporates a patch recently sent in my Markos Chandras,
      "Remove local LL/SC preprocessor variants", so that patch doesn't need
      to be applied if this one is accepted.
      Signed-off-by: default avatarJoshua Kinard <kumba@gentoo.org>
      Fixes: 46011e6e ("MIPS: Make set_pte() SMP safe.)
      Cc: David Daney <david.daney@cavium.com>
      Cc: Linux/MIPS <linux-mips@linux-mips.org>
      Patchwork: https://patchwork.linux-mips.org/patch/11103/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      [bwh: Backported to 3.2:
       - Use {LL,SC}_INSN not __{LL,SC}
       - Use literal arch=r4000 instead of MIPS_ISA_ARCH_LEVEL since R6 is not
         supported]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      a5254486
    • Dan Carpenter's avatar
      ACPI / sysfs: fix error code in get_status() · ae9dc44c
      Dan Carpenter authored
      commit f18ebc21 upstream.
      
      The problem with ornamental, do-nothing gotos is that they lead to
      "forgot to set the error code" bugs.  We should be returning -EINVAL
      here but we don't.  It leads to an uninitalized variable in
      counter_show():
      
          drivers/acpi/sysfs.c:603 counter_show()
          error: uninitialized symbol 'status'.
      
      Fixes: 1c8fce27 (ACPI: introduce drivers/acpi/sysfs.c)
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      ae9dc44c
    • Lei Liu's avatar
      USB: serial: option: add even more ZTE device ids · bdcc4ee4
      Lei Liu authored
      commit 74d2a91a upstream.
      
      Add even more ZTE device ids.
      Signed-off-by: default avatarlei liu <liu.lei78@zte.com.cn>
      [johan: rebase and replace commit message ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      bdcc4ee4
    • lei liu's avatar
      USB: serial: option: add more ZTE device ids · 1782e204
      lei liu authored
      commit f0d09463 upstream.
      
      More ZTE device ids.
      Signed-off-by: default avatarlei liu <liu.lei78@zte.com.cn>
      [properly sort them - gregkh]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      1782e204
    • Jiri Slaby's avatar
      tty: vt, return error when con_startup fails · bc8d9d42
      Jiri Slaby authored
      commit 6798df4c upstream.
      
      When csw->con_startup() fails in do_register_con_driver, we return no
      error (i.e. 0). This was changed back in 2006 by commit 3e795de7.
      Before that we used to return -ENODEV.
      
      So fix the return value to be -ENODEV in that case again.
      
      Fixes: 3e795de7 ("VT binding: Add binding/unbinding support for the VT console")
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Reported-by: default avatar"Dan Carpenter" <dan.carpenter@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      bc8d9d42
    • Geert Uytterhoeven's avatar
      char: Drop bogus dependency of DEVPORT on !M68K · dae2881c
      Geert Uytterhoeven authored
      commit 309124e2 upstream.
      
      According to full-history-linux commit d3794f4fa7c3edc3 ("[PATCH] M68k
      update (part 25)"), port operations are allowed on m68k if CONFIG_ISA is
      defined.
      
      However, commit 153dcc54 ("[PATCH] mem driver: fix conditional
      on isa i/o support") accidentally changed an "||" into an "&&",
      disabling it completely on m68k. This logic was retained when
      introducing the DEVPORT symbol in commit 4f911d64 ("Make
      /dev/port conditional on config symbol").
      
      Drop the bogus dependency on !M68K to fix this.
      
      Fixes: 153dcc54 ("[PATCH] mem driver: fix conditional on isa i/o support")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Tested-by: default avatarAl Stone <ahs3@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      dae2881c
    • Theodore Ts'o's avatar
      ext4: fix hang when processing corrupted orphaned inode list · cb7a13ce
      Theodore Ts'o authored
      commit c9eb13a9 upstream.
      
      If the orphaned inode list contains inode #5, ext4_iget() returns a
      bad inode (since the bootloader inode should never be referenced
      directly).  Because of the bad inode, we end up processing the inode
      repeatedly and this hangs the machine.
      
      This can be reproduced via:
      
         mke2fs -t ext4 /tmp/foo.img 100
         debugfs -w -R "ssv last_orphan 5" /tmp/foo.img
         mount -o loop /tmp/foo.img /mnt
      
      (But don't do this if you are using an unpatched kernel if you care
      about the system staying functional.  :-)
      
      This bug was found by the port of American Fuzzy Lop into the kernel
      to find file system problems[1].  (Since it *only* happens if inode #5
      shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not
      surprising that AFL needed two hours before it found it.)
      
      [1] http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf
      
      Reported by: Vegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      cb7a13ce
    • Raghava Aditya Renukunta's avatar
      aacraid: Fix for aac_command_thread hang · aecf3aa4
      Raghava Aditya Renukunta authored
      commit fc4bf75e upstream.
      
      Typically under error conditions, it is possible for aac_command_thread()
      to miss the wakeup from kthread_stop() and go back to sleep, causing it
      to hang aac_shutdown.
      
      In the observed scenario, the adapter is not functioning correctly and so
      aac_fib_send() never completes (or time-outs depending on how it was
      called). Shortly after aac_command_thread() starts it performs
      aac_fib_send(SendHostTime) which hangs. When aac_probe_one
      /aac_get_adapter_info send time outs, kthread_stop is called which breaks
      the command thread out of it's hang.
      
      The code will still go back to sleep in schedule_timeout() without
      checking kthread_should_stop() so it causes aac_probe_one to hang until
      the schedule_timeout() which is 30 minutes.
      
      Fixed by: Adding another kthread_should_stop() before schedule_timeout()
      Signed-off-by: default avatarRaghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
      Reviewed-by: default avatarJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      aecf3aa4
    • Luke Dashjr's avatar
      btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl · b3c5772b
      Luke Dashjr authored
      commit 4c63c245 upstream.
      
      32-bit ioctl uses these rather than the regular FS_IOC_* versions. They can
      be handled in btrfs using the same code. Without this, 32-bit {ch,ls}attr
      fail.
      Signed-off-by: default avatarLuke Dashjr <luke-jr+git@utopios.org>
      Reviewed-by: default avatarJosef Bacik <jbacik@fb.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      b3c5772b
    • Marek Szyprowski's avatar
      crypto: s5p-sss - fix incorrect usage of scatterlists api · 4a223a2d
      Marek Szyprowski authored
      commit d1497977 upstream.
      
      sg_dma_len() macro can be used only on scattelists which are mapped, so
      all calls to it before dma_map_sg() are invalid. Replace them by proper
      check for direct sg segment length read.
      
      Fixes: a49e490c ("crypto: s5p-sss - add S5PV210 advanced crypto engine support")
      Fixes: 9e4a1100 ("crypto: s5p-sss - Handle unaligned buffers")
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Acked-by: default avatarVladimir Zapolskiy <vz@mleia.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      [bwh: Backported to 3.2: unaligned DMA is unsupported so there is a different
       set of calls to replace]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      4a223a2d
    • Bjorn Helgaas's avatar
      alpha/PCI: Call iomem_is_exclusive() for IORESOURCE_MEM, but not IORESOURCE_IO · 5dd415ec
      Bjorn Helgaas authored
      commit c20e1280 upstream.
      
      The alpha pci_mmap_resource() is used for both IORESOURCE_MEM and
      IORESOURCE_IO resources, but iomem_is_exclusive() is only applicable for
      IORESOURCE_MEM.
      
      Call iomem_is_exclusive() only for IORESOURCE_MEM resources, and do it
      earlier to match the generic version of pci_mmap_resource().
      
      Fixes: 10a0ef39 ("PCI/alpha: pci sysfs resources")
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      5dd415ec
    • Bjorn Helgaas's avatar
      PCI: Supply CPU physical address (not bus address) to iomem_is_exclusive() · c94e97f3
      Bjorn Helgaas authored
      commit ca620723 upstream.
      
      iomem_is_exclusive() requires a CPU physical address, but on some arches we
      supplied a PCI bus address instead.
      
      On most arches, pci_resource_to_user(res) returns "res->start", which is a
      CPU physical address.  But on microblaze, mips, powerpc, and sparc, it
      returns the PCI bus address corresponding to "res->start".
      
      The result is that pci_mmap_resource() may fail when it shouldn't (if the
      bus address happens to match an existing resource), or it may succeed when
      it should fail (if the resource is exclusive but the bus address doesn't
      match it).
      
      Call iomem_is_exclusive() with "res->start", which is always a CPU physical
      address, not the result of pci_resource_to_user().
      
      Fixes: e8de1481 ("resource: allow MMIO exclusivity for device drivers")
      Suggested-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Arjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      c94e97f3
    • Krzysztof Kozlowski's avatar
      crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks · 79171d65
      Krzysztof Kozlowski authored
      commit 79152e8d upstream.
      
      The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
      testing 8 kB size blocks:
      
      	$ sudo modprobe tcrypt sec=1 mode=500
      	testing speed of async ecb(aes) (ecb-aes-s5p) encryption
      	test 0 (128 bit key, 16 byte blocks): 21971 operations in 1 seconds (351536 bytes)
      	test 1 (128 bit key, 64 byte blocks): 21731 operations in 1 seconds (1390784 bytes)
      	test 2 (128 bit key, 256 byte blocks): 21932 operations in 1 seconds (5614592 bytes)
      	test 3 (128 bit key, 1024 byte blocks): 21685 operations in 1 seconds (22205440 bytes)
      	test 4 (128 bit key, 8192 byte blocks):
      
      This was caused by a race issue of missed BRDMA_DONE ("Block cipher
      Receiving DMA") interrupt. Device starts processing the data in DMA mode
      immediately after setting length of DMA block: receiving (FCBRDMAL) or
      transmitting (FCBTDMAL). The driver sets these lengths from interrupt
      handler through s5p_set_dma_indata() function (or xxx_setdata()).
      
      However the interrupt handler was first dealing with receive buffer
      (dma-unmap old, dma-map new, set receive block length which starts the
      operation), then with transmit buffer and finally was clearing pending
      interrupts (FCINTPEND). Because of the time window between setting
      receive buffer length and clearing pending interrupts, the operation on
      receive buffer could end already and driver would miss new interrupt.
      
      User manual for Exynos5422 confirms in example code that setting DMA
      block lengths should be the last operation.
      
      The tcrypt hang could be also observed in following blocked-task dmesg:
      
      INFO: task modprobe:258 blocked for more than 120 seconds.
            Not tainted 4.6.0-rc4-next-20160419-00005-g9eac8b7b7753-dirty #42
      "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      modprobe        D c06b09d8     0   258    256 0x00000000
      [<c06b09d8>] (__schedule) from [<c06b0f24>] (schedule+0x40/0xac)
      [<c06b0f24>] (schedule) from [<c06b49f8>] (schedule_timeout+0x124/0x178)
      [<c06b49f8>] (schedule_timeout) from [<c06b17fc>] (wait_for_common+0xb8/0x144)
      [<c06b17fc>] (wait_for_common) from [<bf0013b8>] (test_acipher_speed+0x49c/0x740 [tcrypt])
      [<bf0013b8>] (test_acipher_speed [tcrypt]) from [<bf003e8c>] (do_test+0x2240/0x30ec [tcrypt])
      [<bf003e8c>] (do_test [tcrypt]) from [<bf008048>] (tcrypt_mod_init+0x48/0xa4 [tcrypt])
      [<bf008048>] (tcrypt_mod_init [tcrypt]) from [<c010177c>] (do_one_initcall+0x3c/0x16c)
      [<c010177c>] (do_one_initcall) from [<c0191ff0>] (do_init_module+0x5c/0x1ac)
      [<c0191ff0>] (do_init_module) from [<c0185610>] (load_module+0x1a30/0x1d08)
      [<c0185610>] (load_module) from [<c0185ab0>] (SyS_finit_module+0x8c/0x98)
      [<c0185ab0>] (SyS_finit_module) from [<c01078c0>] (ret_fast_syscall+0x0/0x3c)
      
      Fixes: a49e490c ("crypto: s5p-sss - add S5PV210 advanced crypto engine support")
      Signed-off-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Tested-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      [bwh: Backported to 3.2: adjust context]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      79171d65
    • Joseph Salisbury's avatar
      ath5k: Change led pin configuration for compaq c700 laptop · 9383358c
      Joseph Salisbury authored
      commit 7b9bc799 upstream.
      
      BugLink: http://bugs.launchpad.net/bugs/972604
      
      Commit 09c9bae2 ("ath5k: add led pin
      configuration for compaq c700 laptop") added a pin configuration for the Compaq
      c700 laptop.  However, the polarity of the led pin is reversed.  It should be
      red for wifi off and blue for wifi on, but it is the opposite.  This bug was
      reported in the following bug report:
      http://pad.lv/972604
      
      Fixes: 09c9bae2 ("ath5k: add led pin configuration for compaq c700 laptop")
      Signed-off-by: default avatarJoseph Salisbury <joseph.salisbury@canonical.com>
      Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      9383358c
    • Andrew F. Davis's avatar
      regmap: cache: Fix typo in cache_bypass parameter description · f9b25cf9
      Andrew F. Davis authored
      commit 267c8586 upstream.
      
      Setting the flag 'cache_bypass' will bypass the cache not the hardware.
      Fix this comment here.
      
      Fixes: 0eef6b04 ("regmap: Fix doc comment")
      Signed-off-by: default avatarAndrew F. Davis <afd@ti.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      f9b25cf9
  2. 15 Jun, 2016 19 commits