linux-kernel - Re: [PATCH v4 3/5] memory: tegra186-emc: Support non-bpmp icc 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: <CALHNRZ83EcVnyBYADsuXtMu9omBd8WW+7reyb4GX8FfJ4sOcyw@mail.gmail.com>
Date: Mon, 8 Dec 2025 22:26:15 -0600
From: Aaron Kling <webgeek1234@...il.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Jon Hunter <jonathanh@...dia.com>, Rob Herring <robh@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Thierry Reding <thierry.reding@...il.com>, 
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-tegra@...r.kernel.org
Subject: Re: [PATCH v4 3/5] memory: tegra186-emc: Support non-bpmp icc scaling

On Sat, Nov 22, 2025 at 6:01 AM Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On 21/11/2025 12:21, Jon Hunter wrote:
> >
> > On 12/11/2025 07:21, Aaron Kling wrote:
> >> On Wed, Nov 12, 2025 at 12:18 AM Jon Hunter <jonathanh@...dia.com> wrote:
> >>>
> >>>
> >>> On 11/11/2025 23:17, Aaron Kling wrote:
> >>>
> >>> ...
> >>>
> >>>> Alright, I think I've got the picture of what's going on now. The
> >>>> standard arm64 defconfig enables the t194 pcie driver as a module. And
> >>>> my simple busybox ramdisk that I use for mainline regression testing
> >>>> isn't loading any modules. If I set the pcie driver to built-in, I
> >>>> replicate the issue. And I don't see the issue on my normal use case,
> >>>> because I have the dt changes as well.
> >>>>
> >>>> So it appears that the pcie driver submits icc bandwidth. And without
> >>>> cpufreq submitting bandwidth as well, the emc driver gets a very low
> >>>> number and thus sets a very low emc freq. The question becomes... what
> >>>> to do about it? If the related dt changes were submitted to
> >>>> linux-next, everything should fall into place. And I'm not sure where
> >>>> this falls on the severity scale since it doesn't full out break boot
> >>>> or prevent operation.
> >>>
> >>> Where are the related DT changes? If we can get these into -next and
> >>> lined up to be merged for v6.19, then that is fine. However, we should
> >>> not merge this for v6.19 without the DT changes.
> >>
> >> The dt changes are here [0].
> >
> > To confirm, applying the DT changes do not fix this for me. Thierry is
> > having a look at this to see if there is a way to fix this.
> >
> > BTW, I have also noticed that Thierry's memory frequency test [0] is
> > also failing on Tegra186. The test simply tries to set the frequency via
> > the sysfs and this is now failing. I am seeing ..

With this patch dropped from -next, what needs to happen to get it
requeued? I gave an analysis over two weeks ago and have seen no
response since.

Aaron