On Wed, Jun 19, 2024 at 09:03:34AM +0000, Grumbach, Emmanuel wrote:
On Wed, 2024-06-19 at 10:51 +0200, Greg KH wrote:
On Tue, Jun 18, 2024 at 02:09:23PM +0300, Emmanuel Grumbach wrote:
commit 8f892e225f416fcf2b55a0f9161162e08e2b0cc7 upstream.
This just adds a __le32 that we (currently) don't use.
Why is this needed for a stable tree if this is nothing that is actually used and then we need another fix for it after that?
Right, so I totally understand you're confused... I should probably have re-written the commit message to explain why this is needed for stable...
This patch allows to handle a new version of a specific command to the firmware. As explained in the commit message, we don't need the new field, but ... the command got bigger and we must align to the new size of course. If we don't, the firmware will get a command that is shorter than expected and will crash. We originally didn't think we'd need that on the firmware versions supported by kernel 6.9 and this is why we didn't queue this patch for 6.9. Now, it appears that the latest firmware version that 6.9 supports does need the new version of the command. Unfortunately, we learnt that the hard way, through bugzilla :-(
Now, this patch introduced a regression that is fixed by another patch... Would you prefer me to squash them?
I can't see how this commit actually does anything on it's own, what am I missing?
What bug is this fixing? A regression? Is this a new feature?
So, yes, it fixes a bug as explained above. This is a regression because older kernels won't load the new firmware and won't hit the firmware crash.
confused,
I should have re-written the commit message. Sorry. I hope things are now clearer..
Keeping the commit message the same is fine, and not squashing is also fine, but a huge hint as to _why_ this is relevent for the stable trees would have been appreciated. That's what [0/X] email blurbs are for :)
thanks, I'll go queue these up now.
greg k-h