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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 8 Sep 2020 15:55:30 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Andy Shevchenko <andy.shevchenko@...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

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.

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.

> 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.