Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> writes: > On Tue, Aug 13, 2013 at 09:42:27PM +0300, Pantelis Antoniou wrote: >> But creation just crashes. >> >> > root@beaglebone:/sys/bus/platform/drivers/omap_i2c# echo 4819c000.i2c >bind >> > [ 145.053929] Unable to handle kernel NULL pointer dereference at virtual address 00000001 >> > [ 145.062651] pgd = ca8c0000 >> > [ 145.065507] [00000001] *pgd=8f437831, *pte=00000000, *ppte=00000000 >> > [ 145.072163] Internal error: Oops: 17 [#1] SMP ARM >> > [ 145.077105] Modules linked in: ipv6 autofs4 >> > [ 145.081537] CPU: 0 PID: 301 Comm: sh Not tainted 3.11.0-rc5-00125-g3b988fb #146 >> > [ 145.089222] task: cf5b5580 ti: cf464000 task.ti: cf464000 >> > [ 145.094918] PC is at omap_i2c_runtime_suspend+0x10/0xb4 >> > [ 145.100408] LR is at omap_i2c_runtime_suspend+0x8/0xb4 > > Well then, what you have here is a bug in the way that OMAP re-uses the > platform device stuff - and that _does_ need fixing somehow. > > The problem is that i2c_dev->regs is NULL at the point where > pm_runtime_set_autosuspend_delay() is called, which as autosuspend > is still set from the time that the device was unbound, it means that > this triggers an immediate suspend. > > I suspect that: > > pm_runtime_set_autosuspend_delay(dev->dev, OMAP_I2C_PM_TIMEOUT); > pm_runtime_use_autosuspend(dev->dev); > > should be moved later in the probe function, after the switch (scheme) > block. That's correct. At a minimum, it should be after the _get_sync() call. Without any users (callers of pm_runtime_get*) the _set_autosuspend_delay() call will try to rpm_idle(). Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
