Linux Tegra architecture development
 help / color / mirror / Atom feed
From: Mikko Perttunen <mperttunen@nvidia.com>
To: Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Krzysztof Kozlowski <krzk@kernel.org>
Cc: Svyatoslav Ryhel <clamor95@gmail.com>,
	linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: Re: [PATCH] memory: tegra: Deduplicate rate request management code
Date: Tue, 17 Feb 2026 19:12:47 +0900	[thread overview]
Message-ID: <4179089.BddDVKsqQX@senjougahara> (raw)
In-Reply-To: <1af11e93-a455-44ce-a7a0-1b5664e48273@kernel.org>

On Tuesday, February 17, 2026 4:14 PM Krzysztof Kozlowski wrote:
> On 17/02/2026 05:22, Mikko Perttunen wrote:
> > On Friday, February 13, 2026 7:24 PM Krzysztof Kozlowski wrote:
> >> On 06/02/2026 03:54, Mikko Perttunen wrote:
> >>> As is, the EMC drivers for each 32-bit platform contain almost
> >>> identical duplicated code for aggregating rate requests. Move this
> >>> code out to a shared tegra-emc-common file to reduce duplication.
> >>> 
> >>> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> >>> ---
> >>> This patch is on top of 'memory: tegra: Add Tegra114 EMC driver'
> >> 
> >> If that patch is not merged, then this should be reversed. First you
> >> remove duplication then you add smaller new patch. Not vice versa, where
> >> you add duplicated code just to remove it.
> > 
> > The code is already duplicated multiple times before.
> 
> That's the meaning of duplication... and adding more duplicated code is
> obviously not proper choice.

I understand you want the cleanup to be done first, and that's fine and you 
decide -- and more duplicated code is obviously not good, but I don't think 
the order these series should go in is obvious. I'm only saying that because 
to me your wording reads as accusing me of making obviously bad arguments, and 
it's not making my day better.

> 
> > The Tegra114 driver doesn't change the situation in any significant way.
> > Sequencing in this way is just easier rather than disrupting that - more
> > important - series.
> Fix your email so message will be properly wrapped.

It seems some update must have overridden my email config. I think I have 
fixed it.

> 
> Also in the future, please use normal ways to express dependencies - by
> lore links or b4 deps.

I did use b4 deps.

> 
> 
> Best regards,
> Krzysztof

Cheers,
Mikko



      reply	other threads:[~2026-02-17 10:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-06  2:54 [PATCH] memory: tegra: Deduplicate rate request management code Mikko Perttunen
2026-02-13 10:24 ` Krzysztof Kozlowski
2026-02-17  4:22   ` Mikko Perttunen
2026-02-17  7:14     ` Krzysztof Kozlowski
2026-02-17 10:12       ` Mikko Perttunen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4179089.BddDVKsqQX@senjougahara \
    --to=mperttunen@nvidia.com \
    --cc=clamor95@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox