Skip to contentSkip to conversation

base/platform: Fix platform drivers with no probe callback (ex alarmtimer)

PATCH In review Martin Fuzzey 3 participants 5 messages Jan 4, 2016 – Jan 5, 2016 Driver core

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 base/platform: Fix platform drivers with no probe callback (ex alarmtimer)

Normally, when a platform driver defines a .probe callback, the result of dev_pm_domain_attach() is ignored unless it is EPROBE_DEFER.

However, when a .probe callback is not defined the result of dev_pm_domain_attach() is propagated to the caller.

But dev_pm_domain_attach() can return -ENODEV for devices with no power domain.

This was causing the alarmtimer .suspend() callback to be ignored and hence alarms not to wake from suspend (since the RTC was not being programmed on suspend).

Fixes b8b2c7d [base/platform: assert that dev_pm_domain callbacks are called unconditionally]
---
 drivers/base/platform.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/base/platform.c +2 -2
index 1dd6d3b..61e5b7e 100644
@@ -513,8 +513,8 @@ static int platform_drv_probe(struct device *_dev)
 		return ret;
 
 	ret = dev_pm_domain_attach(_dev, true);
-	if (ret != -EPROBE_DEFER && drv->probe) {
-		ret = drv->probe(dev);
+	if (ret != -EPROBE_DEFER) {
+		ret = drv->probe ? drv->probe(dev) : 0;
 		if (ret)
 			dev_pm_domain_detach(_dev, true);
 	}
#1 lore raw

Hello,

I think this is the same problem that another Martin found and fixed in

http://mid.gmane.org/[email protected]

I didn't check, but thought Greg already picked that up?!

Best regards
Uwe

Signature · 2 lines
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Tested-by
#2 lore raw
Quoted 7 lines · Uwe Kleine-König

Hello,

I think this is the same problem that another Martin found and fixed in

http://mid.gmane.org/[email protected]

I didn't check, but thought Greg already picked that up?!

I can confirm that applying the patch in that link to 4.4-rc8 fixes the following problem I've seen since 4.4-rc5:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000e20
IP: [<ffffffffa017835e>] asus_sysfs_is_visible+0xe/0x1d0 [asus_laptop]

So:

#3 lore raw
Quoted 9 lines · Tero Roponen
Quoted 6 lines · Uwe Kleine-König

Hello,

I think this is the same problem that another Martin found and fixed in

http://mid.gmane.org/[email protected]

Quoted 7 lines
Quoted 1 line

I didn't check, but thought Greg already picked that up?!

I can confirm that applying the patch in that link to 4.4-rc8 fixes the following problem I've seen since 4.4-rc5:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000e20
IP: [<ffffffffa017835e>] asus_sysfs_is_visible+0xe/0x1d0 [asus_laptop]

This is a separate bug however that is worth fixing, too. I guess this is similar to the tpm problem my broken patch made obvious.

Best regards
Uwe

Signature · 2 lines
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |