Messages in this thread | | | Date | Wed, 2 Sep 2009 00:05:10 +0200 | Subject | Re: [PATCH 1/2] AB3100 regulator support v2 | From | Linus Walleij <> |
| |
2009/9/1 Russell King - ARM Linux <linux@arm.linux.org.uk>: > On Mon, Aug 31, 2009 at 04:16:15PM +0200, Linus Walleij wrote: >> That said, I think the regulator paths are entirely in-kernel and >> under such circumstances that signals from userspace are blocked >> anyway. > > Only if you explicitly block signals will pending signals be ignored > by the foo_interruptible() functions.
Yep and we have some code like that currently. I'm currently contemplating refactoring it the chain down through ab3100-core and the i2c driver here to make sure no _interruptible suffixed operations are used anywhere.
On U300 that is, since we have our own I2C driver we can rid it there.
But generally speaking the AB3100 can be used on top of any i2c adapter and a bunch of them actually use wait_for_completion_interruptible_timeout(); and wait_event_interruptible_timeout(); for example.
One of them being i2c/buses/i2c-imx.c actually, Mark does this mean you actually have the risk of being kill -9:ed in the middle of a regulator operation for the WM drivers, for example
In the general sense perhaps this doesn't happen so much, what we've seen is system shut down, here some code get interrupted by signals, so atleast the shut down path should be protected I guess, I will do that in the U300 board setup pm_poweroff() hook then, which calls down the regulator/ab3100/i2c chain so all that is secured.
Yours, Linus Walleij
| |