I have two questions:
- em28xx_i2c_xfer() in drivers/media/usb/em28xx/em28xx-i2c.c takes a
rt_mutex lock. This struct i2c_algorithm's ->master_xfer callback.
Why does it take an extra lock since it looks to me that it is
protected by struct i2c_adapter's bus_lock already.
- i2c_transfer() has this piece:
2091 if (in_atomic() || irqs_disabled()) {
2092 ret = i2c_trylock_adapter(adap);
is this irqs_disabled() is what bothers me and should not be there.
pxa does a spin_lock_irq() which would enable interrupts on return /
too early.
mxs has a wait_for_completion() which needs irqs enabled _and_ makes
in_atomic() problematic, too. I have't checked other drivers but the
commit, that introduced it, does not explain why it is required.
So _should_ this be invoked from an interrupt handler (for instance),
then it would record the wrong process as the lock owner. This isn't
problematic unless on SMP the owner gets boosted because a process
with a higher priority needs the lock.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
