| Message ID | 20200831202303.15391-1-digetx@gmail.com |
|---|---|
| Headers | show |
| Series | Improvements for Tegra I2C driver | expand |
On Mon, Aug 31, 2020 at 11:23:00PM +0300, Dmitry Osipenko wrote: > The driver's probe function code is difficult to read and follow. This > patch splits probe function into several logical parts that are easy to > work with. > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > drivers/i2c/busses/i2c-tegra.c | 398 ++++++++++++++++++++------------- > 1 file changed, 240 insertions(+), 158 deletions(-) [...] I can see why you want to extract clock setup and combine DT-parsing parts, but the rest is not that clear. At least the clock setup split should be a separate patch, as it seems to require massive code motion. For eg. runtime PM setup/disable or interrupt setup, I would actually suggest to drop the parts as they make the code harder to follow (you have a function doing nothing but calling another one). Best Regards, Michał Mirosław
On Mon, Aug 31, 2020 at 11:22:51PM +0300, Dmitry Osipenko wrote: > Hello! > > This series performs a small refactoring of the Tegra I2C driver code and > hardens the atomic-transfer mode. > > Dmitry Osipenko (12): > i2c: tegra: Make tegra_i2c_flush_fifos() usable in atomic transfer > i2c: tegra: Add missing newline before returns > i2c: tegra: Clean up messages in the code > i2c: tegra: Don't ignore tegra_i2c_flush_fifos() error > i2c: tegra: Use reset_control_reset() > i2c: tegra: Improve formatting of function variables > i2c: tegra: Use dev_err_probe() > i2c: tegra: Runtime PM always available on Tegra > i2c: tegra: Clean up probe function > i2c: tegra: Drop '_timeout' from wait/poll function names > i2c: tegra: Remove likely/unlikely from the code > i2c: tegra: Factor out error recovery from tegra_i2c_xfer_msg() For all, but #3 and #9: Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> 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. Best Regards, Michał Mirosław
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.