* [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
@ 2020-12-04 9:55 Andreas Kemnade
2020-12-04 14:58 ` Ulf Hansson
2020-12-04 15:44 ` Doug Anderson
0 siblings, 2 replies; 9+ messages in thread
From: Andreas Kemnade @ 2020-12-04 9:55 UTC (permalink / raw)
To: tony, ulf.hansson, wsa+renesas, dianders, linux-omap,
linux-arm-kernel, linux-kernel, letux-kernel
Cc: Andreas Kemnade
On the GTA04A5 od->_driver_status was not set to BUS_NOTIFY_BIND_DRIVER
during probe of the second mmc used for wifi. Therefore
omap_device_late_idle idled the device during probing causing oopses when
accessing the registers.
It was not set because od->_state was set to OMAP_DEVICE_STATE_IDLE
in the notifier callback. Therefore set od->_driver_status also in that
case.
This came apparent after
commit 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
causing this oops:
[ 3.179534] omap_hsmmc 480b4000.mmc: omap_device_late_idle: enabled but no driver. Idling
[ 3.265594] 8<--- cut here ---
[ 3.268707] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0b402c
[ 3.276397] pgd = (ptrval)
[ 3.279144] [fa0b402c] *pgd=48011452(bad)
[ 3.283203] Internal error: : 1028 [#1] SMP ARM
[ 3.287750] Modules linked in:
[ 3.290832] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.10.0-rc6 #3
[ 3.297393] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[ 3.303710] Workqueue: events_unbound async_run_entry_fn
[ 3.309082] PC is at omap_hsmmc_set_bus_width+0x8/0x78
[ 3.314239] LR is at omap_hsmmc_set_ios+0x11c/0x258
[ 3.319152] pc : [<c079787c>] lr : [<c07996bc>] psr: 20000013
[ 3.325469] sp : c10f9e00 ip : c175c800 fp : 00000066
[ 3.330718] r10: c175cb80 r9 : fa0b4000 r8 : 00000000
[ 3.335968] r7 : c123e010 r6 : c175ca58 r5 : c175cb80 r4 : c175c800
[ 3.342529] r3 : 00000001 r2 : 58ad940c r1 : fa0b4000 r0 : c175cb80
[ 3.349090] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 3.356262] Control: 10c5387d Table: 80004019 DAC: 00000051
[ 3.362030] Process kworker/u2:0 (pid: 7, stack limit = 0x(ptrval))
[ 3.368347] Stack: (0xc10f9e00 to 0xc10fa000)
[ 3.372741] 9e00: c175c800 00000007 c123e000 c123e010 00000000 c077b2b0 c175c800 00000000
[ 3.380950] 9e20: c123e000 c077c14c c175c800 c077d284 c175c800 c175c800 c123e000 c0799190
[ 3.389190] 9e40: 00000000 c1755040 c175cb80 00000000 c123fd68 58ad940c 00000001 c123e010
[ 3.397430] 9e60: 00000000 c0edaec8 00000000 00000000 c0edaec8 00000006 ffffe000 c0666728
[ 3.405639] 9e80: c123e010 c0f38c28 c0f38c30 00000000 00000000 c066457c c123e010 c0edaec8
[ 3.413879] 9ea0: c06649bc c0e051c8 00000000 00000000 c0efa4a0 c06648b8 00000000 c10f9ef4
[ 3.422119] 9ec0: c06649bc c066298c 00000000 c1039e6c c1653738 58ad940c c123e010 c123e010
[ 3.430328] 9ee0: c0e051c8 c123e054 c100f000 c0663e60 c0e03d00 c123e010 00010101 58ad940c
[ 3.438568] 9f00: c12642d0 c0f02018 c12642c0 c015da48 c12642d0 c10bbf00 c1009400 c100f000
[ 3.446807] 9f20: 00000000 c0153b74 c10bc800 c1009400 00000088 c10bbf00 c10bbf14 c1009400
[ 3.455017] 9f40: 00000088 c1009418 c0e03d00 c1009400 ffffe000 c0153eec ffffe000 00000000
[ 3.463256] 9f60: c10bbf00 00000000 c10b1ac0 c10b1c40 c10f8000 c0153ec0 c10bbf00 c10ebe94
[ 3.471466] 9f80: c10b1ae4 c015a9ac 00000001 c10b1c40 c015a87c 00000000 00000000 00000000
[ 3.479705] 9fa0: 00000000 00000000 00000000 c0100168 00000000 00000000 00000000 00000000
[ 3.487945] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3.496154] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 3.504394] [<c079787c>] (omap_hsmmc_set_bus_width) from [<c07996bc>] (omap_hsmmc_set_ios+0x11c/0x258)
[ 3.513763] [<c07996bc>] (omap_hsmmc_set_ios) from [<c077b2b0>] (mmc_power_up.part.8+0x3c/0xd0)
[ 3.522521] [<c077b2b0>] (mmc_power_up.part.8) from [<c077c14c>] (mmc_start_host+0x88/0x9c)
[ 3.530944] [<c077c14c>] (mmc_start_host) from [<c077d284>] (mmc_add_host+0x58/0x84)
[ 3.538726] [<c077d284>] (mmc_add_host) from [<c0799190>] (omap_hsmmc_probe+0x5fc/0x8c0)
[ 3.546874] [<c0799190>] (omap_hsmmc_probe) from [<c0666728>] (platform_drv_probe+0x48/0x98)
[ 3.555358] [<c0666728>] (platform_drv_probe) from [<c066457c>] (really_probe+0x1dc/0x3b4)
[ 3.563690] [<c066457c>] (really_probe) from [<c06648b8>] (driver_probe_device+0x58/0xb4)
[ 3.571929] [<c06648b8>] (driver_probe_device) from [<c066298c>] (bus_for_each_drv+0x7c/0xc4)
[ 3.580505] [<c066298c>] (bus_for_each_drv) from [<c0663e60>] (__device_attach_async_helper+0xa4/0xd8)
[ 3.589874] [<c0663e60>] (__device_attach_async_helper) from [<c015da48>] (async_run_entry_fn+0x3c/0x1)
[ 3.599487] [<c015da48>] (async_run_entry_fn) from [<c0153b74>] (process_one_work+0x228/0x574)
[ 3.608154] [<c0153b74>] (process_one_work) from [<c0153eec>] (worker_thread+0x2c/0x5d0)
[ 3.616302] [<c0153eec>] (worker_thread) from [<c015a9ac>] (kthread+0x130/0x144)
[ 3.623748] [<c015a9ac>] (kthread) from [<c0100168>] (ret_from_fork+0x14/0x2c)
Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
---
arch/arm/mach-omap2/omap_device.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index fc7bb2ca1672..13adf88d472b 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -230,10 +230,12 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
break;
case BUS_NOTIFY_BIND_DRIVER:
od = to_omap_device(pdev);
- if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED) &&
- pm_runtime_status_suspended(dev)) {
+ if (od) {
od->_driver_status = BUS_NOTIFY_BIND_DRIVER;
- pm_runtime_set_active(dev);
+ if ((od->_state == OMAP_DEVICE_STATE_ENABLED) &&
+ pm_runtime_status_suspended(dev)) {
+ pm_runtime_set_active(dev);
+ }
}
break;
case BUS_NOTIFY_ADD_DEVICE:
--
2.20.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
2020-12-04 9:55 [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe Andreas Kemnade
@ 2020-12-04 14:58 ` Ulf Hansson
2020-12-04 15:44 ` Doug Anderson
1 sibling, 0 replies; 9+ messages in thread
From: Ulf Hansson @ 2020-12-04 14:58 UTC (permalink / raw)
To: Andreas Kemnade
Cc: Tony Lindgren, Wolfram Sang, Doug Anderson, linux-omap,
Linux ARM, Linux Kernel Mailing List,
Discussions about the Letux Kernel
On Fri, 4 Dec 2020 at 10:55, Andreas Kemnade <andreas@kemnade.info> wrote:
>
> On the GTA04A5 od->_driver_status was not set to BUS_NOTIFY_BIND_DRIVER
> during probe of the second mmc used for wifi. Therefore
> omap_device_late_idle idled the device during probing causing oopses when
> accessing the registers.
>
> It was not set because od->_state was set to OMAP_DEVICE_STATE_IDLE
> in the notifier callback. Therefore set od->_driver_status also in that
> case.
>
> This came apparent after
> commit 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
> causing this oops:
>
> [ 3.179534] omap_hsmmc 480b4000.mmc: omap_device_late_idle: enabled but no driver. Idling
> [ 3.265594] 8<--- cut here ---
> [ 3.268707] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0b402c
> [ 3.276397] pgd = (ptrval)
> [ 3.279144] [fa0b402c] *pgd=48011452(bad)
> [ 3.283203] Internal error: : 1028 [#1] SMP ARM
> [ 3.287750] Modules linked in:
> [ 3.290832] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.10.0-rc6 #3
> [ 3.297393] Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [ 3.303710] Workqueue: events_unbound async_run_entry_fn
> [ 3.309082] PC is at omap_hsmmc_set_bus_width+0x8/0x78
> [ 3.314239] LR is at omap_hsmmc_set_ios+0x11c/0x258
> [ 3.319152] pc : [<c079787c>] lr : [<c07996bc>] psr: 20000013
> [ 3.325469] sp : c10f9e00 ip : c175c800 fp : 00000066
> [ 3.330718] r10: c175cb80 r9 : fa0b4000 r8 : 00000000
> [ 3.335968] r7 : c123e010 r6 : c175ca58 r5 : c175cb80 r4 : c175c800
> [ 3.342529] r3 : 00000001 r2 : 58ad940c r1 : fa0b4000 r0 : c175cb80
> [ 3.349090] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> [ 3.356262] Control: 10c5387d Table: 80004019 DAC: 00000051
> [ 3.362030] Process kworker/u2:0 (pid: 7, stack limit = 0x(ptrval))
> [ 3.368347] Stack: (0xc10f9e00 to 0xc10fa000)
> [ 3.372741] 9e00: c175c800 00000007 c123e000 c123e010 00000000 c077b2b0 c175c800 00000000
> [ 3.380950] 9e20: c123e000 c077c14c c175c800 c077d284 c175c800 c175c800 c123e000 c0799190
> [ 3.389190] 9e40: 00000000 c1755040 c175cb80 00000000 c123fd68 58ad940c 00000001 c123e010
> [ 3.397430] 9e60: 00000000 c0edaec8 00000000 00000000 c0edaec8 00000006 ffffe000 c0666728
> [ 3.405639] 9e80: c123e010 c0f38c28 c0f38c30 00000000 00000000 c066457c c123e010 c0edaec8
> [ 3.413879] 9ea0: c06649bc c0e051c8 00000000 00000000 c0efa4a0 c06648b8 00000000 c10f9ef4
> [ 3.422119] 9ec0: c06649bc c066298c 00000000 c1039e6c c1653738 58ad940c c123e010 c123e010
> [ 3.430328] 9ee0: c0e051c8 c123e054 c100f000 c0663e60 c0e03d00 c123e010 00010101 58ad940c
> [ 3.438568] 9f00: c12642d0 c0f02018 c12642c0 c015da48 c12642d0 c10bbf00 c1009400 c100f000
> [ 3.446807] 9f20: 00000000 c0153b74 c10bc800 c1009400 00000088 c10bbf00 c10bbf14 c1009400
> [ 3.455017] 9f40: 00000088 c1009418 c0e03d00 c1009400 ffffe000 c0153eec ffffe000 00000000
> [ 3.463256] 9f60: c10bbf00 00000000 c10b1ac0 c10b1c40 c10f8000 c0153ec0 c10bbf00 c10ebe94
> [ 3.471466] 9f80: c10b1ae4 c015a9ac 00000001 c10b1c40 c015a87c 00000000 00000000 00000000
> [ 3.479705] 9fa0: 00000000 00000000 00000000 c0100168 00000000 00000000 00000000 00000000
> [ 3.487945] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 3.496154] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [ 3.504394] [<c079787c>] (omap_hsmmc_set_bus_width) from [<c07996bc>] (omap_hsmmc_set_ios+0x11c/0x258)
> [ 3.513763] [<c07996bc>] (omap_hsmmc_set_ios) from [<c077b2b0>] (mmc_power_up.part.8+0x3c/0xd0)
> [ 3.522521] [<c077b2b0>] (mmc_power_up.part.8) from [<c077c14c>] (mmc_start_host+0x88/0x9c)
> [ 3.530944] [<c077c14c>] (mmc_start_host) from [<c077d284>] (mmc_add_host+0x58/0x84)
> [ 3.538726] [<c077d284>] (mmc_add_host) from [<c0799190>] (omap_hsmmc_probe+0x5fc/0x8c0)
> [ 3.546874] [<c0799190>] (omap_hsmmc_probe) from [<c0666728>] (platform_drv_probe+0x48/0x98)
> [ 3.555358] [<c0666728>] (platform_drv_probe) from [<c066457c>] (really_probe+0x1dc/0x3b4)
> [ 3.563690] [<c066457c>] (really_probe) from [<c06648b8>] (driver_probe_device+0x58/0xb4)
> [ 3.571929] [<c06648b8>] (driver_probe_device) from [<c066298c>] (bus_for_each_drv+0x7c/0xc4)
> [ 3.580505] [<c066298c>] (bus_for_each_drv) from [<c0663e60>] (__device_attach_async_helper+0xa4/0xd8)
> [ 3.589874] [<c0663e60>] (__device_attach_async_helper) from [<c015da48>] (async_run_entry_fn+0x3c/0x1)
> [ 3.599487] [<c015da48>] (async_run_entry_fn) from [<c0153b74>] (process_one_work+0x228/0x574)
> [ 3.608154] [<c0153b74>] (process_one_work) from [<c0153eec>] (worker_thread+0x2c/0x5d0)
> [ 3.616302] [<c0153eec>] (worker_thread) from [<c015a9ac>] (kthread+0x130/0x144)
> [ 3.623748] [<c015a9ac>] (kthread) from [<c0100168>] (ret_from_fork+0x14/0x2c)
>
> Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Sounds like you found a quite nasty bug, which I guess has existed all
time - but was triggered easily with the async probe thingy, right?
In any case, thanks for helping out and fixing the regression!
FWIW:
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
> ---
> arch/arm/mach-omap2/omap_device.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
> index fc7bb2ca1672..13adf88d472b 100644
> --- a/arch/arm/mach-omap2/omap_device.c
> +++ b/arch/arm/mach-omap2/omap_device.c
> @@ -230,10 +230,12 @@ static int _omap_device_notifier_call(struct notifier_block *nb,
> break;
> case BUS_NOTIFY_BIND_DRIVER:
> od = to_omap_device(pdev);
> - if (od && (od->_state == OMAP_DEVICE_STATE_ENABLED) &&
> - pm_runtime_status_suspended(dev)) {
> + if (od) {
> od->_driver_status = BUS_NOTIFY_BIND_DRIVER;
> - pm_runtime_set_active(dev);
> + if ((od->_state == OMAP_DEVICE_STATE_ENABLED) &&
> + pm_runtime_status_suspended(dev)) {
> + pm_runtime_set_active(dev);
> + }
> }
> break;
> case BUS_NOTIFY_ADD_DEVICE:
> --
> 2.20.1
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
2020-12-04 9:55 [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe Andreas Kemnade
2020-12-04 14:58 ` Ulf Hansson
@ 2020-12-04 15:44 ` Doug Anderson
2020-12-04 16:14 ` Andreas Kemnade
1 sibling, 1 reply; 9+ messages in thread
From: Doug Anderson @ 2020-12-04 15:44 UTC (permalink / raw)
To: Andreas Kemnade
Cc: Tony Lindgren, Ulf Hansson, Wolfram Sang, linux-omap, Linux ARM,
LKML, Discussions about the Letux Kernel
Hi,
On Fri, Dec 4, 2020 at 1:55 AM Andreas Kemnade <andreas@kemnade.info> wrote:
>
> On the GTA04A5 od->_driver_status was not set to BUS_NOTIFY_BIND_DRIVER
> during probe of the second mmc used for wifi. Therefore
> omap_device_late_idle idled the device during probing causing oopses when
> accessing the registers.
>
> It was not set because od->_state was set to OMAP_DEVICE_STATE_IDLE
> in the notifier callback. Therefore set od->_driver_status also in that
> case.
>
> This came apparent after
> commit 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
> causing this oops:
>
> [ 3.179534] omap_hsmmc 480b4000.mmc: omap_device_late_idle: enabled but no driver. Idling
> [ 3.265594] 8<--- cut here ---
> [ 3.268707] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0b402c
> [ 3.276397] pgd = (ptrval)
> [ 3.279144] [fa0b402c] *pgd=48011452(bad)
> [ 3.283203] Internal error: : 1028 [#1] SMP ARM
> [ 3.287750] Modules linked in:
> [ 3.290832] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.10.0-rc6 #3
> [ 3.297393] Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [ 3.303710] Workqueue: events_unbound async_run_entry_fn
> [ 3.309082] PC is at omap_hsmmc_set_bus_width+0x8/0x78
> [ 3.314239] LR is at omap_hsmmc_set_ios+0x11c/0x258
> [ 3.319152] pc : [<c079787c>] lr : [<c07996bc>] psr: 20000013
> [ 3.325469] sp : c10f9e00 ip : c175c800 fp : 00000066
> [ 3.330718] r10: c175cb80 r9 : fa0b4000 r8 : 00000000
> [ 3.335968] r7 : c123e010 r6 : c175ca58 r5 : c175cb80 r4 : c175c800
> [ 3.342529] r3 : 00000001 r2 : 58ad940c r1 : fa0b4000 r0 : c175cb80
> [ 3.349090] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> [ 3.356262] Control: 10c5387d Table: 80004019 DAC: 00000051
> [ 3.362030] Process kworker/u2:0 (pid: 7, stack limit = 0x(ptrval))
> [ 3.368347] Stack: (0xc10f9e00 to 0xc10fa000)
> [ 3.372741] 9e00: c175c800 00000007 c123e000 c123e010 00000000 c077b2b0 c175c800 00000000
> [ 3.380950] 9e20: c123e000 c077c14c c175c800 c077d284 c175c800 c175c800 c123e000 c0799190
> [ 3.389190] 9e40: 00000000 c1755040 c175cb80 00000000 c123fd68 58ad940c 00000001 c123e010
> [ 3.397430] 9e60: 00000000 c0edaec8 00000000 00000000 c0edaec8 00000006 ffffe000 c0666728
> [ 3.405639] 9e80: c123e010 c0f38c28 c0f38c30 00000000 00000000 c066457c c123e010 c0edaec8
> [ 3.413879] 9ea0: c06649bc c0e051c8 00000000 00000000 c0efa4a0 c06648b8 00000000 c10f9ef4
> [ 3.422119] 9ec0: c06649bc c066298c 00000000 c1039e6c c1653738 58ad940c c123e010 c123e010
> [ 3.430328] 9ee0: c0e051c8 c123e054 c100f000 c0663e60 c0e03d00 c123e010 00010101 58ad940c
> [ 3.438568] 9f00: c12642d0 c0f02018 c12642c0 c015da48 c12642d0 c10bbf00 c1009400 c100f000
> [ 3.446807] 9f20: 00000000 c0153b74 c10bc800 c1009400 00000088 c10bbf00 c10bbf14 c1009400
> [ 3.455017] 9f40: 00000088 c1009418 c0e03d00 c1009400 ffffe000 c0153eec ffffe000 00000000
> [ 3.463256] 9f60: c10bbf00 00000000 c10b1ac0 c10b1c40 c10f8000 c0153ec0 c10bbf00 c10ebe94
> [ 3.471466] 9f80: c10b1ae4 c015a9ac 00000001 c10b1c40 c015a87c 00000000 00000000 00000000
> [ 3.479705] 9fa0: 00000000 00000000 00000000 c0100168 00000000 00000000 00000000 00000000
> [ 3.487945] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 3.496154] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [ 3.504394] [<c079787c>] (omap_hsmmc_set_bus_width) from [<c07996bc>] (omap_hsmmc_set_ios+0x11c/0x258)
> [ 3.513763] [<c07996bc>] (omap_hsmmc_set_ios) from [<c077b2b0>] (mmc_power_up.part.8+0x3c/0xd0)
> [ 3.522521] [<c077b2b0>] (mmc_power_up.part.8) from [<c077c14c>] (mmc_start_host+0x88/0x9c)
> [ 3.530944] [<c077c14c>] (mmc_start_host) from [<c077d284>] (mmc_add_host+0x58/0x84)
> [ 3.538726] [<c077d284>] (mmc_add_host) from [<c0799190>] (omap_hsmmc_probe+0x5fc/0x8c0)
> [ 3.546874] [<c0799190>] (omap_hsmmc_probe) from [<c0666728>] (platform_drv_probe+0x48/0x98)
> [ 3.555358] [<c0666728>] (platform_drv_probe) from [<c066457c>] (really_probe+0x1dc/0x3b4)
> [ 3.563690] [<c066457c>] (really_probe) from [<c06648b8>] (driver_probe_device+0x58/0xb4)
> [ 3.571929] [<c06648b8>] (driver_probe_device) from [<c066298c>] (bus_for_each_drv+0x7c/0xc4)
> [ 3.580505] [<c066298c>] (bus_for_each_drv) from [<c0663e60>] (__device_attach_async_helper+0xa4/0xd8)
> [ 3.589874] [<c0663e60>] (__device_attach_async_helper) from [<c015da48>] (async_run_entry_fn+0x3c/0x1)
> [ 3.599487] [<c015da48>] (async_run_entry_fn) from [<c0153b74>] (process_one_work+0x228/0x574)
> [ 3.608154] [<c0153b74>] (process_one_work) from [<c0153eec>] (worker_thread+0x2c/0x5d0)
> [ 3.616302] [<c0153eec>] (worker_thread) from [<c015a9ac>] (kthread+0x130/0x144)
> [ 3.623748] [<c015a9ac>] (kthread) from [<c0100168>] (ret_from_fork+0x14/0x2c)
>
> Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
From the description it sounds like this problem has always existed
but the async probe just tickled it reliably. Seems like it'd make
sense to tag the "Fixes" as some earlier commit so you make sure your
fix gets picked to kernels even if they don't have the async probe
patch?
In any case, thank you very much for tracking this down!
-Doug
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
2020-12-04 15:44 ` Doug Anderson
@ 2020-12-04 16:14 ` Andreas Kemnade
2020-12-04 16:42 ` Doug Anderson
0 siblings, 1 reply; 9+ messages in thread
From: Andreas Kemnade @ 2020-12-04 16:14 UTC (permalink / raw)
To: Doug Anderson
Cc: Tony Lindgren, Ulf Hansson, Wolfram Sang, linux-omap, Linux ARM,
LKML, Discussions about the Letux Kernel
On Fri, 4 Dec 2020 07:44:33 -0800
Doug Anderson <dianders@chromium.org> wrote:
> Hi,
>
> On Fri, Dec 4, 2020 at 1:55 AM Andreas Kemnade <andreas@kemnade.info> wrote:
> >
> > On the GTA04A5 od->_driver_status was not set to BUS_NOTIFY_BIND_DRIVER
> > during probe of the second mmc used for wifi. Therefore
> > omap_device_late_idle idled the device during probing causing oopses when
> > accessing the registers.
> >
> > It was not set because od->_state was set to OMAP_DEVICE_STATE_IDLE
> > in the notifier callback. Therefore set od->_driver_status also in that
> > case.
> >
> > This came apparent after
> > commit 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
> > causing this oops:
> >
> > [ 3.179534] omap_hsmmc 480b4000.mmc: omap_device_late_idle: enabled but no driver. Idling
> > [ 3.265594] 8<--- cut here ---
> > [ 3.268707] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0b402c
> > [ 3.276397] pgd = (ptrval)
> > [ 3.279144] [fa0b402c] *pgd=48011452(bad)
> > [ 3.283203] Internal error: : 1028 [#1] SMP ARM
> > [ 3.287750] Modules linked in:
> > [ 3.290832] CPU: 0 PID: 7 Comm: kworker/u2:0 Not tainted 5.10.0-rc6 #3
> > [ 3.297393] Hardware name: Generic OMAP36xx (Flattened Device Tree)
> > [ 3.303710] Workqueue: events_unbound async_run_entry_fn
> > [ 3.309082] PC is at omap_hsmmc_set_bus_width+0x8/0x78
> > [ 3.314239] LR is at omap_hsmmc_set_ios+0x11c/0x258
> > [ 3.319152] pc : [<c079787c>] lr : [<c07996bc>] psr: 20000013
> > [ 3.325469] sp : c10f9e00 ip : c175c800 fp : 00000066
> > [ 3.330718] r10: c175cb80 r9 : fa0b4000 r8 : 00000000
> > [ 3.335968] r7 : c123e010 r6 : c175ca58 r5 : c175cb80 r4 : c175c800
> > [ 3.342529] r3 : 00000001 r2 : 58ad940c r1 : fa0b4000 r0 : c175cb80
> > [ 3.349090] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> > [ 3.356262] Control: 10c5387d Table: 80004019 DAC: 00000051
> > [ 3.362030] Process kworker/u2:0 (pid: 7, stack limit = 0x(ptrval))
> > [ 3.368347] Stack: (0xc10f9e00 to 0xc10fa000)
> > [ 3.372741] 9e00: c175c800 00000007 c123e000 c123e010 00000000 c077b2b0 c175c800 00000000
> > [ 3.380950] 9e20: c123e000 c077c14c c175c800 c077d284 c175c800 c175c800 c123e000 c0799190
> > [ 3.389190] 9e40: 00000000 c1755040 c175cb80 00000000 c123fd68 58ad940c 00000001 c123e010
> > [ 3.397430] 9e60: 00000000 c0edaec8 00000000 00000000 c0edaec8 00000006 ffffe000 c0666728
> > [ 3.405639] 9e80: c123e010 c0f38c28 c0f38c30 00000000 00000000 c066457c c123e010 c0edaec8
> > [ 3.413879] 9ea0: c06649bc c0e051c8 00000000 00000000 c0efa4a0 c06648b8 00000000 c10f9ef4
> > [ 3.422119] 9ec0: c06649bc c066298c 00000000 c1039e6c c1653738 58ad940c c123e010 c123e010
> > [ 3.430328] 9ee0: c0e051c8 c123e054 c100f000 c0663e60 c0e03d00 c123e010 00010101 58ad940c
> > [ 3.438568] 9f00: c12642d0 c0f02018 c12642c0 c015da48 c12642d0 c10bbf00 c1009400 c100f000
> > [ 3.446807] 9f20: 00000000 c0153b74 c10bc800 c1009400 00000088 c10bbf00 c10bbf14 c1009400
> > [ 3.455017] 9f40: 00000088 c1009418 c0e03d00 c1009400 ffffe000 c0153eec ffffe000 00000000
> > [ 3.463256] 9f60: c10bbf00 00000000 c10b1ac0 c10b1c40 c10f8000 c0153ec0 c10bbf00 c10ebe94
> > [ 3.471466] 9f80: c10b1ae4 c015a9ac 00000001 c10b1c40 c015a87c 00000000 00000000 00000000
> > [ 3.479705] 9fa0: 00000000 00000000 00000000 c0100168 00000000 00000000 00000000 00000000
> > [ 3.487945] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> > [ 3.496154] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> > [ 3.504394] [<c079787c>] (omap_hsmmc_set_bus_width) from [<c07996bc>] (omap_hsmmc_set_ios+0x11c/0x258)
> > [ 3.513763] [<c07996bc>] (omap_hsmmc_set_ios) from [<c077b2b0>] (mmc_power_up.part.8+0x3c/0xd0)
> > [ 3.522521] [<c077b2b0>] (mmc_power_up.part.8) from [<c077c14c>] (mmc_start_host+0x88/0x9c)
> > [ 3.530944] [<c077c14c>] (mmc_start_host) from [<c077d284>] (mmc_add_host+0x58/0x84)
> > [ 3.538726] [<c077d284>] (mmc_add_host) from [<c0799190>] (omap_hsmmc_probe+0x5fc/0x8c0)
> > [ 3.546874] [<c0799190>] (omap_hsmmc_probe) from [<c0666728>] (platform_drv_probe+0x48/0x98)
> > [ 3.555358] [<c0666728>] (platform_drv_probe) from [<c066457c>] (really_probe+0x1dc/0x3b4)
> > [ 3.563690] [<c066457c>] (really_probe) from [<c06648b8>] (driver_probe_device+0x58/0xb4)
> > [ 3.571929] [<c06648b8>] (driver_probe_device) from [<c066298c>] (bus_for_each_drv+0x7c/0xc4)
> > [ 3.580505] [<c066298c>] (bus_for_each_drv) from [<c0663e60>] (__device_attach_async_helper+0xa4/0xd8)
> > [ 3.589874] [<c0663e60>] (__device_attach_async_helper) from [<c015da48>] (async_run_entry_fn+0x3c/0x1)
> > [ 3.599487] [<c015da48>] (async_run_entry_fn) from [<c0153b74>] (process_one_work+0x228/0x574)
> > [ 3.608154] [<c0153b74>] (process_one_work) from [<c0153eec>] (worker_thread+0x2c/0x5d0)
> > [ 3.616302] [<c0153eec>] (worker_thread) from [<c015a9ac>] (kthread+0x130/0x144)
> > [ 3.623748] [<c015a9ac>] (kthread) from [<c0100168>] (ret_from_fork+0x14/0x2c)
> >
> > Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
>
> From the description it sounds like this problem has always existed
> but the async probe just tickled it reliably. Seems like it'd make
> sense to tag the "Fixes" as some earlier commit so you make sure your
> fix gets picked to kernels even if they don't have the async probe
> patch?
>
Hmm, maybe
Fixes: 04abaf07f6d5 ("ARM: OMAP2+: omap_device: Sync omap_device and
pm_runtime after probe defer")
But on the other hand to stable branches only such patches are applied
which solve pratical problems not only theoretical problems. But maybe
it solves several random issues where nobody took care to debug them.
That would be since v4.11.
Regards
Andreas
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
2020-12-04 16:14 ` Andreas Kemnade
@ 2020-12-04 16:42 ` Doug Anderson
2020-12-07 13:57 ` Tony Lindgren
0 siblings, 1 reply; 9+ messages in thread
From: Doug Anderson @ 2020-12-04 16:42 UTC (permalink / raw)
To: Andreas Kemnade
Cc: Tony Lindgren, Ulf Hansson, Wolfram Sang, linux-omap, Linux ARM,
LKML, Discussions about the Letux Kernel
Hi,
On Fri, Dec 4, 2020 at 8:14 AM Andreas Kemnade <andreas@kemnade.info> wrote:
>
> > > Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
> >
> > From the description it sounds like this problem has always existed
> > but the async probe just tickled it reliably. Seems like it'd make
> > sense to tag the "Fixes" as some earlier commit so you make sure your
> > fix gets picked to kernels even if they don't have the async probe
> > patch?
> >
>
> Hmm, maybe
> Fixes: 04abaf07f6d5 ("ARM: OMAP2+: omap_device: Sync omap_device and
> pm_runtime after probe defer")
>
> But on the other hand to stable branches only such patches are applied
> which solve pratical problems not only theoretical problems. But maybe
> it solves several random issues where nobody took care to debug them.
>
> That would be since v4.11.
I guess maybe best is to include both. Then if someone is debugging
why their async probe is failing they will notice this commit, but
they also might decide to pick it earlier just to be safe...
-Doug
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
2020-12-04 16:42 ` Doug Anderson
@ 2020-12-07 13:57 ` Tony Lindgren
2021-01-08 19:17 ` Adam Ford
0 siblings, 1 reply; 9+ messages in thread
From: Tony Lindgren @ 2020-12-07 13:57 UTC (permalink / raw)
To: Doug Anderson
Cc: Andreas Kemnade, Ulf Hansson, Wolfram Sang, linux-omap,
Linux ARM, LKML, Discussions about the Letux Kernel
* Doug Anderson <dianders@chromium.org> [201204 16:43]:
> Hi,
>
> On Fri, Dec 4, 2020 at 8:14 AM Andreas Kemnade <andreas@kemnade.info> wrote:
> >
> > > > Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
> > >
> > > From the description it sounds like this problem has always existed
> > > but the async probe just tickled it reliably. Seems like it'd make
> > > sense to tag the "Fixes" as some earlier commit so you make sure your
> > > fix gets picked to kernels even if they don't have the async probe
> > > patch?
> > >
> >
> > Hmm, maybe
> > Fixes: 04abaf07f6d5 ("ARM: OMAP2+: omap_device: Sync omap_device and
> > pm_runtime after probe defer")
> >
> > But on the other hand to stable branches only such patches are applied
> > which solve pratical problems not only theoretical problems. But maybe
> > it solves several random issues where nobody took care to debug them.
> >
> > That would be since v4.11.
>
> I guess maybe best is to include both. Then if someone is debugging
> why their async probe is failing they will notice this commit, but
> they also might decide to pick it earlier just to be safe...
OK I'll add the above fixes tag too and apply this into fixes.
Thanks,
Tony
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
2020-12-07 13:57 ` Tony Lindgren
@ 2021-01-08 19:17 ` Adam Ford
2021-01-08 19:37 ` Andreas Kemnade
0 siblings, 1 reply; 9+ messages in thread
From: Adam Ford @ 2021-01-08 19:17 UTC (permalink / raw)
To: Tony Lindgren
Cc: Doug Anderson, Andreas Kemnade, Ulf Hansson, Wolfram Sang,
linux-omap, Linux ARM, LKML, Discussions about the Letux Kernel
On Mon, Dec 7, 2020 at 8:01 AM Tony Lindgren <tony@atomide.com> wrote:
>
> * Doug Anderson <dianders@chromium.org> [201204 16:43]:
> > Hi,
> >
> > On Fri, Dec 4, 2020 at 8:14 AM Andreas Kemnade <andreas@kemnade.info> wrote:
> > >
> > > > > Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
> > > >
> > > > From the description it sounds like this problem has always existed
> > > > but the async probe just tickled it reliably. Seems like it'd make
> > > > sense to tag the "Fixes" as some earlier commit so you make sure your
> > > > fix gets picked to kernels even if they don't have the async probe
> > > > patch?
> > > >
> > >
> > > Hmm, maybe
> > > Fixes: 04abaf07f6d5 ("ARM: OMAP2+: omap_device: Sync omap_device and
> > > pm_runtime after probe defer")
> > >
> > > But on the other hand to stable branches only such patches are applied
> > > which solve pratical problems not only theoretical problems. But maybe
> > > it solves several random issues where nobody took care to debug them.
> > >
> > > That would be since v4.11.
> >
> > I guess maybe best is to include both. Then if someone is debugging
> > why their async probe is failing they will notice this commit, but
> > they also might decide to pick it earlier just to be safe...
>
> OK I'll add the above fixes tag too and apply this into fixes.
>
It might be too late, but...
Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
> Thanks,
>
> Tony
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
2021-01-08 19:17 ` Adam Ford
@ 2021-01-08 19:37 ` Andreas Kemnade
2021-01-09 16:00 ` Adam Ford
0 siblings, 1 reply; 9+ messages in thread
From: Andreas Kemnade @ 2021-01-08 19:37 UTC (permalink / raw)
To: Adam Ford
Cc: Tony Lindgren, Doug Anderson, Ulf Hansson, Wolfram Sang,
linux-omap, Linux ARM, LKML, Discussions about the Letux Kernel
Hi,
On Fri, 8 Jan 2021 13:17:06 -0600
Adam Ford <aford173@gmail.com> wrote:
> On Mon, Dec 7, 2020 at 8:01 AM Tony Lindgren <tony@atomide.com> wrote:
> >
> > * Doug Anderson <dianders@chromium.org> [201204 16:43]:
> > > Hi,
> > >
> > > On Fri, Dec 4, 2020 at 8:14 AM Andreas Kemnade <andreas@kemnade.info> wrote:
> > > >
> > > > > > Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
> > > > >
> > > > > From the description it sounds like this problem has always existed
> > > > > but the async probe just tickled it reliably. Seems like it'd make
> > > > > sense to tag the "Fixes" as some earlier commit so you make sure your
> > > > > fix gets picked to kernels even if they don't have the async probe
> > > > > patch?
> > > > >
> > > >
> > > > Hmm, maybe
> > > > Fixes: 04abaf07f6d5 ("ARM: OMAP2+: omap_device: Sync omap_device and
> > > > pm_runtime after probe defer")
> > > >
> > > > But on the other hand to stable branches only such patches are applied
> > > > which solve pratical problems not only theoretical problems. But maybe
> > > > it solves several random issues where nobody took care to debug them.
> > > >
> > > > That would be since v4.11.
> > >
> > > I guess maybe best is to include both. Then if someone is debugging
> > > why their async probe is failing they will notice this commit, but
> > > they also might decide to pick it earlier just to be safe...
> >
> > OK I'll add the above fixes tag too and apply this into fixes.
> >
>
> It might be too late, but...
>
> Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
>
hmm, when will it arrive in mainline?
Regards,
Andreas
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe
2021-01-08 19:37 ` Andreas Kemnade
@ 2021-01-09 16:00 ` Adam Ford
0 siblings, 0 replies; 9+ messages in thread
From: Adam Ford @ 2021-01-09 16:00 UTC (permalink / raw)
To: Andreas Kemnade
Cc: Tony Lindgren, Doug Anderson, Ulf Hansson, Wolfram Sang,
linux-omap, Linux ARM, LKML, Discussions about the Letux Kernel
On Fri, Jan 8, 2021 at 1:37 PM Andreas Kemnade <andreas@kemnade.info> wrote:
>
> Hi,
>
> On Fri, 8 Jan 2021 13:17:06 -0600
> Adam Ford <aford173@gmail.com> wrote:
>
> > On Mon, Dec 7, 2020 at 8:01 AM Tony Lindgren <tony@atomide.com> wrote:
> > >
> > > * Doug Anderson <dianders@chromium.org> [201204 16:43]:
> > > > Hi,
> > > >
> > > > On Fri, Dec 4, 2020 at 8:14 AM Andreas Kemnade <andreas@kemnade.info> wrote:
> > > > >
> > > > > > > Fixes: 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4")
> > > > > >
> > > > > > From the description it sounds like this problem has always existed
> > > > > > but the async probe just tickled it reliably. Seems like it'd make
> > > > > > sense to tag the "Fixes" as some earlier commit so you make sure your
> > > > > > fix gets picked to kernels even if they don't have the async probe
> > > > > > patch?
> > > > > >
> > > > >
> > > > > Hmm, maybe
> > > > > Fixes: 04abaf07f6d5 ("ARM: OMAP2+: omap_device: Sync omap_device and
> > > > > pm_runtime after probe defer")
> > > > >
> > > > > But on the other hand to stable branches only such patches are applied
> > > > > which solve pratical problems not only theoretical problems. But maybe
> > > > > it solves several random issues where nobody took care to debug them.
> > > > >
> > > > > That would be since v4.11.
> > > >
> > > > I guess maybe best is to include both. Then if someone is debugging
> > > > why their async probe is failing they will notice this commit, but
> > > > they also might decide to pick it earlier just to be safe...
> > >
> > > OK I'll add the above fixes tag too and apply this into fixes.
> > >
> >
> > It might be too late, but...
> >
> > Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
> >
> hmm, when will it arrive in mainline?
It looks like it's been merged onto Linus Torvalds' branch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95f05058b2bbe3b85c8617b961879e52f692caa5
>
> Regards,
> Andreas
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-01-09 16:01 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-04 9:55 [PATCH] ARM: OMAP2+: omap_device: fix idling of devices during probe Andreas Kemnade
2020-12-04 14:58 ` Ulf Hansson
2020-12-04 15:44 ` Doug Anderson
2020-12-04 16:14 ` Andreas Kemnade
2020-12-04 16:42 ` Doug Anderson
2020-12-07 13:57 ` Tony Lindgren
2021-01-08 19:17 ` Adam Ford
2021-01-08 19:37 ` Andreas Kemnade
2021-01-09 16:00 ` Adam Ford
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).