Thanks for the reply Thorsten.
So is anybody able to indicate why this commit 1fe15be1fb6135 has been backported to 5.15.y? Actually this creates a bug on v5.15 (see commands executed in my original message). I don't know for 6.8 or 6.12 release, I'm not able to update my target with such gap.
Regards Joel
________________________________________ De : Thorsten Leemhuis regressions@leemhuis.info Envoyé : lundi 14 octobre 2024 08h45 À : Jay Buddhabhatti jay.buddhabhatti@amd.com Cc : Greg KH gregkh@linuxfoundation.org; Linux kernel regressions list regressions@lists.linux.dev; Sasha Levin sashal@kernel.org; Stephen Boyd sboyd@kernel.org; Joel GUITTET jguittet.opensource@witekio.com; linux-kernel@vger.kernel.org linux-kernel@vger.kernel.org; stable@vger.kernel.org stable@vger.kernel.org Objet : Re: Bad commit backported on the v5.15.y branch ? [Vous ne recevez pas souvent de courriers de regressions@leemhuis.info. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification%C2%A0]
On 11.10.24 10:48, Joel GUITTET wrote:
I faced some issue related to scaling frequency on ZynqMP device using v5.15.167 kernel. As an exemple setting the scaling frequency below show it's not properly set:
cat /sys/devices/system/cpu/cpufreq/policy0/ scaling_available_frequencies 299999 399999 599999 1199999
echo 399999 > /sys/devices/system/cpu/cpufreq/policy0/ scaling_setspeed
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 399999
cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq 299999 ====> Should be 399999
After analysis of this issue with the help of Xilinx, it appears that a commit was backported on the 5.15.y branch, but probably it should not, or not as is. The commit is 9117fc44fd3a9538261e530ba5a022dfc9519620 modifying drivers/clk/ zynqmp/divider.c.
FWIW, that is 1fe15be1fb6135 ("drivers: clk: zynqmp: update divider round rate logic") [v6.8-rc1].
Is anybody reading this message able to answer why it was backported ?
Looks like because it fixes a bug. I CCed the original author and those that handled the patch, maybe they can help us out and tell us what's the best strategy forward here.
The information I have until now is that it is intended recent kernel version. Dependencies for this modification is currently under clarification with Xilinx (maybe another commit to backport).
By the way, reverting this commit fix the issue shown above.
Does 6.12-rc work fine for you? Because if not, we should fix the problem there.
Ciao, Thorsten