Re: [PATCH] i2c: omap: Cleaned up coding style and parameters

[Dhruv Menon]

> > Not sure if that is correct as sleeps can be now shorter? I wouldn't
> > touch them unless you can show some real benefit (checkpatch.pl warning
> > isn't one for old driver code).
> > 
> The sleeps are not shorter, instead possibly longer. I do not think
> that is an issue, AFAIK the idea with sleep range is to bundle wakeups
> and reduce power consumption.
> 
As per timer,how-to docs present, using ms_sleep(1) will 
lead longer sleep time (about 20ms in HZ=100)

> > Maybe also changes should be split into separate patches for easier
> > review.
> > 
> I would leave out omap_i2c_*data() parameter stuff until the i2c irq
> regressions are fixed, maybe that parameter is needed.
> 
Using git blame, the only usage of it has been for error logging.

On Tue, Dec 03, 2024 at 08:35:47AM +0100, Andreas Kemnade wrote:
> Am Mon, 2 Dec 2024 22:58:17 +0200
> schrieb Aaro Koskinen <aaro.koskinen@xxxxxx>:
> 
> > On Tue, Dec 03, 2024 at 12:22:51AM +0530, Dhruv Menon wrote:
> > > This commit addresses the coding style issues present in i2c-omap.c,
> > > identified by checkpatch.pl and removes unused parameters present in
> > > two functions.
> > > 
> > > 1. Coding style issues includes Macro Utilization, alignnment
> > >    correction, updating ms_sleep() < 20 to usleep_range().
> > > 2. Removed unused parameters from omap_i2c_receive_data()
> > >    and omap_i2c_transmit_data().
> > > 
> > > No functional changes have been introduced in this commit.  
> > 
> > Not sure if that is correct as sleeps can be now shorter? I wouldn't
> > touch them unless you can show some real benefit (checkpatch.pl warning
> > isn't one for old driver code).
> > 
> The sleeps are not shorter, instead possibly longer. I do not think
> that is an issue, AFAIK the idea with sleep range is to bundle wakeups
> and reduce power consumption.
> 
> > Maybe also changes should be split into separate patches for easier
> > review.
> > 
> I would leave out omap_i2c_*data() parameter stuff until the i2c irq
> regressions are fixed, maybe that parameter is needed.
> 
> Regards,
> Andreas