> This is not perfectly equivalent, since i2c_smbus_xfer was callable from > atomic/irq context if you happened to end up emulating SMBus with an I2C > transfer, and that is no longer the case with this patch. It is unknown > (to me) if anything depends on that quirk, but it seems fragile enough to > simply break those cases and require them to call i2c_transfer directly > instead. Couldn't we just add the same trylock-code path here as well? I always wondered why I2C and SMBus were not in sync when it came to that. Yet, I didn't want to change the code for no reason, but it seems we now have one? Rest of the series looks good to me, very nice diffstat!
