diff mbox series

ARM: OMAP2+: omap_device: fix idling of devices during probe

Message ID 20201204095539.31705-1-andreas@kemnade.info
State New
Headers show
Series ARM: OMAP2+: omap_device: fix idling of devices during probe | expand

Commit Message

Andreas Kemnade Dec. 4, 2020, 9:55 a.m. UTC
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(-)

Comments

Doug Anderson Dec. 4, 2020, 3:44 p.m. UTC | #1
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")
Doug Anderson Dec. 4, 2020, 4:42 p.m. UTC | #2
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
Tony Lindgren Dec. 7, 2020, 1:57 p.m. UTC | #3
* 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
Adam Ford Jan. 8, 2021, 7:17 p.m. UTC | #4
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
Andreas Kemnade Jan. 8, 2021, 7:37 p.m. UTC | #5
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
Adam Ford Jan. 9, 2021, 4 p.m. UTC | #6
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
diff mbox series

Patch

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: