On 5/6/2022 4:46 PM, Kalle Valo wrote:
Dan Carpenter <dan.carpenter@xxxxxxxxxx> writes:
On Thu, May 05, 2022 at 09:29:40AM +0800, Carl Huang wrote:
Hi Kalle,
Is the below the same fix that you have already applied to ath.git?
[-next] ath11k: fix missing unlock on error in ath11k_wow_op_resume() -
Patchwork (kernel.org)
<https://patchwork.kernel.org/project/linux-wireless/patch/20220408030912.3087293-1-yangyingliang@xxxxxxxxxx/
That looks good. It's sort of annoying for me to send a bug report a
month after the fix has been applied... Sorry about that.
My ath.git tree is not included in linux-wireless builds so there's also
a delay before linux-next sees the fix.
Hi,
Sorry for the overdue report , we'll take a look to prevent the same
problem arising again.
1) These are kbuild warnings. The zero day bot generates the
warnings and I look them over and hit send. I don't know why the kbuild
bot seems to get confused by -mm. The subject says 408/8237 which is
pretty crazy. Maybe I should just ignore the -mm patches?
Yeah, I have been also wondering about using -mm for ath11k reports.
Does anyone know why that's happening?
We don't have a filter to ignore some warnings from specific branches,
we can create one to only report ath11k issues if found in ath.git,
please remind me if there are other rules.
2) The blamed patch came from a git tree but it had a Link tag to
lore.kernel.org so we could have used that as an In-Reply-to tag.
In an ideal world, all the bug reports for a patch would go to a
standard location.
Link:
https://lore.kernel.org/r/1644308006-22784-5-git-send-email-quic_cjhuang@xxxxxxxxxxx
Yeah, that would be nice.
We have already linked the bug reports to the patch if the patch hasn't
been applied, I'm not sure is it possible to find the link of patch if
it's already applied in a branch.
3) Another idea is that the kbuild bot could search lore for Fixes to
the original commit and include links to those threads?
Yeah. Also searching for all references to the commit id from git log
would be nice.
Yes, It could avoid such false positive, we'll give it a try.
Best Regards,
Rong Chen
