03.09.2020 19:47, Michał Mirosław пишет: > On Thu, Sep 03, 2020 at 04:12:13AM +0300, Dmitry Osipenko wrote: >> 03.09.2020 00:20, Michał Mirosław пишет: >>> BTW, I wonder if you could expose i2c_in_atomic_xfer_mode() and use it >>> to differentiate atomic_xfer from normal and get rid of the internal >>> flag and .master_xfer_atomic callback. >> >> The atomic transfer uses 90% of the code path that a non-atomic transfer >> uses. I don't see how it could be exposed without duplicated lots of the >> code, unless I'm not missing what you're suggesting. > > The I2C core falls back to .master_xfer even in atomic mode if > .master_xfer_atomic is NULL, so what I'm suggesting is to make > i2c_in_atomic_xfer_mode() public (from i2c-core.h) and use it in > normal .master_xfer to choose atomic wait variants. Okay, I see now. But the I2C core prints a noisy warning if master_xfer_atomic is NULL in atomic transfer, so I'm not sure whether changing all that code will bring much benefits to us and anyone else. It's a bit too questionable change to me, but maybe I'm still missing something. Will be great if you could provide an example patch.
