linux-kernel - Re: [PATCH v6 16/35] i2c: tegra: Reorder location of functions in the code

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 8 Sep 2020 16:03:07 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Dmitry Osipenko <digetx@...il.com>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Laxman Dewangan <ldewangan@...dia.com>,
        Wolfram Sang <wsa@...-dreams.de>,
        Michał Mirosław <mirq-linux@...e.qmqm.pl>,
        linux-i2c <linux-i2c@...r.kernel.org>,
        linux-tegra@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 16/35] i2c: tegra: Reorder location of functions in the code

On Tue, Sep 8, 2020 at 3:55 PM Dmitry Osipenko <digetx@...il.com> wrote:
> 08.09.2020 11:43, Andy Shevchenko пишет:
> > On Tue, Sep 8, 2020 at 5:11 AM Dmitry Osipenko <digetx@...il.com> wrote:
> >>
> >> Reorder location of functions in the code in order to have definition
> >> of functions closer to the place of the invocation. This change makes
> >> easier to navigate around the code and removes the need to have a
> >> prototype for tegra_i2c_init().
> >
> > Still seems to have ordering issues (it moves pieces you actually
> > change in the next patches).
>
> It's unavoidable that this patch either touches previous or next
> changes. You actually had an opposite complaint to v5.

Nice :-)

> This diver has a long overdue for the refactoring. I think it's a good
> time to do it right now because driver works stable and it's quite
> unlikely that there will ever be fixes for the older code. Hence it
> should be good to have the code reordered now, so that we could have a
> nicer code base for the future changes.

I agree.

> > Have you considered which one looks neat this variant or if you move
> > it closer to the end of the series?

> This variant should be more logical because changes have this order:
>
> 1. fixes
> 2. features
> 3. code reorder
> 4. more important cleanups
> 5. less important cleanups
>
> The 3 merely shuffles code around without any changes to the code, hence
> it's a safe change.
>
> The 4 has a potential danger since there are cleanups of the outdated
> features and some changes may change semantic in a case of a bug. Hence,
> if in the future we'll happen to find a problem in one of the 4 patches,
> then there is a better chance that the problem could be fixed with a
> simple revert. If 3 is placed after 4, then the chance is completely gone.

Thanks for elaboration. If you think so (and I guess you are), go ahead!

-- 
With Best Regards,
Andy Shevchenko