user/sven/linux.git/drivers/mmc/host, branch v3.13.2

mmc: sdhci-esdhc-imx: fix access hardirq-unsafe lock in atomic context

2014-02-06T19:34:09Z

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); 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 Acked-by: Shawn Guo Tested-by: Philippe De Muyter Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: fix lockdep error in tuning routine

2014-02-06T19:34:09Z

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); 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 Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: sdhci-pci: add broken HS200 quirk for Intel Merrifield

2014-02-06T19:34:08Z

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] [] dump_stack+0x4b/0x79 [ 53.850408] [] warn_slowpath_common+0x84/0xa0 [ 53.850436] [] ? sdhci_send_command+0xb4f/0xc50 [ 53.850462] [] ? sdhci_send_command+0xb4f/0xc50 [ 53.850490] [] warn_slowpath_null+0x22/0x30 [ 53.850516] [] sdhci_send_command+0xb4f/0xc50 [ 53.850545] [] ? native_sched_clock+0x2c/0xb0 [ 53.850575] [] ? delay_tsc+0x73/0xb0 [ 53.850601] [] ? __const_udelay+0x1e/0x20 [ 53.850626] [] ? sdhci_reset+0x93/0x190 [ 53.850654] [] sdhci_finish_data+0xf0/0x2e0 [ 53.850683] [] sdhci_irq+0x31f/0x930 [ 53.850713] [] ? __buffer_unlock_commit+0x10/0x20 [ 53.850740] [] ? trace_buffer_unlock_commit+0x37/0x50 [ 53.850773] [] handle_irq_event_percpu+0x5c/0x220 [ 53.850800] [] ? handle_fasteoi_irq+0x16/0xd0 [ 53.850827] [] handle_irq_event+0x3a/0x60 [ 53.850852] [] ? unmask_irq+0x30/0x30 [ 53.850878] [] handle_fasteoi_irq+0x4e/0xd0 [ 53.850895] [] ? do_IRQ+0x42/0xb0 [ 53.850943] [] ? common_interrupt+0x31/0x38 [ 53.850973] [] ? cgroup_mkdir+0x4e8/0x580 [ 53.851001] [] ? default_idle+0x22/0xf0 [ 53.851029] [] ? arch_cpu_idle+0x26/0x30 [ 53.851054] [] ? cpu_startup_entry+0x65/0x240 [ 53.851082] [] ? rest_init+0xb5/0xc0 [ 53.851108] [] ? __read_lock_failed+0x18/0x18 [ 53.851138] [] ? start_kernel+0x31b/0x321 [ 53.851164] [] ? repair_env_string+0x51/0x51 [ 53.851190] [] ? 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 Reviewed-by: Chuanxiao Dong Acked-by: Dong Aisheng Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: sdhci: add quirk for broken HS200 support

2014-02-06T19:34:08Z

commit 13868bf20f2f2c305f96e23620b024e167d6f9cb upstream. This patch defines a quirk for platforms unable to enable HS200 support. Signed-off-by: David Cohen Reviewed-by: Chuanxiao Dong Acked-by: Dong Aisheng Signed-off-by: Chris Ball Signed-off-by: Greg Kroah-Hartman

mmc: omap: Fix I2C dependency and make driver usable with device tree

2013-11-26T23:51:16Z

Some features can be configured by the companion I2C chips, which may not be available at the probe time. Fix the issue by returning -EPROBE_DEFER when the MMC controller slots are not configured. While at it, let's also add minimal device tree support so omap24xx platforms can use this driver without legacy mode since we claim to support device tree for mach-omap2 based systems. Although adding the minimal device tree support is not strictly a fix, it does remove one of the last blockers for dropping a bunch of legacy platform data for mach-omap2. Cc: linux-mmc@vger.kernel.org Acked-by: Chris Ball Signed-off-by: Tony Lindgren

mmc: omap: Fix DMA configuration to not rely on device id

2013-11-26T23:50:33Z

We are wrongly relying on device id for the DMA configuration which can lead to wrong DMA channel being selected. Fix the issue by using the standard resources like we should. Cc: linux-mmc@vger.kernel.org Acked-by: Chris Ball Signed-off-by: Tony Lindgren

