Srinath Mannam [Fri, 18 May 2018 22:03:55 +0000 (15:03 -0700)]
mmc: sdhci-iproc: remove hard coded mmc cap 1.8v
commit
4c94238f37af87a2165c3fb491b4a8b50e90649c upstream.
Remove hard coded mmc cap 1.8v from platform data as it is board specific.
The 1.8v DDR mmc caps can be enabled using DTS property for those
boards that support it.
Fixes:
b17b4ab8ce38 ("mmc: sdhci-iproc: define MMC caps in platform data")
Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
Signed-off-by: Scott Branden <scott.branden@broadcom.com>
Reviewed-by: Ray Jui <ray.jui@broadcom.com>
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Fri, 4 May 2018 12:23:01 +0000 (08:23 -0400)]
do d_instantiate/unlock_new_inode combinations safely
commit
1e2e547a93a00ebc21582c06ca3c6cfea2a309ee upstream.
For anything NFS-exported we do _not_ want to unlock new inode
before it has grown an alias; original set of fixes got the
ordering right, but missed the nasty complication in case of
lockdep being enabled - unlock_new_inode() does
lockdep_annotate_inode_mutex_key(inode)
which can only be done before anyone gets a chance to touch
->i_mutex. Unfortunately, flipping the order and doing
unlock_new_inode() before d_instantiate() opens a window when
mkdir can race with open-by-fhandle on a guessed fhandle, leading
to multiple aliases for a directory inode and all the breakage
that follows from that.
Correct solution: a new primitive (d_instantiate_new())
combining these two in the right order - lockdep annotate, then
d_instantiate(), then the rest of unlock_new_inode(). All
combinations of d_instantiate() with unlock_new_inode() should
be converted to that.
Cc: stable@kernel.org # 2.6.29 and later
Tested-by: Mike Marshall <hubcap@omnibond.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Thu, 17 May 2018 21:34:39 +0000 (22:34 +0100)]
ALSA: timer: Fix pause event notification
commit
3ae180972564846e6d794e3615e1ab0a1e6c4ef9 upstream.
Commit
f65e0d299807 ("ALSA: timer: Call notifier in the same spinlock")
combined the start/continue and stop/pause functions, and in doing so
changed the event code for the pause case to SNDRV_TIMER_EVENT_CONTINUE.
Change it back to SNDRV_TIMER_EVENT_PAUSE.
Fixes:
f65e0d299807 ("ALSA: timer: Call notifier in the same spinlock")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sun, 20 May 2018 20:46:23 +0000 (16:46 -0400)]
aio: fix io_destroy(2) vs. lookup_ioctx() race
commit
baf10564fbb66ea222cae66fbff11c444590ffd9 upstream.
kill_ioctx() used to have an explicit RCU delay between removing the
reference from ->ioctx_table and percpu_ref_kill() dropping the refcount.
At some point that delay had been removed, on the theory that
percpu_ref_kill() itself contained an RCU delay. Unfortunately, that was
the wrong kind of RCU delay and it didn't care about rcu_read_lock() used
by lookup_ioctx(). As the result, we could get ctx freed right under
lookup_ioctx(). Tejun has fixed that in
a6d7cff472e ("fs/aio: Add explicit
RCU grace period when freeing kioctx"); however, that fix is not enough.
Suppose io_destroy() from one thread races with e.g. io_setup() from another;
CPU1 removes the reference from current->mm->ioctx_table[...] just as CPU2
has picked it (under rcu_read_lock()). Then CPU1 proceeds to drop the
refcount, getting it to 0 and triggering a call of free_ioctx_users(),
which proceeds to drop the secondary refcount and once that reaches zero
calls free_ioctx_reqs(). That does
INIT_RCU_WORK(&ctx->free_rwork, free_ioctx);
queue_rcu_work(system_wq, &ctx->free_rwork);
and schedules freeing the whole thing after RCU delay.
In the meanwhile CPU2 has gotten around to percpu_ref_get(), bumping the
refcount from 0 to 1 and returned the reference to io_setup().
Tejun's fix (that queue_rcu_work() in there) guarantees that ctx won't get
freed until after percpu_ref_get(). Sure, we'd increment the counter before
ctx can be freed. Now we are out of rcu_read_lock() and there's nothing to
stop freeing of the whole thing. Unfortunately, CPU2 assumes that since it
has grabbed the reference, ctx is *NOT* going away until it gets around to
dropping that reference.
The fix is obvious - use percpu_ref_tryget_live() and treat failure as miss.
It's not costlier than what we currently do in normal case, it's safe to
call since freeing *is* delayed and it closes the race window - either
lookup_ioctx() comes before percpu_ref_kill() (in which case ctx->users
won't reach 0 until the caller of lookup_ioctx() drops it) or lookup_ioctx()
fails, ctx->users is unaffected and caller of lookup_ioctx() doesn't see
the object in question at all.
Cc: stable@kernel.org
Fixes:
a6d7cff472e "fs/aio: Add explicit RCU grace period when freeing kioctx"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Chinner [Fri, 11 May 2018 01:20:57 +0000 (11:20 +1000)]
fs: don't scan the inode cache before SB_BORN is set
commit
79f546a696bff2590169fb5684e23d65f4d9f591 upstream.
We recently had an oops reported on a 4.14 kernel in
xfs_reclaim_inodes_count() where sb->s_fs_info pointed to garbage
and so the m_perag_tree lookup walked into lala land. It produces
an oops down this path during the failed mount:
radix_tree_gang_lookup_tag+0xc4/0x130
xfs_perag_get_tag+0x37/0xf0
xfs_reclaim_inodes_count+0x32/0x40
xfs_fs_nr_cached_objects+0x11/0x20
super_cache_count+0x35/0xc0
shrink_slab.part.66+0xb1/0x370
shrink_node+0x7e/0x1a0
try_to_free_pages+0x199/0x470
__alloc_pages_slowpath+0x3a1/0xd20
__alloc_pages_nodemask+0x1c3/0x200
cache_grow_begin+0x20b/0x2e0
fallback_alloc+0x160/0x200
kmem_cache_alloc+0x111/0x4e0
The problem is that the superblock shrinker is running before the
filesystem structures it depends on have been fully set up. i.e.
the shrinker is registered in sget(), before ->fill_super() has been
called, and the shrinker can call into the filesystem before
fill_super() does it's setup work. Essentially we are exposed to
both use-after-free and use-before-initialisation bugs here.
To fix this, add a check for the SB_BORN flag in super_cache_count.
In general, this flag is not set until ->fs_mount() completes
successfully, so we know that it is set after the filesystem
setup has completed. This matches the trylock_super() behaviour
which will not let super_cache_scan() run if SB_BORN is not set, and
hence will not allow the superblock shrinker from entering the
filesystem while it is being set up or after it has failed setup
and is being torn down.
Cc: stable@kernel.org
Signed-Off-By: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Al Viro [Sun, 6 May 2018 16:15:20 +0000 (12:15 -0400)]
affs_lookup(): close a race with affs_remove_link()
commit
30da870ce4a4e007c901858a96e9e394a1daa74a upstream.
we unlock the directory hash too early - if we are looking at secondary
link and primary (in another directory) gets removed just as we unlock,
we could have the old primary moved in place of the secondary, leaving
us to look into freed entry (and leaving our dentry with ->d_fsdata
pointing to a freed entry).
Cc: stable@vger.kernel.org # 2.4.4+
Acked-by: David Sterba <dsterba@suse.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Mon, 14 May 2018 17:23:50 +0000 (18:23 +0100)]
KVM: Fix spelling mistake: "cop_unsuable" -> "cop_unusable"
commit
ba3696e94d9d590d9a7e55f68e81c25dba515191 upstream.
Trivial fix to spelling mistake in debugfs_entries text.
Fixes:
669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: kernel-janitors@vger.kernel.org
Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Mon, 14 May 2018 15:49:43 +0000 (16:49 +0100)]
MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR accesses to o32 FGRs
commit
9a3a92ccfe3620743d4ae57c987dc8e9c5f88996 upstream.
Check the TIF_32BIT_FPREGS task setting of the tracee rather than the
tracer in determining the layout of floating-point general registers in
the floating-point context, correcting access to odd-numbered registers
for o32 tracees where the setting disagrees between the two processes.
Fixes:
597ce1723e0f ("MIPS: Support for 64-bit FP with O32 binaries")
Signed-off-by: Maciej W. Rozycki <macro@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 3.14+
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Mon, 30 Apr 2018 14:56:47 +0000 (15:56 +0100)]
MIPS: ptrace: Expose FIR register through FP regset
commit
71e909c0cdad28a1df1fa14442929e68615dee45 upstream.
Correct commit
7aeb753b5353 ("MIPS: Implement task_user_regset_view.")
and expose the FIR register using the unused 4 bytes at the end of the
NT_PRFPREG regset. Without that register included clients cannot use
the PTRACE_GETREGSET request to retrieve the complete FPU register set
and have to resort to one of the older interfaces, either PTRACE_PEEKUSR
or PTRACE_GETFPREGS, to retrieve the missing piece of data. Also the
register is irreversibly missing from core dumps.
This register is architecturally hardwired and read-only so the write
path does not matter. Ignore data supplied on writes then.
Fixes:
7aeb753b5353 ("MIPS: Implement task_user_regset_view.")
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Maciej W. Rozycki <macro@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 3.13+
Patchwork: https://patchwork.linux-mips.org/patch/19273/
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Thu, 26 Apr 2018 23:28:34 +0000 (09:28 +1000)]
MIPS: c-r4k: Fix data corruption related to cache coherence
commit
55a2aa08b3af519a9693f99cdf7fa6d8b62d9f65 upstream.
When DMA will be performed to a MIPS32 1004K CPS, the L1-cache for the
range needs to be flushed and invalidated first.
The code currently takes one of two approaches.
1/ If the range is less than the size of the dcache, then HIT type
requests flush/invalidate cache lines for the particular addresses.
HIT-type requests a globalised by the CPS so this is safe on SMP.
2/ If the range is larger than the size of dcache, then INDEX type
requests flush/invalidate the whole cache. INDEX type requests affect
the local cache only. CPS does not propagate them in any way. So this
invalidation is not safe on SMP CPS systems.
Data corruption due to '2' can quite easily be demonstrated by
repeatedly "echo 3 > /proc/sys/vm/drop_caches" and then sha1sum a file
that is several times the size of available memory. Dropping caches
means that large contiguous extents (large than dcache) are more likely.
This was not a problem before Linux-4.8 because option 2 was never used
if CONFIG_MIPS_CPS was defined. The commit which removed that apparently
didn't appreciate the full consequence of the change.
We could, in theory, globalize the INDEX based flush by sending an IPI
to other cores. These cache invalidation routines can be called with
interrupts disabled and synchronous IPI require interrupts to be
enabled. Asynchronous IPI may not trigger writeback soon enough. So we
cannot use IPI in practice.
We can already test if IPI would be needed for an INDEX operation with
r4k_op_needs_ipi(R4K_INDEX). If this is true then we mustn't try the
INDEX approach as we cannot use IPI. If this is false (e.g. when there
is only one core and hence one L1 cache) then it is safe to use the
INDEX approach without IPI.
This patch avoids options 2 if r4k_op_needs_ipi(R4K_INDEX), and so
eliminates the corruption.
Fixes:
c00ab4896ed5 ("MIPS: Remove cpu_has_safe_index_cacheops")
Signed-off-by: NeilBrown <neil@brown.name>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 4.8+
Patchwork: https://patchwork.linux-mips.org/patch/19259/
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Fri, 25 May 2018 14:18:02 +0000 (16:18 +0200)]
Linux 4.14.44
James Hogan [Tue, 16 Jan 2018 14:45:21 +0000 (14:45 +0000)]
rtc: goldfish: Add missing MODULE_LICENSE
[ Upstream commit
82d632b85eb89f97051530f556cb49ee1c04bde7 ]
Fix the following warning in MIPS allmodconfig by adding a
MODULE_LICENSE() at the end of rtc-goldfish.c, based on the file header
comment which says GNU General Public License version 2:
WARNING: modpost: missing MODULE_LICENSE() in drivers/rtc/rtc-goldfish.o
Fixes:
f22d9cdcb5eb ("rtc: goldfish: Add RTC driver for Android emulator")
Signed-off-by: James Hogan <jhogan@kernel.org>
Cc: Miodrag Dinic <miodrag.dinic@mips.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: linux-rtc@vger.kernel.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandre Belloni [Mon, 12 Feb 2018 22:47:49 +0000 (23:47 +0100)]
rtc: rp5c01: fix possible race condition
[ Upstream commit
bcdd559268039d8340d38fa58668393596e29fdc ]
The probe function is not allowed to fail after registering the RTC because
the following may happen:
CPU0: CPU1:
sys_load_module()
do_init_module()
do_one_initcall()
cmos_do_probe()
rtc_device_register()
__register_chrdev()
cdev->owner = struct module*
open("/dev/rtc0")
rtc_device_unregister()
module_put()
free_module()
module_free(mod->module_core)
/* struct module *module is now
freed */
chrdev_open()
spin_lock(cdev_lock)
cdev_get()
try_module_get()
module_is_live()
/* dereferences already
freed struct module* */
Switch to devm_rtc_allocate_device/rtc_register_device to register the rtc
as late as possible.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Thu, 15 Feb 2018 19:36:14 +0000 (19:36 +0000)]
rtc: tx4939: avoid unintended sign extension on a 24 bit shift
[ Upstream commit
347876ad47b9923ce26e686173bbf46581802ffa ]
The shifting of buf[5] by 24 bits to the left will be promoted to
a 32 bit signed int and then sign-extended to an unsigned long. If
the top bit of buf[5] is set then all then all the upper bits sec
end up as also being set because of the sign-extension. Fix this by
casting buf[5] to an unsigned long before the shift.
Detected by CoverityScan, CID#1465292 ("Unintended sign extension")
Fixes:
0e1492330cd2 ("rtc: add rtc-tx4939 driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandre Belloni [Sun, 25 Feb 2018 20:14:31 +0000 (21:14 +0100)]
rtc: m41t80: fix race conditions
[ Upstream commit
10d0c768cc6d581523d673b9d1b54213f8a5eb24 ]
The IRQ is requested before the struct rtc is allocated and registered, but
this struct is used in the IRQ handler, leading to:
Unable to handle kernel NULL pointer dereference at virtual address
0000017c
pgd =
a38a2f9b
[
0000017c] *pgd=
00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 613 Comm: irq/48-m41t80 Not tainted 4.16.0-rc1+ #42
Hardware name: Atmel SAMA5
PC is at mutex_lock+0x14/0x38
LR is at m41t80_handle_irq+0x1c/0x9c
pc : [<
c06e864c>] lr : [<
c04b70f0>] psr:
20000013
sp :
dec73f30 ip :
00000000 fp :
dec56d98
r10:
df437cf0 r9 :
c0a03008 r8 :
c0145ffc
r7 :
df5c4300 r6 :
dec568d0 r5 :
df593000 r4 :
0000017c
r3 :
df592800 r2 :
60000013 r1 :
df593000 r0 :
0000017c
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control:
10c53c7d Table:
20004059 DAC:
00000051
Process irq/48-m41t80 (pid: 613, stack limit = 0xb52d091e)
Stack: (0xdec73f30 to 0xdec74000)
3f20:
dec56840 df5c4300 00000001 df5c4300
3f40:
c0145ffc c0146018 dec56840 ffffe000 00000001 c0146290 dec567c0 00000000
3f60:
c0146084 ed7c9a62 c014615c dec56d80 dec567c0 00000000 dec72000 dec56840
3f80:
c014615c c012ffc0 dec72000 dec567c0 c012fe80 00000000 00000000 00000000
3fa0:
00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
3fc0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0:
00000000 00000000 00000000 00000000 00000013 00000000 29282726 2d2c2b2a
[<
c06e864c>] (mutex_lock) from [<
c04b70f0>] (m41t80_handle_irq+0x1c/0x9c)
[<
c04b70f0>] (m41t80_handle_irq) from [<
c0146018>] (irq_thread_fn+0x1c/0x54)
[<
c0146018>] (irq_thread_fn) from [<
c0146290>] (irq_thread+0x134/0x1c0)
[<
c0146290>] (irq_thread) from [<
c012ffc0>] (kthread+0x140/0x148)
[<
c012ffc0>] (kthread) from [<
c01010e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0xdec73fb0 to 0xdec73ff8)
3fa0:
00000000 00000000 00000000 00000000
3fc0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3fe0:
00000000 00000000 00000000 00000000 00000013 00000000
Code:
e3c33d7f e3c3303f f5d0f000 e593300c (
e1901f9f)
---[ end trace
22b027302eb7c604 ]---
genirq: exiting task "irq/48-m41t80" (613) is an active IRQ thread (irq 48)
Also, there is another possible race condition. The probe function is not
allowed to fail after the RTC is registered because the following may
happen:
CPU0: CPU1:
sys_load_module()
do_init_module()
do_one_initcall()
cmos_do_probe()
rtc_device_register()
__register_chrdev()
cdev->owner = struct module*
open("/dev/rtc0")
rtc_device_unregister()
module_put()
free_module()
module_free(mod->module_core)
/* struct module *module is now
freed */
chrdev_open()
spin_lock(cdev_lock)
cdev_get()
try_module_get()
module_is_live()
/* dereferences already
freed struct module* */
Switch to devm_rtc_allocate_device/rtc_register_device to allocate the rtc
before requesting the IRQ and register it as late as possible.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandre Belloni [Wed, 21 Feb 2018 10:57:05 +0000 (11:57 +0100)]
rtc: rk808: fix possible race condition
[ Upstream commit
201fac95e799c3d0304ec724d555e1251b9f6e84 ]
The probe function is not allowed to fail after registering the RTC because
the following may happen:
CPU0: CPU1:
sys_load_module()
do_init_module()
do_one_initcall()
cmos_do_probe()
rtc_device_register()
__register_chrdev()
cdev->owner = struct module*
open("/dev/rtc0")
rtc_device_unregister()
module_put()
free_module()
module_free(mod->module_core)
/* struct module *module is now
freed */
chrdev_open()
spin_lock(cdev_lock)
cdev_get()
try_module_get()
module_is_live()
/* dereferences already
freed struct module* */
Switch to devm_rtc_allocate_device/rtc_register_device to register the rtc
as late as possible.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexandre Belloni [Thu, 8 Mar 2018 22:27:31 +0000 (23:27 +0100)]
rtc: hctosys: Ensure system time doesn't overflow time_t
[ Upstream commit
b3a5ac42ab18b7d1a8f2f072ca0ee76a3b754a43 ]
On 32bit platforms, time_t is still a signed 32bit long. If it is
overflowed, userspace and the kernel cant agree on the current system time.
This causes multiple issues, in particular with systemd:
https://github.com/systemd/systemd/issues/1143
A good workaround is to simply avoid using hctosys which is something I
greatly encourage as the time is better set by userspace.
However, many distribution enable it and use systemd which is rendering the
system unusable in case the RTC holds a date after 2038 (and more so after
2106). Many drivers have workaround for this case and they should be
eliminated so there is only one place left to fix when userspace is able to
cope with dates after the 31bit overflow.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bryan O'Donoghue [Wed, 28 Mar 2018 19:14:05 +0000 (20:14 +0100)]
rtc: snvs: Fix usage of snvs_rtc_enable
[ Upstream commit
1485991c024603b2fb4ae77beb7a0d741128a48e ]
commit
179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") introduces
the SNVS RTC driver with a function snvs_rtc_enable().
snvs_rtc_enable() can return an error on the enable path however this
driver does not currently trap that failure on the probe() path and
consequently if enabling the RTC fails we encounter a later error spinning
forever in rtc_write_sync_lp().
[ 36.093481] [<
c010d630>] (__irq_svc) from [<
c0c2e9ec>] (_raw_spin_unlock_irqrestore+0x34/0x44)
[ 36.102122] [<
c0c2e9ec>] (_raw_spin_unlock_irqrestore) from [<
c072e32c>] (regmap_read+0x4c/0x5c)
[ 36.110938] [<
c072e32c>] (regmap_read) from [<
c085d0f4>] (rtc_write_sync_lp+0x6c/0x98)
[ 36.118881] [<
c085d0f4>] (rtc_write_sync_lp) from [<
c085d160>] (snvs_rtc_alarm_irq_enable+0x40/0x4c)
[ 36.128041] [<
c085d160>] (snvs_rtc_alarm_irq_enable) from [<
c08567b4>] (rtc_timer_do_work+0xd8/0x1a8)
[ 36.137291] [<
c08567b4>] (rtc_timer_do_work) from [<
c01441b8>] (process_one_work+0x28c/0x76c)
[ 36.145840] [<
c01441b8>] (process_one_work) from [<
c01446cc>] (worker_thread+0x34/0x58c)
[ 36.153961] [<
c01446cc>] (worker_thread) from [<
c014aee4>] (kthread+0x138/0x150)
[ 36.161388] [<
c014aee4>] (kthread) from [<
c0107e14>] (ret_from_fork+0x14/0x20)
[ 36.168635] rcu_sched kthread starved for 2602 jiffies! g496 c495 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
[ 36.178564] rcu_sched R running task 0 8 2 0x00000000
[ 36.185664] [<
c0c288b0>] (__schedule) from [<
c0c29134>] (schedule+0x3c/0xa0)
[ 36.192739] [<
c0c29134>] (schedule) from [<
c0c2db80>] (schedule_timeout+0x78/0x4e0)
[ 36.200422] [<
c0c2db80>] (schedule_timeout) from [<
c01a7ab0>] (rcu_gp_kthread+0x648/0x1864)
[ 36.208800] [<
c01a7ab0>] (rcu_gp_kthread) from [<
c014aee4>] (kthread+0x138/0x150)
[ 36.216309] [<
c014aee4>] (kthread) from [<
c0107e14>] (ret_from_fork+0x14/0x20)
This patch fixes by parsing the result of rtc_write_sync_lp() and
propagating both in the probe and elsewhere. If the RTC doesn't start we
don't proceed loading the driver and don't get into this loop mess later
on.
Fixes:
179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver")
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Uwe Kleine-König [Thu, 25 Jan 2018 13:30:43 +0000 (14:30 +0100)]
serial: altera: ensure port->regshift is honored consistently
[ Upstream commit
0e254963b6ba4d63ac911e79537fea38dd03dc50 ]
Most register accesses in the altera driver honor port->regshift by
using altera_uart_writel(). There are a few accesses however that were
missed when the driver was converted to use port->regshift and some
others were added later in commit
4d9d7d896d77 ("serial: altera_uart:
add earlycon support").
Fixes:
2780ad42f5fe ("tty: serial: altera_uart: Use port->regshift to store bus shift")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vignesh R [Thu, 8 Feb 2018 12:55:41 +0000 (18:25 +0530)]
serial: 8250: Don't service RX FIFO if interrupts are disabled
[ Upstream commit
2e9fe539108320820016f78ca7704a7342788380 ]
Currently, data in RX FIFO is read based on UART_LSR register state even
if RDI and RLSI interrupts are disabled in UART_IER register.
This is because when IRQ handler is called due to TX FIFO empty event,
RX FIFO is serviced based on UART_LSR register status instead of
UART_IIR status. This defeats the purpose of disabling UART RX
FIFO interrupts during throttling(see, omap_8250_throttle()) as IRQ
handler continues to drain UART RX FIFO resulting in overflow of buffer
at tty layer.
Fix this by making sure that driver drains UART RX FIFO only when
UART_IIR_RDI is set along with UART_LSR_BI or UART_LSR_DR bits.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:29 +0000 (14:38 +0100)]
serial: arc_uart: Fix out-of-bounds access through DT alias
[ Upstream commit
f9f5786987e81d166c60833edcb7d1836aa16944 ]
The arc_uart_ports[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.
Fix this by adding a range check.
Note that the array size is defined by a Kconfig symbol
(CONFIG_SERIAL_ARC_NR_PORTS), so this can even be triggered using a
legitimate DTB.
Fixes:
ea28fd56fcde69af ("serial/arc-uart: switch to devicetree based probing")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:30 +0000 (14:38 +0100)]
serial: fsl_lpuart: Fix out-of-bounds access through DT alias
[ Upstream commit
ffab87fdecc655cc676f8be8dd1a2c5e22bd6d47 ]
The lpuart_ports[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.
Fix this by adding a range check.
Fixes:
c9e2e946fb0ba5d2 ("tty: serial: add Freescale lpuart driver support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:31 +0000 (14:38 +0100)]
serial: imx: Fix out-of-bounds access through serial port index
[ Upstream commit
5673444821406dda5fc25e4b52aca419f8065a19 ]
The imx_ports[] array is indexed using a value derived from the
"serialN" alias in DT, or from platform data, which may lead to an
out-of-bounds access.
Fix this by adding a range check.
Fixes:
ff05967a07225ab6 ("serial/imx: add of_alias_get_id() reference back")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:32 +0000 (14:38 +0100)]
serial: mxs-auart: Fix out-of-bounds access through serial port index
[ Upstream commit
dd345a31bfdec350d2593e6de5964e55c7f19c76 ]
The auart_port[] array is indexed using a value derived from the
"serialN" alias in DT, or from platform data, which may lead to an
out-of-bounds access.
Fix this by adding a range check.
Fixes:
1ea6607d4cdc9179 ("serial: mxs-auart: Allow device tree probing")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:34 +0000 (14:38 +0100)]
serial: samsung: Fix out-of-bounds access through serial port index
[ Upstream commit
49ee23b71877831ac087d6083f6f397dc19c9664 ]
The s3c24xx_serial_ports[] array is indexed using a value derived from
the "serialN" alias in DT, or from an incrementing probe index, which
may lead to an out-of-bounds access.
Fix this by adding a range check.
Note that the array size is defined by a Kconfig symbol
(CONFIG_SERIAL_SAMSUNG_UARTS), so this can even be triggered using
a legitimate DTB or legitimate board code.
Fixes:
13a9f6c64fdc55eb ("serial: samsung: Consider DT alias when probing ports")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:35 +0000 (14:38 +0100)]
serial: sh-sci: Fix out-of-bounds access through DT alias
[ Upstream commit
090fa4b0dccfa3d04e1c5ab0fe4eba16e6713895 ]
The sci_ports[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.
Fix this by adding a range check.
Note that the array size is defined by a Kconfig symbol
(CONFIG_SERIAL_SH_SCI_NR_UARTS), so this can even be triggered using a
legitimate DTB.
Fixes:
97ed9790c514066b ("serial: sh-sci: Remove unused platform data capabilities field")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Fri, 23 Feb 2018 13:38:37 +0000 (14:38 +0100)]
serial: xuartps: Fix out-of-bounds access through DT alias
[ Upstream commit
e7d75e18d0fc3f7193b65282b651f980c778d935 ]
The cdns_uart_port[] array is indexed using a value derived from the
"serialN" alias in DT, which may lead to an out-of-bounds access.
Fix this by adding a range check.
Fixes:
928e9263492069ee ("tty: xuartps: Initialize ports according to aliases")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Wed, 31 Jan 2018 17:33:09 +0000 (12:33 -0500)]
media: cx25821: prevent out-of-bounds read on array card
[ Upstream commit
67300abdbe9f1717532aaf4e037222762716d0f6 ]
Currently an out of range dev->nr is detected by just reporting the
issue and later on an out-of-bounds read on array card occurs because
of this. Fix this by checking the upper range of dev->nr with the size
of array card (removes the hard coded size), move this check earlier
and also exit with the error -ENOSYS to avoid the later out-of-bounds
array read.
Detected by CoverityScan, CID#711191 ("Out-of-bounds-read")
Fixes: commit
02b20b0b4cde ("V4L/DVB (12730): Add conexant cx25821 driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
[hans.verkuil@cisco.com: %ld -> %zd]
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans Verkuil [Thu, 1 Feb 2018 07:36:33 +0000 (02:36 -0500)]
media: vivid: fix incorrect capabilities for radio
[ Upstream commit
65243386f41d38460bfd4375d231a7c0346d0401 ]
The vivid driver has two custom controls that change the behavior of RDS.
Depending on the control setting the V4L2_CAP_READWRITE capability is toggled.
However, after an earlier commit the capability was no longer set correctly.
This is now fixed.
Fixes:
9765a32cd8 ("vivid: set device_caps in video_device")
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masami Hiramatsu [Tue, 6 Feb 2018 08:02:23 +0000 (03:02 -0500)]
media: vb2: Fix videobuf2 to map correct area
[ Upstream commit
d13a0139d7874a0577b5955d6eed895517d23b72 ]
Fixes vb2_vmalloc_get_userptr() to ioremap correct area.
Since the current code does ioremap the page address, if the offset > 0,
it does not do ioremap the last page and results in kernel panic.
This fixes to pass the size + offset to ioremap so that ioremap
can map correct area. Also, this uses __pfn_to_phys() to get the physical
address of given PFN.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Reported-by: Takao Orito <orito.takao@socionext.com>
Reported-by: Fumihiro ATSUMI <atsumi@infinitegra.co.jp>
Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kieran Bingham [Mon, 8 Jan 2018 18:14:04 +0000 (13:14 -0500)]
media: i2c: adv748x: fix HDMI field heights
[ Upstream commit
9f564184e6cc21a86c26bab920afac1bab7653ff ]
The ADV748x handles interlaced media using V4L2_FIELD_ALTERNATE field
types. The correct specification for the height on the mbus is the
image height, in this instance, the field height.
The AFE component already correctly adjusts the height on the mbus, but
the HDMI component got left behind.
Adjust the mbus height to correctly describe the image height of the
fields when processing interlaced video for HDMI pipelines.
Fixes:
3e89586a64df ("media: i2c: adv748x: add adv748x driver")
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laurent Pinchart [Sun, 3 Dec 2017 10:06:57 +0000 (05:06 -0500)]
media: v4l: vsp1: Fix display stalls when requesting too many inputs
[ Upstream commit
5e3e4cb5e24b92773b194aa90066170b12133bc6 ]
Make sure we don't accept more inputs than the hardware can handle. This
is a temporary fix to avoid display stall, we need to instead allocate
the BRU or BRS to display pipelines dynamically based on the number of
planes they each use.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brad Love [Fri, 5 Jan 2018 00:04:15 +0000 (19:04 -0500)]
media: em28xx: Add Hauppauge SoloHD/DualHD bulk models
[ Upstream commit
f2a326c928cca1f5e36a3dceaf66e8c6b34e9cb8 ]
Add additional pids to driver list
Signed-off-by: Brad Love <brad@nextdimension.cc>
Reviewed-by: Michael Ira Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brad Love [Fri, 5 Jan 2018 14:57:13 +0000 (09:57 -0500)]
media: lgdt3306a: Fix a double kfree on i2c device remove
[ Upstream commit
94448e21cf08b10f7dc7acdaca387594370396b0 ]
Both lgdt33606a_release and lgdt3306a_remove kfree state, but _release is
called first, then _remove operates on states members before kfree'ing it.
This can lead to random oops/GPF/etc on USB disconnect.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Tue, 16 Jan 2018 21:52:15 +0000 (16:52 -0500)]
media: s3c-camif: fix out-of-bounds array access
[ Upstream commit
a398e043637a4819a0e96467bfecaabf3224dd62 ]
While experimenting with older compiler versions, I ran
into a warning that no longer shows up on gcc-4.8 or newer:
drivers/media/platform/s3c-camif/camif-capture.c: In function '__camif_subdev_try_format':
drivers/media/platform/s3c-camif/camif-capture.c:1265:25: error: array subscript is below array bounds
This is an off-by-one bug, leading to an access before the start of the
array, while newer compilers silently assume this undefined behavior
cannot happen and leave the loop at index 0 if no other entry matches.
As Sylvester explains, we actually need to ensure that the
value is within the range, so this reworks the loop to be
easier to parse correctly, and an additional check to fall
back on the first format value for any unexpected input.
I found an existing gcc bug for it and added a reduced version
of the function there.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69249#c3
Fixes:
babde1c243b2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brad Love [Tue, 6 Mar 2018 19:15:36 +0000 (14:15 -0500)]
media: cx23885: Set subdev host data to clk_freq pointer
[ Upstream commit
5ceade1d97fc6687e050c44c257382c192f56276 ]
Currently clk_freq is ignored entirely, because the cx235840 driver
configures the xtal at the chip defaults. This is an issue if a
board is produced with a non-default frequency crystal. If clk_freq
is not zero the cx25840 will attempt to use the setting provided,
or fall back to defaults otherwise.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brad Love [Tue, 6 Mar 2018 19:15:37 +0000 (14:15 -0500)]
media: cx23885: Override 888 ImpactVCBe crystal frequency
[ Upstream commit
779c79d4b833ec646b0aed878da38edb45bbe156 ]
Hauppauge produced a revision of ImpactVCBe using an 888,
with a 25MHz crystal, instead of using the default third
overtone 50Mhz crystal. This overrides that frequency so
that the cx25840 is properly configured. Without the proper
crystal setup the cx25840 cannot load the firmware or
decode video.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Akinobu Mita [Mon, 19 Mar 2018 16:14:17 +0000 (12:14 -0400)]
media: ov5645: add missing of_node_put() in error path
[ Upstream commit
06fe932307d58108a11c3e603517dd2a73a57b80 ]
The device node obtained with of_graph_get_next_endpoint() should be
released by calling of_node_put(). But it was not released when
v4l2_fwnode_endpoint_parse() failed.
This change moves the of_node_put() call before the error check and
fixes the issue.
Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Todor Tomov <todor.tomov@linaro.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Mon, 19 Feb 2018 18:23:39 +0000 (13:23 -0500)]
media: Don't let tvp5150_get_vbi() go out of vbi_ram_default array
[ Upstream commit
3dd6b560dc5d59e7cb6dbda6e85dc9af7925fcf8 ]
As pointed by Dan, possible values for bits[3:0] of te Line Mode Registers
can range from 0x0 to 0xf, but the check logic allow values ranging
from 0x0 to 0xe.
As static arrays are initialized with zero, using a value without
an explicit initializer at the array won't cause any harm.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sun, 11 Feb 2018 10:44:21 +0000 (05:44 -0500)]
media: dmxdev: fix error code for invalid ioctls
[ Upstream commit
a145f64c6107d3aa5a7cec9f8977d04ac2a896c9 ]
Returning -EINVAL when an ioctl is not implemented is a very
bad idea, as it is hard to distinguish from other error
contitions that an ioctl could lead. Replace it by its
right error code: -ENOTTY.
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 16 Feb 2018 14:57:48 +0000 (15:57 +0100)]
clk: samsung: exynos3250: Fix PLL rates
[ Upstream commit
a8321e7887410a2b2e80ab89d1ef7b30562658ea ]
Rates declared in PLL rate tables should match exactly rates calculated
from PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a
393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is
393216003, after setting PLL's clk rate to
393216000 clk_get_rate
will return
393216003. If we now attempt to set rate of a PLL's child divider
clock to
393216000/2 its rate will be
131072001, rather than
196608000.
That is, the divider will be set to 3 instead of 2, because
393216003/2 is
greater than
196608000.
To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.
In this patch an erroneous P value for
74176002 output frequency is also
corrected.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 16 Feb 2018 14:57:49 +0000 (15:57 +0100)]
clk: samsung: exynos5250: Fix PLL rates
[ Upstream commit
2ac051eeabaa411ef89ae7cd5bb8e60cb41ad780 ]
Rates declared in PLL rate tables should match exactly rates calculated
from PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a
393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is
393216003, after setting PLL's clk rate to
393216000 clk_get_rate
will return
393216003. If we now attempt to set rate of a PLL's child divider
clock to
393216000/2 its rate will be
131072001, rather than
196608000.
That is, the divider will be set to 3 instead of 2, because
393216003/2 is
greater than
196608000.
To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 16 Feb 2018 14:57:51 +0000 (15:57 +0100)]
clk: samsung: exynos5433: Fix PLL rates
[ Upstream commit
ab0447845cffc0fd752df2ccd6b4e34006000ce4 ]
Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a
393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is
393216003, after setting PLL's clk rate to
393216000 clk_get_rate
will return
393216003. If we now attempt to set rate of a PLL's child divider
clock to
393216000/2 its rate will be
131072001, rather than
196608000.
That is, the divider will be set to 3 instead of 2, because
393216003/2 is
greater than
196608000.
To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 16 Feb 2018 14:57:50 +0000 (15:57 +0100)]
clk: samsung: exynos5260: Fix PLL rates
[ Upstream commit
cdb68fbd4e7962be742c4f29475220c5bf28d8a5 ]
Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a
393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is
393216003, after setting PLL's clk rate to
393216000 clk_get_rate
will return
393216003. If we now attempt to set rate of a PLL's child divider
clock to
393216000/2 its rate will be
131072001, rather than
196608000.
That is, the divider will be set to 3 instead of 2, because
393216003/2 is
greater than
196608000.
To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 16 Feb 2018 14:57:52 +0000 (15:57 +0100)]
clk: samsung: exynos7: Fix PLL rates
[ Upstream commit
7e4db0c2836e892766565965207eee051c8037b9 ]
Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a
393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is
393216003, after setting PLL's clk rate to
393216000 clk_get_rate
will return
393216003. If we now attempt to set rate of a PLL's child divider
clock to
393216000/2 its rate will be
131072001, rather than
196608000.
That is, the divider will be set to 3 instead of 2, because
393216003/2 is
greater than
196608000.
To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrzej Hajda [Fri, 16 Feb 2018 14:57:53 +0000 (15:57 +0100)]
clk: samsung: s3c2410: Fix PLL rates
[ Upstream commit
179db533c08431f509a3823077549773d519358b ]
Rates declared in PLL rate tables should match exactly rates calculated from
the PLL coefficients. If that is not the case, rate of the PLL's child clock
might be set not as expected. For instance, if in the PLL rates table we have
a
393216000 Hz entry and the real value as returned by the PLL's recalc_rate
callback is
393216003, after setting PLL's clk rate to
393216000 clk_get_rate
will return
393216003. If we now attempt to set rate of a PLL's child divider
clock to
393216000/2 its rate will be
131072001, rather than
196608000.
That is, the divider will be set to 3 instead of 2, because
393216003/2 is
greater than
196608000.
To fix this issue declared rates are changed to exactly match rates generated
by the PLL, as calculated from the P, M, S, K coefficients.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Lin [Mon, 5 Mar 2018 03:25:58 +0000 (11:25 +0800)]
clk: rockchip: Prevent calculating mmc phase if clock rate is zero
[ Upstream commit
4bf59902b50012b1dddeeaa23b217d9c4956cdda ]
The MMC sample and drv clock for rockchip platforms are derived from
the bus clock output to the MMC/SDIO card. So it should never happens
that the clk rate is zero given it should inherits the clock rate from
its parent. If something goes wrong and makes the clock rate to be zero,
the calculation would be wrong but may still make the mmc tuning process
work luckily. However it makes people harder to debug when the following
data transfer is unstable.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marcel Ziswiler [Thu, 22 Feb 2018 23:04:51 +0000 (00:04 +0100)]
clk: tegra: Fix pll_u rate configuration
[ Upstream commit
c35b518f9ba06c9de79fb3ff62eed7462d804995 ]
Turns out latest upstream U-Boot does not configure/enable pll_u which
leaves it at some default rate of 500 kHz:
root@apalis-t30:~# cat /sys/kernel/debug/clk/clk_summary | grep pll_u
pll_u 3 3 0 500000 0
Of course this won't quite work leading to the following messages:
[ 6.559593] usb 2-1: new full-speed USB device number 2 using tegra-
ehci
[ 11.759173] usb 2-1: device descriptor read/64, error -110
[ 27.119453] usb 2-1: device descriptor read/64, error -110
[ 27.389217] usb 2-1: new full-speed USB device number 3 using tegra-
ehci
[ 32.559454] usb 2-1: device descriptor read/64, error -110
[ 47.929777] usb 2-1: device descriptor read/64, error -110
[ 48.049658] usb usb2-port1: attempt power cycle
[ 48.759475] usb 2-1: new full-speed USB device number 4 using tegra-
ehci
[ 59.349457] usb 2-1: device not accepting address 4, error -110
[ 59.509449] usb 2-1: new full-speed USB device number 5 using tegra-
ehci
[ 70.069457] usb 2-1: device not accepting address 5, error -110
[ 70.079721] usb usb2-port1: unable to enumerate USB device
Fix this by actually allowing the rate also being set from within
the Linux kernel.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Tue, 20 Feb 2018 15:15:21 +0000 (16:15 +0100)]
clk: hisilicon: mark wdt_mux_p[] as const
[ Upstream commit
df934cbcbff7afbc024bf05f02615917c61f6470 ]
The symbol is in the __initconst section but not marked init, which
caused a warning when building with LTO.
This makes it 'const' as was obviously intended.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes:
c80dfd9bf54e ("clk: hisilicon: add CRG driver for Hi3516CV300 SoC")
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Lin [Wed, 14 Mar 2018 00:28:31 +0000 (08:28 +0800)]
clk: Don't show the incorrect clock phase
[ Upstream commit
1f9c63e8de3d7b377c9d74e4a17524cfb60e6384 ]
It's found that the clock phase output from clk_summary is
wrong compared to the actual phase reading from the register.
cat /sys/kernel/debug/clk/clk_summary | grep sdio_sample
sdio_sample 0 1 0
50000000 0 -22
It exposes an issue that clk core, clk_core_get_phase, always
returns the cached core->phase which should be either updated
by calling clk_set_phase or directly from the first place the
clk was registered.
When registering the clk, the core->phase geting from ->get_phase()
may return negative value indicating error. This is quite common
since the clk's phase may be highly related to its parent chain,
but it was temporarily orphan when registered, since its parent
chains hadn't be ready at that time, so the clk drivers decide to
return error in this case. However, if no clk_set_phase is called or
maybe the ->set_phase() isn't even implemented, the core->phase would
never be updated. This is wrong, and we should try to update it when
all its parent chains are settled down, like the way of updating clock
rate for that. But it's not deserved to complicate the code now and
just update it anyway when calling clk_core_get_phase, which would be
much simple and enough.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Lin [Wed, 21 Mar 2018 02:39:19 +0000 (10:39 +0800)]
clk: rockchip: Fix wrong parent for SDMMC phase clock for rk3228
[ Upstream commit
4b0556a441dd37e598887215bc89b49a6ef525b3 ]
commit
c420c1e4db22 ("clk: rockchip: Prevent calculating mmc phase
if clock rate is zero") catches one gremlin again for clk-rk3228.c
that the parent of SDMMC phase clock should be sclk_sdmmc0, but not
sclk_sdmmc. However, the naming of the sdmmc clocks varies in the
manual with the card clock having the 0 while the hclk is named
without appended 0. So standardize one one format to prevent
confusion, as there also is only one (non-sdio) mmc controller on
the soc.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sylwester Nawrocki [Mon, 5 Feb 2018 15:43:56 +0000 (16:43 +0100)]
ASoC: samsung: i2s: Ensure the RCLK rate is properly determined
[ Upstream commit
647d04f8e07afc7c3b7a42b3ee01a8b28db29631 ]
If the RCLK mux clock configuration is specified in DT and no set_sysclk()
callback is used in the sound card driver the sclk_srcrate field will remain
set to 0, leading to an incorrect PSR divider setting.
To fix this the frequency value is retrieved from the CLK_I2S_RCLK_SRC clock,
so the actual RCLK mux selection is taken into account.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ranjani Sridharan [Fri, 9 Mar 2018 19:11:17 +0000 (11:11 -0800)]
ASoC: topology: create TLV data for dapm widgets
[ Upstream commit
bde8b3887add8368ecf0ca71117baf2fd56a6fc9 ]
This patch adds the change required to create the TLV data
for dapm widget kcontrols from topology. This also fixes the following
TLV read error shown in amixer while showing the card control contents.
"amixer: Control hw:1 element TLV read error: No such device or address"
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sylwester Nawrocki [Wed, 14 Mar 2018 16:41:13 +0000 (17:41 +0100)]
ASoC: samsung: odroid: Fix 32000 sample rate handling
[ Upstream commit
1d22c337dc8f3a25638f7262e7bcb5729a34d140 ]
In case of sample rates lower than 44100 currently there is too low MCLK
frequency set for the CODEC. Playback fails with following errors:
$ speaker-test -c2 -t sine -f 1500 -l2 -r 32000
Sine wave rate is 1500.0000Hz
Rate set to 32000Hz (requested 32000Hz)
Buffer size range from 128 to 131072
Period size range from 64 to 65536
Using max buffer size 131072
Periods = 4
Unable to set hw params for playback: Invalid argument
Setting of hwparams failed: Invalid argument
[ 497.883700] max98090 1-0010: Invalid master clock frequency
To fix this the I2S root clock's frequency is increased, depending
on sampling rate.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ezequiel Garcia [Tue, 20 Mar 2018 16:03:31 +0000 (13:03 -0300)]
ASoC: rockchip: rk3288-hdmi-analog: Select needed codecs
[ Upstream commit
b1d0db067fbe2598d62b248beea5d705a0ea7642 ]
The driver does not select all the codec drivers that needs.
Fix it by selecting the analog and HDMI codecs.
Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Ujfalusi [Tue, 20 Feb 2018 14:19:05 +0000 (16:19 +0200)]
ASoC: hdmi-codec: Fix module unloading caused kernel crash
[ Upstream commit
5e558f8afaec8957932b1dbe5aeff800f9fc6957 ]
The hcp->chmap_info must not be freed up in the hdmi_codec_remove()
function as it leads to kernel crash due ALSA core's
pcm_chmap_ctl_private_free() is trying to free it up again when the card
destroyed via snd_card_free.
Commit
cd6111b26280a ("ASoC: hdmi-codec: add channel mapping control")
should not have added the kfree(hcp->chmap_info); to the hdmi_codec_remove
function.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Reviewed-by: Jyri Sarha <jsarha@ti.com>
Tested-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Smart [Tue, 30 Jan 2018 23:58:45 +0000 (15:58 -0800)]
scsi: lpfc: Fix frequency of Release WQE CQEs
[ Upstream commit
04673e38f56b30cd39b1fa0f386137d818b17781 ]
The driver controls when the hardware sends completions that communicate
consumption of elements from the WQ. This is done by setting a WQEC bit
on a WQE.
The current driver sets it on every Nth WQE posting. However, the driver
isn't clearing the bit if the WQE is reused. Thus, if the queue depth
isn't evenly divisible by N, with enough time, it can be set on every
element, creating a lot of overhead and risking CQ full conditions.
Correct by clearing the bit when not setting it on an Nth element.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Smart [Tue, 30 Jan 2018 23:58:54 +0000 (15:58 -0800)]
scsi: lpfc: Fix soft lockup in lpfc worker thread during LIP testing
[ Upstream commit
161df4f09987ae2e9f0f97f0b38eee298b4a39ff ]
During link bounce testing in a point-to-point topology, the host may
enter a soft lockup on the lpfc_worker thread:
Call Trace:
lpfc_work_done+0x1f3/0x1390 [lpfc]
lpfc_do_work+0x16f/0x180 [lpfc]
kthread+0xc7/0xe0
ret_from_fork+0x3f/0x70
The driver was simultaneously setting a combination of flags that caused
lpfc_do_work()to effectively spin between slow path work and new event
data, causing the lockup.
Ensure in the typical wq completions, that new event data flags are set
if the slow path flag is running. The slow path will eventually
reschedule the wq handling.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Smart [Tue, 30 Jan 2018 23:58:55 +0000 (15:58 -0800)]
scsi: lpfc: Fix issue_lip if link is disabled
[ Upstream commit
2289e9598dde9705400559ca2606fb8c145c34f0 ]
The driver ignored checks on whether the link should be kept
administratively down after a link bounce. Correct the checks.
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <james.smart@broadcom.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wilfried Weissmann [Fri, 23 Feb 2018 19:52:34 +0000 (20:52 +0100)]
scsi: mvsas: fix wrong endianness of sgpio api
[ Upstream commit
e75fba9c0668b3767f608ea07485f48d33c270cf ]
This patch fixes the byte order of the SGPIO api and brings it back in
sync with ledmon v0.80 and above.
[mkp: added missing SoB and fixed whitespace]
Signed-off-by: Wilfried Weissmann <wilfried.weissmann@gmx.at>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Douglas Gilbert [Wed, 7 Mar 2018 03:19:49 +0000 (22:19 -0500)]
scsi: core: Make SCSI Status CONDITION MET equivalent to GOOD
[ Upstream commit
1875ede02ed5e176a18dccbca84abc28d5b3e141 ]
The SCSI PRE-FETCH (10 or 16) command is present both on hard disks
and some SSDs. It is useful when the address of the next block(s) to
be read is known but it is not following the LBA of the current READ
(so read-ahead won't help). It returns two "good" SCSI Status values.
If the requested blocks have fitted (or will most likely fit (when
the IMMED bit is set)) into the disk's cache, it returns CONDITION
MET. If it didn't (or will not) fit then it returns GOOD status.
The goal of this patch is to stop the SCSI subsystem treating the
CONDITION MET SCSI status as an error. The current state makes the
PRE-FETCH command effectively unusable via pass-throughs.
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Reviewed-by: Bart Van Assche <bart.vanassche@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Carroll [Tue, 3 Apr 2018 21:50:42 +0000 (15:50 -0600)]
scsi: aacraid: Insure command thread is not recursively stopped
[ Upstream commit
1c6b41fb92936fa5facea464d5d7cbf855966d04 ]
If a recursive IOP_RESET is invoked, usually due to the eh_thread
handling errors after the first reset, be sure we flag that the command
thread has been stopped to avoid an Oops of the form;
[ 336.620256] CPU: 28 PID: 1193 Comm: scsi_eh_0 Kdump: loaded Not tainted 4.14.0-49.el7a.ppc64le #1
[ 336.620297] task:
c000003fd630b800 task.stack:
c000003fd61a4000
[ 336.620326] NIP:
c000000000176794 LR:
c00000000013038c CTR:
c00000000024bc10
[ 336.620361] REGS:
c000003fd61a7720 TRAP: 0300 Not tainted (4.14.0-49.el7a.ppc64le)
[ 336.620395] MSR:
9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR:
22084022 XER:
20040000
[ 336.620435] CFAR:
c000000000130388 DAR:
0000000000000000 DSISR:
40000000 SOFTE: 1
[ 336.620435] GPR00:
c00000000013038c c000003fd61a79a0 c0000000014c7e00 0000000000000000
[ 336.620435] GPR04:
000000000000000c 000000000000000c 9000000000009033 0000000000000477
[ 336.620435] GPR08:
0000000000000477 0000000000000000 0000000000000000 c008000010f7d940
[ 336.620435] GPR12:
c00000000024bc10 c000000007a33400 c0000000001708a8 c000003fe3b881d8
[ 336.620435] GPR16:
c000003fe3b88060 c000003fd61a7d10 fffffffffffff000 000000000000001e
[ 336.620435] GPR20:
0000000000000001 c000000000ebf1a0 0000000000000001 c000003fe3b88000
[ 336.620435] GPR24:
0000000000000003 0000000000000002 c000003fe3b88840 c000003fe3b887e8
[ 336.620435] GPR28:
c000003fe3b88000 c000003fc8181788 0000000000000000 c000003fc8181700
[ 336.620750] NIP [
c000000000176794] exit_creds+0x34/0x160
[ 336.620775] LR [
c00000000013038c] __put_task_struct+0x8c/0x1f0
[ 336.620804] Call Trace:
[ 336.620817] [
c000003fd61a79a0] [
c000003fe3b88000] 0xc000003fe3b88000 (unreliable)
[ 336.620853] [
c000003fd61a79d0] [
c00000000013038c] __put_task_struct+0x8c/0x1f0
[ 336.620889] [
c000003fd61a7a00] [
c000000000171418] kthread_stop+0x1e8/0x1f0
[ 336.620922] [
c000003fd61a7a40] [
c008000010f7448c] aac_reset_adapter+0x14c/0x8d0 [aacraid]
[ 336.620959] [
c000003fd61a7b00] [
c008000010f60174] aac_eh_host_reset+0x84/0x100 [aacraid]
[ 336.621010] [
c000003fd61a7b30] [
c000000000864f24] scsi_try_host_reset+0x74/0x180
[ 336.621046] [
c000003fd61a7bb0] [
c000000000867ac0] scsi_eh_ready_devs+0xc00/0x14d0
[ 336.625165] [
c000003fd61a7ca0] [
c0000000008699e0] scsi_error_handler+0x550/0x730
[ 336.632101] [
c000003fd61a7dc0] [
c000000000170a08] kthread+0x168/0x1b0
[ 336.639031] [
c000003fd61a7e30] [
c00000000000b528] ret_from_kernel_thread+0x5c/0xb4
[ 336.645971] Instruction dump:
[ 336.648743]
384216a0 7c0802a6 fbe1fff8 f8010010 f821ffd1 7c7f1b78 60000000 60000000
[ 336.657056]
39400000 e87f0838 f95f0838 7c0004ac <
7d401828>
314affff 7d40192d 40c2fff4
[ 336.663997] -[ end trace
4640cf8d4945ad95 ]-
So flag when the thread is stopped by setting the thread pointer to NULL.
Signed-off-by: Dave Carroll <david.carroll@microsemi.com>
Reviewed-by: Raghava Aditya Renukunta <raghavaaditya.renukunta@microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jianchao Wang [Wed, 7 Mar 2018 12:29:03 +0000 (20:29 +0800)]
scsi: iscsi_tcp: set BDI_CAP_STABLE_WRITES when data digest enabled
[ Upstream commit
89d0c804392bb962553f23dc4c119d11b6bd1675 ]
iscsi tcp will first send out data, then calculate and send data
digest. If we don't have BDI_CAP_STABLE_WRITES, the page cache will be
written in spite of the on going writeback. Consequently, wrong digest
will be got and sent to target.
To fix this, set BDI_CAP_STABLE_WRITES when data digest is enabled
in iscsi_tcp .slave_configure callback.
Signed-off-by: Jianchao Wang <jianchao.w.wang@oracle.com>
Acked-by: Chris Leech <cleech@redhat.com>
Acked-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeremy Cline [Tue, 6 Mar 2018 21:47:32 +0000 (21:47 +0000)]
scsi: sd: Keep disk read-only when re-reading partition
[ Upstream commit
20bd1d026aacc5399464f8328f305985c493cde3 ]
If the read-only flag is true on a SCSI disk, re-reading the partition
table sets the flag back to false.
To observe this bug, you can run:
1. blockdev --setro /dev/sda
2. blockdev --rereadpt /dev/sda
3. blockdev --getro /dev/sda
This commit reads the disk's old state and combines it with the device
disk-reported state rather than unconditionally marking it as RW.
Reported-by: Li Ning <lining916740672@icloud.com>
Signed-off-by: Jeremy Cline <jeremy@jcline.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hannes Reinecke [Mon, 26 Feb 2018 14:26:01 +0000 (15:26 +0100)]
scsi: mpt3sas: Do not mark fw_event workqueue as WQ_MEM_RECLAIM
[ Upstream commit
864449eea7c600596e305ffdc4a6a846414b222c ]
The firmware event workqueue should not be marked as WQ_MEM_RECLAIM
as it's doesn't need to make forward progress under memory pressure.
In the current state it will result in a deadlock if the device had been
forcefully removed.
Cc: Sreekanth Reddy <sreekanth.reddy@broadcom.com>
Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
Acked-by: Sreekanth Reddy <Sreekanth.Reddy@broadcom.com>
Signed-off-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Manish Rangankar [Mon, 26 Feb 2018 09:01:17 +0000 (01:01 -0800)]
scsi: qedi: Fix kernel crash during port toggle
[ Upstream commit
967823d6c3980a30e214b92bfe6a101e7b46d025 ]
BUG: unable to handle kernel NULL pointer dereference at
0000000000000100
[ 985.596918] IP: _raw_spin_lock_bh+0x17/0x30
[ 985.601581] PGD 0 P4D 0
[ 985.604405] Oops: 0002 [#1] SMP
:
[ 985.704533] CPU: 16 PID: 1156 Comm: qedi_thread/16 Not tainted 4.16.0-rc2 #1
[ 985.712397] Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 2.4.3 01/17/2017
[ 985.720747] RIP: 0010:_raw_spin_lock_bh+0x17/0x30
[ 985.725996] RSP: 0018:
ffffa4b1c43d3e10 EFLAGS:
00010246
[ 985.731823] RAX:
0000000000000000 RBX:
ffff94a31bd03000 RCX:
0000000000000000
[ 985.739783] RDX:
0000000000000001 RSI:
ffff94a32fa16938 RDI:
0000000000000100
[ 985.747744] RBP:
0000000000000004 R08:
0000000000000000 R09:
0000000000000a33
[ 985.755703] R10:
0000000000000000 R11:
ffffa4b1c43d3af0 R12:
0000000000000000
[ 985.763662] R13:
ffff94a301f40818 R14:
0000000000000000 R15:
000000000000000c
[ 985.771622] FS:
0000000000000000(0000) GS:
ffff94a32fa00000(0000) knlGS:
0000000000000000
[ 985.780649] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 985.787057] CR2:
0000000000000100 CR3:
000000067a009006 CR4:
00000000001606e0
[ 985.795017] Call Trace:
[ 985.797747] qedi_fp_process_cqes+0x258/0x980 [qedi]
[ 985.803294] qedi_percpu_io_thread+0x10f/0x1b0 [qedi]
[ 985.808931] kthread+0xf5/0x130
[ 985.812434] ? qedi_free_uio+0xd0/0xd0 [qedi]
[ 985.817298] ? kthread_bind+0x10/0x10
[ 985.821372] ? do_syscall_64+0x6e/0x1a0
Signed-off-by: Manish Rangankar <manish.rangankar@cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Manish Rangankar [Mon, 12 Feb 2018 06:48:41 +0000 (22:48 -0800)]
scsi: qla4xxx: skip error recovery in case of register disconnect.
[ Upstream commit
1bc5ad3a6acdcf56f83272f2de1cd2389ea9e9e2 ]
A system crashes when continuously removing/re-adding the storage
controller.
Signed-off-by: Manish Rangankar <manish.rangankar@cavium.com>
Reviewed-by: Ewan D. Milne <emilne@redhat.com>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Meelis Roos [Fri, 9 Feb 2018 06:57:44 +0000 (08:57 +0200)]
scsi: aacraid: fix shutdown crash when init fails
[ Upstream commit
00c20cdc79259c6c5bf978b21af96c2d3edb646d ]
When aacraid init fails with "AAC0: adapter self-test failed.", shutdown
leads to UBSAN warning and then oops:
[154316.118423] ================================================================================
[154316.118508] UBSAN: Undefined behaviour in drivers/scsi/scsi_lib.c:2328:27
[154316.118566] member access within null pointer of type 'struct Scsi_Host'
[154316.118631] CPU: 2 PID: 14530 Comm: reboot Tainted: G W 4.15.0-dirty #89
[154316.118701] Hardware name: Hewlett Packard HP NetServer/HP System Board, BIOS 4.06.46 PW 06/25/2003
[154316.118774] Call Trace:
[154316.118848] dump_stack+0x48/0x65
[154316.118916] ubsan_epilogue+0xe/0x40
[154316.118976] __ubsan_handle_type_mismatch+0xfb/0x180
[154316.119043] scsi_block_requests+0x20/0x30
[154316.119135] aac_shutdown+0x18/0x40 [aacraid]
[154316.119196] pci_device_shutdown+0x33/0x50
[154316.119269] device_shutdown+0x18a/0x390
[...]
[154316.123435] BUG: unable to handle kernel NULL pointer dereference at
000000f4
[154316.123515] IP: scsi_block_requests+0xa/0x30
This is because aac_shutdown() does
struct Scsi_Host *shost = pci_get_drvdata(dev);
scsi_block_requests(shost);
and that assumes shost has been assigned with pci_set_drvdata().
However, pci_set_drvdata(pdev, shost) is done in aac_probe_one() far
after bailing out with error from calling the init function
((*aac_drivers[index].init)(aac)), and when the init function fails, no
error is returned from aac_probe_one() so PCI layer assumes there is
driver attached, and tries to shut it down later.
Fix it by returning error from aac_probe_one() when card-specific init
function fails.
This fixes reboot on my HP NetRAID-4M with dead battery.
Signed-off-by: Meelis Roos <mroos@linux.ee>
Reviewed-by: Dave Carroll <david.carroll@microsemi.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrew Vasquez [Wed, 7 Feb 2018 16:12:35 +0000 (08:12 -0800)]
scsi: qedi: Fix truncation of CHAP name and secret
[ Upstream commit
1683ce57f568c7c92d53e9234624a53554a29cd5 ]
The data in NVRAM is not guaranteed to be NUL terminated. Since
snprintf expects byte-stream to accommodate null byte, the CHAP secret
is truncated. Use sprintf instead of snprintf to fix the truncation of
CHAP name and secret.
Signed-off-by: Andrew Vasquez <andrew.vasquez@cavium.com>
Signed-off-by: Nilesh Javali <nilesh.javali@cavium.com>
Reviewed-by: Bart Van Assche <bart.vanassche@wdc.com>
Acked-by: Chris Leech <cleech@redhat.com>
Acked-by: Lee Duncan <lduncan@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Kelley (EOSG) [Wed, 24 Jan 2018 22:49:57 +0000 (22:49 +0000)]
scsi: storvsc: Increase cmd_per_lun for higher speed devices
[ Upstream commit
cabe92a55e3a12005a4ac4d3954c9a174b0efe2a ]
Increase cmd_per_lun to allow more I/Os in progress per device,
particularly for NVMe's. The Hyper-V host side can handle the higher
count with no issues.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Acked-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bart Van Assche [Thu, 25 Jan 2018 16:24:29 +0000 (08:24 -0800)]
scsi: qla2xxx: Avoid triggering undefined behavior in qla2x00_mbx_completion()
[ Upstream commit
c02189e12ce3bf3808cb880569d3b10249f50bd9 ]
A left shift must shift less than the bit width of the left argument.
Avoid triggering undefined behavior if ha->mbx_count == 32.
This patch avoids that UBSAN reports the following complaint:
UBSAN: Undefined behaviour in drivers/scsi/qla2xxx/qla_isr.c:275:14
shift exponent 32 is too large for 32-bit type 'int'
Call Trace:
dump_stack+0x4e/0x6c
ubsan_epilogue+0xd/0x3b
__ubsan_handle_shift_out_of_bounds+0x112/0x14c
qla2x00_mbx_completion+0x1c5/0x25d [qla2xxx]
qla2300_intr_handler+0x1ea/0x3bb [qla2xxx]
qla2x00_mailbox_command+0x77b/0x139a [qla2xxx]
qla2x00_mbx_reg_test+0x83/0x114 [qla2xxx]
qla2x00_chip_diag+0x354/0x45f [qla2xxx]
qla2x00_initialize_adapter+0x2c2/0xa4e [qla2xxx]
qla2x00_probe_one+0x1681/0x392e [qla2xxx]
pci_device_probe+0x10b/0x1f1
driver_probe_device+0x21f/0x3a4
__driver_attach+0xa9/0xe1
bus_for_each_dev+0x6e/0xb5
driver_attach+0x22/0x3c
bus_add_driver+0x1d1/0x2ae
driver_register+0x78/0x130
__pci_register_driver+0x75/0xa8
qla2x00_module_init+0x21b/0x267 [qla2xxx]
do_one_initcall+0x5a/0x1e2
do_init_module+0x9d/0x285
load_module+0x20db/0x38e3
SYSC_finit_module+0xa8/0xbc
SyS_finit_module+0x9/0xb
do_syscall_64+0x77/0x271
entry_SYSCALL64_slow_path+0x25/0x25
Reported-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com>
Cc: Himanshu Madhani <himanshu.madhani@cavium.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Acked-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Thu, 25 Jan 2018 14:27:27 +0000 (17:27 +0300)]
scsi: mptfusion: Add bounds check in mptctl_hp_targetinfo()
[ Upstream commit
a7043e9529f3c367cc4d82997e00be034cbe57ca ]
My static checker complains about an out of bounds read:
drivers/message/fusion/mptctl.c:2786 mptctl_hp_targetinfo()
error: buffer overflow 'hd->sel_timeout' 255 <= u32max.
It's true that we probably should have a bounds check here.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Thu, 25 Jan 2018 14:13:40 +0000 (17:13 +0300)]
scsi: sym53c8xx_2: iterator underflow in sym_getsync()
[ Upstream commit
e6f791d95313c85f3dd4a26141e28e50ae9aa0ae ]
We wanted to exit the loop with "div" set to zero, but instead, if we
don't hit the break then "div" is -1 when we finish the loop. It leads
to an array underflow a few lines later.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Acked-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chad Dupuis [Wed, 24 Jan 2018 16:07:06 +0000 (08:07 -0800)]
scsi: bnx2fc: Fix check in SCSI completion handler for timed out request
[ Upstream commit
ecf7ff49945f5741fa1da112f994939f942031d3 ]
When a request times out we set the io_req flag BNX2FC_FLAG_IO_COMPL so
that if a subsequent completion comes in on that task ID we will ignore
it. The issue is that in the check for this flag there is a missing
return so we will continue to process a request which may have already
been returned to the ownership of the SCSI layer. This can cause
unpredictable results.
Solution is to add in the missing return.
[mkp: typo plus title shortening]
Signed-off-by: Chad Dupuis <chad.dupuis@cavium.com>
Reviewed-by: Laurence Oberman <loberman@redhat.com>
Tested-by: Laurence Oberman <loberman@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sujit Reddy Thumma [Wed, 24 Jan 2018 04:22:35 +0000 (09:52 +0530)]
scsi: ufs: Enable quirk to ignore sending WRITE_SAME command
[ Upstream commit
84af7e8b895088d89f246d6b0f82717fafdebf61 ]
WRITE_SAME command is not supported by UFS. Enable a quirk for the upper
level drivers to not send WRITE SAME command.
[mkp: botched patch, applied by hand]
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Quinn Tran [Tue, 23 Jan 2018 19:05:21 +0000 (11:05 -0800)]
scsi: qla2xxx: Fix memory corruption during hba reset test
[ Upstream commit
2ce87cc5b269510de9ca1185ca8a6e10ec78c069 ]
This patch fixes memory corrpution while performing HBA Reset test.
Following stack trace is seen:
[ 466.397219] BUG: unable to handle kernel NULL pointer dereference at
0000000000000020
[ 466.433669] IP: [<
ffffffffc06f5dd0>] qlt_free_session_done+0x260/0x5f0 [qla2xxx]
[ 466.467731] PGD 0
[ 466.476718] Oops: 0000 [#1] SMP
Signed-off-by: Quinn Tran <quinn.tran@cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomas Henzl [Fri, 19 Jan 2018 15:22:05 +0000 (16:22 +0100)]
scsi: mpt3sas: fix an out of bound write
[ Upstream commit
4a8842de8db4953fdda7866626b78b12fb8adb97 ]
cpu_msix_table is allocated to store online cpus, but pci_irq_get_affinity
may return cpu_possible_mask which is then used to access cpu_msix_table.
That causes bad user experience. Fix limits access to only online cpus,
I've also added an additional test to protect from an unlikely change in
cpu_online_mask.
[mkp: checkpatch]
Fixes:
1d55abc0e98a ("scsi: mpt3sas: switch to pci_alloc_irq_vectors")
Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Acked-by: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Antoine Tenart [Tue, 13 Feb 2018 08:26:55 +0000 (09:26 +0100)]
crypto: inside-secure - fix the invalidation step during cra_exit
[ Upstream commit
b7007dbccd92f7b8c00e590020bee542a48c6a2c ]
When exiting a transformation, the cra_exit() helper is called in each
driver providing one. The Inside Secure SafeXcel driver has one, which
is responsible of freeing some areas and of sending one invalidation
request to the crypto engine, to invalidate the context that was used
during the transformation.
We could see in some setups (when lots of transformations were being
used with a short lifetime, and hence lots of cra_exit() calls) NULL
pointer dereferences and other weird issues. All these issues were
coming from accessing the tfm context.
The issue is the invalidation request completion is checked using a
wait_for_completion_interruptible() call in both the cipher and hash
cra_exit() helpers. In some cases this was interrupted while the
invalidation request wasn't processed yet. And then cra_exit() returned,
and its caller was freeing the tfm instance. Only then the request was
being handled by the SafeXcel driver, which lead to the said issues.
This patch fixes this by using wait_for_completion() calls in these
specific cases.
Fixes:
1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Robinson [Sun, 11 Feb 2018 23:15:37 +0000 (23:15 +0000)]
crypto: sunxi-ss - Add MODULE_ALIAS to sun4i-ss
[ Upstream commit
7c73cf4cc2ac16465f5102437dc0a12d66671bd6 ]
The MODULE_ALIAS is required to enable the sun4i-ss driver to load
automatically when built at a module. Tested on a Cubietruck.
Fixes:
6298e948215f ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator")
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Antoine Tenart [Tue, 13 Feb 2018 08:26:52 +0000 (09:26 +0100)]
crypto: inside-secure - fix the extra cache computation
[ Upstream commit
c1a8fa6e240ed4b99778d48ab790743565cb61c8 ]
This patch fixes the extra cache computation when the queued data is a
multiple of a block size. This fixes the hash support in some cases.
Fixes:
809778e02cd4 ("crypto: inside-secure - fix hash when length is a multiple of a block")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Antoine Tenart [Tue, 13 Feb 2018 08:26:53 +0000 (09:26 +0100)]
crypto: inside-secure - fix the cache_len computation
[ Upstream commit
666a9c70b04fccabde5cea5e680ae1ae92460a62 ]
This patch fixes the cache length computation as cache_len could end up
being a negative value. The check between the queued size and the
block size is updated to reflect the caching mechanism which can cache
up to a full block size (included!).
Fixes:
809778e02cd4 ("crypto: inside-secure - fix hash when length is a multiple of a block")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Antoine Tenart [Tue, 13 Feb 2018 08:26:54 +0000 (09:26 +0100)]
crypto: inside-secure - do not process request if no command was issued
[ Upstream commit
95831ceafc0de7d94a5fe86ebb1c2042317cc2cd ]
This patch adds a check in the SafeXcel dequeue function, to avoid
processing request further if no hardware command was issued. This can
happen in certain cases where the ->send() function caches all the data
that would have been send.
Fixes:
809778e02cd4 ("crypto: inside-secure - fix hash when length is a multiple of a block")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Andrzej Siewior [Fri, 23 Feb 2018 22:33:07 +0000 (23:33 +0100)]
crypto: ccp - don't disable interrupts while setting up debugfs
[ Upstream commit
79eb382b5e06a6dca5806465d7195d686a463ab0 ]
I don't why we need take a single write lock and disable interrupts
while setting up debugfs. This is what what happens when we try anyway:
|ccp 0000:03:00.2: enabling device (0000 -> 0002)
|BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:69
|in_atomic(): 1, irqs_disabled(): 1, pid: 3, name: kworker/0:0
|irq event stamp: 17150
|hardirqs last enabled at (17149): [<
0000000097a18c49>] restore_regs_and_return_to_kernel+0x0/0x23
|hardirqs last disabled at (17150): [<
000000000773b3a9>] _raw_write_lock_irqsave+0x1b/0x50
|softirqs last enabled at (17148): [<
0000000064d56155>] __do_softirq+0x3b8/0x4c1
|softirqs last disabled at (17125): [<
0000000092633c18>] irq_exit+0xb1/0xc0
|CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.16.0-rc2+ #30
|Workqueue: events work_for_cpu_fn
|Call Trace:
| dump_stack+0x7d/0xb6
| ___might_sleep+0x1eb/0x250
| down_write+0x17/0x60
| start_creating+0x4c/0xe0
| debugfs_create_dir+0x9/0x100
| ccp5_debugfs_setup+0x191/0x1b0
| ccp5_init+0x8a7/0x8c0
| ccp_dev_init+0xb8/0xe0
| sp_init+0x6c/0x90
| sp_pci_probe+0x26e/0x590
| local_pci_probe+0x3f/0x90
| work_for_cpu_fn+0x11/0x20
| process_one_work+0x1ff/0x650
| worker_thread+0x1d4/0x3a0
| kthread+0xfe/0x130
| ret_from_fork+0x27/0x50
If any locking is required, a simple mutex will do it.
Cc: Gary R Hook <gary.hook@amd.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Gary R Hook <gary.hook@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Antoine Tenart [Fri, 23 Feb 2018 09:01:40 +0000 (10:01 +0100)]
crypto: atmel-aes - fix the keys zeroing on errors
[ Upstream commit
5d804a5157dbaa64872a675923ae87161165c66b ]
The Atmel AES driver uses memzero_explicit on the keys on error, but the
variable zeroed isn't the right one because of a typo. Fix this by using
the right variable.
Fixes:
89a82ef87e01 ("crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes")
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Antoine Tenart [Mon, 26 Feb 2018 13:45:12 +0000 (14:45 +0100)]
crypto: inside-secure - wait for the request to complete if in the backlog
[ Upstream commit
4dc5475ae0375ea4f9283dfd9b2ddc91b20d4c4b ]
This patch updates the safexcel_hmac_init_pad() function to also wait
for completion when the digest return code is -EBUSY, as it would mean
the request is in the backlog to be processed later.
Fixes:
1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine driver")
Suggested-by: Ofer Heifetz <oferh@marvell.com>
Signed-off-by: Antoine Tenart <antoine.tenart@bootlin.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Thu, 22 Feb 2018 22:09:33 +0000 (09:09 +1100)]
staging: lustre: lmv: correctly iput lmo_root
[ Upstream commit
17556cdbe6ed70a6a20e597b228628f7f34387f8 ]
Commit
8f18c8a48b73 ("staging: lustre: lmv: separate master object
with master stripe") changed how lmo_root inodes were managed,
particularly when LMV_HASH_FLAG_MIGRATION is not set.
Previously lsm_md_oinfo[0].lmo_root was always a borrowed
inode reference and didn't need to by iput().
Since the change, that special case only applies when
LMV_HASH_FLAG_MIGRATION is set
In the upstream (lustre-release) version of this patch [Commit
60e07b972114 ("LU-4690 lod: separate master object with master
stripe")] the for loop in the lmv_unpack_md() was changed to count
from 0 and to ignore entry 0 if LMV_HASH_FLAG_MIGRATION is set.
In the patch that got applied to Linux, that change was missing,
so lsm_md_oinfo[0].lmo_root is never iput().
This results in a "VFS: Busy inodes" warning at unmount.
Fixes:
8f18c8a48b73 ("staging: lustre: lmv: separate master object with master stripe")
Signed-off-by: NeilBrown <neilb@suse.com>
Reviewed-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Quytelda Kahja [Thu, 1 Mar 2018 05:19:07 +0000 (21:19 -0800)]
staging: ks7010: Use constants from ieee80211_eid instead of literal ints.
[ Upstream commit
dc13498ab47fdfae3cda4df712beb2e4244b3fe0 ]
The case statement in get_ap_information() should not use literal integers
to parse information element IDs when these values are provided by name
in 'enum ieee80211_eid' in the header 'linux/ieee80211.h'.
Signed-off-by: Quytelda Kahja <quytelda@tamalin.org>
Reviewed-by: Tobin C. Harding <me@tobin.cc>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Wed, 28 Feb 2018 11:28:49 +0000 (11:28 +0000)]
staging: rtl8192u: return -ENOMEM on failed allocation of priv->oldaddr
[ Upstream commit
e1a7418529e33bc4efc346324557251a16a3e79b ]
Currently the allocation of priv->oldaddr is not null checked which will
lead to subsequent errors when accessing priv->oldaddr. Fix this with
a null pointer check and a return of -ENOMEM on allocation failure.
Detected with Coccinelle:
drivers/staging/rtl8192u/r8192U_core.c:1708:2-15: alloc with no test,
possible model on line 1723
Fixes:
8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ioana Radulescu [Mon, 26 Feb 2018 16:28:06 +0000 (10:28 -0600)]
staging: fsl-dpaa2/eth: Fix incorrect casts
[ Upstream commit
75c583ab9709692a60871d4719006391cde8dc1d ]
The DPAA2 Ethernet driver incorrectly assumes virtual addresses
are always 64b long, which causes compiler errors when building
for a 32b platform.
Fix this by using explicit casts to uintptr_t where necessary.
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Thu, 1 Mar 2018 23:31:25 +0000 (10:31 +1100)]
staging: lustre: fix bug in osc_enter_cache_try
[ Upstream commit
2fab9faf9b27298c4536c1c1b14072ab18b8f80b ]
The lustre-release patch commit
bdc5bb52c554 ("LU-4933 osc:
Automatically increase the max_dirty_mb") changed
- if (cli->cl_dirty + PAGE_CACHE_SIZE <= cli->cl_dirty_max &&
+ if (cli->cl_dirty_pages < cli->cl_dirty_max_pages &&
When this patch landed in Linux a couple of years later, it landed as
- if (cli->cl_dirty + PAGE_SIZE <= cli->cl_dirty_max &&
+ if (cli->cl_dirty_pages <= cli->cl_dirty_max_pages &&
which is clearly different ('<=' vs '<'), and allows cl_dirty_pages to
increase beyond cl_dirty_max_pages - which causes a latter assertion
to fails.
Fixes:
3147b268400a ("staging: lustre: osc: Automatically increase the max_dirty_mb")
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kirill Marinushkin [Fri, 23 Mar 2018 19:32:54 +0000 (20:32 +0100)]
staging: bcm2835-audio: Release resources on module_exit()
[ Upstream commit
626118b472d2eb45f83a0276a18d3e6a01c69f6a ]
In the current implementation, `rmmod snd_bcm2835` does not release
resources properly. It causes an oops when trying to list sound devices.
This commit fixes it.
The details WRT allocation / free are described below.
Device structure WRT allocation:
pdev
\childdev[]
\card
\chip
\pcm
\ctl
Allocation / register sequence:
* childdev: devm_kzalloc - freed during driver detach
* childdev: device_initialize - freed during device_unregister
* pdev: devres_alloc - freed during driver detach
* childdev: device_add - removed during device_unregister
* pdev, childdev: devres_add - freed during driver detach
* card: snd_card_new - freed during snd_card_free
* chip: kzalloc - freed during kfree
* card, chip: snd_device_new - freed during snd_device_free
* chip: new_pcm - TODO: free pcm
* chip: new_ctl - TODO: free ctl
* card: snd_card_register - unregistered during snd_card_free
Free / unregister sequence:
* card: snd_card_free
* card, chip: snd_device_free
* childdev: device_unregister
* chip: kfree
Steps to reproduce the issue before this commit:
~~~~
$ rmmod snd_bcm2835
$ aplay -L
[ 138.648130] Unable to handle kernel paging request at virtual address
7f1343c0
[ 138.660415] pgd =
ad8f0000
[ 138.665567] [
7f1343c0] *pgd=
3864c811, *pte=
00000000, *ppte=
00000000
[ 138.674887] Internal error: Oops: 7 [#1] SMP ARM
[ 138.683571] Modules linked in: sha256_generic cfg80211 rfkill snd_pcm snd_timer
snd fixed uio_pdrv_genirq uio ip_tables x_tables ipv6 [last unloaded: snd_bcm2835
]
[ 138.706594] CPU: 3 PID: 463 Comm: aplay Tainted: G WC 4.15.0-rc1-v
7+ #6
[ 138.719833] Hardware name: BCM2835
[ 138.726016] task:
b877ac00 task.stack:
aebec000
[ 138.733408] PC is at try_module_get+0x38/0x24c
[ 138.740813] LR is at snd_ctl_open+0x58/0x194 [snd]
[ 138.748485] pc : [<
801c4d5c>] lr : [<
7f0e6b2c>] psr:
20000013
[ 138.757709] sp :
aebedd60 ip :
aebedd88 fp :
aebedd84
[ 138.765884] r10:
00000000 r9 :
00000004 r8 :
7f0ed440
[ 138.774040] r7 :
b7e469b0 r6 :
7f0e6b2c r5 :
afd91900 r4 :
7f1343c0
[ 138.783571] r3 :
aebec000 r2 :
00000001 r1 :
b877ac00 r0 :
7f1343c0
[ 138.793084] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 138.803300] Control:
10c5387d Table:
2d8f006a DAC:
00000055
[ 138.812064] Process aplay (pid: 463, stack limit = 0xaebec210)
[ 138.820868] Stack: (0xaebedd60 to 0xaebee000)
[ 138.828207] dd60:
00000000 b848d000 afd91900 00000000 b7e469b0 7f0ed440 aebedda4 aebedd88
[ 138.842371] dd80:
7f0e6b2c 801c4d30 afd91900 7f0ea4dc 00000000 b7e469b0 aebeddcc aebedda8
[ 138.856611] dda0:
7f0e250c 7f0e6ae0 7f0e2464 b8478ec0 b7e469b0 afd91900 7f0ea388 00000000
[ 138.870864] ddc0:
aebeddf4 aebeddd0 802ce590 7f0e2470 8090ab64 afd91900 afd91900 b7e469b0
[ 138.885301] dde0:
afd91908 802ce4e4 aebede1c aebeddf8 802c57b4 802ce4f0 afd91900 aebedea8
[ 138.900110] de00:
b7fa4c00 00000000 00000000 00000004 aebede3c aebede20 802c6ba8 802c56b4
[ 138.915260] de20:
aebedea8 00000000 aebedf5c 00000000 aebedea4 aebede40 802d9a68 802c6b58
[ 138.930661] de40:
b874ddd0 00000000 00000000 00000001 00000041 00000000 afd91900 aebede70
[ 138.946402] de60:
00000000 00000000 00000002 b7e469b0 b8a87610 b8d6ab80 801852f8 00080000
[ 138.962314] de80:
aebedf5c aebedea8 00000001 80108464 aebec000 00000000 aebedf4c aebedea8
[ 138.978414] dea0:
802dacd4 802d970c b8a87610 b8d6ab80 a7982bc6 00000009 af363019 b9231480
[ 138.994617] dec0:
00000000 b8c038a0 b7e469b0 00000101 00000002 00000238 00000000 00000000
[ 139.010823] dee0:
00000000 aebedee8 00080000 0000000f aebedf3c aebedf00 802ed7e4 80843f94
[ 139.027025] df00:
00000003 00080000 b9231490 b9231480 00000000 00080000 af363000 00000000
[ 139.043229] df20:
00000005 00000002 ffffff9c 00000000 00080000 ffffff9c af363000 00000003
[ 139.059430] df40:
aebedf94 aebedf50 802c6f70 802dac70 aebec000 00000000 00000001 00000000
[ 139.075629] df60:
00020000 00000004 00000100 00000001 7ebe577c 0002e038 00000000 00000005
[ 139.091828] df80:
80108464 aebec000 aebedfa4 aebedf98 802c7060 802c6e6c 00000000 aebedfa8
[ 139.108025] dfa0:
801082c0 802c7040 7ebe577c 0002e038 7ebe577c 00080000 00000b98 e81c8400
[ 139.124222] dfc0:
7ebe577c 0002e038 00000000 00000005 7ebe57e4 00a20af8 7ebe57f0 76f87394
[ 139.140419] dfe0:
00000000 7ebe55c4 76ec88e8 76df1d9c 60000010 7ebe577c 00000000 00000000
[ 139.156715] [<
801c4d5c>] (try_module_get) from [<
7f0e6b2c>] (snd_ctl_open+0x58/0x194 [snd])
[ 139.173222] [<
7f0e6b2c>] (snd_ctl_open [snd]) from [<
7f0e250c>] (snd_open+0xa8/0x14c [snd])
[ 139.189683] [<
7f0e250c>] (snd_open [snd]) from [<
802ce590>] (chrdev_open+0xac/0x188)
[ 139.205465] [<
802ce590>] (chrdev_open) from [<
802c57b4>] (do_dentry_open+0x10c/0x314)
[ 139.221347] [<
802c57b4>] (do_dentry_open) from [<
802c6ba8>] (vfs_open+0x5c/0x88)
[ 139.236788] [<
802c6ba8>] (vfs_open) from [<
802d9a68>] (path_openat+0x368/0x944)
[ 139.248270] [<
802d9a68>] (path_openat) from [<
802dacd4>] (do_filp_open+0x70/0xc4)
[ 139.263731] [<
802dacd4>] (do_filp_open) from [<
802c6f70>] (do_sys_open+0x110/0x1d4)
[ 139.279378] [<
802c6f70>] (do_sys_open) from [<
802c7060>] (SyS_open+0x2c/0x30)
[ 139.290647] [<
802c7060>] (SyS_open) from [<
801082c0>] (ret_fast_syscall+0x0/0x28)
[ 139.306021] Code:
e3c3303f e5932004 e2822001 e5832004 (
e5943000)
[ 139.316265] ---[ end trace
7f3f7f6193b663ed ]---
[ 139.324956] note: aplay[463] exited with preempt_count 1
~~~~
Signed-off-by: Kirill Marinushkin <k.marinushkin@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Cc: Michael Zoran <mzoran@crowfest.net>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: linux-rpi-kernel@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: devel@driverdev.osuosl.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Nyman [Fri, 16 Mar 2018 14:33:06 +0000 (16:33 +0200)]
xhci: Show what USB release number the xHC supports from protocol capablity
[ Upstream commit
0ee78c101425aae681c631ba59c6ac7f44b1d83a ]
xhci driver displays the supported xHC USB revision in a message during
driver load:
"Host supports USB 3.1 Enhanced SuperSpeed"
Get the USB minor revision number from the xhci protocol capability.
This will show the correct supported revisions for new USB 3.2 and later
hosts
Don't rely on the SBRN (serial bus revision number) register, it's often
showing 0x30 (USB3.0) for hosts that support USB 3.1
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Sun, 11 Feb 2018 18:24:32 +0000 (12:24 -0600)]
Bluetooth: btusb: Add device ID for RTL8822BE
[ Upstream commit
fed03fe7e55b7dc16077f672bd9d7bbe92b3a691 ]
The Asus Z370-I contains a Realtek RTL8822BE device with an associated
BT chip using a USB ID of 0b05:185c. This device is added to the driver.
Signed-off-by: Hon Weng Chong <honwchong@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brad Love [Fri, 5 Jan 2018 00:04:13 +0000 (19:04 -0500)]
media: em28xx: USB bulk packet size fix
[ Upstream commit
c7c7e8d7803406daa21e96d00c357de8b77b6764 ]
Hauppauge em28xx bulk devices exhibit continuity errors and corrupted
packets, when run in VMWare virtual machines. Unknown if other
manufacturers bulk models exhibit the same issue. KVM/Qemu is unaffected.
According to documentation the maximum packet multiplier for em28xx in bulk
transfer mode is 256 * 188 bytes. This changes the size of bulk transfers
to maximum supported value and have a bonus beneficial alignment.
Before:
After:
This sets up USB to expect just as many bytes as the em28xx is set to emit.
Successful usage under load afterwards natively and in both VMWare
and KVM/Qemu virtual machines.
Signed-off-by: Brad Love <brad@nextdimension.cc>
Reviewed-by: Michael Ira Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brad Love [Fri, 5 Jan 2018 14:57:12 +0000 (09:57 -0500)]
media: lgdt3306a: Fix module count mismatch on usb unplug
[ Upstream commit
835d66173a38538c072a7c393d02360dcfac8582 ]
When used as an i2c device there is a module usage count mismatch on
removal, preventing the driver from being used thereafter. dvb_attach
increments the usage count so it is properly balanced on removal.
On disconnect of Hauppauge SoloHD/DualHD before:
lsmod | grep lgdt3306a
lgdt3306a 28672 -1
i2c_mux 16384 1 lgdt3306a
On disconnect of Hauppauge SoloHD/DualHD after:
lsmod | grep lgdt3306a
lgdt3306a 28672 0
i2c_mux 16384 1 lgdt3306a
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Dickens [Mon, 1 Jan 2018 02:59:42 +0000 (18:59 -0800)]
usb: gadget: composite: fix incorrect handling of OS desc requests
[ Upstream commit
5d6ae4f0da8a64a185074dabb1b2f8c148efa741 ]
When handling an OS descriptor request, one of the first operations is
to zero out the request buffer using the wLength from the setup packet.
There is no bounds checking, so a wLength > 4096 would clobber memory
adjacent to the request buffer. Fix this by taking the min of wLength
and the request buffer length prior to the memset. While at it, define
the buffer length in a header file so that magic numbers don't appear
throughout the code.
When returning data to the host, the data length should be the min of
the wLength and the valid data we have to return. Currently we are
returning wLength, thus requests for a wLength greater than the amount
of data in the OS descriptor buffer would return invalid (albeit zero'd)
data following the valid descriptor data. Fix this by counting the
number of bytes when constructing the data and using this when
determining the length of the request.
Signed-off-by: Chris Dickens <christopher.a.dickens@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wolfram Sang [Tue, 6 Feb 2018 08:50:40 +0000 (09:50 +0100)]
usb: gadget: udc: change comparison to bitshift when dealing with a mask
[ Upstream commit
ac87e560f7c0f91b62012e9a159c0681a373b922 ]
Due to a typo, the mask was destroyed by a comparison instead of a bit
shift.
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Mon, 29 Jan 2018 00:04:18 +0000 (00:04 +0000)]
usbip: Correct maximum value of CONFIG_USBIP_VHCI_HC_PORTS
[ Upstream commit
351a8d4837ae0d61744e64262c3a80ab92ff3e42 ]
Now that usbip supports USB3, the maximum number of ports allowed
on a hub is 15 (USB_SS_MAXPORTS), not 31 (USB_MAXCHILDREN).
Reported-by: Gianluigi Tiesi <sherpya@netfarm.it>
Reported-by: Borissh1983 <borissh1983@gmail.com>
References: https://bugs.debian.org/878866
Fixes:
1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed support")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lars-Peter Clausen [Fri, 12 Jan 2018 10:05:02 +0000 (11:05 +0100)]
usb: gadget: ffs: Execute copy_to_user() with USER_DS set
[ Upstream commit
4058ebf33cb0be88ca516f968eda24ab7b6b93e4 ]
When using a AIO read() operation on the function FS gadget driver a URB is
submitted asynchronously and on URB completion the received data is copied
to the userspace buffer associated with the read operation.
This is done from a kernel worker thread invoking copy_to_user() (through
copy_to_iter()). And while the user space process memory is made available
to the kernel thread using use_mm(), some architecture require in addition
to this that the operation runs with USER_DS set. Otherwise the userspace
memory access will fail.
For example on ARM64 with Privileged Access Never (PAN) and User Access
Override (UAO) enabled the following crash occurs.
Internal error: Accessing user space memory with fs=KERNEL_DS:
9600004f [#1] SMP
Modules linked in:
CPU: 2 PID: 1636 Comm: kworker/2:1 Not tainted 4.9.0-04081-g8ab2dfb-dirty #487
Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
Workqueue: events ffs_user_copy_worker
task:
ffffffc87afc8080 task.stack:
ffffffc87a00c000
PC is at __arch_copy_to_user+0x190/0x220
LR is at copy_to_iter+0x78/0x3c8
[...]
[<
ffffff800847b790>] __arch_copy_to_user+0x190/0x220
[<
ffffff80086f25d8>] ffs_user_copy_worker+0x70/0x130
[<
ffffff80080b8c64>] process_one_work+0x1dc/0x460
[<
ffffff80080b8f38>] worker_thread+0x50/0x4b0
[<
ffffff80080bf5a0>] kthread+0xd8/0xf0
[<
ffffff8008083680>] ret_from_fork+0x10/0x50
Address this by placing a set_fs(USER_DS) before of the copy operation
and revert it again once the copy operation has finished.
This patch is analogous to commit
d7ffde35e31a ("vhost: use USER_DS in
vhost_worker thread") which addresses the same underlying issue.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lars-Peter Clausen [Fri, 12 Jan 2018 10:26:16 +0000 (11:26 +0100)]
usb: gadget: ffs: Let setup() return USB_GADGET_DELAYED_STATUS
[ Upstream commit
946ef68ad4e45aa048a5fb41ce8823ed29da866a ]
Some UDC drivers (like the DWC3) expect that the response to a setup()
request is queued from within the setup function itself so that it is
available as soon as setup() has completed.
Upon receiving a setup request the function fs driver creates an event that
is made available to userspace. And only once userspace has acknowledged
that event the response to the setup request is queued.
So it violates the requirement of those UDC drivers and random failures can
be observed. This is basically a race condition and if userspace is able to
read the event and queue the response fast enough all is good. But if it is
not, for example because other processes are currently scheduled to run,
the USB host that sent the setup request will observe an error.
To avoid this the gadget framework provides the USB_GADGET_DELAYED_STATUS
return code. If a setup() callback returns this value the UDC driver is
aware that response is not yet available and can uses the appropriate
methods to handle this case.
Since in the case of function fs the response will never be available when
the setup() function returns make sure that this status code is used.
This fixed random occasional failures that were previously observed on a
DWC3 based system under high system load.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / platform / kernel / linux-rpi.git / log