mbox series

pull-request: wireless-next-2024-01-25

Message ID 20240125104030.B6CA6C433C7@smtp.kernel.org (mailing list archive)
State Not Applicable
Headers show
Series pull-request: wireless-next-2024-01-25 | expand

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git tags/wireless-next-2024-01-25

Message

Kalle Valo Jan. 25, 2024, 10:40 a.m. UTC
Hi,

here's a pull request to net-next tree, more info below. Please let me know if
there are any problems.

Kalle

The following changes since commit 3fbf61207c66ff7ac9b60ab76d4bfd239f97e973:

  Revert "mlx5 updates 2023-12-20" (2024-01-07 17:16:11 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git tags/wireless-next-2024-01-25

for you to fetch changes up to acf868ff60b1cd1f2e597f0b15aee2ff43f9fcd3:

  wifi: iwlegacy: Use kcalloc() instead of kzalloc() (2024-01-23 13:51:24 +0200)

----------------------------------------------------------------
wireless-next patches for v6.9

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.

Major changes:

rtwl8xxxu

* RTL8188F: concurrent interface support

* Channel Switch Announcement (CSA) support in AP mode

brcmfmac

* per-vendor feature support

* per-vendor SAE password setup

rtlwifi

* speed up USB firmware initialisation

----------------------------------------------------------------
Ajay Singh (4):
      wifi: wilc1000: fix driver_handler when committing initial configuration
      wifi: wilc1000: do not realloc workqueue everytime an interface is added
      wifi: wilc1000: fix incorrect power down sequence
      wifi: wilc1000: fix multi-vif management when deleting a vif

Alexis Lothoré (2):
      wifi: wilc1000: fix declarations ordering
      wifi: wilc1000: fix RCU usage in connect path

Arend van Spriel (5):
      wifi: brcmfmac: export firmware interface functions
      wifi: brcmfmac: add per-vendor feature detection callback
      wifi: brcmfmac: move feature overrides before feature_disable
      wifi: brcmfmac: avoid invalid list operation when vendor attach fails
      wifi: brcmfmac: allow per-vendor event handling

Artem Chernyshev (1):
      wifi: brcmsmac: phy: Remove unreachable code

Bitterblue Smith (5):
      wifi: rtl8xxxu: Fix LED control code of RTL8192FU
      wifi: rtl8xxxu: Fix off by one initial RTS rate
      wifi: rtlwifi: rtl_usb: Use sync register writes
      wifi: rtlwifi: rtl8192de: Don't read register in _rtl92de_query_rxphystatus
      wifi: rtlwifi: Speed up firmware loading for USB

Cheng-Chieh Hsieh (1):
      wifi: rtw89: 8922a: update the register used in DIG and the DIG flow

Chih-Kang Chang (2):
      wifi: rtw89: fix HW scan timeout due to TSF sync issue
      wifi: rtw89: fix disabling concurrent mode TX hang issue

Chin-Yen Lee (1):
      wifi: rtw89: pci: use DBI function for 8852AE/8852BE/8851BE

Chung-Hsuan Hung (3):
      wifi: rtw89: phy: add parser to support RX gain dynamic setting flow
      wifi: rtw89: 8922a: set RX gain along with set_channel operation
      wifi: rtw89: 8922a: add BTG functions to assist BT coexistence to control TX/RX

Colin Ian King (1):
      wifi: rtw89: mac: Fix spelling mistakes "notfify" -> "notify"

Dmitry Antipov (3):
      wifi: rtlwifi: cleanup few rtlxxx_tx_fill_desc() routines
      wifi: rtw88: use kstrtoX_from_user() in debugfs handlers
      wifi: rt2x00: simplify rt2x00crypto_rx_insert_iv()

Erick Archer (1):
      wifi: iwlegacy: Use kcalloc() instead of kzalloc()

Hector Martin (2):
      wifi: brcmfmac: cfg80211: Use WSEC to set SAE password
      wifi: brcmfmac: Demote vendor-specific attach/detach messages to info

Jinjie Ruan (1):
      wifi: mwifiex: debugfs: Drop unnecessary error check for debugfs_create_dir()

Martin Kaistra (24):
      wifi: rtl8xxxu: remove assignment of priv->vif in rtl8xxxu_bss_info_changed()
      wifi: rtl8xxxu: prepare supporting two virtual interfaces
      wifi: rtl8xxxu: support setting linktype for both interfaces
      wifi: rtl8xxxu: 8188e: convert usage of priv->vif to priv->vifs[0]
      wifi: rtl8xxxu: support setting mac address register for both interfaces
      wifi: rtl8xxxu: extend wifi connected check to both interfaces
      wifi: rtl8xxxu: extend check for matching bssid to both interfaces
      wifi: rtl8xxxu: don't parse CFO, if both interfaces are connected in STA mode
      wifi: rtl8xxxu: support setting bssid register for multiple interfaces
      wifi: rtl8xxxu: support multiple interfaces in set_aifs()
      wifi: rtl8xxxu: support multiple interfaces in update_beacon_work_callback()
      wifi: rtl8xxxu: support multiple interfaces in configure_filter()
      wifi: rtl8xxxu: support multiple interfaces in watchdog_callback()
      wifi: rtl8xxxu: support multiple interfaces in {add,remove}_interface()
      wifi: rtl8xxxu: support multiple interfaces in bss_info_changed()
      wifi: rtl8xxxu: support multiple interface in start_ap()
      wifi: rtl8xxxu: add macids for STA mode
      wifi: rtl8xxxu: remove obsolete priv->vif
      wifi: rtl8xxxu: add hw crypto support for AP mode
      wifi: rtl8xxxu: make supporting AP mode only on port 0 transparent
      wifi: rtl8xxxu: declare concurrent mode support for 8188f
      wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work
      wifi: rtl8xxxu: enable channel switch support
      wifi: rtl8xxxu: add missing number of sec cam entries for all variants

Ping-Ke Shih (35):
      wifi: rtw89: phy: move bb_gain_info used by WiFi 6 chips to union
      wifi: rtw89: phy: ignore special data from BB parameter file
      wifi: rtw89: 8922a: add NCTL pre-settings for WiFi 7 chips
      wifi: rtw89: phy: add BB wrapper of TX power for WiFi 7 chips
      wifi: rtw89: phy: set channel_info for WiFi 7 chips
      wifi: rtw88: 8822ce: refine power parameters for RFE type 5
      wifi: rtw89: add firmware H2C command of BA CAM V1
      wifi: rtw89: mac: add feature_init to initialize BA CAM V1
      wifi: rtw89: add chip_ops::h2c_ba_cam() to configure BA CAM
      wifi: rtw89: 8922a: update BA CAM number to 24
      wifi: rtw89: fw: use struct to fill BA CAM H2C commands
      wifi: rtw89: refine H2C command that pause transmitting by MAC ID
      wifi: rtw89: add new H2C command to pause/sleep transmitting by MAC ID
      wifi: rtw89: use struct to fill H2C command to download beacon frame
      wifi: rtw89: add H2C command to download beacon frame for WiFi 7 chips
      wifi: rtw89: add chip_ops::update_beacon to abstract update beacon operation
      wifi: rtw89: adjust init_he_cap() to add EHT cap into iftype_data
      wifi: rtw89: change supported bandwidths of chip_info to bit mask
      wifi: rtw89: add EHT capabilities for WiFi 7 chips
      wifi: rtw89: declare EXT NSS BW of VHT capability
      wifi: rtw89: fw: add H2C command to update security CAM v2
      wifi: rtw89: fw: fill CMAC table to associated station for WiFi 7 chips
      wifi: rtw89: fw: add chip_ops to update CMAC table to associated station
      wifi: rtw89: fw: update TX AMPDU parameter to CMAC table
      wifi: rtw89: fw: add H2C command to reset CMAC table for WiFi 7
      wifi: rtw89: fw: add H2C command to reset DMAC table for WiFi 7
      wifi: rtw89: fw: use struct to fill JOIN H2C command
      wifi: rtw89: fw: extend JOIN H2C command to support WiFi 7 chips
      wifi: rtl8xxxu: convert EN_DESC_ID of TX descriptor to le32 type
      wifi: rtl8xxxu: make instances of iface limit and combination to be static const
      wifi: rtw89: add mlo_dbcc_mode for WiFi 7 chips
      wifi: rtw89: 8922a: add chip_ops::{enable,disable}_bb_rf
      wifi: rtw89: 8922a: add chip_ops related to BB init
      wifi: rtw89: 8922a: add register definitions of H2C, C2H, page, RRSR and EDCCA
      wifi: rtw89: 8922a: add TX power related ops

Po-Hao Huang (6):
      wifi: rtw89: refine add_chan H2C command to encode_bits
      wifi: rtw89: refine hardware scan C2H events
      wifi: rtw89: Set default CQM config if not present
      wifi: rtw89: disable RTS when broadcast/multicast
      wifi: rtw89: fix null pointer access when abort scan
      wifi: rtw89: add wait/completion for abort scan

Rahul Rameshbabu (4):
      wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
      wifi: b43: Stop/wake correct queue in PIO Tx path when QoS is disabled
      wifi: b43: Stop correct queue in DMA worker when QoS is disabled
      wifi: b43: Disable QoS for bcm4331

Ruan Jinjie (1):
      wifi: mwifiex: Use helpers to check multicast addresses

Zheng Wang (1):
      wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach

Zong-Zhe Yang (2):
      wifi: rtw89: 8852b: update TX power tables to R36
      wifi: rtw89: 8851b: update TX power tables to R37

 drivers/net/wireless/broadcom/b43/b43.h            |  16 +
 drivers/net/wireless/broadcom/b43/dma.c            |   4 +-
 drivers/net/wireless/broadcom/b43/main.c           |  16 +-
 drivers/net/wireless/broadcom/b43/pio.c            |   6 +-
 .../broadcom/brcm80211/brcmfmac/bca/core.c         |  30 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.c         |  64 +-
 .../broadcom/brcm80211/brcmfmac/cfg80211.h         |   2 +
 .../wireless/broadcom/brcm80211/brcmfmac/common.c  |  18 +-
 .../wireless/broadcom/brcm80211/brcmfmac/core.c    |  12 +-
 .../wireless/broadcom/brcm80211/brcmfmac/core.h    |   2 +-
 .../broadcom/brcm80211/brcmfmac/cyw/core.c         |  50 +-
 .../wireless/broadcom/brcm80211/brcmfmac/feature.c |  11 +-
 .../wireless/broadcom/brcm80211/brcmfmac/fweh.c    | 154 +++-
 .../wireless/broadcom/brcm80211/brcmfmac/fweh.h    |  60 +-
 .../wireless/broadcom/brcm80211/brcmfmac/fwil.c    | 116 +--
 .../wireless/broadcom/brcm80211/brcmfmac/fwil.h    | 125 ++-
 .../broadcom/brcm80211/brcmfmac/fwil_types.h       |   2 +-
 .../wireless/broadcom/brcm80211/brcmfmac/fwvid.c   |  13 +-
 .../wireless/broadcom/brcm80211/brcmfmac/fwvid.h   |  48 +-
 .../broadcom/brcm80211/brcmfmac/wcc/core.c         |  31 +-
 .../broadcom/brcm80211/brcmsmac/phy/phy_cmn.c      |   3 +-
 .../broadcom/brcm80211/brcmsmac/phy/phy_int.h      |   2 +-
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c        |  11 +-
 drivers/net/wireless/intel/iwlegacy/common.c       |   4 +-
 drivers/net/wireless/marvell/mwifiex/cfg80211.c    |   2 +-
 drivers/net/wireless/marvell/mwifiex/debugfs.c     |   3 -
 drivers/net/wireless/marvell/mwifiex/wmm.c         |   2 +-
 drivers/net/wireless/microchip/wilc1000/cfg80211.c |  12 +-
 drivers/net/wireless/microchip/wilc1000/hif.c      |  40 +-
 drivers/net/wireless/microchip/wilc1000/netdev.c   |  12 +-
 drivers/net/wireless/microchip/wilc1000/wlan.c     |  35 +-
 drivers/net/wireless/microchip/wilc1000/wlan.h     |   6 +
 drivers/net/wireless/ralink/rt2x00/rt2x00crypto.c  |   5 +-
 drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h   |  20 +-
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c |   3 +-
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188f.c |   2 +
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192c.c |   1 +
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c |   1 +
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192f.c |  33 +-
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8710b.c |   1 +
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723a.c |   1 +
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c |   1 +
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c  | 409 +++++++--
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h  |  15 +
 drivers/net/wireless/realtek/rtlwifi/efuse.c       |  36 +-
 drivers/net/wireless/realtek/rtlwifi/efuse.h       |   4 +-
 drivers/net/wireless/realtek/rtlwifi/pci.c         |  12 +-
 .../net/wireless/realtek/rtlwifi/rtl8192ce/trx.c   |   4 -
 .../net/wireless/realtek/rtlwifi/rtl8192cu/sw.c    |   6 +-
 .../net/wireless/realtek/rtlwifi/rtl8192cu/trx.c   |   3 -
 .../net/wireless/realtek/rtlwifi/rtl8192de/trx.c   |   5 +-
 .../net/wireless/realtek/rtlwifi/rtl8723ae/trx.c   |   6 +-
 drivers/net/wireless/realtek/rtlwifi/usb.c         | 164 ++--
 drivers/net/wireless/realtek/rtlwifi/wifi.h        |  38 +-
 drivers/net/wireless/realtek/rtw88/debug.c         |  44 +-
 drivers/net/wireless/realtek/rtw88/pci.c           |   4 +
 drivers/net/wireless/realtek/rtw88/reg.h           |   3 +
 drivers/net/wireless/realtek/rtw89/cam.c           |  61 ++
 drivers/net/wireless/realtek/rtw89/cam.h           | 109 +++
 drivers/net/wireless/realtek/rtw89/chan.c          |   2 +-
 drivers/net/wireless/realtek/rtw89/core.c          | 344 +++++---
 drivers/net/wireless/realtek/rtw89/core.h          | 136 ++-
 drivers/net/wireless/realtek/rtw89/fw.c            | 944 ++++++++++++++++++---
 drivers/net/wireless/realtek/rtw89/fw.h            | 810 ++++++++++--------
 drivers/net/wireless/realtek/rtw89/mac.c           |  96 ++-
 drivers/net/wireless/realtek/rtw89/mac.h           |   5 +-
 drivers/net/wireless/realtek/rtw89/mac80211.c      |  18 +-
 drivers/net/wireless/realtek/rtw89/mac_be.c        |   4 +-
 drivers/net/wireless/realtek/rtw89/pci.c           |  69 +-
 drivers/net/wireless/realtek/rtw89/pci.h           |   1 +
 drivers/net/wireless/realtek/rtw89/phy.c           |  46 +-
 drivers/net/wireless/realtek/rtw89/phy.h           |  72 ++
 drivers/net/wireless/realtek/rtw89/phy_be.c        | 312 +++++++
 drivers/net/wireless/realtek/rtw89/reg.h           | 278 +++++-
 drivers/net/wireless/realtek/rtw89/rtw8851b.c      |  15 +-
 .../net/wireless/realtek/rtw89/rtw8851b_table.c    |  72 +-
 drivers/net/wireless/realtek/rtw89/rtw8852a.c      |  11 +-
 drivers/net/wireless/realtek/rtw89/rtw8852b.c      |  15 +-
 .../net/wireless/realtek/rtw89/rtw8852b_table.c    | 142 ++--
 drivers/net/wireless/realtek/rtw89/rtw8852c.c      |  14 +-
 drivers/net/wireless/realtek/rtw89/rtw8922a.c      | 705 ++++++++++++++-
 drivers/net/wireless/realtek/rtw89/wow.c           |   2 +-
 82 files changed, 4618 insertions(+), 1398 deletions(-)

Comments

Jakub Kicinski Jan. 26, 2024, 12:51 a.m. UTC | #1
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
patchwork-bot+netdevbpf@kernel.org Jan. 26, 2024, 1:10 a.m. UTC | #2
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!
Kalle Valo Jan. 26, 2024, 6:01 a.m. UTC | #3
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?
Arend van Spriel Jan. 26, 2024, 6:37 a.m. UTC | #4
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
Kalle Valo Jan. 26, 2024, 10:05 a.m. UTC | #5
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!
Jakub Kicinski Jan. 26, 2024, 6:52 p.m. UTC | #6
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.
Kalle Valo Jan. 27, 2024, 10:08 a.m. UTC | #7
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
Jakub Kicinski Jan. 29, 2024, 7:55 p.m. UTC | #8
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.
Kalle Valo Feb. 13, 2024, 3:27 p.m. UTC | #9
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.