Merge tag 'mmc-updates-for-3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc

2013-11-18T22:47:30Z

Pull MMC updates from Chris Ball: "MMC highlights for 3.13: Core: - Improve runtime PM support, remove mmc_{suspend,resume}_host(). - Add MMC_CAP_RUNTIME_RESUME, for delaying MMC resume until we're outside of the resume sequence (in runtime_resume) to decrease system resume time. Drivers: - dw_mmc: Support HS200 mode. - sdhci-eshdc-imx: Support SD3.0 SDR clock tuning, DDR on IMX6. - sdhci-pci: Add support for Intel Clovertrail and Merrifield" * tag 'mmc-updates-for-3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc: (108 commits) mmc: wbsd: Silence compiler warning mmc: core: Silence compiler warning in __mmc_switch mmc: sh_mmcif: Convert to clk_prepare|unprepare mmc: sh_mmcif: Convert to PM macros when defining dev_pm_ops mmc: dw_mmc: exynos: Revert the sdr_timing assignment mmc: sdhci: Avoid needless loop while handling SDIO interrupts in sdhci_irq mmc: core: Add MMC_CAP_RUNTIME_RESUME to resume at runtime_resume mmc: core: Improve runtime PM support during suspend/resume for sd/mmc mmc: core: Remove redundant mmc_power_up|off at runtime callbacks mmc: Don't force card to active state when entering suspend/shutdown MIPS: db1235: Don't use MMC_CLKGATE mmc: core: Remove deprecated mmc_suspend|resume_host APIs mmc: mmci: Move away from using deprecated APIs mmc: via-sdmmc: Move away from using deprecated APIs mmc: tmio: Move away from using deprecated APIs mmc: sh_mmcif: Move away from using deprecated APIs mmc: sdricoh_cs: Move away from using deprecated APIs mmc: rtsx: Remove redundant suspend and resume callbacks mmc: wbsd: Move away from using deprecated APIs mmc: pxamci: Remove redundant suspend and resume callbacks ...

Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm

2013-11-13T23:51:29Z

Pull ARM updates from Russell King: "Included in this series are: 1. BE8 (modern big endian) changes for ARM from Ben Dooks 2. big.Little support from Nicolas Pitre and Dave Martin 3. support for LPAE systems with all system memory above 4GB 4. Perf updates from Will Deacon 5. Additional prefetching and other performance improvements from Will. 6. Neon-optimised AES implementation fro Ard. 7. A number of smaller fixes scattered around the place. There is a rather horrid merge conflict in tools/perf - I was never notified of the conflict because it originally occurred between Will's tree and other stuff. Consequently I have a resolution which Will forwarded me, which I'll forward on immediately after sending this mail. The other notable thing is I'm expecting some build breakage in the crypto stuff on ARM only with Ard's AES patches. These were merged into a stable git branch which others had already pulled, so there's little I can do about this. The problem is caused because these patches have a dependency on some code in the crypto git tree - I tried requesting a branch I can pull to resolve these, and all I got each time from the crypto people was "we'll revert our patches then" which would only make things worse since I still don't have the dependent patches. I've no idea what's going on there or how to resolve that, and since I can't split these patches from the rest of this pull request, I'm rather stuck with pushing this as-is or reverting Ard's patches. Since it should "come out in the wash" I've left them in - the only build problems they seem to cause at the moment are with randconfigs, and since it's a new feature anyway. However, if by -rc1 the dependencies aren't in, I think it'd be best to revert Ard's patches" I resolved the perf conflict roughly as per the patch sent by Russell, but there may be some differences. Any errors are likely mine. Let's see how the crypto issues work out.. * 'for-linus' of git://git.linaro.org/people/rmk/linux-arm: (110 commits) ARM: 7868/1: arm/arm64: remove atomic_clear_mask() in "include/asm/atomic.h" ARM: 7867/1: include: asm: use 'int' instead of 'unsigned long' for 'oldval' in atomic_cmpxchg(). ARM: 7866/1: include: asm: use 'long long' instead of 'u64' within atomic.h ARM: 7871/1: amba: Extend number of IRQS ARM: 7887/1: Don't smp_cross_call() on UP devices in arch_irq_work_raise() ARM: 7872/1: Support arch_irq_work_raise() via self IPIs ARM: 7880/1: Clear the IT state independent of the Thumb-2 mode ARM: 7878/1: nommu: Implement dummy early_paging_init() ARM: 7876/1: clear Thumb-2 IT state on exception handling ARM: 7874/2: bL_switcher: Remove cpu_hotplug_driver_{lock,unlock}() ARM: footbridge: fix build warnings for netwinder ARM: 7873/1: vfp: clear vfp_current_hw_state for dying cpu ARM: fix misplaced arch_virt_to_idmap() ARM: 7848/1: mcpm: Implement cpu_kill() to synchronise on powerdown ARM: 7847/1: mcpm: Factor out logical-to-physical CPU translation ARM: 7869/1: remove unused XSCALE_PMU Kconfig param ARM: 7864/1: Handle 64-bit memory in case of 32-bit phys_addr_t ARM: 7863/1: Let arm_add_memory() always use 64-bit arguments ARM: 7862/1: pcpu: replace __get_cpu_var_uses ARM: 7861/1: cacheflush: consolidate single-CPU ARMv7 cache disabling code ...

