linux-kernel - Re: [PATCH v4 0/7] memory: tegra: Cleanup Tegra210 EMC frequency scaling

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]

Message-ID: <8b75756d-aec9-4c28-96be-81cd12496757@kernel.org>
Date: Mon, 29 Jul 2024 17:31:16 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Diogo Ivo <diogo.ivo@...nico.ulisboa.pt>,
 Thierry Reding <thierry.reding@...il.com>,
 Jonathan Hunter <jonathanh@...dia.com>
Cc: linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH v4 0/7] memory: tegra: Cleanup Tegra210 EMC frequency
 scaling

On 04/07/2024 13:31, Diogo Ivo wrote:
> Hello,
> 
> This patch series consists of a general cleanup of the Tegra210 EMC
> frequency scaling code for revision 7.
> 
> Currently the code is relying heavily on a function, update_clock_tree_delay(),
> that is responsible for too many things, making it long and confusing.
> The general idea with these patches is to simplify this function and its
> surrounding code, making it more modular.
> 
> The motivation behind these changes (besides improving readability and
> maintainability) is to make it simpler to add support in the future for
> frequency change revisions other than 7, where we can reuse a large
> portion of the modularized code rather than essentially repeating 2k
> lines of code with minimal changes.
> 
> There are no functional changes with this patch set, as it is only meant
> as preparation for following patches where revision 6 support is added.
> 
> Signed-off-by: Diogo Ivo <diogo.ivo@...nico.ulisboa.pt>
> ---
> Changes in v4:
> - PATCH 07/07: Add missing parenthesis around operands when calculating
>   delay
> - Link to v3: https://lore.kernel.org/r/20240507093056.3921-1-diogo.ivo@tecnico.ulisboa.pt
> 
> ---
> Diogo Ivo (7):
>       memory: tegra: Remove periodic compensation duplicate calls
>       memory: tegra: Move DQSOSC measurement to common place
>       memory: tegra: Reword and correct comments
>       memory: tegra: Change macros to interpret parameter as integer
>       memory: tegra: Loop update_clock_tree_delay()
>       memory: tegra: Move compare/update current delay values to a function
>       memory: tegra: Rework update_clock_tree_delay()
> 
>  drivers/memory/tegra/tegra210-emc-cc-r21021.c | 429 ++++++--------------------
>  1 file changed, 86 insertions(+), 343 deletions(-)
> ---
> base-commit: 22a40d14b572deb80c0648557f4bd502d7e83826
> change-id: 20240704-tegra210_emcfreq-9d2466310cec

I don't understand what happened with this series. lore cannot find
anything for above change-id. b4 diff also fails:
b4 diff '<20240704-tegra210_emcfreq-v4-0-3e450503c555@...nico.ulisboa.pt>'
Grabbing thread from
lore.kernel.org/all/20240704-tegra210_emcfreq-v4-0-3e450503c555@...nico.ulisboa.pt/t.mbox.gz
Checking for older revisions
Grabbing search results from lore.kernel.org
Nothing matching that query.
---
Analyzing 8 messages in the thread
Could not find lower series to compare against.

Link to v3 does not point to v3, but to some resend. Changelog is
incomplete - mentions only v3, but what happened between v1->v2, v2->v3?

There is canonical way to send patches which makes everything
straightforward (and IMHO easy). It's called b4. But you can just use
git format-patch and git send-email. Whatever you choose, this makes
maintainer life easy.

Way you sent patches is somehow broken, I don't know how, but it does
not make maintainer life easy.

Please reply with changelog and explanation where is original v3.


Best regards,
Krzysztof