On June 26, 2018 4:37:58 AM GMT+02:00, Wolfram Sang <[email protected]> wrote: > >> 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!
I don't think it's that easy as I just thought about another problem with lifting the locking from the emulation function. It calls kzalloc(..., GFP_KERNEL), at least in some cases, and that's not a very good idea from atomic/irq context... Cheers, Peter
