[PATCH net-next 02/11] net: hostap: fix function cast warning

[PATCH net-next 02/11] net: hostap: fix function cast warning

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

gcc -Wextra complains about the function type cast:

drivers/net/wireless/intersil/hostap/hostap_hw.c:3173:48: warning: cast between incompatible function types from ‘void (*)(struct tasklet_struct *)’ to ‘void (*)(long unsigned int)’ [-Wcast-function-type]

Avoid this by just using the regular tasklet_setup() function instead
of the incorrect homegrown version.

Fixes: 7433c9690318 ("intersil: convert tasklets to use new tasklet_setup() API")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 .../net/wireless/intersil/hostap/hostap_hw.c    | 17 +++++------------
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/intersil/hostap/hostap_hw.c b/drivers/net/wireless/intersil/hostap/hostap_hw.c
index 22cfb6452644..9a19046217df 100644
--- a/drivers/net/wireless/intersil/hostap/hostap_hw.c
+++ b/drivers/net/wireless/intersil/hostap/hostap_hw.c
@@ -3169,22 +3169,15 @@ prism2_init_local_data(struct prism2_helper_functions *funcs, int card_idx,
 
 	/* Initialize tasklets for handling hardware IRQ related operations
 	 * outside hw IRQ handler */
-#define HOSTAP_TASKLET_INIT(q, f, d) \
-do { memset((q), 0, sizeof(*(q))); (q)->func = (void(*)(unsigned long))(f); } \
-while (0)
-	HOSTAP_TASKLET_INIT(&local->bap_tasklet, hostap_bap_tasklet,
-			    (unsigned long) local);
-
-	HOSTAP_TASKLET_INIT(&local->info_tasklet, hostap_info_tasklet,
-			    (unsigned long) local);
+	tasklet_setup(&local->bap_tasklet, hostap_bap_tasklet);
+	tasklet_setup(&local->info_tasklet, hostap_info_tasklet);
 	hostap_info_init(local);
 
-	HOSTAP_TASKLET_INIT(&local->rx_tasklet,
-			    hostap_rx_tasklet, (unsigned long) local);
+	tasklet_setup(&local->rx_tasklet, hostap_rx_tasklet);
 	skb_queue_head_init(&local->rx_list);
 
-	HOSTAP_TASKLET_INIT(&local->sta_tx_exc_tasklet,
-			    hostap_sta_tx_exc_tasklet, (unsigned long) local);
+	tasklet_setup(&local->sta_tx_exc_tasklet,
+			    hostap_sta_tx_exc_tasklet);
 	skb_queue_head_init(&local->sta_tx_exc_list);
 
 	INIT_LIST_HEAD(&local->cmd_queue);
-- 
2.27.0

[PATCH net-next 06/11] rtlwifi: fix -Wpointer-sign warning

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

There are thousands of warnings in a W=2 build from just one file:

drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.c:3788:15: warning: pointer targets in initialization of 'u8 *' {aka 'unsigned char *'} from 'char *' differ in signedness [-Wpointer-sign]

Change the types to consistently use 'const char *' for the
strings.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 .../wireless/realtek/rtlwifi/rtl8821ae/phy.c  | 81 ++++++++++---------
 .../realtek/rtlwifi/rtl8821ae/table.c         |  4 +-
 .../realtek/rtlwifi/rtl8821ae/table.h         |  4 +-
 3 files changed, 45 insertions(+), 44 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
index f41a7643b9c4..119e0f799826 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c
@@ -1581,7 +1581,7 @@ static void _rtl8821ae_phy_txpower_by_rate_configuration(struct ieee80211_hw *hw
 }
 
 /* string is in decimal */
-static bool _rtl8812ae_get_integer_from_string(char *str, u8 *pint)
+static bool _rtl8812ae_get_integer_from_string(const char *str, u8 *pint)
 {
 	u16 i = 0;
 	*pint = 0;
@@ -1599,7 +1599,7 @@ static bool _rtl8812ae_get_integer_from_string(char *str, u8 *pint)
 	return true;
 }
 
-static bool _rtl8812ae_eq_n_byte(u8 *str1, u8 *str2, u32 num)
+static bool _rtl8812ae_eq_n_byte(const char *str1, const char *str2, u32 num)
 {
 	if (num == 0)
 		return false;
@@ -1637,10 +1637,11 @@ static s8 _rtl8812ae_phy_get_chnl_idx_of_txpwr_lmt(struct ieee80211_hw *hw,
 	return channel_index;
 }
 
-static void _rtl8812ae_phy_set_txpower_limit(struct ieee80211_hw *hw, u8 *pregulation,
-				      u8 *pband, u8 *pbandwidth,
-				      u8 *prate_section, u8 *prf_path,
-				      u8 *pchannel, u8 *ppower_limit)
+static void _rtl8812ae_phy_set_txpower_limit(struct ieee80211_hw *hw,
+				      const char *pregulation,
+				      const char *pband, const char *pbandwidth,
+				      const char *prate_section, const char *prf_path,
+				      const char *pchannel, const char *ppower_limit)
 {
 	struct rtl_priv *rtlpriv = rtl_priv(hw);
 	struct rtl_phy *rtlphy = &rtlpriv->phy;
@@ -1648,8 +1649,8 @@ static void _rtl8812ae_phy_set_txpower_limit(struct ieee80211_hw *hw, u8 *pregul
 	u8 channel_index;
 	s8 power_limit = 0, prev_power_limit, ret;
 
-	if (!_rtl8812ae_get_integer_from_string((char *)pchannel, &channel) ||
-	    !_rtl8812ae_get_integer_from_string((char *)ppower_limit,
+	if (!_rtl8812ae_get_integer_from_string(pchannel, &channel) ||
+	    !_rtl8812ae_get_integer_from_string(ppower_limit,
 						&power_limit)) {
 		rtl_dbg(rtlpriv, COMP_INIT, DBG_TRACE,
 			"Illegal index of pwr_lmt table [chnl %d][val %d]\n",
@@ -1659,42 +1660,42 @@ static void _rtl8812ae_phy_set_txpower_limit(struct ieee80211_hw *hw, u8 *pregul
 	power_limit = power_limit > MAX_POWER_INDEX ?
 		      MAX_POWER_INDEX : power_limit;
 
-	if (_rtl8812ae_eq_n_byte(pregulation, (u8 *)("FCC"), 3))
+	if (_rtl8812ae_eq_n_byte(pregulation, "FCC", 3))
 		regulation = 0;
-	else if (_rtl8812ae_eq_n_byte(pregulation, (u8 *)("MKK"), 3))
+	else if (_rtl8812ae_eq_n_byte(pregulation, "MKK", 3))
 		regulation = 1;
-	else if (_rtl8812ae_eq_n_byte(pregulation, (u8 *)("ETSI"), 4))
+	else if (_rtl8812ae_eq_n_byte(pregulation, "ETSI", 4))
 		regulation = 2;
-	else if (_rtl8812ae_eq_n_byte(pregulation, (u8 *)("WW13"), 4))
+	else if (_rtl8812ae_eq_n_byte(pregulation, "WW13", 4))
 		regulation = 3;
 
-	if (_rtl8812ae_eq_n_byte(prate_section, (u8 *)("CCK"), 3))
+	if (_rtl8812ae_eq_n_byte(prate_section, "CCK", 3))
 		rate_section = 0;
-	else if (_rtl8812ae_eq_n_byte(prate_section, (u8 *)("OFDM"), 4))
+	else if (_rtl8812ae_eq_n_byte(prate_section, "OFDM", 4))
 		rate_section = 1;
-	else if (_rtl8812ae_eq_n_byte(prate_section, (u8 *)("HT"), 2) &&
-		 _rtl8812ae_eq_n_byte(prf_path, (u8 *)("1T"), 2))
+	else if (_rtl8812ae_eq_n_byte(prate_section, "HT", 2) &&
+		 _rtl8812ae_eq_n_byte(prf_path, "1T", 2))
 		rate_section = 2;
-	else if (_rtl8812ae_eq_n_byte(prate_section, (u8 *)("HT"), 2) &&
-		 _rtl8812ae_eq_n_byte(prf_path, (u8 *)("2T"), 2))
+	else if (_rtl8812ae_eq_n_byte(prate_section, "HT", 2) &&
+		 _rtl8812ae_eq_n_byte(prf_path, "2T", 2))
 		rate_section = 3;
-	else if (_rtl8812ae_eq_n_byte(prate_section, (u8 *)("VHT"), 3) &&
-		 _rtl8812ae_eq_n_byte(prf_path, (u8 *)("1T"), 2))
+	else if (_rtl8812ae_eq_n_byte(prate_section, "VHT", 3) &&
+		 _rtl8812ae_eq_n_byte(prf_path, "1T", 2))
 		rate_section = 4;
-	else if (_rtl8812ae_eq_n_byte(prate_section, (u8 *)("VHT"), 3) &&
-		 _rtl8812ae_eq_n_byte(prf_path, (u8 *)("2T"), 2))
+	else if (_rtl8812ae_eq_n_byte(prate_section, "VHT", 3) &&
+		 _rtl8812ae_eq_n_byte(prf_path, "2T", 2))
 		rate_section = 5;
 
-	if (_rtl8812ae_eq_n_byte(pbandwidth, (u8 *)("20M"), 3))
+	if (_rtl8812ae_eq_n_byte(pbandwidth, "20M", 3))
 		bandwidth = 0;
-	else if (_rtl8812ae_eq_n_byte(pbandwidth, (u8 *)("40M"), 3))
+	else if (_rtl8812ae_eq_n_byte(pbandwidth, "40M", 3))
 		bandwidth = 1;
-	else if (_rtl8812ae_eq_n_byte(pbandwidth, (u8 *)("80M"), 3))
+	else if (_rtl8812ae_eq_n_byte(pbandwidth, "80M", 3))
 		bandwidth = 2;
-	else if (_rtl8812ae_eq_n_byte(pbandwidth, (u8 *)("160M"), 4))
+	else if (_rtl8812ae_eq_n_byte(pbandwidth, "160M", 4))
 		bandwidth = 3;
 
-	if (_rtl8812ae_eq_n_byte(pband, (u8 *)("2.4G"), 4)) {
+	if (_rtl8812ae_eq_n_byte(pband, "2.4G", 4)) {
 		ret = _rtl8812ae_phy_get_chnl_idx_of_txpwr_lmt(hw,
 							       BAND_ON_2_4G,
 							       channel);
@@ -1718,7 +1719,7 @@ static void _rtl8812ae_phy_set_txpower_limit(struct ieee80211_hw *hw, u8 *pregul
 			regulation, bandwidth, rate_section, channel_index,
 			rtlphy->txpwr_limit_2_4g[regulation][bandwidth]
 				[rate_section][channel_index][RF90_PATH_A]);
-	} else if (_rtl8812ae_eq_n_byte(pband, (u8 *)("5G"), 2)) {
+	} else if (_rtl8812ae_eq_n_byte(pband, "5G", 2)) {
 		ret = _rtl8812ae_phy_get_chnl_idx_of_txpwr_lmt(hw,
 							       BAND_ON_5G,
 							       channel);
@@ -1749,10 +1750,10 @@ static void _rtl8812ae_phy_set_txpower_limit(struct ieee80211_hw *hw, u8 *pregul
 }
 
 static void _rtl8812ae_phy_config_bb_txpwr_lmt(struct ieee80211_hw *hw,
-					  u8 *regulation, u8 *band,
-					  u8 *bandwidth, u8 *rate_section,
-					  u8 *rf_path, u8 *channel,
-					  u8 *power_limit)
+					  const char *regulation, const char *band,
+					  const char *bandwidth, const char *rate_section,
+					  const char *rf_path, const char *channel,
+					  const char *power_limit)
 {
 	_rtl8812ae_phy_set_txpower_limit(hw, regulation, band, bandwidth,
 					 rate_section, rf_path, channel,
@@ -1765,7 +1766,7 @@ static void _rtl8821ae_phy_read_and_config_txpwr_lmt(struct ieee80211_hw *hw)
 	struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
 	u32 i = 0;
 	u32 array_len;
-	u8 **array;
+	const char **array;
 
 	if (rtlhal->hw_type == HARDWARE_TYPE_RTL8812AE) {
 		array_len = RTL8812AE_TXPWR_LMT_ARRAY_LEN;
@@ -1778,13 +1779,13 @@ static void _rtl8821ae_phy_read_and_config_txpwr_lmt(struct ieee80211_hw *hw)
 	rtl_dbg(rtlpriv, COMP_INIT, DBG_TRACE, "\n");
 
 	for (i = 0; i < array_len; i += 7) {
-		u8 *regulation = array[i];
-		u8 *band = array[i+1];
-		u8 *bandwidth = array[i+2];
-		u8 *rate = array[i+3];
-		u8 *rf_path = array[i+4];
-		u8 *chnl = array[i+5];
-		u8 *val = array[i+6];
+		const char *regulation = array[i];
+		const char *band = array[i+1];
+		const char *bandwidth = array[i+2];
+		const char *rate = array[i+3];
+		const char *rf_path = array[i+4];
+		const char *chnl = array[i+5];
+		const char *val = array[i+6];
 
 		_rtl8812ae_phy_config_bb_txpwr_lmt(hw, regulation, band,
 						   bandwidth, rate, rf_path,
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.c
index 85093b3e5373..27c8a5d96520 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.c
@@ -2654,7 +2654,7 @@ u32 RTL8821AE_AGC_TAB_1TARRAYLEN = ARRAY_SIZE(RTL8821AE_AGC_TAB_ARRAY);
 *                           TXPWR_LMT.TXT
 ******************************************************************************/
 
-u8 *RTL8812AE_TXPWR_LMT[] = {
+const char *RTL8812AE_TXPWR_LMT[] = {
 	"FCC", "2.4G", "20M", "CCK", "1T", "01", "36",
 	"ETSI", "2.4G", "20M", "CCK", "1T", "01", "32",
 	"MKK", "2.4G", "20M", "CCK", "1T", "01", "32",
@@ -3223,7 +3223,7 @@ u8 *RTL8812AE_TXPWR_LMT[] = {
 
 u32 RTL8812AE_TXPWR_LMT_ARRAY_LEN = ARRAY_SIZE(RTL8812AE_TXPWR_LMT);
 
-u8 *RTL8821AE_TXPWR_LMT[] = {
+const char *RTL8821AE_TXPWR_LMT[] = {
 	"FCC", "2.4G", "20M", "CCK", "1T", "01", "32",
 	"ETSI", "2.4G", "20M", "CCK", "1T", "01", "32",
 	"MKK", "2.4G", "20M", "CCK", "1T", "01", "32",
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.h b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.h
index 540159c25078..76c62b7c0fb2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.h
@@ -28,7 +28,7 @@ extern u32 RTL8821AE_AGC_TAB_ARRAY[];
 extern u32 RTL8812AE_AGC_TAB_1TARRAYLEN;
 extern u32 RTL8812AE_AGC_TAB_ARRAY[];
 extern u32 RTL8812AE_TXPWR_LMT_ARRAY_LEN;
-extern u8 *RTL8812AE_TXPWR_LMT[];
+extern const char *RTL8812AE_TXPWR_LMT[];
 extern u32 RTL8821AE_TXPWR_LMT_ARRAY_LEN;
-extern u8 *RTL8821AE_TXPWR_LMT[];
+extern const char *RTL8821AE_TXPWR_LMT[];
 #endif
-- 
2.27.0

[PATCH net-next 07/11] rtw88: remove extraneous 'const' qualifier

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

clang -Wextra warns about functions returning a 'const' integer:

drivers/net/wireless/realtek/rtw88/rtw8822b.c:90:8: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
static const u8 rtw8822b_get_swing_index(struct rtw_dev *rtwdev)

Remove the extra qualifier here.

Fixes: c97ee3e0bea2 ("rtw88: add power tracking support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/wireless/realtek/rtw88/rtw8822b.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822b.c b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
index 22d0dd640ac9..b420eb914879 100644
--- a/drivers/net/wireless/realtek/rtw88/rtw8822b.c
+++ b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
@@ -87,7 +87,7 @@ static const u32 rtw8822b_txscale_tbl[RTW_TXSCALE_SIZE] = {
 	0x2d3, 0x2fe, 0x32b, 0x35c, 0x38e, 0x3c4, 0x3fe
 };
 
-static const u8 rtw8822b_get_swing_index(struct rtw_dev *rtwdev)
+static u8 rtw8822b_get_swing_index(struct rtw_dev *rtwdev)
 {
 	u8 i = 0;
 	u32 swing, table_value;
-- 
2.27.0

[PATCH net-next 08/11] ath9k: work around false-positive gcc warning

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

gcc-10 shows a false-positive warning with CONFIG_KASAN:

drivers/net/wireless/ath/ath9k/dynack.c: In function 'ath_dynack_sample_tx_ts':
include/linux/etherdevice.h:290:14: warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=]
  290 |  *(u32 *)dst = *(const u32 *)src;
      |  ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~

Until gcc is fixed, work around this by using memcpy() in place
of ether_addr_copy(). Hopefully gcc-11 will not have this problem.

Link: https://godbolt.org/z/sab1MK
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/wireless/ath/ath9k/dynack.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/dynack.c b/drivers/net/wireless/ath/ath9k/dynack.c
index fbeb4a739d32..e4eb96b26ca4 100644
--- a/drivers/net/wireless/ath/ath9k/dynack.c
+++ b/drivers/net/wireless/ath/ath9k/dynack.c
@@ -247,8 +247,14 @@ void ath_dynack_sample_tx_ts(struct ath_hw *ah, struct sk_buff *skb,
 	ridx = ts->ts_rateindex;
 
 	da->st_rbf.ts[da->st_rbf.t_rb].tstamp = ts->ts_tstamp;
+#if defined(CONFIG_KASAN) && (CONFIG_GCC_VERSION >= 100000) && (CONFIG_GCC_VERSION < 110000)
+	/* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490 */
+	memcpy(da->st_rbf.addr[da->st_rbf.t_rb].h_dest, hdr->addr1, ETH_ALEN);
+	memcpy(da->st_rbf.addr[da->st_rbf.t_rb].h_src, hdr->addr2, ETH_ALEN);
+#else
 	ether_addr_copy(da->st_rbf.addr[da->st_rbf.t_rb].h_dest, hdr->addr1);
 	ether_addr_copy(da->st_rbf.addr[da->st_rbf.t_rb].h_src, hdr->addr2);
+#endif
 
 	if (!(info->status.rates[ridx].flags & IEEE80211_TX_RC_MCS)) {
 		const struct ieee80211_rate *rate;
-- 
2.27.0

[PATCH net-next 09/11] ath6kl: fix enum-conversion warning

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

gcc -Wextra points out a type mismatch

drivers/net/wireless/ath/ath6kl/wmi.c: In function 'ath6kl_wmi_cmd_send':
drivers/net/wireless/ath/ath6kl/wmi.c:1825:19: warning: implicit conversion from 'enum <anonymous>' to 'enum wmi_data_hdr_data_type' [-Wenum-conversion]
 1825 |            false, false, 0, NULL, if_idx);
      |                   ^~~~~

As far as I can tell, the numeric value is current here,
so just use the correct enum literal instead of 'false'.

Fixes: bdcd81707973 ("Add ath6kl cleaned up driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/wireless/ath/ath6kl/wmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c b/drivers/net/wireless/ath/ath6kl/wmi.c
index dbc47702a268..b137e7f34397 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -1821,8 +1821,8 @@ int ath6kl_wmi_cmd_send(struct wmi *wmi, u8 if_idx, struct sk_buff *skb,
 
 	/* Only for OPT_TX_CMD, use BE endpoint. */
 	if (cmd_id == WMI_OPT_TX_FRAME_CMDID) {
-		ret = ath6kl_wmi_data_hdr_add(wmi, skb, OPT_MSGTYPE,
-					      false, false, 0, NULL, if_idx);
+		ret = ath6kl_wmi_data_hdr_add(wmi, skb, OPT_MSGTYPE, false,
+				WMI_DATA_HDR_DATA_TYPE_802_3, 0, NULL, if_idx);
 		if (ret) {
 			dev_kfree_skb(skb);
 			return ret;
-- 
2.27.0

Re: [PATCH net-next 06/11] rtlwifi: fix -Wpointer-sign warning

[Pkshih]

On Mon, 2020-10-26 at 22:29 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> There are thousands of warnings in a W=2 build from just one file:
> 
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.c:3788:15: warning:
> pointer targets in initialization of 'u8 *' {aka 'unsigned char *'} from 'char
> *' differ in signedness [-Wpointer-sign]
> 
> Change the types to consistently use 'const char *' for the
> strings.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Ping-Ke Shih <pkshih@realtek.com>

> ---
>  .../wireless/realtek/rtlwifi/rtl8821ae/phy.c  | 81 ++++++++++---------
>  .../realtek/rtlwifi/rtl8821ae/table.c         |  4 +-
>  .../realtek/rtlwifi/rtl8821ae/table.h         |  4 +-
>  3 files changed, 45 insertions(+), 44 deletions(-)
> 

[snip]

Re: [PATCH net-next 07/11] rtw88: remove extraneous 'const' qualifier

[Nathan Chancellor]

On Mon, Oct 26, 2020 at 10:29:54PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> clang -Wextra warns about functions returning a 'const' integer:
> 
> drivers/net/wireless/realtek/rtw88/rtw8822b.c:90:8: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
> static const u8 rtw8822b_get_swing_index(struct rtw_dev *rtwdev)
> 
> Remove the extra qualifier here.
> 
> Fixes: c97ee3e0bea2 ("rtw88: add power tracking support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>

> ---
>  drivers/net/wireless/realtek/rtw88/rtw8822b.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822b.c b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
> index 22d0dd640ac9..b420eb914879 100644
> --- a/drivers/net/wireless/realtek/rtw88/rtw8822b.c
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8822b.c
> @@ -87,7 +87,7 @@ static const u32 rtw8822b_txscale_tbl[RTW_TXSCALE_SIZE] = {
>  	0x2d3, 0x2fe, 0x32b, 0x35c, 0x38e, 0x3c4, 0x3fe
>  };
>  
> -static const u8 rtw8822b_get_swing_index(struct rtw_dev *rtwdev)
> +static u8 rtw8822b_get_swing_index(struct rtw_dev *rtwdev)
>  {
>  	u8 i = 0;
>  	u32 swing, table_value;
> -- 
> 2.27.0
> 

Re: [PATCH net-next 09/11] ath6kl: fix enum-conversion warning

[Kalle Valo]

Arnd Bergmann <arnd@kernel.org> writes:

> From: Arnd Bergmann <arnd@arndb.de>
>
> gcc -Wextra points out a type mismatch
>
> drivers/net/wireless/ath/ath6kl/wmi.c: In function 'ath6kl_wmi_cmd_send':
> drivers/net/wireless/ath/ath6kl/wmi.c:1825:19: warning: implicit conversion from 'enum <anonymous>' to 'enum wmi_data_hdr_data_type' [-Wenum-conversion]
>  1825 |            false, false, 0, NULL, if_idx);
>       |                   ^~~~~
>
> As far as I can tell, the numeric value is current here,
> so just use the correct enum literal instead of 'false'.
>
> Fixes: bdcd81707973 ("Add ath6kl cleaned up driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Looks good to me. I'll take this to my ath.git tree.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH net-next 08/11] ath9k: work around false-positive gcc warning

[Kalle Valo]

Arnd Bergmann <arnd@kernel.org> writes:

> From: Arnd Bergmann <arnd@arndb.de>
>
> gcc-10 shows a false-positive warning with CONFIG_KASAN:
>
> drivers/net/wireless/ath/ath9k/dynack.c: In function 'ath_dynack_sample_tx_ts':
> include/linux/etherdevice.h:290:14: warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=]
>   290 |  *(u32 *)dst = *(const u32 *)src;
>       |  ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
>
> Until gcc is fixed, work around this by using memcpy() in place
> of ether_addr_copy(). Hopefully gcc-11 will not have this problem.
>
> Link: https://godbolt.org/z/sab1MK
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/net/wireless/ath/ath9k/dynack.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath9k/dynack.c b/drivers/net/wireless/ath/ath9k/dynack.c
> index fbeb4a739d32..e4eb96b26ca4 100644
> --- a/drivers/net/wireless/ath/ath9k/dynack.c
> +++ b/drivers/net/wireless/ath/ath9k/dynack.c
> @@ -247,8 +247,14 @@ void ath_dynack_sample_tx_ts(struct ath_hw *ah, struct sk_buff *skb,
>  	ridx = ts->ts_rateindex;
>  
>  	da->st_rbf.ts[da->st_rbf.t_rb].tstamp = ts->ts_tstamp;
> +#if defined(CONFIG_KASAN) && (CONFIG_GCC_VERSION >= 100000) && (CONFIG_GCC_VERSION < 110000)
> +	/* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490 */
> +	memcpy(da->st_rbf.addr[da->st_rbf.t_rb].h_dest, hdr->addr1, ETH_ALEN);
> +	memcpy(da->st_rbf.addr[da->st_rbf.t_rb].h_src, hdr->addr2, ETH_ALEN);
> +#else
>  	ether_addr_copy(da->st_rbf.addr[da->st_rbf.t_rb].h_dest, hdr->addr1);
>  	ether_addr_copy(da->st_rbf.addr[da->st_rbf.t_rb].h_src, hdr->addr2);
> +#endif

Isn't there a better way to handle this? I really would not want
checking for GCC versions become a common approach in drivers.

I even think that using memcpy() always is better than the ugly ifdef.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH net-next 08/11] ath9k: work around false-positive gcc warning

[Johannes Berg]

On Mon, 2020-11-02 at 18:26 +0200, Kalle Valo wrote:
> Arnd Bergmann <arnd@kernel.org> writes:
> 
> > From: Arnd Bergmann <arnd@arndb.de>
> > 
> > gcc-10 shows a false-positive warning with CONFIG_KASAN:
> > 
> > drivers/net/wireless/ath/ath9k/dynack.c: In function 'ath_dynack_sample_tx_ts':
> > include/linux/etherdevice.h:290:14: warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=]
> >   290 |  *(u32 *)dst = *(const u32 *)src;
> >       |  ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
> > 
> > Until gcc is fixed, work around this by using memcpy() in place
> > of ether_addr_copy(). Hopefully gcc-11 will not have this problem.
> > 
> > Link: https://godbolt.org/z/sab1MK
> > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > ---
> >  drivers/net/wireless/ath/ath9k/dynack.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/net/wireless/ath/ath9k/dynack.c b/drivers/net/wireless/ath/ath9k/dynack.c
> > index fbeb4a739d32..e4eb96b26ca4 100644
> > --- a/drivers/net/wireless/ath/ath9k/dynack.c
> > +++ b/drivers/net/wireless/ath/ath9k/dynack.c
> > @@ -247,8 +247,14 @@ void ath_dynack_sample_tx_ts(struct ath_hw *ah, struct sk_buff *skb,
> >  	ridx = ts->ts_rateindex;
> >  
> >  	da->st_rbf.ts[da->st_rbf.t_rb].tstamp = ts->ts_tstamp;
> > +#if defined(CONFIG_KASAN) && (CONFIG_GCC_VERSION >= 100000) && (CONFIG_GCC_VERSION < 110000)
> > +	/* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490 */
> > +	memcpy(da->st_rbf.addr[da->st_rbf.t_rb].h_dest, hdr->addr1, ETH_ALEN);
> > +	memcpy(da->st_rbf.addr[da->st_rbf.t_rb].h_src, hdr->addr2, ETH_ALEN);
> > +#else
> >  	ether_addr_copy(da->st_rbf.addr[da->st_rbf.t_rb].h_dest, hdr->addr1);
> >  	ether_addr_copy(da->st_rbf.addr[da->st_rbf.t_rb].h_src, hdr->addr2);
> > +#endif
> 
> Isn't there a better way to handle this? I really would not want
> checking for GCC versions become a common approach in drivers.
> 
> I even think that using memcpy() always is better than the ugly ifdef.

If you put memcpy() always somebody will surely go and clean it up to
use ether_addr_copy() soon ...

That said, if there's a gcc issue with ether_addr_copy() then how come
it's specific to this place?

johannes

Re: [PATCH net-next 08/11] ath9k: work around false-positive gcc warning

[Arnd Bergmann]

On Mon, Nov 2, 2020 at 7:01 PM Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2020-11-02 at 18:26 +0200, Kalle Valo wrote:
> > Arnd Bergmann <arnd@kernel.org> writes:
> > > From: Arnd Bergmann <arnd@arndb.de>
> >
> > Isn't there a better way to handle this? I really would not want
> > checking for GCC versions become a common approach in drivers.
> >
> > I even think that using memcpy() always is better than the ugly ifdef.
>
> If you put memcpy() always somebody will surely go and clean it up to
> use ether_addr_copy() soon ...
>
> That said, if there's a gcc issue with ether_addr_copy() then how come
> it's specific to this place?

I have not been able to figure this out, hopefully some gcc developer
eventually looks at the bug in more detail.

Presumably it has something to do with the specific way the five levels
of structures are nested here, and how things get inlined in this driver.
If the bug happened everywhere, it would likely have been found and
fixed earlier.

       Arnd

Re: [PATCH net-next 09/11] ath6kl: fix enum-conversion warning

[Kalle Valo]

Arnd Bergmann <arnd@kernel.org> wrote:

> gcc -Wextra points out a type mismatch
> 
> drivers/net/wireless/ath/ath6kl/wmi.c: In function 'ath6kl_wmi_cmd_send':
> drivers/net/wireless/ath/ath6kl/wmi.c:1825:19: warning: implicit conversion from 'enum <anonymous>' to 'enum wmi_data_hdr_data_type' [-Wenum-conversion]
>  1825 |            false, false, 0, NULL, if_idx);
>       |                   ^~~~~
> 
> As far as I can tell, the numeric value is current here,
> so just use the correct enum literal instead of 'false'.
> 
> Fixes: bdcd81707973 ("Add ath6kl cleaned up driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

ce54bf5e9554 ath6kl: fix enum-conversion warning

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201026213040.3889546-9-arnd@kernel.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH net-next 08/11] ath9k: work around false-positive gcc warning

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> writes:

> On Mon, 2020-11-02 at 18:26 +0200, Kalle Valo wrote:
>> Arnd Bergmann <arnd@kernel.org> writes:
>> 
>> > From: Arnd Bergmann <arnd@arndb.de>
>> > 
>> > gcc-10 shows a false-positive warning with CONFIG_KASAN:
>> > 
>> > drivers/net/wireless/ath/ath9k/dynack.c: In function 'ath_dynack_sample_tx_ts':
>> > include/linux/etherdevice.h:290:14: warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=]
>> >   290 |  *(u32 *)dst = *(const u32 *)src;
>> >       |  ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
>> > 
>> > Until gcc is fixed, work around this by using memcpy() in place
>> > of ether_addr_copy(). Hopefully gcc-11 will not have this problem.
>> > 
>> > Link: https://godbolt.org/z/sab1MK
>> > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490
>> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> > ---
>> >  drivers/net/wireless/ath/ath9k/dynack.c | 6 ++++++
>> >  1 file changed, 6 insertions(+)
>> > 
>> > diff --git a/drivers/net/wireless/ath/ath9k/dynack.c b/drivers/net/wireless/ath/ath9k/dynack.c
>> > index fbeb4a739d32..e4eb96b26ca4 100644
>> > --- a/drivers/net/wireless/ath/ath9k/dynack.c
>> > +++ b/drivers/net/wireless/ath/ath9k/dynack.c
>> > @@ -247,8 +247,14 @@ void ath_dynack_sample_tx_ts(struct ath_hw *ah, struct sk_buff *skb,
>> >  	ridx = ts->ts_rateindex;
>> >  
>> >  	da->st_rbf.ts[da->st_rbf.t_rb].tstamp = ts->ts_tstamp;
>> > +#if defined(CONFIG_KASAN) && (CONFIG_GCC_VERSION >= 100000) && (CONFIG_GCC_VERSION < 110000)
>> > +	/* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490 */
>> > +	memcpy(da->st_rbf.addr[da->st_rbf.t_rb].h_dest, hdr->addr1, ETH_ALEN);
>> > +	memcpy(da->st_rbf.addr[da->st_rbf.t_rb].h_src, hdr->addr2, ETH_ALEN);
>> > +#else
>> >  	ether_addr_copy(da->st_rbf.addr[da->st_rbf.t_rb].h_dest, hdr->addr1);
>> >  	ether_addr_copy(da->st_rbf.addr[da->st_rbf.t_rb].h_src, hdr->addr2);
>> > +#endif
>> 
>> Isn't there a better way to handle this? I really would not want
>> checking for GCC versions become a common approach in drivers.
>> 
>> I even think that using memcpy() always is better than the ugly ifdef.
>
> If you put memcpy() always somebody will surely go and clean it up to
> use ether_addr_copy() soon ...

I can always add a comment and hope that the cleanup people read
comments :) I did that now in the pending branch:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=25cfc077bd7a798d1aa527ad2aa9932bb3284376

Does that look ok? I prefer that over the ifdef.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH net-next 08/11] ath9k: work around false-positive gcc warning

[Arnd Bergmann]

On Sat, Nov 7, 2020 at 12:21 PM Kalle Valo <kvalo@codeaurora.org> wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
> > On Mon, 2020-11-02 at 18:26 +0200, Kalle Valo wrote:
> >> Arnd Bergmann <arnd@kernel.org> writes:
> >> Isn't there a better way to handle this? I really would not want
> >> checking for GCC versions become a common approach in drivers.
> >>
> >> I even think that using memcpy() always is better than the ugly ifdef.
> >
> > If you put memcpy() always somebody will surely go and clean it up to
> > use ether_addr_copy() soon ...
>
> I can always add a comment and hope that the cleanup people read
> comments :) I did that now in the pending branch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=25cfc077bd7a798d1aa527ad2aa9932bb3284376
>
> Does that look ok? I prefer that over the ifdef.

Fine with me. My original reason for the compiler version check
was that we can eventually restore the previous version once the
compiler is fixed for long enough that all broken compilers are
too old to build the kernel, in maybe six years from now at the
current rate of deprecating old compilers.

       Arnd

Re: [PATCH net-next 02/11] net: hostap: fix function cast warning

[Kalle Valo]

Arnd Bergmann <arnd@kernel.org> wrote:

> From: Arnd Bergmann <arnd@arndb.de>
> 
> gcc -Wextra complains about the function type cast:
> 
> drivers/net/wireless/intersil/hostap/hostap_hw.c:3173:48: warning: cast between incompatible function types from ‘void (*)(struct tasklet_struct *)’ to ‘void (*)(long unsigned int)’ [-Wcast-function-type]
> 
> Avoid this by just using the regular tasklet_setup() function instead
> of the incorrect homegrown version.
> 
> Fixes: 7433c9690318 ("intersil: convert tasklets to use new tasklet_setup() API")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

3 patches applied to wireless-drivers-next.git, thanks.

9fdd02aa5988 net: hostap: fix function cast warning
ef41937631bf rtlwifi: fix -Wpointer-sign warning
6ac654697301 rtw88: remove extraneous 'const' qualifier

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201026213040.3889546-2-arnd@kernel.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH net-next 08/11] ath9k: work around false-positive gcc warning

[Kalle Valo]

Arnd Bergmann <arnd@kernel.org> wrote:

> gcc-10 shows a false-positive warning with CONFIG_KASAN:
> 
> drivers/net/wireless/ath/ath9k/dynack.c: In function 'ath_dynack_sample_tx_ts':
> include/linux/etherdevice.h:290:14: warning: writing 4 bytes into a region of size 0 [-Wstringop-overflow=]
>   290 |  *(u32 *)dst = *(const u32 *)src;
>       |  ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
> 
> Until gcc is fixed, work around this by using memcpy() in place
> of ether_addr_copy(). Hopefully gcc-11 will not have this problem.
> 
> Link: https://godbolt.org/z/sab1MK
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97490
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> [kvalo@codeaurora.org: remove ifdef and add a comment]
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>

Patch applied to ath-next branch of ath.git, thanks.

b96fab4e3602 ath9k: work around false-positive gcc warning

-- 
https://patchwork.kernel.org/project/linux-wireless/patch/20201026213040.3889546-8-arnd@kernel.org/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches