| Age | Commit message (Collapse) | Author |
|---|
|
commit ee291e63293146db64668e8d65eb35c97e8324f4 upstream.
When creating network portals rapidly, such as when restoring a
configuration, LIO's code to reuse existing portals can return a false
negative if the thread hasn't run yet and set np_thread_state to
ISCSI_NP_THREAD_ACTIVE. This causes an error in the network stack
when attempting to bind to the same address/port.
This patch sets NP_THREAD_ACTIVE before the np is placed on g_np_list,
so even if the thread hasn't run yet, iscsit_get_np will return the
existing np.
Also, convert np_lock -> np_mutex + hold across adding new net portal
to g_np_list to prevent a race where two threads may attempt to create
the same network portal, resulting in one of them failing.
(nab: Add missing mutex_unlocks in iscsit_add_np failure paths)
(DanC: Fix incorrect spin_unlock -> spin_unlock_bh)
Signed-off-by: Andy Grover <agrover@redhat.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4a4caa29f1abcb14377e05d57c0793d338fb945d upstream.
This patch addresses an traditional iscsi-target fabric ack starvation
issue where iscsit_allocate_cmd() -> percpu_ida_alloc_state() ends up
hitting slow path percpu-ida code, because iscsit_ack_from_expstatsn()
is expected to free ack'ed tags after tag allocation.
This is done to take into account the tags waiting to be acknowledged
and released in iscsit_ack_from_expstatsn(), but who's number are not
directly limited by the CmdSN Window queue_depth being enforced by
the target.
So that said, this patch bumps up the pre-allocated number of
per session tags to:
(max(queue_depth, ISCSIT_MIN_TAGS) * 2) + ISCSIT_EXTRA_TAGS
for good measure to avoid the percpu_ida_alloc_state() slow path.
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f466f75385369a181409e46da272db3de6f5c5cb upstream.
vqs are freed in virtscsi_freeze but the hotcpu_notifier is not
unregistered. We will have a use-after-free usage when the notifier
callback is called after virtscsi_freeze.
Fixes: 285e71ea6f3583a85e27cb2b9a7d8c35d4c0d558
("virtio-scsi: reset virtqueue affinity when doing cpu hotplug")
Signed-off-by: Asias He <asias.hejun@gmail.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3c60cfd73966797746530768d66597d025a69804 upstream.
We should cap the size of memcpy() because it comes from the network
and can't be trusted.
Fixes: 26ffd7b45fe9 ('[SCSI] qla4xxx: Add support to set CHAP entries')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Vikas Chaudhary <vikas.chaudhary@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit dcaf9aed995c2b2a49fb86bbbcfa2f92c797ab5d upstream.
Bfa driver crash is observed while pushing the firmware on to chinook
quad port card due to uninitialized bfi_image_ct2 access which gets
initialized only for CT2 ASIC based cards after request_firmware().
For quard port chinook (CT2 ASIC based), bfi_image_ct2 is not getting
initialized as there is no check for chinook PCI device ID before
request_firmware and instead bfi_image_cb is initialized as it is the
default case for card type check.
This patch includes changes to read the right firmware for quad port chinook.
Signed-off-by: Vijaya Mohan Guvva <vmohan@brocade.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 83e83ecb79a8225e79bc8e54e9aff3e0e27658a2 upstream.
There is no need to skip querying the config and string descriptors for
unauthorized WUSB devices when usb_new_device is called. It is allowed
by WUSB spec. The only action that needs to be delayed until
authorization time is the set config. This change allows user mode
tools to see the config and string descriptors earlier in enumeration
which is needed for some WUSB devices to function properly on Android
systems. It also reduces the amount of divergent code paths needed
for WUSB devices.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8a10bc9d27ceb084b0d8be621a033a475eb9fdfd upstream.
The built-in ROM fonts lack many necessary ASCII characters, which is
why it makes sens to prefer the Linux fonts instead if they are
available. This makes consoles on STI graphics cards which are not
supported by the stifb driver (e.g. Visualize FXe) looks much nicer.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a974862faee199cba3ff36b5a148df5fd34bd1e7 upstream.
Sometimes we may meet the following lockdep issue.
The root cause is .set_clock callback is executed with spin_lock_irqsave
in sdhci_do_set_ios. However, the IMX set_clock callback will try to access
clk_get_rate which is using a mutex lock.
The fix avoids access mutex in .set_clock callback by initializing the
pltfm_host->clock at probe time and use it later instead of calling
clk_get_rate again in atomic context.
[ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
3.13.0-rc1+ #285 Not tainted
------------------------------------------------------
kworker/u8:1/29 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
(prepare_lock){+.+...}, at: [<80480b08>] clk_prepare_lock+0x44/0xe4
and this task is already holding:
(&(&host->lock)->rlock#2){-.-...}, at: [<804611f4>] sdhci_do_set_ios+0x20/0x720
which would create a new lock dependency:
(&(&host->lock)->rlock#2){-.-...} -> (prepare_lock){+.+...}
but this new dependency connects a HARDIRQ-irq-safe lock:
(&(&host->lock)->rlock#2){-.-...}
... which became HARDIRQ-irq-safe at:
[<8005f030>] mark_lock+0x140/0x6ac
[<80060760>] __lock_acquire+0xb30/0x1cbc
[<800620d0>] lock_acquire+0x70/0x84
[<8061d2f0>] _raw_spin_lock+0x30/0x40
[<80460668>] sdhci_irq+0x24/0xa68
[<8006b1d4>] handle_irq_event_percpu+0x54/0x18c
[<8006b350>] handle_irq_event+0x44/0x64
[<8006e50c>] handle_fasteoi_irq+0xa0/0x170
[<8006a8f0>] generic_handle_irq+0x30/0x44
[<8000f238>] handle_IRQ+0x54/0xbc
[<8000864c>] gic_handle_irq+0x30/0x64
[<80013024>] __irq_svc+0x44/0x5c
[<80614c58>] printk+0x38/0x40
[<804622a8>] sdhci_add_host+0x844/0xbcc
[<80464948>] sdhci_esdhc_imx_probe+0x378/0x67c
[<8032ee88>] platform_drv_probe+0x20/0x50
[<8032d48c>] driver_probe_device+0x118/0x234
[<8032d690>] __driver_attach+0x9c/0xa0
[<8032b89c>] bus_for_each_dev+0x68/0x9c
[<8032cf44>] driver_attach+0x20/0x28
[<8032cbc8>] bus_add_driver+0x148/0x1f4
[<8032dce0>] driver_register+0x80/0x100
[<8032ee54>] __platform_driver_register+0x50/0x64
[<8084b094>] sdhci_esdhc_imx_driver_init+0x18/0x20
[<80008980>] do_one_initcall+0x108/0x16c
[<8081cca4>] kernel_init_freeable+0x10c/0x1d0
[<80611c50>] kernel_init+0x10/0x120
[<8000e9c8>] ret_from_fork+0x14/0x2c
to a HARDIRQ-irq-unsafe lock:
(prepare_lock){+.+...}
... which became HARDIRQ-irq-unsafe at:
... [<8005f030>] mark_lock+0x140/0x6ac
[<8005f604>] mark_held_locks+0x68/0x12c
[<8005f780>] trace_hardirqs_on_caller+0xb8/0x1d8
[<8005f8b4>] trace_hardirqs_on+0x14/0x18
[<8061a130>] mutex_trylock+0x180/0x20c
[<80480ad8>] clk_prepare_lock+0x14/0xe4
[<804816a4>] clk_notifier_register+0x28/0xf0
[<80015120>] twd_clk_init+0x50/0x68
[<80008980>] do_one_initcall+0x108/0x16c
[<8081cca4>] kernel_init_freeable+0x10c/0x1d0
[<80611c50>] kernel_init+0x10/0x120
[<8000e9c8>] ret_from_fork+0x14/0x2c
other info that might help us debug this:
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(prepare_lock);
local_irq_disable();
lock(&(&host->lock)->rlock#2);
lock(prepare_lock);
<Interrupt>
lock(&(&host->lock)->rlock#2);
*** DEADLOCK ***
3 locks held by kworker/u8:1/29:
#0: (kmmcd){.+.+.+}, at: [<8003db18>] process_one_work+0x128/0x468
#1: ((&(&host->detect)->work)){+.+.+.}, at: [<8003db18>] process_one_work+0x128/0x468
#2: (&(&host->lock)->rlock#2){-.-...}, at: [<804611f4>] sdhci_do_set_ios+0x20/0x720
the dependencies between HARDIRQ-irq-safe lock and the holding lock:
-> (&(&host->lock)->rlock#2){-.-...} ops: 330 {
IN-HARDIRQ-W at:
[<8005f030>] mark_lock+0x140/0x6ac
[<80060760>] __lock_acquire+0xb30/0x1cbc
[<800620d0>] lock_acquire+0x70/0x84
[<8061d2f0>] _raw_spin_lock+0x30/0x40
[<80460668>] sdhci_irq+0x24/0xa68
[<8006b1d4>] handle_irq_event_percpu+0x54/0x18c
[<8006b350>] handle_irq_event+0x44/0x64
[<8006e50c>] handle_fasteoi_irq+0xa0/0x170
[<8006a8f0>] generic_handle_irq+0x30/0x44
[<8000f238>] handle_IRQ+0x54/0xbc
[<8000864c>] gic_handle_irq+0x30/0x64
[<80013024>] __irq_svc+0x44/0x5c
[<80614c58>] printk+0x38/0x40
[<804622a8>] sdhci_add_host+0x844/0xbcc
[<80464948>] sdhci_esdhc_imx_probe+0x378/0x67c
[<8032ee88>] platform_drv_probe+0x20/0x50
[<8032d48c>] driver_probe_device+0x118/0x234
[<8032d690>] __driver_attach+0x9c/0xa0
[<8032b89c>] bus_for_each_dev+0x68/0x9c
[<8032cf44>] driver_attach+0x20/0x28
[<8032cbc8>] bus_add_driver+0x148/0x1f4
[<8032dce0>] driver_register+0x80/0x100
[<8032ee54>] __platform_driver_register+0x50/0x64
[<8084b094>] sdhci_esdhc_imx_driver_init+0x18/0x20
[<80008980>] do_one_initcall+0x108/0x16c
[<8081cca4>] kernel_init_freeable+0x10c/0x1d0
[<80611c50>] kernel_init+0x10/0x120
[<8000e9c8>] ret_from_fork+0x14/0x2c
IN-SOFTIRQ-W at:
[<8005f030>] mark_lock+0x140/0x6ac
[<80060204>] __lock_acquire+0x5d4/0x1cbc
[<800620d0>] lock_acquire+0x70/0x84
[<8061d40c>] _raw_spin_lock_irqsave+0x40/0x54
[<8045e4a4>] sdhci_tasklet_finish+0x1c/0x120
[<8002b538>] tasklet_action+0xa0/0x15c
[<8002b778>] __do_softirq+0x118/0x290
[<8002bcf4>] irq_exit+0xb4/0x10c
[<8000f240>] handle_IRQ+0x5c/0xbc
[<8000864c>] gic_handle_irq+0x30/0x64
[<80013024>] __irq_svc+0x44/0x5c
[<80614c58>] printk+0x38/0x40
[<804622a8>] sdhci_add_host+0x844/0xbcc
[<80464948>] sdhci_esdhc_imx_probe+0x378/0x67c
[<8032ee88>] platform_drv_probe+0x20/0x50
[<8032d48c>] driver_probe_device+0x118/0x234
[<8032d690>] __driver_attach+0x9c/0xa0
[<8032b89c>] bus_for_each_dev+0x68/0x9c
[<8032cf44>] driver_attach+0x20/0x28
[<8032cbc8>] bus_add_driver+0x148/0x1f4
[<8032dce0>] driver_register+0x80/0x100
[<8032ee54>] __platform_driver_register+0x50/0x64
[<8084b094>] sdhci_esdhc_imx_driver_init+0x18/0x20
[<80008980>] do_one_initcall+0x108/0x16c
[<8081cca4>] kernel_init_freeable+0x10c/0x1d0
[<80611c50>] kernel_init+0x10/0x120
[<8000e9c8>] ret_from_fork+0x14/0x2c
INITIAL USE at:
[<8005f030>] mark_lock+0x140/0x6ac
[<8005ff0c>] __lock_acquire+0x2dc/0x1cbc
[<800620d0>] lock_acquire+0x70/0x84
[<8061d40c>] _raw_spin_lock_irqsave+0x40/0x54
[<804611f4>] sdhci_do_set_ios+0x20/0x720
[<80461924>] sdhci_set_ios+0x30/0x3c
[<8044cea0>] mmc_power_up+0x6c/0xd0
[<8044dac4>] mmc_start_host+0x60/0x70
[<8044eb3c>] mmc_add_host+0x60/0x88
[<8046225c>] sdhci_add_host+0x7f8/0xbcc
[<80464948>] sdhci_esdhc_imx_probe+0x378/0x67c
[<8032ee88>] platform_drv_probe+0x20/0x50
[<8032d48c>] driver_probe_device+0x118/0x234
[<8032d690>] __driver_attach+0x9c/0xa0
[<8032b89c>] bus_for_each_dev+0x68/0x9c
[<8032cf44>] driver_attach+0x20/0x28
[<8032cbc8>] bus_add_driver+0x148/0x1f4
[<8032dce0>] driver_register+0x80/0x100
[<8032ee54>] __platform_driver_register+0x50/0x64
[<8084b094>] sdhci_esdhc_imx_driver_init+0x18/0x20
[<80008980>] do_one_initcall+0x108/0x16c
[<8081cca4>] kernel_init_freeable+0x10c/0x1d0
[<80611c50>] kernel_init+0x10/0x120
[<8000e9c8>] ret_from_fork+0x14/0x2c
}
... key at: [<80e040e8>] __key.26952+0x0/0x8
... acquired at:
[<8005eb60>] check_usage+0x3d0/0x5c0
[<8005edac>] check_irq_usage+0x5c/0xb8
[<80060d38>] __lock_acquire+0x1108/0x1cbc
[<800620d0>] lock_acquire+0x70/0x84
[<8061a210>] mutex_lock_nested+0x54/0x3c0
[<80480b08>] clk_prepare_lock+0x44/0xe4
[<8048188c>] clk_get_rate+0x14/0x64
[<8046374c>] esdhc_pltfm_set_clock+0x20/0x2a4
[<8045d70c>] sdhci_set_clock+0x4c/0x498
[<80461518>] sdhci_do_set_ios+0x344/0x720
[<80461924>] sdhci_set_ios+0x30/0x3c
[<8044c390>] __mmc_set_clock+0x44/0x60
[<8044cd4c>] mmc_set_clock+0x10/0x14
[<8044f8f4>] mmc_init_card+0x1b4/0x1520
[<80450f00>] mmc_attach_mmc+0xb4/0x194
[<8044da08>] mmc_rescan+0x294/0x2f0
[<8003db94>] process_one_work+0x1a4/0x468
[<8003e850>] worker_thread+0x118/0x3e0
[<80044de0>] kthread+0xd4/0xf0
[<8000e9c8>] ret_from_fork+0x14/0x2c
the dependencies between the lock to be acquired and HARDIRQ-irq-unsafe lock:
-> (prepare_lock){+.+...} ops: 395 {
HARDIRQ-ON-W at:
[<8005f030>] mark_lock+0x140/0x6ac
[<8005f604>] mark_held_locks+0x68/0x12c
[<8005f780>] trace_hardirqs_on_caller+0xb8/0x1d8
[<8005f8b4>] trace_hardirqs_on+0x14/0x18
[<8061a130>] mutex_trylock+0x180/0x20c
[<80480ad8>] clk_prepare_lock+0x14/0xe4
[<804816a4>] clk_notifier_register+0x28/0xf0
[<80015120>] twd_clk_init+0x50/0x68
[<80008980>] do_one_initcall+0x108/0x16c
[<8081cca4>] kernel_init_freeable+0x10c/0x1d0
[<80611c50>] kernel_init+0x10/0x120
[<8000e9c8>] ret_from_fork+0x14/0x2c
SOFTIRQ-ON-W at:
[<8005f030>] mark_lock+0x140/0x6ac
[<8005f604>] mark_held_locks+0x68/0x12c
[<8005f7c8>] trace_hardirqs_on_caller+0x100/0x1d8
[<8005f8b4>] trace_hardirqs_on+0x14/0x18
[<8061a130>] mutex_trylock+0x180/0x20c
[<80480ad8>] clk_prepare_lock+0x14/0xe4
[<804816a4>] clk_notifier_register+0x28/0xf0
[<80015120>] twd_clk_init+0x50/0x68
[<80008980>] do_one_initcall+0x108/0x16c
[<8081cca4>] kernel_init_freeable+0x10c/0x1d0
[<80611c50>] kernel_init+0x10/0x120
[<8000e9c8>] ret_from_fork+0x14/0x2c
INITIAL USE at:
[<8005f030>] mark_lock+0x140/0x6ac
[<8005ff0c>] __lock_acquire+0x2dc/0x1cbc
[<800620d0>] lock_acquire+0x70/0x84
[<8061a0c8>] mutex_trylock+0x118/0x20c
[<80480ad8>] clk_prepare_lock+0x14/0xe4
[<80482af8>] __clk_init+0x1c/0x45c
[<8048306c>] _clk_register+0xd0/0x170
[<80483148>] clk_register+0x3c/0x7c
[<80483b4c>] clk_register_fixed_rate+0x88/0xd8
[<80483c04>] of_fixed_clk_setup+0x68/0x94
[<8084c6fc>] of_clk_init+0x44/0x68
[<808202b0>] time_init+0x2c/0x38
[<8081ca14>] start_kernel+0x1e4/0x368
[<10008074>] 0x10008074
}
... key at: [<808afebc>] prepare_lock+0x38/0x48
... acquired at:
[<8005eb94>] check_usage+0x404/0x5c0
[<8005edac>] check_irq_usage+0x5c/0xb8
[<80060d38>] __lock_acquire+0x1108/0x1cbc
[<800620d0>] lock_acquire+0x70/0x84
[<8061a210>] mutex_lock_nested+0x54/0x3c0
[<80480b08>] clk_prepare_lock+0x44/0xe4
[<8048188c>] clk_get_rate+0x14/0x64
[<8046374c>] esdhc_pltfm_set_clock+0x20/0x2a4
[<8045d70c>] sdhci_set_clock+0x4c/0x498
[<80461518>] sdhci_do_set_ios+0x344/0x720
[<80461924>] sdhci_set_ios+0x30/0x3c
[<8044c390>] __mmc_set_clock+0x44/0x60
[<8044cd4c>] mmc_set_clock+0x10/0x14
[<8044f8f4>] mmc_init_card+0x1b4/0x1520
[<80450f00>] mmc_attach_mmc+0xb4/0x194
[<8044da08>] mmc_rescan+0x294/0x2f0
[<8003db94>] process_one_work+0x1a4/0x468
[<8003e850>] worker_thread+0x118/0x3e0
[<80044de0>] kthread+0xd4/0xf0
[<8000e9c8>] ret_from_fork+0x14/0x2c
stack backtrace:
CPU: 2 PID: 29 Comm: kworker/u8:1 Not tainted 3.13.0-rc1+ #285
Workqueue: kmmcd mmc_rescan
Backtrace:
[<80012160>] (dump_backtrace+0x0/0x10c) from [<80012438>] (show_stack+0x18/0x1c)
r6:00000000 r5:00000000 r4:8088ecc8 r3:bfa11200
[<80012420>] (show_stack+0x0/0x1c) from [<80616b14>] (dump_stack+0x84/0x9c)
[<80616a90>] (dump_stack+0x0/0x9c) from [<8005ebb4>] (check_usage+0x424/0x5c0)
r5:80979940 r4:bfa29b44
[<8005e790>] (check_usage+0x0/0x5c0) from [<8005edac>] (check_irq_usage+0x5c/0xb8)
[<8005ed50>] (check_irq_usage+0x0/0xb8) from [<80060d38>] (__lock_acquire+0x1108/0x1cbc)
r8:bfa115e8 r7:80df9884 r6:80dafa9c r5:00000003 r4:bfa115d0
[<8005fc30>] (__lock_acquire+0x0/0x1cbc) from [<800620d0>] (lock_acquire+0x70/0x84)
[<80062060>] (lock_acquire+0x0/0x84) from [<8061a210>] (mutex_lock_nested+0x54/0x3c0)
r7:bfa11200 r6:80dafa9c r5:00000000 r4:80480b08
[<8061a1bc>] (mutex_lock_nested+0x0/0x3c0) from [<80480b08>] (clk_prepare_lock+0x44/0xe4)
[<80480ac4>] (clk_prepare_lock+0x0/0xe4) from [<8048188c>] (clk_get_rate+0x14/0x64)
r6:03197500 r5:bf0e9aa8 r4:bf827400 r3:808ae128
[<80481878>] (clk_get_rate+0x0/0x64) from [<8046374c>] (esdhc_pltfm_set_clock+0x20/0x2a4)
r5:bf0e9aa8 r4:bf0e9c40
[<8046372c>] (esdhc_pltfm_set_clock+0x0/0x2a4) from [<8045d70c>] (sdhci_set_clock+0x4c/0x498)
[<8045d6c0>] (sdhci_set_clock+0x0/0x498) from [<80461518>] (sdhci_do_set_ios+0x344/0x720)
r8:0000003b r7:20000113 r6:bf0e9d68 r5:bf0e9aa8 r4:bf0e9c40
r3:00000000
[<804611d4>] (sdhci_do_set_ios+0x0/0x720) from [<80461924>] (sdhci_set_ios+0x30/0x3c)
r9:00000004 r8:bf131000 r7:bf131048 r6:00000000 r5:bf0e9aa8
r4:bf0e9800
[<804618f4>] (sdhci_set_ios+0x0/0x3c) from [<8044c390>] (__mmc_set_clock+0x44/0x60)
r5:03197500 r4:bf0e9800
[<8044c34c>] (__mmc_set_clock+0x0/0x60) from [<8044cd4c>] (mmc_set_clock+0x10/0x14)
r5:00000000 r4:bf0e9800
[<8044cd3c>] (mmc_set_clock+0x0/0x14) from [<8044f8f4>] (mmc_init_card+0x1b4/0x1520)
[<8044f740>] (mmc_init_card+0x0/0x1520) from [<80450f00>] (mmc_attach_mmc+0xb4/0x194)
[<80450e4c>] (mmc_attach_mmc+0x0/0x194) from [<8044da08>] (mmc_rescan+0x294/0x2f0)
r5:8065f358 r4:bf0e9af8
[<8044d774>] (mmc_rescan+0x0/0x2f0) from [<8003db94>] (process_one_work+0x1a4/0x468)
r8:00000000 r7:bfa29eb0 r6:bf80dc00 r5:bf0e9af8 r4:bf9e3f00
r3:8044d774
[<8003d9f0>] (process_one_work+0x0/0x468) from [<8003e850>] (worker_thread+0x118/0x3e0)
[<8003e738>] (worker_thread+0x0/0x3e0) from [<80044de0>] (kthread+0xd4/0xf0)
[<80044d0c>] (kthread+0x0/0xf0) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
r7:00000000 r6:00000000 r5:80044d0c r4:bf9e7f00
Fixes: 0ddf03c mmc: esdhc-imx: parse max-frequency from devicetree
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Philippe De Muyter <phdm@macqel.be>
Signed-off-by: Chris Ball <chris@printf.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2b35bd83467df6f8284b9148d6f768148c3a5e5f upstream.
The sdhci_execute_tuning routine gets lock separately by
disable_irq(host->irq);
spin_lock(&host->lock);
It will cause the following lockdep error message since the &host->lock
could also be got in irq context.
Use spin_lock_irqsave/spin_unlock_restore instead to get rid of
this error message.
[ INFO: inconsistent lock state ]
3.13.0-rc1+ #287 Not tainted
---------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
kworker/u2:1/33 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&(&host->lock)->rlock){?.-...}, at: [<8045f7f4>] sdhci_execute_tuning+0x4c/0x710
{IN-HARDIRQ-W} state was registered at:
[<8005f030>] mark_lock+0x140/0x6ac
[<80060760>] __lock_acquire+0xb30/0x1cbc
[<800620d0>] lock_acquire+0x70/0x84
[<8061d1c8>] _raw_spin_lock+0x30/0x40
[<804605cc>] sdhci_irq+0x24/0xa68
[<8006b1d4>] handle_irq_event_percpu+0x54/0x18c
[<8006b350>] handle_irq_event+0x44/0x64
[<8006e50c>] handle_fasteoi_irq+0xa0/0x170
[<8006a8f0>] generic_handle_irq+0x30/0x44
[<8000f238>] handle_IRQ+0x54/0xbc
[<8000864c>] gic_handle_irq+0x30/0x64
[<80013024>] __irq_svc+0x44/0x5c
[<80329bf4>] dev_vprintk_emit+0x50/0x58
[<80329c24>] dev_printk_emit+0x28/0x30
[<80329fec>] __dev_printk+0x4c/0x90
[<8032a180>] dev_err+0x3c/0x48
[<802dd4f0>] _regulator_get+0x158/0x1cc
[<802dd5b4>] regulator_get_optional+0x18/0x1c
[<80461df4>] sdhci_add_host+0x42c/0xbd8
[<80464820>] sdhci_esdhc_imx_probe+0x378/0x67c
[<8032ee88>] platform_drv_probe+0x20/0x50
[<8032d48c>] driver_probe_device+0x118/0x234
[<8032d690>] __driver_attach+0x9c/0xa0
[<8032b89c>] bus_for_each_dev+0x68/0x9c
[<8032cf44>] driver_attach+0x20/0x28
[<8032cbc8>] bus_add_driver+0x148/0x1f4
[<8032dce0>] driver_register+0x80/0x100
[<8032ee54>] __platform_driver_register+0x50/0x64
[<8084b094>] sdhci_esdhc_imx_driver_init+0x18/0x20
[<80008980>] do_one_initcall+0x108/0x16c
[<8081cca4>] kernel_init_freeable+0x10c/0x1d0
[<80611b28>] kernel_init+0x10/0x120
[<8000e9c8>] ret_from_fork+0x14/0x2c
irq event stamp: 805
hardirqs last enabled at (805): [<8061d43c>] _raw_spin_unlock_irqrestore+0x38/0x4c
hardirqs last disabled at (804): [<8061d2c8>] _raw_spin_lock_irqsave+0x24/0x54
softirqs last enabled at (570): [<8002b824>] __do_softirq+0x1c4/0x290
softirqs last disabled at (561): [<8002bcf4>] irq_exit+0xb4/0x10c
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&host->lock)->rlock);
<Interrupt>
lock(&(&host->lock)->rlock);
*** DEADLOCK ***
2 locks held by kworker/u2:1/33:
#0: (kmmcd){.+.+..}, at: [<8003db18>] process_one_work+0x128/0x468
#1: ((&(&host->detect)->work)){+.+...}, at: [<8003db18>] process_one_work+0x128/0x468
stack backtrace:
CPU: 0 PID: 33 Comm: kworker/u2:1 Not tainted 3.13.0-rc1+ #287
Workqueue: kmmcd mmc_rescan
Backtrace:
[<80012160>] (dump_backtrace+0x0/0x10c) from [<80012438>] (show_stack+0x18/0x1c)
r6:bfad0900 r5:00000000 r4:8088ecc8 r3:bfad0900
[<80012420>] (show_stack+0x0/0x1c) from [<806169ec>] (dump_stack+0x84/0x9c)
[<80616968>] (dump_stack+0x0/0x9c) from [<806147b4>] (print_usage_bug+0x260/0x2d0)
r5:8076ba88 r4:80977410
[<80614554>] (print_usage_bug+0x0/0x2d0) from [<8005f0d0>] (mark_lock+0x1e0/0x6ac)
r9:8005e678 r8:00000000 r7:bfad0900 r6:00001015 r5:bfad0cd0
r4:00000002
[<8005eef0>] (mark_lock+0x0/0x6ac) from [<80060234>] (__lock_acquire+0x604/0x1cbc)
[<8005fc30>] (__lock_acquire+0x0/0x1cbc) from [<800620d0>] (lock_acquire+0x70/0x84)
[<80062060>] (lock_acquire+0x0/0x84) from [<8061d1c8>] (_raw_spin_lock+0x30/0x40)
r7:00000000 r6:bfb63000 r5:00000000 r4:bfb60568
[<8061d198>] (_raw_spin_lock+0x0/0x40) from [<8045f7f4>] (sdhci_execute_tuning+0x4c/0x710)
r4:bfb60000
[<8045f7a8>] (sdhci_execute_tuning+0x0/0x710) from [<80453454>] (mmc_sd_init_card+0x5f8/0x660)
[<80452e5c>] (mmc_sd_init_card+0x0/0x660) from [<80453748>] (mmc_attach_sd+0xb4/0x180)
r9:bf92d400 r8:8065f364 r7:00061a80 r6:bfb60000 r5:8065f358
r4:bfb60000
[<80453694>] (mmc_attach_sd+0x0/0x180) from [<8044d9f8>] (mmc_rescan+0x284/0x2f0)
r5:8065f358 r4:bfb602f8
[<8044d774>] (mmc_rescan+0x0/0x2f0) from [<8003db94>] (process_one_work+0x1a4/0x468)
r8:00000000 r7:bfb55eb0 r6:bf80dc00 r5:bfb602f8 r4:bfb35980
r3:8044d774
[<8003d9f0>] (process_one_work+0x0/0x468) from [<8003e850>] (worker_thread+0x118/0x3e0)
[<8003e738>] (worker_thread+0x0/0x3e0) from [<80044de0>] (kthread+0xd4/0xf0)
[<80044d0c>] (kthread+0x0/0xf0) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
r7:00000000 r6:00000000 r5:80044d0c r4:bfb37b40
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Chris Ball <chris@printf.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 390145f9adcf2730fcee81c8a51fd7c6c08f705f upstream.
Due to unknown hw issue so far, Merrifield is unable to enable HS200
support. This patch adds quirk to avoid SDHCI to initialize with error
below:
[ 53.850132] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W
3.12.0-rc6-00037-g3d7c8d9-dirty #36
[ 53.850150] Hardware name: Intel Corporation Merrifield/SALT BAY,
BIOS 397 2013.09.12:11.51.40
[ 53.850167] 00000000 00000000 ee409e48 c18816d2 00000000 ee409e78
c123e254 c1acc9b0
[ 53.850227] 00000000 00000000 c1b14148 000003de c16c03bf c16c03bf
ee75b480 ed97c54c
[ 53.850282] ee75b480 ee409e88 c123e292 00000009 00000000 ee409ef8
c16c03bf c1207fac
[ 53.850339] Call Trace:
[ 53.850376] [<c18816d2>] dump_stack+0x4b/0x79
[ 53.850408] [<c123e254>] warn_slowpath_common+0x84/0xa0
[ 53.850436] [<c16c03bf>] ? sdhci_send_command+0xb4f/0xc50
[ 53.850462] [<c16c03bf>] ? sdhci_send_command+0xb4f/0xc50
[ 53.850490] [<c123e292>] warn_slowpath_null+0x22/0x30
[ 53.850516] [<c16c03bf>] sdhci_send_command+0xb4f/0xc50
[ 53.850545] [<c1207fac>] ? native_sched_clock+0x2c/0xb0
[ 53.850575] [<c14c1f93>] ? delay_tsc+0x73/0xb0
[ 53.850601] [<c14c1ebe>] ? __const_udelay+0x1e/0x20
[ 53.850626] [<c16bdeb3>] ? sdhci_reset+0x93/0x190
[ 53.850654] [<c16c05b0>] sdhci_finish_data+0xf0/0x2e0
[ 53.850683] [<c16c130f>] sdhci_irq+0x31f/0x930
[ 53.850713] [<c12cb080>] ? __buffer_unlock_commit+0x10/0x20
[ 53.850740] [<c12cbcd7>] ? trace_buffer_unlock_commit+0x37/0x50
[ 53.850773] [<c1288f3c>] handle_irq_event_percpu+0x5c/0x220
[ 53.850800] [<c128bc96>] ? handle_fasteoi_irq+0x16/0xd0
[ 53.850827] [<c128913a>] handle_irq_event+0x3a/0x60
[ 53.850852] [<c128bc80>] ? unmask_irq+0x30/0x30
[ 53.850878] [<c128bcce>] handle_fasteoi_irq+0x4e/0xd0
[ 53.850895] <IRQ> [<c1890b52>] ? do_IRQ+0x42/0xb0
[ 53.850943] [<c1890a31>] ? common_interrupt+0x31/0x38
[ 53.850973] [<c12b00d8>] ? cgroup_mkdir+0x4e8/0x580
[ 53.851001] [<c1208d32>] ? default_idle+0x22/0xf0
[ 53.851029] [<c1209576>] ? arch_cpu_idle+0x26/0x30
[ 53.851054] [<c1288505>] ? cpu_startup_entry+0x65/0x240
[ 53.851082] [<c18793d5>] ? rest_init+0xb5/0xc0
[ 53.851108] [<c1879320>] ? __read_lock_failed+0x18/0x18
[ 53.851138] [<c1bf6a15>] ? start_kernel+0x31b/0x321
[ 53.851164] [<c1bf652f>] ? repair_env_string+0x51/0x51
[ 53.851190] [<c1bf6363>] ? i386_start_kernel+0x139/0x13c
[ 53.851209] ---[ end trace 92777f5fe48d33f2 ]---
[ 53.853449] mmcblk0: error -84 transferring data, sector 11142162, nr
304, cmd response 0x0, card status 0x0
[ 53.853476] mmcblk0: retrying using single block read
[ 55.937863] sdhci: Timeout waiting for Buffer Read Ready interrupt
during tuning procedure, falling back to fixed sampling clock
[ 56.207951] sdhci: Timeout waiting for Buffer Read Ready interrupt
during tuning procedure, falling back to fixed sampling clock
[ 66.228785] mmc0: Timeout waiting for hardware interrupt.
[ 66.230855] ------------[ cut here ]------------
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Reviewed-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Acked-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Chris Ball <chris@printf.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 13868bf20f2f2c305f96e23620b024e167d6f9cb upstream.
This patch defines a quirk for platforms unable to enable HS200 support.
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Reviewed-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Acked-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Chris Ball <chris@printf.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit cefe0078eea52af17411eb1248946a94afb84ca5 ]
This patch removes grant transfer releasing code from netfront, and uses
gnttab_end_foreign_access to end grant access since
gnttab_end_foreign_access_ref may fail when the grant entry is
currently used for reading or writing.
* clean up grant transfer code kept from old netfront(2.6.18) which grants
pages for access/map and transfer. But grant transfer is deprecated in current
netfront, so remove corresponding release code for transfer.
* fix resource leak, release grant access (through gnttab_end_foreign_access)
and skb for tx/rx path, use get_page to ensure page is released when grant
access is completed successfully.
Xen-blkfront/xen-tpmfront/xen-pcifront also have similar issue, but patches
for them will be created separately.
V6: Correct subject line and commit message.
V5: Remove unecessary change in xennet_end_access.
V4: Revert put_page in gnttab_end_foreign_access, and keep netfront change in
single patch.
V3: Changes as suggestion from David Vrabel, ensure pages are not freed untill
grant acess is ended.
V2: Improve patch comments.
Signed-off-by: Annie Li <annie.li@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit d0bc65557ad09a57b4db176e9e3ccddb26971453 ]
Make sure the practice set by commit 0afb166 "vxlan: Add capability
of Rx checksum offload for inner packet" is applied when the skb
goes through the portion of the RX code which is shared between
vxlan netdevices and ovs vxlan port instances.
Cc: Joseph Gasparakis <joseph.gasparakis@intel.com>
Cc: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a183d3ae63c08186477d2b0ef2798d47d10add4b upstream.
ehv_bytechan is marked tristate but fails to build as a module:
drivers/tty/ehv_bytechan.c:363:1: error: type defaults to ‘int’ in declaration of ‘console_initcall’ [-Werror=implicit-int]
It doesn't make much sense for a console driver to be built as
a module, so change it to a bool.
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Scott Wood <scottwood@freescale.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 032f708bc4f6da868ec49dac48ddf3670d8035d3 upstream.
The locations of SMBus register base address and enablement bit are changed
from AMD ML, which need this patch to be supported.
Signed-off-by: Shane Huang <shane.huang@amd.com>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6cf70ae928bae17077efc0d528dec49bc380438b upstream.
The first variants of Armada XP SoCs (A0 stepping) have issues related
to the i2c controller which prevent to use the offload mechanism and
lead to a kernel hang during boot.
The commit introduces a new the compatible string
marvell,mv78230-a0-i2c for the i2c controller. When this compatible
string is used the driver disables the offload mechanism and the
kernel no more hangs on these SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reported-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support)
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b0ad4ff35d479a46a3b995a299db9aeb097acfce upstream.
The DriveGuard chips on the new HP laptops are with a new PnP ID
"HPQ6007". It should be compatible with older chips.
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit da4a04126baa3be03bc566d4a2ee0944c5e783d0 upstream.
Dan and Sergey reported that there is a racy between reset and flushing
of pending work so that it could make oops by freeing zram->meta in
reset while zram_slot_free can access zram->meta if new request is
adding during the race window.
This patch moves flush after taking init_lock so it prevents new request
so that it closes the race.
Signed-off-by: Minchan Kim <minchan@kernel.org>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Jerome Marchand <jmarchan@redhat.com>
Tested-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ef71ec00002d92a08eb27e9d036e3d48835b6597 upstream.
The code that handles overlapping extents that we've just read back in from disk
was depending on the behaviour of the code that handles overlapping extents as
we're inserting into a btree node in the case of an insert that forced an
existing extent to be split: on insert, if we had to split we'd also insert a
new extent to represent the top part of the old extent - and then that new
extent would get written out.
The code that read the extents back in thus not bother with splitting extents -
if it saw an extent that ovelapped in the middle of an older extent, it would
trim the old extent to only represent the bottom part, assuming that the
original insert would've inserted a new extent to represent the top part.
I still haven't figured out _how_ it can happen, but I'm now pretty convinced
(and testing has confirmed) that there's some kind of an obscure corner case
(probably involving extent merging, and multiple overwrites in different sets)
that breaks this. The fix is to change the mergesort fixup code to split extents
itself when required.
Signed-off-by: Kent Overstreet <kmo@daterainc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ecd75ad514d73efc1bbcc5f10a13566c3ace5f53 upstream.
For some reason, some early WD drives spin up and down drives
erratically when the link is put into slumber mode which can reduce
the life expectancy of the device significantly. Unfortunately, we
don't have full list of devices and given the nature of the issue it'd
be better to err on the side of false positives than the other way
around. Let's disable LPM on all WD devices which match one of the
known problematic model prefixes and are SATA-I.
As horkage list doesn't support matching SATA capabilities, this is
implemented as two horkages - WD_BROKEN_LPM and NOLPM. The former is
set for the known prefixes and sets the latter if the matched device
is SATA-I.
Note that this isn't optimal as this disables all LPM operations and
partial link power state reportedly works fine on these; however, the
way LPM is implemented in libata makes it difficult to precisely map
libata LPM setting to specific link power state. Well, these devices
are already fairly outdated. Let's just disable whole LPM for now.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Nikos Barkas <levelwol@gmail.com>
Reported-and-tested-by: Ioannis Barkas <risc4all@yahoo.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=57211
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9013d64e661fc2a37a1742670202171c27fef4b5 upstream.
On Armada 370/XP SoCs, once a disk is removed from a SATA port, then the
re-plug events are not detected by the sata_mv driver. This patch fixes
the issue by updating the PHY speed in the LP_PHY_CTL register (0x58)
according to the SControl speed.
Note that this fix is only applied if the compatible string
"marvell,armada-370-sata" is found in the SATA DT node.
Fixes: 9ae6f740b49f ("arm: mach-mvebu: add support for Armada 370 and Armada XP with DT")
Signed-off-by: Lior Amsalem <alior@marvell.com>
Signed-off-by: Nadav Haklai <nadavh@marvell.com>
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b1f5c73bd5a4752efb7d7af019034044b08aafe9 upstream.
The sata_mv driver supports the SATA IP found in several Marvell SoCs.
As some new SATA registers have been introduced with the Armada 370/XP
SoCs, a way to identify them is needed.
This patch introduces a new compatible string for the SATA IP found in
Armada 370/XP SoCs.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Lior Amsalem <alior@marvell.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 747d35bd9bb4ae6bd74b19baa5bbe32f3e0cee11 upstream.
Depending on the implementation strcmp might return the difference between
two strings not only -1,0,1 consequently
if (strcmp (a,b) == -1)
might lead to taking the wrong branch
-> compare with < 0 instead,
which in any case is more canonical.
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 85c5e0d451125c6ddb78663972e40af810b83644 upstream.
The 'get_burstcount' function can in some circumstances 'return -EBUSY' which
in tpm_stm_i2c_send is stored in an 'u32 burstcnt'
thus converting the signed value into an unsigned value, resulting
in 'burstcnt' being huge.
Changing the type to u32 only does not solve the problem as the signed
value is converted to an unsigned in I2C_WRITE_DATA, resulting in the
same effect.
Thus
-> Change type of burstcnt to u32 (the return type of get_burstcount)
-> Add a check for the return value of 'get_burstcount' and propagate a
potential error.
This makes also sense in the 'I2C_READ_DATA' case, where the there is no
signed/unsigned conversion.
found by coverity
Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 74142ffc0b52cfe6f9d2f6f34a5f3eedbfe3ce51 upstream.
The regmap used by max77686 MFD driver was not freed with regmap_exit()
on driver exit. This lead to leak of resources.
Replace regmap_init_i2c() call in driver probe with initialization of
managed register map so the regmap will be properly freed by the device
management code.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fa8cf57c923e86a693a85aff1df579245a27cbb3 upstream.
Some GPIO users, such as fixed-regulator, request GPIO output with
initial value of 1. This was ignored by sunxi driver.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit df5e4e8b576108f88f79e5b4c984d51d460d2360 upstream.
The interrupt handler (mic_interrupt), called in the MSI/INTx mode,
writes to the interrupt sources register to acknowledge the
interrupt and then calls the corresponding callback handlers to handle
the same. These callback handlers acknowledge the interrupts again
leading to missed interrupts. This patch fixes the issue by removing
the interrupt acknowlegment code from the callback handlers.
Reviewed-by: Sudeep Dutt <sudeep.dutt@intel.com>
Reviewed-by: Nikhil Rao <nikhil.rao@intel.com>
Reviewed-by: Siva Krishna Kumar Reddy Yerramreddy <siva.krishna.kumar.reddy.yerramreddy@intel.com>
Signed-off-by: Dasaratharaman Chandramouli <dasaratharaman.chandramouli@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 75ea799df4cb07e505c91b4abaa87bc28aad3e66 upstream.
The current MAX8907 driver has two issues related to weekday value
handling:
1)
The HW WEEKDAY register has range 0..6 rather than 1..7 as documented.
Note that I validated the actual HW range by observing the HW register
roll from 6->0 rather than 6->7->1 as would otherwise be expected.
This matches Linux's tm_wday range of 0..6.
When the CMOS RAM content is lost, the date returned from the device is
2007-01-01 00:00:00, which is a Monday. The WEEKDAY register reads 1 in
this case. This matches the numbering in Linux's tm_wday field.
Hence we should write Linux's tm_wday value to the register without
modifying it. Hence, remove the +1/-1 calculations for WEEKDAY/tm_wday.
2)
There's no need to make alarms match on the WEEKDAY register, since the
other fields together uniquely define the alarm date/time. Ignoring the
WEEKDAY value in the match isolates the driver from any incorrect value in
the current time copy of the WEEKDAY register.
Each change individually, or both together, solves an issue that I
observed; "hwclock -r" would time out waiting for its alarm to fire if the
CMOS RAM content had been lost, and hence the WEEKDAY register value
mismatched what the driver expected it to be. "hwclock -w" would solve
this by over-writing the HW default WEEKDAY register value with what the
driver expected.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d6a484520c5572a4170fa915109ccfc0c38f5008 upstream.
In commit 85747f ("PATCH] parport: add NetMOS 9805 support") Max added
the PCI ID for NetMOS 9805 based on a Debian bug report from 2k4 which
was at the v2.4.26 time frame. The patch made into 2.6.14.
Shortly before that patch akpm merged commit 296d3c783b ("[PATCH] Support
NetMOS based PCI cards providing serial and parallel ports") which made
into v2.6.9-rc1.
Now we have two different entries for the same PCI id.
I have here the NetMos 9805 which claims to support SPP/EPP/ECP mode.
This patch takes Max's entry for titan_1284p1 (base != -1 specifies the
ioport for ECP mode) and replaces akpm's entry for netmos_9805 which
specified -1 (=none). Both share the same PCI-ID (my card has subsystem
0x1000 / 0x0020 so it should match PCI_ANY).
While here I also drop the entry for titan_1284p2 which is the same as
netmos_9815.
Cc: Maximilian Attems <maks@stro.at>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3685f19e07802ec4207b52465c408f185b66490e upstream.
Tegra chips have 4 or 5 identical UART modules embedded. UARTs C..E have
their MODEM-control signals tied off to a static state. However UARTs A
and B can optionally route those signals to/from package pins, depending
on the exact pinmux configuration.
When these signals are not routed to package pins, false interrupts may
trigger either temporarily, or permanently, all while not showing up in
the IIR; it will read as NO_INT. This will eventually lead to the UART
IRQ being disabled due to unhandled interrupts. When this happens, the
kernel may print e.g.:
irq 68: nobody cared (try booting with the "irqpoll" option)
In order to prevent this, enable UART_BUG_NOMSR. This prevents
UART_IER_MSI from being enabled, which prevents the false interrupts
from triggering.
In practice, this is not needed under any of the following conditions:
* On Tegra chips after Tegra30, since the HW bug has apparently been
fixed.
* On UARTs C..E since their MODEM control signals are tied to the correct
static state which doesn't trigger the issue.
* On UARTs A..B if the MODEM control signals are routed out to package
pins, since they will then carry valid signals.
However, we ignore these exceptions for now, since they are only relevant
if a board actually hooks up more than a 4-wire UART, and no currently
supported board does this. If we ever support a board that does, we can
refine the algorithm that enables UART_BUG_NOMSR to take those exceptions
into account, and/or read a flag from DT/... that indicates that the
board has hooked up and pinmux'd more than a 4-wire UART.
Reported-by: Olof Johansson <olof@lixom.net> # autotester
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9c5320f8d7d9a2cf623e65d50e1113f34d9b9eb1 upstream.
Fix the initialisation of older Quatech serial cards which are fitted with
the AMCC PCI Matchmaker interface chip.
Signed-off-by: Jonathan Woithe (jwoithe@just42.net)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 48c0247d7b7bf58abb85a39021099529df365c4d upstream.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 632fefaf1fff7c344191c363e08a43cf006fe60e upstream.
Commit e6789cd3dfb553077606ccafeb05e0043f072481 (uio: Simplify uio error
path by using devres functions) converted uio to use devm_request_irq().
This introduced a change in behaviour since the IRQ is associated with
the parent device instead of the created UIO device. The IRQ will remain
active after uio_unregister_device() is called, and some drivers will
crash because of this. The patch fixes this.
Signed-off-by: Aaro Koskinen <aaro.koskinen@nsn.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f2d9b991c549f159dc9ae81f77d8206c790cbfee upstream.
Commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e "usb: xhci: Link TRB
must not occur within a USB payload burst" attempted to fix an issue
found with USB ethernet adapters, and inadvertently broke USB storage
devices. The patch attempts to ensure that transfers never span a
segment, and rejects transfers that have more than 63 entries (or
possibly less, if some entries cross 64KB boundaries).
usb-storage limits the maximum transfer size to 120K, and we had assumed
the block layer would pass a scatter-gather list of 4K entries,
resulting in no more than 31 sglist entries:
http://marc.info/?l=linux-usb&m=138498190419312&w=2
That assumption was wrong, since we've seen the driver reject a write
that was 218 sectors long (of probably 512 bytes each):
Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd 0000:00:14.0: Too many fragments 79, max 63
...
Jan 1 07:04:58 jidanni5 kernel: [ 568.622583] Write(10): 2a 00 00 06 85 0e 00 00 da 00
Limit the number of scatter-gather entries to half a ring segment. That
should be margin enough in case some entries cross 64KB boundaries.
Increase the number of TRBs per segment from 64 to 256, which should
result in ring segments fitting on a 4K page.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: jidanni@jidanni.org
References: http://bugs.debian.org/733907
Fixes: 35773dac5f86 ('usb: xhci: Link TRB must not occur within a USB payload burst')
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d6c9ea9069af684358efedcaf2f2f687f51c58ee upstream.
Currently prepare_ring() returns -ENOMEM if the urb won't fit into a
single ring segment. usb_sg_wait() treats this error as a temporary
condition and will keep retrying until something else goes wrong.
The number of retries should be limited in usb_sg_wait(), but also
prepare_ring() should not return an error code that suggests it might
be worth retrying. Change it to -EINVAL.
Reported-by: jidanni@jidanni.org
References: http://bugs.debian.org/733907
Fixes: 35773dac5f86 ('usb: xhci: Link TRB must not occur within a USB payload burst')
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d303b1b5fbb688282bbf72a534b9dfed7af9fe4f upstream.
Add new PCI ID to support new model "Kaveri" family.
Signed-off-by: Philip Pokorny <ppokorny@penguincomputing.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8bc661bfc0c2d221e209f4205bdaaf574d50100c upstream.
The uart timer will schedule a tasklet when it fires. It is possible that it
can fire inside _shutdown before it is killed in the dma and pdc cleanup
routines. This causes a tasklet that exists after the port is shutdown, so when
the kernel finally executes it, it panics as the tty port is NULL.
This is a somewhat rare condition but its possible if a program keeps on
opening/closing the port. It has been observed in particular with systemd
boot messages that were causing a kernel panic because of this behavior.
Moving the timer deletion to the beginning of the function stops a tasklet from
being scheduled unexpectedly.
Signed-off-by: Marek Roszko <mark.roszko@gmail.com>
[nicolas.ferre@atmel.com: modify commit message, call setup_timer() in any case]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit bb7e73c598fb226c75f7625088a8f6a45a0fc892 upstream.
When using RX DMA, the driver won't pass any data to the uart layer
until the buffer is flipped. When the port is shutdown, the dma buffers
are unmapped, but the head and tail of the ring buffer are not reseted.
Since the serial console will keep the port open, this will only
present itself when the uart is not shared.
To reproduce the issue, with an unpatched driver, run a getty on /dev/ttyS0
with no serial console and exit. Getty will exit, and when the new one returns
you will be unable to log in. If you hold down a key long enough to fill the
DMA buffer and flip it, you can then log in.
Signed-off-by: Mark Deneen <mdeneen@gmail.com>
Acked-by: Leilei Zhao <leilei.zhao@atmel.com>
[nicolas.ferre@atmel.com: adapt to mainline kernel, handle !DMA case]
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f50c995f9ebf064cea1368bf361c4e29679415b4 upstream.
The _remove callback could be called when a tasklet is scheduled. tasklet_kill
was called inside the function in order to free up any scheduled tasklets.
However it was called after uart_remove_one_port which destroys tty references
needed in the port for atmel_tasklet_func.
Simply putting the tasklet_kill at the start of the function will prevent this
conflict.
Signed-off-by: Marek Roszko <mark.roszko@gmail.com>
Acked-by: Leilei Zhao <leilei.zhao@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0cc7c6c7916b1b6f34350ff1473b80b9f7e459c0 upstream.
Interrupts were being cleaned up late in the shutdown handler, it is possible
that an interrupt can occur and schedule a tasklet that runs after the port is
cleaned up. There is a null dereference due to this race condition with the
following stacktrace:
[<c02092b0>] (atmel_tasklet_func+0x514/0x814) from [<c001fd34>] (tasklet_action+0x70/0xa8)
[<c001fd34>] (tasklet_action+0x70/0xa8) from [<c001f60c>] (__do_softirq+0x90/0x144)
[<c001f60c>] (__do_softirq+0x90/0x144) from [<c001fa18>] (irq_exit+0x40/0x4c)
[<c001fa18>] (irq_exit+0x40/0x4c) from [<c000e298>] (handle_IRQ+0x64/0x84)
[<c000e298>] (handle_IRQ+0x64/0x84) from [<c000d6c0>] (__irq_svc+0x40/0x50)
[<c000d6c0>] (__irq_svc+0x40/0x50) from [<c0208060>] (atmel_rx_dma_release+0x88/0xb8)
[<c0208060>] (atmel_rx_dma_release+0x88/0xb8) from [<c0209740>] (atmel_shutdown+0x104/0x160)
[<c0209740>] (atmel_shutdown+0x104/0x160) from [<c0205e8c>] (uart_port_shutdown+0x2c/0x38)
Signed-off-by: Marek Roszko <mark.roszko@gmail.com>
Acked-by: Leilei Zhao <leilei.zhao@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 66ae460b13c31a176b41550259683c841a62af3e upstream.
When reset is caused by hbm protocol mismatch or timeout
we might end up in an endless reset loop and hbm protocol
will never sync
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9acec059c0cef0bf086c738f4c0b1f4447782a48 upstream.
value uLowNextTBTT yields wrong value.
ULL is needed with qwTSF
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
bScanning
commit 8f248dae133668bfb8e9379b4b3f0571c858b24a upstream.
byBBPreEDIndex value is initially 0, this means that from
cold BBvUpdatePreEDThreshold is never set.
This means that sensitivity may be in an ambiguous state,
failing to scan any wireless points or at least distant ones.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3a21f00a5002b14e4aab52aef59d33ed28468a13 upstream.
The latest version of NetworkManager does not recognize the device as wireless
without this change.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3c92a0bf4d72737035a16c4fe357ccd439c9b7d2 upstream.
When a system runs out of memory and the function
ptlrpc_register_bulk() is called from ptl_send_rpc() the call to
LNetMEAttach() fails due to failure to allocate memory. This forces
the code into an error path, which most probably previously went
untested. The error path:
if (rc != 0) {
CERROR("%s: LNetMEAttach failed x"LPU64"/%d: rc = %dn",
desc->bd_export->exp_obd->obd_name, xid,
posted_md, rc);
break;
}
This print assumes that desc->bd_export is not NULL. However, it is.
In fact it is expected to be NULL. desc->bd_import is the correct
structure to access in this case.
Lustre-change: http://review.whamcloud.com/7121
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3585
Signed-off-by: Amir Shehata <amir.shehata@intel.com>
Reviewed-by: Liang Zhen <liang.zhen@intel.com>
Reviewed-by: Doug Oucharek <doug.s.oucharek@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: Peng Tao <bergwolf@gmail.com>
Signed-off-by: Andreas Dilger <andreas.dilger@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1e2f9295f4c657500111514f92a3d3894d0e05b4 upstream.
Fast Channel Change across bands was enabled for
AR9462 recently, but this is causing baseband issues.
Disable it until this feature is tested well. Also,
remove the feature bit for AR9565 since it is
a single-band card and doesn't support this feature.
Reported-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ff9a93f2ebb88ac7aab9568de80b64b92078e96d upstream.
Accessing the current channel definition in mac80211
when processing RX packets is problematic because it
could have been updated when a scan is issued. Since a
channel change involves flushing the existing packets
in the RX queue before a chip-reset is done, they would
be processed using the wrong band/channel information.
To avoid this, use the current channel information
maintained in the driver.
Reported-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 64e5acb09ca6b50c97299cff9ef51299470b29f2 upstream.
Use the right function to update frequency value.
If rx skb is probe response or beacon, the wrong frequency value can
cause problem that bss info can't be updated when it should be.
Fixes: 8318d78a44d4 ("cfg80211 API for channels/bitrates, mac80211 and driver conversion")
Signed-off-by: ZHAO Gang <gamerh2o@gmail.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 452028665312672c6ba9e16a19248ee00ead9400 upstream.
The asyncronous firmware load uses a completion struct to hold firmware
processing until the user-space routines are up and running. There is.
however, a problem in that the waiter is nevered canceled during teardown.
As a result, unloading the driver when firmware is not available causes an oops.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0673effd41dba323d6a280ef37b5ef29f3f5a653 upstream.
The asyncronous firmware load uses a completion struct to hold firmware
processing until the user-space routines are up and running. There is.
however, a problem in that the waiter is nevered canceled during teardown.
As a result, unloading the driver when firmware is not available causes an oops.
To be able to access the completion structure at teardown, it had to be moved
into the b43_wldev structure.
This patch also fixes a typo in a comment.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
