On 2018-09-04 16:25, Wolfram Sang wrote: >> There is still the "if (in_atomic() || irqs_disabled())" thing in >> i2c_transfer(), something we did not replicate in the recent >> rework of i2c_smbus_xfer() >> >> Do we not need to do that dance in i2c_smbus_xfer() too and as apart >> of that add ->smbus_xfer_irqless? > > I'd be pragmtic here and only add it when it is needed. Nobody wanted it > so far. It would throw lockdep warnings and irq related OOPSes if > somebody uses SMBus for this. So, I'd expect we would know of a user. > >> My guess was that many things that needs to be done "late" are >> performed as one of the i2c_smbus_read/write... calls, but what do I >> know? Or maybe I'm just too far ahead? > > They are probably SMBus calls but my bet is that they will get emulated > to I2C transfers. SMBus controllers are more common on PC hardware and > above I'd say, and those seem to have so far their custom firmware > methods to shut down. Right, but keep in mind that (normal) emulation will still go through the unconditional locking in i2c_smbus_xfer, so that will also be a source of problems/oopses/splats. > With all that being said, if there is someone who needs it, we can add > it later. Right. I didn't mean to say that there was anything wrong per se, just that irqless support from the I2C core was a bit incomplete. Cheers, Peter
