Re: [PATCH v4 11/31] i2c: tegra: Factor out runtime PM and hardware initialization
06.09.2020 01:51, Michał Mirosław пишет: > On Sun, Sep 06, 2020 at 01:24:14AM +0300, Dmitry Osipenko wrote: >> 06.09.2020 01:10, Michał Mirosław пишет: >>> On Sat, Sep 05, 2020 at 11:41:31PM +0300, Dmitry Osipenko wrote: Factor out runtime PM and hardware initialization into separate function in order have a cleaner error unwinding in the probe function. >>> [...] + ret = tegra_i2c_init_runtime_pm_and_hardware(i2c_dev); >>> [...] >>> >>> This one doesn't improve the code for me. The problems are: 1) putting two >>> unrelated parts in one function, 2) silently reordered initialization. >> >> The hardware initialization depends on the resumed RPM and the rest of >> the probe function doesn't care about the RPM. I don't quite understand >> why you're saying that they are unrelated, could you please explain? >> >> The DMA/RPM initialization is intentionally reordered in order to clean >> up the error handling, like the commit message says. To me it's a clear >> improvement :) > > Ok, then wouldn't it be enough to just move this part in the probe()? > A sign of a problem for me is how much information you had to put in > the name of the new function. Looking at it again now, I think you're right. I also now noticed that the RPM isn't disabled now if tegra_i2c_init() fails. I'll try to take another look, but probably will lean to yours variant in the v5. Thanks!
Re: [PATCH v4 11/31] i2c: tegra: Factor out runtime PM and hardware initialization
On Sun, Sep 06, 2020 at 01:24:14AM +0300, Dmitry Osipenko wrote: > 06.09.2020 01:10, Michał Mirosław пишет: > > On Sat, Sep 05, 2020 at 11:41:31PM +0300, Dmitry Osipenko wrote: > >> Factor out runtime PM and hardware initialization into separate function > >> in order have a cleaner error unwinding in the probe function. > > [...] > >> + ret = tegra_i2c_init_runtime_pm_and_hardware(i2c_dev); > > [...] > > > > This one doesn't improve the code for me. The problems are: 1) putting two > > unrelated parts in one function, 2) silently reordered initialization. > > The hardware initialization depends on the resumed RPM and the rest of > the probe function doesn't care about the RPM. I don't quite understand > why you're saying that they are unrelated, could you please explain? > > The DMA/RPM initialization is intentionally reordered in order to clean > up the error handling, like the commit message says. To me it's a clear > improvement :) Ok, then wouldn't it be enough to just move this part in the probe()? A sign of a problem for me is how much information you had to put in the name of the new function. Best Regards, Michał Mirosław
Re: [PATCH v4 11/31] i2c: tegra: Factor out runtime PM and hardware initialization
06.09.2020 01:10, Michał Mirosław пишет: > On Sat, Sep 05, 2020 at 11:41:31PM +0300, Dmitry Osipenko wrote: >> Factor out runtime PM and hardware initialization into separate function >> in order have a cleaner error unwinding in the probe function. > [...] >> +ret = tegra_i2c_init_runtime_pm_and_hardware(i2c_dev); > [...] > > This one doesn't improve the code for me. The problems are: 1) putting two > unrelated parts in one function, 2) silently reordered initialization. The hardware initialization depends on the resumed RPM and the rest of the probe function doesn't care about the RPM. I don't quite understand why you're saying that they are unrelated, could you please explain? The DMA/RPM initialization is intentionally reordered in order to clean up the error handling, like the commit message says. To me it's a clear improvement :)
Re: [PATCH v4 11/31] i2c: tegra: Factor out runtime PM and hardware initialization
On Sat, Sep 05, 2020 at 11:41:31PM +0300, Dmitry Osipenko wrote: > Factor out runtime PM and hardware initialization into separate function > in order have a cleaner error unwinding in the probe function. [...] > + ret = tegra_i2c_init_runtime_pm_and_hardware(i2c_dev); [...] This one doesn't improve the code for me. The problems are: 1) putting two unrelated parts in one function, 2) silently reordered initialization. Best Regards, Michał Mirosław
