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: <45057c95-1dba-4302-94fa-f63941ee2b20@nvidia.com>
Date: Wed, 17 Dec 2025 18:59:38 +0000
From: Jon Hunter <jonathanh@...dia.com>
To: Aaron Kling <webgeek1234@...il.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, 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 17/12/2025 18:39, Aaron Kling wrote:

...

> To try to move a resolution along, let me try to enumerate the issues
> again. Again, please clarify should I have something incorrect or
> incomplete.
> 
> 1) The primary issue is when an old dtb is used with this commit and
> the pcie driver is loaded. I can reproduce this issue on t186 and
> t194. If this becomes the sole remaining blocking issue, I would like
> for an exception to the normal rule be considered and this merged
> anyways. Since it does not cause a boot failure and distros package a
> new dt normally anyways. And to my knowledge, working around this
> would involve redoing part off the icc subsystem itself, a major task
> in comparison.
> 
> 2) T194 is reported to have low clocks even with a new dt on the
> Nvidia regression bench. I cannot reproduce this, even with the pcie
> driver loaded. Can this be re-verified, please? And if it still
> happens, can logs from the failure be made available and/or more
> information provided as to the state of the unit? Like changes to the
> default defconfig, modules that get loaded, etc.

Can you list all the patches that need to be applied on top of the 
current -next and I will run it through our testing to make sure I have 
this correct.

> 3) Setting the max clock via debugfs fails when icc has pushed the
> current clock higher than the requested rate. This is a logic issue
> with all tegra emc drivers that implement dfs via icc. The suggested
> resolutions are to leave this as is to keep consistency with the
> existing drivers, perhaps updating all later, or to update the
> existing implementations in a separate series, then send a new
> revision here to match. I am personally unable to verify anything
> older than tegra124, however.

Thierry and I chatted about this last week and we feel that debugfs 
should be able to override the current configuration. So this will need 
to be addressed as well.

Jon

-- 
nvpublic