> > The current code calls device_init_wakeup() before device_register, but
Patch looked OK to me, except for the one comment below.
The root cause of the bug could be blamed on the new-style code
recycling the legacy i2c_attach_client() code instead of taking
a more driver-model-ish approach.
That forced use of device_register(), instead of device_add() ...
and register() always zero-initializes those wakeup flags. On the
other hand, add() just takes their original value. This patch
seems like the most concise fix possible.
I thought I had. The one board I had with a wake-capable I2C
device (i2c/chips/menelaus.c) seems to have an ugly workaround
for the problem this addresses ... I probably just forgot to
remove that workaround, so of course it (still) worked.
(Well, actually I have another now, but its Linux support is
still incomplete, notably power managment. www.beagleboard.org
can't yet run with mainline kernels.)
The goal was to make sure that wakeup flags could be initialized
sanely for I2C devices, with RTCs being the most common example.
It would be wrong to have the drivers setting such flags, since they
can't actually know when their IRQs (or whatever) are wakeup-capable.
That kind of information is specific to how any given board is wired.
It's kind of essential to making this patch work! Else the flag
won't be available when the i2c core gets control of that device
node again, after device_initialize() code zeroes those flags.
Better would be to preserve any existing settings:
if (!device_can_wakeup(&client->dev))
device_init_wakeup(...)
That way the userspace policy setting is preserved unless the
device itself gets removed ... instead of being clobbered by
the simple act of (re)probing a driver.
- Dave
--