mbox series

[v1,00/12] Improvements for Tegra I2C driver

Message ID 20200831202303.15391-1-digetx@gmail.com
Headers show
Series Improvements for Tegra I2C driver | expand

Message

Dmitry Osipenko Aug. 31, 2020, 8:22 p.m. UTC
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()

 drivers/i2c/busses/i2c-tegra.c | 601 ++++++++++++++++++---------------
 1 file changed, 338 insertions(+), 263 deletions(-)

Comments

Michał Mirosław Sept. 2, 2020, 9:06 p.m. UTC | #1
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
Michał Mirosław Sept. 2, 2020, 9:20 p.m. UTC | #2
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
Dmitry Osipenko Sept. 3, 2020, 10:18 p.m. UTC | #3
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.