Message ID | 20240416045943.576656-1-quic_adisi@quicinc.com (mailing list archive) |
---|---|
Headers | show |
Series | wifi: cfg80211/mac80211: add support for HE BSS color handling with Multi-Link Operation | expand |
Sparse complains on these patches. I think everyone at QCA should be able to *consistently* run that. Jeff, do you really have no internal processes, it all depends on people running checks manually? We have our own internal tree first, where CI enforces a whole bunch of things, and *then* we send patches out. That obviously *still* misses things and I need to review etc., but getting the trivial bits sorted out before the patches even hit the list would be useful. (Also not sure why no bots complained about this set, it's been a few days, but who knows, maybe they're just behind.) Also this set needs a rebase now with the kernel-doc update, but I was even willing to do that. johannes
On 4/19/24 14:42, Johannes Berg wrote: > Sparse complains on these patches. I think everyone at QCA should be > able to *consistently* run that. > Oops! I don't know for some reason, this got missed in my manual run. Or well I was using sparse from Ubuntu (apt-get install sparse) which might not be the latest (and that prints a lot of warnings on ToT itself). However, now I tested on ToT from sparse.git and I see it complaining. Let me fix that and send next version. > (Also not sure why no bots complained about this set, it's been a few > days, but who knows, maybe they're just behind.) > Yeah even I'm surprised how come bot is not able to catch it. But yeah, missed from my side as well, sorry for that. > Also this set needs a rebase now with the kernel-doc update, but I was > even willing to do that. > Sure will rebase it.
On 4/19/2024 2:12 AM, Johannes Berg wrote: > Sparse complains on these patches. I think everyone at QCA should be > able to *consistently* run that. > > Jeff, do you really have no internal processes, it all depends on people > running checks manually? We have our own internal tree first, where CI > enforces a whole bunch of things, and *then* we send patches out. We are trying to get there but, as the community knows, Qualcomm has historically had a "downstream first" mentality, so all of our automation is built around that. The good news is that there has recently been a massive shift in philosophy (and one reason why after many years of working on the downstream Android driver I moved to the upstream driver). At Linaro Connect 2023 (<https://www.qualcomm.com/developer/blog/2023/06/highlights-linaro-connect-2023>) Leendert van Doorn, SVP of Engineering, announced "Qualcomm is about to adopt a developer first strategy" and "embrace open source and its upstream contribution model." So more resources are being directed at upstream, including updating CI to support that. In the meantime, in my personal semi-automated review workflow I run sparse via ath1*k-check, but unfortunately that only looks in drivers/net/wireless/ath/ath1*k. I have now updated my workflow to check all of the files that are modified by a given patchset, and that flagged: net/mac80211/cfg.c:4847:1: warning: context imbalance in 'ieee80211_obss_color_collision_notify' - different lock contexts for basic block So hopefully in the future I'll catch issues like these internally, before they escape into public. /jeff