Message ID | 20240125104030.B6CA6C433C7@smtp.kernel.org (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Series | pull-request: wireless-next-2024-01-25 | expand |
On Thu, 25 Jan 2024 10:40:30 +0000 (UTC) Kalle Valo wrote: > The first "new features" pull request for v6.9. We have only driver > changes this time and most of them are for Realtek drivers. Really > nice to see activity in Broadcom drivers again. minor thing for a follow up: drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49: warning: no newline at end of file
Hello: This pull request was applied to netdev/net-next.git (main) by Jakub Kicinski <kuba@kernel.org>: On Thu, 25 Jan 2024 10:40:30 +0000 (UTC) you wrote: > Hi, > > here's a pull request to net-next tree, more info below. Please let me know if > there are any problems. > > Kalle > > [...] Here is the summary with links: - pull-request: wireless-next-2024-01-25 https://git.kernel.org/netdev/net-next/c/b54846da4594 You are awesome, thank you!
Jakub Kicinski <kuba@kernel.org> writes: > On Thu, 25 Jan 2024 10:40:30 +0000 (UTC) Kalle Valo wrote: >> The first "new features" pull request for v6.9. We have only driver >> changes this time and most of them are for Realtek drivers. Really >> nice to see activity in Broadcom drivers again. > > minor thing for a follow up: > > drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49: > warning: no newline at end of file Oh, sorry about that. Any tips how to detect this?
On January 26, 2024 7:01:18 AM Kalle Valo <kvalo@kernel.org> wrote: > Jakub Kicinski <kuba@kernel.org> writes: > >> On Thu, 25 Jan 2024 10:40:30 +0000 (UTC) Kalle Valo wrote: >>> The first "new features" pull request for v6.9. We have only driver >>> changes this time and most of them are for Realtek drivers. Really >>> nice to see activity in Broadcom drivers again. >> >> minor thing for a follow up: >> >> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49: >> warning: no newline at end of file > > Oh, sorry about that. Any tips how to detect this? I thought checkpatch would signal that or is it a sparse warning. Anyway, I can fix it. Gr. AvS > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Arend Van Spriel <arend.vanspriel@broadcom.com> writes: > On January 26, 2024 7:01:18 AM Kalle Valo <kvalo@kernel.org> wrote: > >> Jakub Kicinski <kuba@kernel.org> writes: >> >>> On Thu, 25 Jan 2024 10:40:30 +0000 (UTC) Kalle Valo wrote: >>>> The first "new features" pull request for v6.9. We have only driver >>>> changes this time and most of them are for Realtek drivers. Really >>>> nice to see activity in Broadcom drivers again. >>> >>> minor thing for a follow up: >>> >>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49: >>> warning: no newline at end of file >> >> Oh, sorry about that. Any tips how to detect this? > > I thought checkpatch would signal that or is it a sparse warning. I don't run checkpatch except for ath10k/ath11k/ath12k, too much noise. I ended up adding this to my script: for file in $(git ls-tree -r --name-only HEAD drivers/net/wireless/ net/wireless/ net/mac80211/); do if [ "$(tail -c 1 $file | cat -E)" != "$" ]; then echo $file: no newline at end of file; fi; done > Anyway, I can fix it. Thanks!
On Fri, 26 Jan 2024 12:05:17 +0200 Kalle Valo wrote: > > I thought checkpatch would signal that or is it a sparse warning. > > I don't run checkpatch except for ath10k/ath11k/ath12k, too much noise. > I ended up adding this to my script: We run build with sparse and W=1 and then diff the number of warnings to weed out the pre-existing ones, FWIW.
Jakub Kicinski <kuba@kernel.org> writes: > On Fri, 26 Jan 2024 12:05:17 +0200 Kalle Valo wrote: >> > I thought checkpatch would signal that or is it a sparse warning. >> >> I don't run checkpatch except for ath10k/ath11k/ath12k, too much noise. >> I ended up adding this to my script: > > We run build with sparse and W=1 and then diff the number of warnings > to weed out the pre-existing ones, FWIW. So for wireless and wireless-next I now check W=1 warnings every time I push. We are mostly warning free now but I'm not checking the linker warnings, for example the current MODULE_DESCRIPTION() warnings. It's really annoying, and extra work, that people enable new W=1 warnings before fixing them. Could we somehow push back on those and require that warnings are fixed before enabling with W=1 level? In wireless there is a significant number of sparse warnings. I have tried the cleanup people to fix them but it seems there's no interest, instead we get to receive pointless cleanups wasting our time. <loud sigh> BTW the 'no new line at end of file' warning is indeed from sparse, like Arend suspected: drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49: warning: no newline at end of file
On Sat, 27 Jan 2024 12:08:59 +0200 Kalle Valo wrote: > Jakub Kicinski <kuba@kernel.org> writes: > >> I don't run checkpatch except for ath10k/ath11k/ath12k, too much noise. > >> I ended up adding this to my script: > > > > We run build with sparse and W=1 and then diff the number of warnings > > to weed out the pre-existing ones, FWIW. > > So for wireless and wireless-next I now check W=1 warnings every time I > push. We are mostly warning free now but I'm not checking the linker > warnings, for example the current MODULE_DESCRIPTION() warnings. > > It's really annoying, and extra work, that people enable new W=1 > warnings before fixing them. Could we somehow push back on those and > require that warnings are fixed before enabling with W=1 level? My quite possibly incorrect understanding is that "giving people time to fix" is the main point of W=1 :( W=2 is for stuff which may false positive, W=1 is for stuff which does not false positive but we can't enable it in formal builds because the tree is full of it. > In wireless there is a significant number of sparse warnings. I have > tried the cleanup people to fix them but it seems there's no interest, > instead we get to receive pointless cleanups wasting our time. <loud sigh> Tell me about it.. :) > BTW the 'no new line at end of file' warning is indeed from sparse, like > Arend suspected: > > drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49: warning: no newline at end of file BTW I'd happy to help you set up an instance of our build testing bot, if you have a VM that can be used. It does take a bit of care and feeding, but seeing the build failures in patchwork pays the time back.
Jakub Kicinski <kuba@kernel.org> writes: > On Sat, 27 Jan 2024 12:08:59 +0200 Kalle Valo wrote: >> Jakub Kicinski <kuba@kernel.org> writes: >> >> I don't run checkpatch except for ath10k/ath11k/ath12k, too much noise. >> >> I ended up adding this to my script: >> > >> > We run build with sparse and W=1 and then diff the number of warnings >> > to weed out the pre-existing ones, FWIW. >> >> So for wireless and wireless-next I now check W=1 warnings every time I >> push. We are mostly warning free now but I'm not checking the linker >> warnings, for example the current MODULE_DESCRIPTION() warnings. >> >> It's really annoying, and extra work, that people enable new W=1 >> warnings before fixing them. Could we somehow push back on those and >> require that warnings are fixed before enabling with W=1 level? > > My quite possibly incorrect understanding is that "giving people time > to fix" is the main point of W=1 :( W=2 is for stuff which may false > positive, W=1 is for stuff which does not false positive but we can't > enable it in formal builds because the tree is full of it. Ok, so keeping the code clean from W=1 warnings will be hard :/ >> In wireless there is a significant number of sparse warnings. I have >> tried the cleanup people to fix them but it seems there's no interest, >> instead we get to receive pointless cleanups wasting our time. <loud sigh> > > Tell me about it.. :) > >> BTW the 'no new line at end of file' warning is indeed from sparse, like >> Arend suspected: >> >> drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil.c:432:49: >> warning: no newline at end of file > > BTW I'd happy to help you set up an instance of our build testing bot, > if you have a VM that can be used. It does take a bit of care and > feeding, but seeing the build failures in patchwork pays the time back. We have talked about setting up your build bot for linux-wireless patchwork project but never found the time to do anything. Also we don't have a VM for it right now.