Merge branch 'for-linus-dma-masks' of git://git.linaro.org/people/rmk/linux-arm

2013-11-13T22:55:21Z

Pull DMA mask updates from Russell King: "This series cleans up the handling of DMA masks in a lot of drivers, fixing some bugs as we go. Some of the more serious errors include: - drivers which only set their coherent DMA mask if the attempt to set the streaming mask fails. - drivers which test for a NULL dma mask pointer, and then set the dma mask pointer to a location in their module .data section - which will cause problems if the module is reloaded. To counter these, I have introduced two helper functions: - dma_set_mask_and_coherent() takes care of setting both the streaming and coherent masks at the same time, with the correct error handling as specified by the API. - dma_coerce_mask_and_coherent() which resolves the problem of drivers forcefully setting DMA masks. This is more a marker for future work to further clean these locations up - the code which creates the devices really should be initialising these, but to fix that in one go along with this change could potentially be very disruptive. The last thing this series does is prise away some of Linux's addition to "DMA addresses are physical addresses and RAM always starts at zero". We have ARM LPAE systems where all system memory is above 4GB physical, hence having DMA masks interpreted by (eg) the block layers as describing physical addresses in the range 0..DMAMASK fails on these platforms. Santosh Shilimkar addresses this in this series; the patches were copied to the appropriate people multiple times but were ignored. Fixing this also gets rid of some ARM weirdness in the setup of the max*pfn variables, and brings ARM into line with every other Linux architecture as far as those go" * 'for-linus-dma-masks' of git://git.linaro.org/people/rmk/linux-arm: (52 commits) ARM: 7805/1: mm: change max*pfn to include the physical offset of memory ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for bounce_limit calculations ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations ARM: 7795/1: mm: dma-mapping: Add dma_max_pfn(dev) helper function ARM: 7794/1: block: Rename parameter dma_mask to max_addr for blk_queue_bounce_limit() ARM: DMA-API: better handing of DMA masks for coherent allocations ARM: 7857/1: dma: imx-sdma: setup dma mask DMA-API: firmware/google/gsmi.c: avoid direct access to DMA masks DMA-API: dcdbas: update DMA mask handing DMA-API: dma: edma.c: no need to explicitly initialize DMA masks DMA-API: usb: musb: use platform_device_register_full() to avoid directly messing with dma masks DMA-API: crypto: remove last references to 'static struct device *dev' DMA-API: crypto: fix ixp4xx crypto platform device support DMA-API: others: use dma_set_coherent_mask() DMA-API: staging: use dma_set_coherent_mask() DMA-API: usb: use new dma_coerce_mask_and_coherent() DMA-API: usb: use dma_set_coherent_mask() DMA-API: parport: parport_pc.c: use dma_coerce_mask_and_coherent() DMA-API: net: octeon: use dma_coerce_mask_and_coherent() DMA-API: net: nxp/lpc_eth: use dma_coerce_mask_and_coherent() ...

Merge branches 'fixes', 'mmci' and 'sa11x0' into for-next

2013-11-12T10:59:08Z