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@xxxxxxxxxxxxx> Envoyé : lundi 14 octobre 2024 08h45 À : Jay Buddhabhatti <jay.buddhabhatti@xxxxxxx> Cc : Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>; Linux kernel regressions list <regressions@xxxxxxxxxxxxxxx>; Sasha Levin <sashal@xxxxxxxxxx>; Stephen Boyd <sboyd@xxxxxxxxxx>; Joel GUITTET <jguittet.opensource@xxxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx <linux-kernel@xxxxxxxxxxxxxxx>; stable@xxxxxxxxxxxxxxx <stable@xxxxxxxxxxxxxxx> Objet : Re: Bad commit backported on the v5.15.y branch ? [Vous ne recevez pas souvent de courriers de regressions@xxxxxxxxxxxxx. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ;] 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
