Message ID | 20200903005300.7894-1-digetx@gmail.com |
---|---|
Headers | show |
Series | Improvements for Tegra I2C driver | expand |
On Thu, Sep 3, 2020 at 3:53 AM Dmitry Osipenko <digetx@gmail.com> wrote: > > Use a single reset_control_reset() instead of assert/deasset couple in > order to make code cleaner a tad. > Note that the reset_control_reset() > uses 1 microsecond delay instead of 2 that was used previously, but this > shouldn't matter. What datasheet says about this delay? > In addition don't ignore potential error of the reset. > > Reviewed-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> > Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
03.09.2020 14:06, Andy Shevchenko пишет: > On Thu, Sep 3, 2020 at 3:53 AM Dmitry Osipenko <digetx@gmail.com> wrote: >> >> This patch unifies style of all messages in the driver by starting them >> with a lowercase letter and using consistent capitalization and wording >> for all messages. > > I didn't look at the rest (yet) but this series has a patch ordering issue. > Why do we first do some little, non-critical clean ups? > > The preferred way is to arrange like: > - fixes that may be backported > - fixes that are likely not going to be backported > - features > - cleanups > > In its turn cleanups go by severity: > - code affected ones (and maybe logical changers) > - ... > - commentary / indentation fixes > That's a good suggestion! All patches in this version are ordered by the time they were created ans since none of these patches should be worthwhile to backport (IMO) and because majority of patches do minor changes, it appeared to me that it should be okay as-is. I agree that it should be worthwhile to reorder the patches now, after the series grew up a tad in regards to amount of patches. I'll change the order in the next version, thanks!
03.09.2020 14:02, Andy Shevchenko пишет: > On Thu, Sep 3, 2020 at 3:53 AM Dmitry Osipenko <digetx@gmail.com> wrote: >> >> The tegra_i2c_flush_fifos() shouldn't sleep in atomic transfer and jiffies >> are not updating if interrupts are disabled. Hence let's use proper delay >> functions and use ktime API in order not to hang atomic transfer. Note >> that this patch doesn't fix any known problem because normally FIFO is >> flushed at the time of starting a new transfer. > >> + /* >> + * ktime_get() may take up to couple milliseconds in a worst case >> + * and normally FIFOs are flushed, hence let's check the state before >> + * proceeding to polling. >> + */ > > Everything, including above can be done by using macros from iopoll.h. Why not? Perhaps indeed it should be possible to use the common macros, at least I can't recall why I chose not to use them. Maybe because it appeared to me that the current variant is a bit nicer than: if (atomic) read_poll_atomic() else read_poll() I'll consider to use the common iopoll macros in v4, thanks!