Re: Patch "spi: axi-spi-engine: Convert to platform remove callback returning void" has been added to the 6.1-stable tree
On 5/6/24 2:30 PM, Sasha Levin wrote:
This is a note to let you know that I've just added the patch titled
spi: axi-spi-engine: Convert to platform remove callback returning voidto the 6.1-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...
The filename of the patch is: spi-axi-spi-engine-convert-to-platform-remove-callba.patch and it can be found in the queue-6.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.
Does not meet the criteria for stable.
Hello,
On Mon, May 06, 2024 at 03:43:47PM -0500, David Lechner wrote:
Does not meet the criteria for stable.
It was identified as a dependency of another patch. But I agree to David, it should be trivial to back this patch out. If you need help, please tell me.
Best regards Uwe
On 5/7/24 1:13 AM, Uwe Kleine-König wrote:
Hello,
On Mon, May 06, 2024 at 03:43:47PM -0500, David Lechner wrote:
Does not meet the criteria for stable.
It was identified as a dependency of another patch. But I agree to David, it should be trivial to back this patch out. If you need help, please tell me.
The "fix" patch isn't something that should be backported to stable either, so we shouldn't need to do anything here other than drop the whole series from the stable queue.
Hello David,
On Tue, May 07, 2024 at 08:59:16AM -0500, David Lechner wrote:
On 5/7/24 1:13 AM, Uwe Kleine-König wrote:
On Mon, May 06, 2024 at 03:43:47PM -0500, David Lechner wrote:
Does not meet the criteria for stable.
It was identified as a dependency of another patch. But I agree to David, it should be trivial to back this patch out. If you need help, please tell me.
The "fix" patch isn't something that should be backported to stable either, so we shouldn't need to do anything here other than drop the whole series from the stable queue.
Maybe it's just me, but for me backporting commit 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") looks sensible. (Or what do you mean with "the "fix" patch"?) It's a small fix for a small annoyance, but looks harmless enough that I'd tend to include it in stable.
Best regards Uwe
On 5/7/24 9:08 AM, Uwe Kleine-König wrote:
Hello David,
On Tue, May 07, 2024 at 08:59:16AM -0500, David Lechner wrote:
On 5/7/24 1:13 AM, Uwe Kleine-König wrote:
On Mon, May 06, 2024 at 03:43:47PM -0500, David Lechner wrote:
Does not meet the criteria for stable.
It was identified as a dependency of another patch. But I agree to David, it should be trivial to back this patch out. If you need help, please tell me.
The "fix" patch isn't something that should be backported to stable either, so we shouldn't need to do anything here other than drop the whole series from the stable queue.
Maybe it's just me, but for me backporting commit 0064db9ce4aa ("spi: axi-spi-engine: fix version format string") looks sensible. (Or what do you mean with "the "fix" patch"?) It's a small fix for a small annoyance, but looks harmless enough that I'd tend to include it in stable.
It's just fixing a theoretical problem, not one that has actually caused problems for people. The stable guidelines I read [1] said we shouldn't include fixes like that.
[1]: https://docs.kernel.org/process/stable-kernel-rules.html
So, sure it would probably be harmless to include it without the other dependencies. But not sure it is worth the effort for only a theoretical problem.
On Tue, May 07, 2024 at 09:22:48AM -0500, David Lechner wrote:
It's just fixing a theoretical problem, not one that has actually caused problems for people. The stable guidelines I read [1] said we shouldn't include fixes like that.
So, sure it would probably be harmless to include it without the other dependencies. But not sure it is worth the effort for only a theoretical problem.
The written stable guidelines don't really reflect what's going on with stable these days at all, these days it's very aggressive with what it backports. Personally I tend to be a lot more conservative than this and would tend to agree that this isn't a great candidate for backporting but people seem OK with this sort of stuff.
On Tue, May 07, 2024 at 11:39:58PM +0900, Mark Brown wrote:
On Tue, May 07, 2024 at 09:22:48AM -0500, David Lechner wrote:
It's just fixing a theoretical problem, not one that has actually caused problems for people. The stable guidelines I read [1] said we shouldn't include fixes like that.
So, sure it would probably be harmless to include it without the other dependencies. But not sure it is worth the effort for only a theoretical problem.
The written stable guidelines don't really reflect what's going on with stable these days at all, these days it's very aggressive with what it backports.
It's "aggressive" in that many dependent patches are finally being properly found and backported as needed to be able to get the "real" fix applied properly. That's all, nothing odd here, and all of these commits have been through proper review and development and acceptance already, so it's not like they are brand new things, they are required for real fixes.
Personally I tend to be a lot more conservative than this and would tend to agree that this isn't a great candidate for backporting but people seem OK with this sort of stuff.
Again, we want to keep as close as possible with Linus's tree because ALMOST EVERY time we try to do our own thing, we get something wrong. Keeping in sync is essencial to rely on our overall testing and future fix ability to keep in sync properly.
To attempt to do "one off" backports all over the place just does not work, we have tried it and failed. To not accept the fix at all leaves us vulnerable to a known bug, why would that be ok?
Change is good, and these changes are extra-good as they fix things.
thanks,
greg k-h
On Mon, May 13, 2024 at 8:07 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, May 07, 2024 at 11:39:58PM +0900, Mark Brown wrote:
On Tue, May 07, 2024 at 09:22:48AM -0500, David Lechner wrote:
It's just fixing a theoretical problem, not one that has actually caused problems for people. The stable guidelines I read [1] said we shouldn't include fixes like that.
So, sure it would probably be harmless to include it without the other dependencies. But not sure it is worth the effort for only a theoretical problem.
The written stable guidelines don't really reflect what's going on with stable these days at all, these days it's very aggressive with what it backports.
It's "aggressive" in that many dependent patches are finally being properly found and backported as needed to be able to get the "real" fix applied properly. That's all, nothing odd here, and all of these commits have been through proper review and development and acceptance already, so it's not like they are brand new things, they are required for real fixes.
Personally I tend to be a lot more conservative than this and would tend to agree that this isn't a great candidate for backporting but people seem OK with this sort of stuff.
Again, we want to keep as close as possible with Linus's tree because ALMOST EVERY time we try to do our own thing, we get something wrong. Keeping in sync is essencial to rely on our overall testing and future fix ability to keep in sync properly.
To attempt to do "one off" backports all over the place just does not work, we have tried it and failed. To not accept the fix at all leaves us vulnerable to a known bug, why would that be ok?
Change is good, and these changes are extra-good as they fix things.
I see there are differences in opinion of what a "real" problem is. And it sounds like the opinions have been shifting while I was away from kernel development for a few years.
If you prefer to take this patch and all of it's dependencies to keep things as close to mainline as possible, I guess that is fine.
linux-stable-mirror@lists.linaro.org
-
David Lechner -
Greg KH -
Mark Brown -
Uwe Kleine-König