Please drop the following commits from stable 5.10.y and 5.15.y respectively
972acd701b19 ("clk: imx: pll14xx: dynamically configure PLL for 393216000/361267200Hz") a8474506c912 ("clk: imx: pll14xx: dynamically configure PLL for 393216000/361267200Hz")
The commit message states 'Cc: stable@vger.kernel.org # v5.18+' and the commit should only be applied to Linux 5.18.y and newer, on anything older it breaks PLL configuration due to missing prerequisite patches.
Thanks
On Tue, Oct 03, 2023 at 10:52:25PM +0200, Marek Vasut wrote:
Please drop the following commits from stable 5.10.y and 5.15.y respectively
972acd701b19 ("clk: imx: pll14xx: dynamically configure PLL for 393216000/361267200Hz") a8474506c912 ("clk: imx: pll14xx: dynamically configure PLL for 393216000/361267200Hz")
The commit message states 'Cc: stable@vger.kernel.org # v5.18+' and the commit should only be applied to Linux 5.18.y and newer, on anything older it breaks PLL configuration due to missing prerequisite patches.
Ok, I'll go revert them, but the Fixes: tag in this commit is very wrong as that's what we used to determine how far back to take these changes.
thanks,
greg k-h
Hello Greg,
On 07.10.23 13:44, Greg KH wrote:
On Tue, Oct 03, 2023 at 10:52:25PM +0200, Marek Vasut wrote:
Please drop the following commits from stable 5.10.y and 5.15.y respectively
972acd701b19 ("clk: imx: pll14xx: dynamically configure PLL for 393216000/361267200Hz") a8474506c912 ("clk: imx: pll14xx: dynamically configure PLL for 393216000/361267200Hz")
The commit message states 'Cc: stable@vger.kernel.org # v5.18+' and the commit should only be applied to Linux 5.18.y and newer, on anything older it breaks PLL configuration due to missing prerequisite patches.
Ok, I'll go revert them, but the Fixes: tag in this commit is very wrong as that's what we used to determine how far back to take these changes.
The Fixes tag is correct. The PLL parameters added in that commit were deemed suboptimal. Kernels >= v5.18 can compute better parameters on the fly, so that's why the patch says
Cc: stable@vger.kernel.org # v5.18+
Which is the syntax described in Documentation/admin-guide/reporting-issues.rst. I see now though that Documentation/process/stable-kernel-rules.rst has a slightly different syntax:
Cc: stable@vger.kernel.org # 3.3.x
Perhaps your maintainer scripts can't handle both cases?
FWIW, I've reached out multiple times about that the patches aren't suitable for backports:
- https://lore.kernel.org/all/6e3ad25c-1042-f786-6f0e-f71ae85aed6b@pengutronix... - a76406b2-4154-2de4-b1f5-43e86312d487@pengutronix.de (reply to linux-stable-commits) - https://lore.kernel.org/all/7df69de2-1b3a-5226-7dc2-d1489e48f6a2@pengutronix... - https://lore.kernel.org/all/e85da95c-5451-31ea-cae9-76d697fb548f@pengutronix...
Yet, today I got an email[1] telling me that it's being added to v5.4.258-rc1, although it had been dropped from v5.4.257-rc1 after I objected to it.
So that looks like another potential avenue for improving the maintainer scripts.
[1]: https://lore.kernel.org/all/20231009130131.263594775@linuxfoundation.org/
Thanks, Ahmad
thanks,
greg k-h
On 09.10.23 16:17, Ahmad Fatoum wrote:
On 07.10.23 13:44, Greg KH wrote: Cc: stable@vger.kernel.org # v5.18+
Which is the syntax described in Documentation/admin-guide/reporting-issues.rst.
This is wrong. The example in that file has "Cc: stable@vger.kernel.org # 5.4+" without the v. Still, looking at other commits, the syntax with leading v is common enough that it's worth handling.
I see now though that Documentation/process/stable-kernel-rules.rst has a slightly different syntax:
Cc: stable@vger.kernel.org # 3.3.x
Perhaps your maintainer scripts can't handle both cases?
FWIW, I've reached out multiple times about that the patches aren't suitable for backports:
- https://lore.kernel.org/all/6e3ad25c-1042-f786-6f0e-f71ae85aed6b@pengutronix...
- a76406b2-4154-2de4-b1f5-43e86312d487@pengutronix.de (reply to linux-stable-commits)
- https://lore.kernel.org/all/7df69de2-1b3a-5226-7dc2-d1489e48f6a2@pengutronix...
- https://lore.kernel.org/all/e85da95c-5451-31ea-cae9-76d697fb548f@pengutronix...
Yet, today I got an email[1] telling me that it's being added to v5.4.258-rc1, although it had been dropped from v5.4.257-rc1 after I objected to it.
So that looks like another potential avenue for improving the maintainer scripts.
Thanks, Ahmad
thanks,
greg k-h
On Mon, Oct 09, 2023 at 04:33:32PM +0200, Ahmad Fatoum wrote:
On 09.10.23 16:17, Ahmad Fatoum wrote:
On 07.10.23 13:44, Greg KH wrote: Cc: stable@vger.kernel.org # v5.18+
Which is the syntax described in Documentation/admin-guide/reporting-issues.rst.
This is wrong. The example in that file has "Cc: stable@vger.kernel.org # 5.4+" without the v. Still, looking at other commits, the syntax with leading v is common enough that it's worth handling.
We can handle it either way, it's me reading it, no script is parsing this :)
thanks,
greg k-h
On Mon, Oct 09, 2023 at 04:17:53PM +0200, Ahmad Fatoum wrote:
Hello Greg,
On 07.10.23 13:44, Greg KH wrote:
On Tue, Oct 03, 2023 at 10:52:25PM +0200, Marek Vasut wrote:
Please drop the following commits from stable 5.10.y and 5.15.y respectively
972acd701b19 ("clk: imx: pll14xx: dynamically configure PLL for 393216000/361267200Hz") a8474506c912 ("clk: imx: pll14xx: dynamically configure PLL for 393216000/361267200Hz")
The commit message states 'Cc: stable@vger.kernel.org # v5.18+' and the commit should only be applied to Linux 5.18.y and newer, on anything older it breaks PLL configuration due to missing prerequisite patches.
Ok, I'll go revert them, but the Fixes: tag in this commit is very wrong as that's what we used to determine how far back to take these changes.
The Fixes tag is correct. The PLL parameters added in that commit were deemed suboptimal. Kernels >= v5.18 can compute better parameters on the fly, so that's why the patch says
Cc: stable@vger.kernel.org # v5.18+
Which is the syntax described in Documentation/admin-guide/reporting-issues.rst. I see now though that Documentation/process/stable-kernel-rules.rst has a slightly different syntax:
Cc: stable@vger.kernel.org # 3.3.x
Perhaps your maintainer scripts can't handle both cases?
That's not what happened here, sorry.
We went off of the Fixes: tag, and ignored the # VERSION marking as sometimes that is wrong (like when we backport changes to older kernels.)
FWIW, I've reached out multiple times about that the patches aren't suitable for backports:
- https://lore.kernel.org/all/6e3ad25c-1042-f786-6f0e-f71ae85aed6b@pengutronix...
- a76406b2-4154-2de4-b1f5-43e86312d487@pengutronix.de (reply to linux-stable-commits)
- https://lore.kernel.org/all/7df69de2-1b3a-5226-7dc2-d1489e48f6a2@pengutronix...
- https://lore.kernel.org/all/e85da95c-5451-31ea-cae9-76d697fb548f@pengutronix...
Yet, today I got an email[1] telling me that it's being added to v5.4.258-rc1, although it had been dropped from v5.4.257-rc1 after I objected to it.
So that looks like another potential avenue for improving the maintainer scripts.
I'll go drop it from 5.4 again, Sasha's and my scripts don't always sync up well at times, thanks for pointing this out.
greg k-h
linux-stable-mirror@lists.linaro.org