[PATCH net-next 01/11] atm: horizon: shut up clang null pointer arithmetic warning

[PATCH net-next 01/11] atm: horizon: shut up clang null pointer arithmetic warning

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

Building a "W=1" kernel with clang produces a warning about
suspicous pointer arithmetic:

drivers/atm/horizon.c:1844:52: warning: performing pointer arithmetic
on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
  for (mem = (HDW *) memmap; mem < (HDW *) (memmap + 1); ++mem)

The way that the addresses are handled is very obscure, and
rewriting it to be more conventional seems fairly pointless, given
that this driver probably has no users.
Shut up this warning by adding a cast to uintptr_t.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/atm/horizon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/atm/horizon.c b/drivers/atm/horizon.c
index 4f2951cbe69c..cd368786b216 100644
--- a/drivers/atm/horizon.c
+++ b/drivers/atm/horizon.c
@@ -1841,7 +1841,7 @@ static int hrz_init(hrz_dev *dev)
   
   printk (" clearing memory");
   
-  for (mem = (HDW *) memmap; mem < (HDW *) (memmap + 1); ++mem)
+  for (mem = (HDW *) memmap; mem < (HDW *) ((uintptr_t)memmap + 1); ++mem)
     wr_mem (dev, mem, 0);
   
   printk (" tx channels");
-- 
2.27.0

[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

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

[PATCH net-next 03/11] rsxx: remove extraneous 'const' qualifier

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

The returned string from rsxx_card_state_to_str is 'const',
but the other qualifier doesn't change anything here except
causing a warning with 'clang -Wextra':

drivers/block/rsxx/core.c:393:21: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
static const char * const rsxx_card_state_to_str(unsigned int state)

Fixes: f37912039eb0 ("block: IBM RamSan 70/80 trivial changes.")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/block/rsxx/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
index 63f549889f87..d0af46d7b681 100644
--- a/drivers/block/rsxx/core.c
+++ b/drivers/block/rsxx/core.c
@@ -390,7 +390,7 @@ static irqreturn_t rsxx_isr(int irq, void *pdata)
 }
 
 /*----------------- Card Event Handler -------------------*/
-static const char * const rsxx_card_state_to_str(unsigned int state)
+static const char *rsxx_card_state_to_str(unsigned int state)
 {
 	static const char * const state_strings[] = {
 		"Unknown", "Shutdown", "Starting", "Formatting",
-- 
2.27.0

Re: [PATCH net-next 03/11] rsxx: remove extraneous 'const' qualifier

[Nick Desaulniers]

On Mon, Oct 26, 2020 at 2:31 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> The returned string from rsxx_card_state_to_str is 'const',
> but the other qualifier doesn't change anything here except
> causing a warning with 'clang -Wextra':
>
> drivers/block/rsxx/core.c:393:21: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
> static const char * const rsxx_card_state_to_str(unsigned int state)
>
> Fixes: f37912039eb0 ("block: IBM RamSan 70/80 trivial changes.")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

> ---
>  drivers/block/rsxx/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
> index 63f549889f87..d0af46d7b681 100644
> --- a/drivers/block/rsxx/core.c
> +++ b/drivers/block/rsxx/core.c
> @@ -390,7 +390,7 @@ static irqreturn_t rsxx_isr(int irq, void *pdata)
>  }
>
>  /*----------------- Card Event Handler -------------------*/
> -static const char * const rsxx_card_state_to_str(unsigned int state)
> +static const char *rsxx_card_state_to_str(unsigned int state)
>  {
>         static const char * const state_strings[] = {
>                 "Unknown", "Shutdown", "Starting", "Formatting",
> --
> 2.27.0
>


-- 
Thanks,
~Nick Desaulniers

Re: [PATCH net-next 03/11] rsxx: remove extraneous 'const' qualifier

[Joe Perches]

On Thu, 2020-10-29 at 12:34 -0700, Nick Desaulniers wrote:
> On Mon, Oct 26, 2020 at 2:31 PM Arnd Bergmann <arnd@kernel.org> wrote:
> > 
> > From: Arnd Bergmann <arnd@arndb.de>
> > 
> > The returned string from rsxx_card_state_to_str is 'const',
> > but the other qualifier doesn't change anything here except
> > causing a warning with 'clang -Wextra':
> > 
> > drivers/block/rsxx/core.c:393:21: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers]
> > static const char * const rsxx_card_state_to_str(unsigned int state)
> > 
> > Fixes: f37912039eb0 ("block: IBM RamSan 70/80 trivial changes.")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

Perhaps this should also be converted to avoid any possible
dereference of strings with an invalid state.
---
 drivers/block/rsxx/core.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/block/rsxx/core.c b/drivers/block/rsxx/core.c
index 8799e3bab067..f50b00b4887f 100644
--- a/drivers/block/rsxx/core.c
+++ b/drivers/block/rsxx/core.c
@@ -390,15 +390,27 @@ static irqreturn_t rsxx_isr(int irq, void *pdata)
 }
 
 /*----------------- Card Event Handler -------------------*/
-static const char * const rsxx_card_state_to_str(unsigned int state)
+static const char *rsxx_card_state_to_str(unsigned int state)
 {
 	static const char * const state_strings[] = {
-		"Unknown", "Shutdown", "Starting", "Formatting",
-		"Uninitialized", "Good", "Shutting Down",
-		"Fault", "Read Only Fault", "dStroying"
+		"Unknown",		/* no bit set - all zeros */
+		"Shutdown",		/* BIT(0) */
+		"Starting",		/* BIT(1) */
+		"Formatting",		/* BIT(2) */
+		"Uninitialized",	/* BIT(3) */
+		"Good",			/* BIT(4) */
+		"Shutting Down",	/* BIT(5) */
+		"Fault",		/* BIT(6) */
+		"Read Only Fault",	/* BIT(7) */
+		"Destroying"		/* BIT(8) */
 	};
 
-	return state_strings[ffs(state)];
+	int i = ffs(state);
+
+	if (i >= ARRAY_SIZE(state_strings))
+		return "Invalid state";
+
+	return state_strings[i];
 }
 
 static void card_state_change(struct rsxx_cardinfo *card,
 

[PATCH net-next 04/11] wimax: fix duplicate initializer warning

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

gcc -Wextra points out multiple fields that use the same index '1'
in the wimax_gnl_policy definition:

net/wimax/stack.c:393:29: warning: initialized field overwritten [-Woverride-init]
net/wimax/stack.c:397:28: warning: initialized field overwritten [-Woverride-init]
net/wimax/stack.c:398:26: warning: initialized field overwritten [-Woverride-init]

This seems to work since all four use the same NLA_U32 value, but it
still appears to be wrong. In addition, there is no intializer for
WIMAX_GNL_MSG_PIPE_NAME, which uses the same index '2' as
WIMAX_GNL_RFKILL_STATE.

Johannes already changed this twice to improve it, but I don't think
there is a good solution, so try to work around it by using a
numeric index and adding comments.

Cc: Johannes Berg <johannes.berg@intel.com>
Fixes: 3b0f31f2b8c9 ("genetlink: make policy common to family")
Fixes: b61a5eea5904 ("wimax: use genl_register_family_with_ops()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 net/wimax/stack.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/net/wimax/stack.c b/net/wimax/stack.c
index b6dd9d956ed8..3a62af3f80bf 100644
--- a/net/wimax/stack.c
+++ b/net/wimax/stack.c
@@ -388,17 +388,24 @@ void wimax_dev_init(struct wimax_dev *wimax_dev)
 }
 EXPORT_SYMBOL_GPL(wimax_dev_init);
 
+/*
+ * There are multiple enums reusing the same values, adding
+ * others is only possible if they use a compatible policy.
+ */
 static const struct nla_policy wimax_gnl_policy[WIMAX_GNL_ATTR_MAX + 1] = {
-	[WIMAX_GNL_RESET_IFIDX] = { .type = NLA_U32, },
-	[WIMAX_GNL_RFKILL_IFIDX] = { .type = NLA_U32, },
-	[WIMAX_GNL_RFKILL_STATE] = {
-		.type = NLA_U32		/* enum wimax_rf_state */
-	},
-	[WIMAX_GNL_STGET_IFIDX] = { .type = NLA_U32, },
-	[WIMAX_GNL_MSG_IFIDX] = { .type = NLA_U32, },
-	[WIMAX_GNL_MSG_DATA] = {
-		.type = NLA_UNSPEC,	/* libnl doesn't grok BINARY yet */
-	},
+	/*
+	 * WIMAX_GNL_RESET_IFIDX, WIMAX_GNL_RFKILL_IFIDX,
+	 * WIMAX_GNL_STGET_IFIDX, WIMAX_GNL_MSG_IFIDX
+	 */
+	[1] = { .type = NLA_U32, },
+	/*
+	 * WIMAX_GNL_RFKILL_STATE, WIMAX_GNL_MSG_PIPE_NAME
+	 */
+	[2] = { .type = NLA_U32, }, /* enum wimax_rf_state */
+	/*
+	 * WIMAX_GNL_MSG_DATA
+	 */
+	[3] = { .type = NLA_UNSPEC, }, /* libnl doesn't grok BINARY yet */
 };
 
 static const struct genl_small_ops wimax_gnl_ops[] = {
-- 
2.27.0

Re: [PATCH net-next 04/11] wimax: fix duplicate initializer warning

[Johannes Berg]

On Mon, 2020-10-26 at 22:29 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> gcc -Wextra points out multiple fields that use the same index '1'
> in the wimax_gnl_policy definition:
> 
> net/wimax/stack.c:393:29: warning: initialized field overwritten [-Woverride-init]
> net/wimax/stack.c:397:28: warning: initialized field overwritten [-Woverride-init]
> net/wimax/stack.c:398:26: warning: initialized field overwritten [-Woverride-init]
> 
> This seems to work since all four use the same NLA_U32 value, but it
> still appears to be wrong. In addition, there is no intializer for
> WIMAX_GNL_MSG_PIPE_NAME, which uses the same index '2' as
> WIMAX_GNL_RFKILL_STATE.

That's funny. This means that WIMAX_GNL_MSG_PIPE_NAME was never used,
since it is meant to be a string, and that won't (usually) fit into 4
bytes...

I suppose that's all an artifact of wimax being completely and utterly
dead anyway. We should probably just remove it.

> Johannes already changed this twice to improve it, but I don't think
> there is a good solution, so try to work around it by using a
> numeric index and adding comments.

Yeah, though maybe there's a better solution now.

Given that we (again and properly) have per-ops policy support, which
really was the thing that broke it here (the commit 3b0f31f2b8c9 you
mentioned), we could split this up into per-ops policies and do the
right thing in the separate policies.

OTOH, that really just makes it use more space, for no discernible
effect to userspace.


So as far as the warning fix is concerned:

Acked-by: Johannes Berg <johannes@sipsolutions.net>


Looks like I introduced a bug there with WIMAX_GNL_MSG_PIPE_NAME, but
obviously nobody cared.

johannes

Re: [PATCH net-next 04/11] wimax: fix duplicate initializer warning

[Arnd Bergmann]

On Tue, Oct 27, 2020 at 8:22 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Mon, 2020-10-26 at 22:29 +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > gcc -Wextra points out multiple fields that use the same index '1'
> > in the wimax_gnl_policy definition:
> >
> > net/wimax/stack.c:393:29: warning: initialized field overwritten [-Woverride-init]
> > net/wimax/stack.c:397:28: warning: initialized field overwritten [-Woverride-init]
> > net/wimax/stack.c:398:26: warning: initialized field overwritten [-Woverride-init]
> >
> > This seems to work since all four use the same NLA_U32 value, but it
> > still appears to be wrong. In addition, there is no intializer for
> > WIMAX_GNL_MSG_PIPE_NAME, which uses the same index '2' as
> > WIMAX_GNL_RFKILL_STATE.
>
> That's funny. This means that WIMAX_GNL_MSG_PIPE_NAME was never used,
> since it is meant to be a string, and that won't (usually) fit into 4
> bytes...
>
> I suppose that's all an artifact of wimax being completely and utterly
> dead anyway. We should probably just remove it.

Makes sense. I checked
https://en.wikipedia.org/wiki/List_of_WiMAX_networks, and it appears
that these entries are all stale, after everyone has migrated to LTE
or discontinued their service altogether.

NetworkManager appears to have dropped userspace support in 2015
https://bugzilla.gnome.org/show_bug.cgi?id=747846, the
www.linuxwimax.org site had already shut down earlier.

WiMax is apparently still being deployed on airport campus
networks ("AeroMACS"), but in a frequency band that was not
supported by the old Intel 2400m (used in Sandy Bridge laptops
and earlier), which is the only driver using the kernel's wimax
stack.

Inaky, do you have any additional information about possible
users? If we are sure there are none, then I'd suggest removing
all the wimax code directly, otherwise it could go through
drivers/staging/ for a release or two (and move it back in case
there are users after all). I can send a patch if you like.

> So as far as the warning fix is concerned:
>
> Acked-by: Johannes Berg <johannes@sipsolutions.net>
>

Thanks!

        Arnd

Re: [PATCH net-next 04/11] wimax: fix duplicate initializer warning

[Perez-Gonzalez, Inaky]

> From: Arnd Bergmann <arnd@kernel.org>
> 
> Makes sense. I checked
> https://en.wikipedia.org/wiki/List_of_WiMAX_networks, and it appears
> that these entries are all stale, after everyone has migrated to LTE
> or discontinued their service altogether.
> 
> NetworkManager appears to have dropped userspace support in 2015
> https://bugzilla.gnome.org/show_bug.cgi?id=747846, the
> www.linuxwimax.org site had already shut down earlier.
> 
> WiMax is apparently still being deployed on airport campus
> networks ("AeroMACS"), but in a frequency band that was not
> supported by the old Intel 2400m (used in Sandy Bridge laptops
> and earlier), which is the only driver using the kernel's wimax
> stack.
> 
> Inaky, do you have any additional information about possible
> users? If we are sure there are none, then I'd suggest removing
> all the wimax code directly, otherwise it could go through
> drivers/staging/ for a release or two (and move it back in case
> there are users after all). I can send a patch if you like.

I have not

Every now and then I get the occasional message from a student or
researcher asking for support about a production network, but they
have dwindled in the last years.

My vote would be to scrap the whole thing; if there are die hard
users, they can always rise up and move it back from staging.

[PATCH net-next 05/11] wimax/i2400m/control: fix enum warning

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

gcc -Wextra warns about mixing two enum types:

drivers/net/wimax/i2400m/control.c: In function 'i2400m_get_device_info':
drivers/net/wimax/i2400m/control.c:960:10: warning: implicit conversion from 'enum <anonymous>' to 'enum i2400m_tlv' [-Wenum-conversion]

Merge the anonymous enum into the global one that has all the other
values. It's not clear why they were originally kept separate, but this
appears to be the logical place for it.

Fixes: 3a35a1d0bdf7 ("i2400m: various functions for device management")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/wimax/i2400m/control.c | 7 -------
 include/uapi/linux/wimax/i2400m.h  | 1 +
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/net/wimax/i2400m/control.c b/drivers/net/wimax/i2400m/control.c
index 8df98757d901..180d5f417bdc 100644
--- a/drivers/net/wimax/i2400m/control.c
+++ b/drivers/net/wimax/i2400m/control.c
@@ -903,13 +903,6 @@ int i2400m_cmd_enter_powersave(struct i2400m *i2400m)
 EXPORT_SYMBOL_GPL(i2400m_cmd_enter_powersave);
 
 
-/*
- * Definitions for getting device information
- */
-enum {
-	I2400M_TLV_DETAILED_DEVICE_INFO = 140
-};
-
 /**
  * i2400m_get_device_info - Query the device for detailed device information
  *
diff --git a/include/uapi/linux/wimax/i2400m.h b/include/uapi/linux/wimax/i2400m.h
index fd198bc24a3c..595ab3511d45 100644
--- a/include/uapi/linux/wimax/i2400m.h
+++ b/include/uapi/linux/wimax/i2400m.h
@@ -409,6 +409,7 @@ enum i2400m_ms {
  */
 enum i2400m_tlv {
 	I2400M_TLV_L4_MESSAGE_VERSIONS = 129,
+	I2400M_TLV_DETAILED_DEVICE_INFO = 140,
 	I2400M_TLV_SYSTEM_STATE = 141,
 	I2400M_TLV_MEDIA_STATUS = 161,
 	I2400M_TLV_RF_OPERATION = 162,
-- 
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

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]

[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

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
> 

[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

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 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 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

[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 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 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

[PATCH net-next 10/11] ch_ktls: fix enum-conversion warning

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

gcc points out an incorrect enum assignment:

drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c: In function 'chcr_ktls_cpl_set_tcb_rpl':
drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c:684:22: warning: implicit conversion from 'enum <anonymous>' to 'enum ch_ktls_open_state' [-Wenum-conversion]

This appears harmless, and should apparently use 'CH_KTLS_OPEN_SUCCESS'
instead of 'false', with the same value '0'.

Fixes: efca3878a5fb ("ch_ktls: Issue if connection offload fails")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c b/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
index 5195f692f14d..83787f62577d 100644
--- a/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
+++ b/drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c
@@ -681,7 +681,7 @@ static int chcr_ktls_cpl_set_tcb_rpl(struct adapter *adap, unsigned char *input)
 		kvfree(tx_info);
 		return 0;
 	}
-	tx_info->open_state = false;
+	tx_info->open_state = CH_KTLS_OPEN_SUCCESS;
 	spin_unlock(&tx_info->lock);
 
 	complete(&tx_info->completion);
-- 
2.27.0

Re: [PATCH net-next 10/11] ch_ktls: fix enum-conversion warning

[Andrew Lunn]

On Mon, Oct 26, 2020 at 10:29:57PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> gcc points out an incorrect enum assignment:
> 
> drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c: In function 'chcr_ktls_cpl_set_tcb_rpl':
> drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c:684:22: warning: implicit conversion from 'enum <anonymous>' to 'enum ch_ktls_open_state' [-Wenum-conversion]
> 
> This appears harmless, and should apparently use 'CH_KTLS_OPEN_SUCCESS'
> instead of 'false', with the same value '0'.
> 
> Fixes: efca3878a5fb ("ch_ktls: Issue if connection offload fails")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Hi Arnd

I have the same fix in my tree of W=1 fixes. I was just waiting for
net-next to open.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

[PATCH net-next 11/11] ipv6: fix type mismatch warning

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

Building with 'make W=2' shows a warning for every time this header
gets included because of a pointer type mismatch:

net/addrconf.h:163:32: warning: passing 'unsigned char *' to parameter of type 'const char *' converts between pointers to integer
types with different sign [-Wpointer-sign]
        addrconf_addr_eui48_base(eui, dev->dev_addr);

Change the type to unsigned according to the input argument.

Fixes: 4d6f28591fe4 ("{net,IB}/{rxe,usnic}: Utilize generic mac to eui32 function")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/net/addrconf.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 18f783dcd55f..074ce761e482 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -127,7 +127,8 @@ int addrconf_prefix_rcv_add_addr(struct net *net, struct net_device *dev,
 				 u32 addr_flags, bool sllao, bool tokenized,
 				 __u32 valid_lft, u32 prefered_lft);
 
-static inline void addrconf_addr_eui48_base(u8 *eui, const char *const addr)
+static inline void addrconf_addr_eui48_base(u8 *eui,
+					    const unsigned char *const addr)
 {
 	memcpy(eui, addr, 3);
 	eui[3] = 0xFF;
@@ -135,7 +136,7 @@ static inline void addrconf_addr_eui48_base(u8 *eui, const char *const addr)
 	memcpy(eui + 5, addr + 3, 3);
 }
 
-static inline void addrconf_addr_eui48(u8 *eui, const char *const addr)
+static inline void addrconf_addr_eui48(u8 *eui, const unsigned char *const addr)
 {
 	addrconf_addr_eui48_base(eui, addr);
 	eui[0] ^= 2;
-- 
2.27.0

Re: [PATCH net-next 01/11] atm: horizon: shut up clang null pointer arithmetic warning

[Xie He]

> -  for (mem = (HDW *) memmap; mem < (HDW *) (memmap + 1); ++mem)
> +  for (mem = (HDW *) memmap; mem < (HDW *) ((uintptr_t)memmap + 1); ++mem)

Note that these two lines are semantically different. In the first line,
"+ 1" moves the pointer by (sizeof memmap) bytes. However in the second
line, "+ 1" moves the pointer by only 1 byte.

This driver is old, but let's still keep its code correct!

Re: [PATCH net-next 01/11] atm: horizon: shut up clang null pointer arithmetic warning

[Xie He]

On Mon, Oct 26, 2020 at 8:56 PM Xie He <xie.he.0141@gmail.com> wrote:
>
> > -  for (mem = (HDW *) memmap; mem < (HDW *) (memmap + 1); ++mem)
> > +  for (mem = (HDW *) memmap; mem < (HDW *) ((uintptr_t)memmap + 1); ++mem)
>
> Note that these two lines are semantically different. In the first line,
> "+ 1" moves the pointer by (sizeof memmap) bytes. However in the second
> line, "+ 1" moves the pointer by only 1 byte.

Correction: in the first line "+ 1" moves the pointer by (sizeof *memmap) bytes.

Re: [PATCH net-next 01/11] atm: horizon: shut up clang null pointer arithmetic warning

[Arnd Bergmann]

On Tue, Oct 27, 2020 at 5:02 AM Xie He <xie.he.0141@gmail.com> wrote:
>
> On Mon, Oct 26, 2020 at 8:56 PM Xie He <xie.he.0141@gmail.com> wrote:
> >
> > > -  for (mem = (HDW *) memmap; mem < (HDW *) (memmap + 1); ++mem)
> > > +  for (mem = (HDW *) memmap; mem < (HDW *) ((uintptr_t)memmap + 1); ++mem)
> >
> > Note that these two lines are semantically different. In the first line,
> > "+ 1" moves the pointer by (sizeof memmap) bytes. However in the second
> > line, "+ 1" moves the pointer by only 1 byte.
>
> Correction: in the first line "+ 1" moves the pointer by (sizeof *memmap) bytes.

Ah, of course. I had looked up the types but mixed up the memmap
and HDW definitions, but then got confused trying to understand the
logic in wr_mem() that operates on bytes but expands them into
multiples of 4.

I've modified it as below now, will resend along with the other patches
if you think this makes sense.

        Arnd

--- a/drivers/atm/horizon.c
+++ b/drivers/atm/horizon.c
@@ -1815,7 +1815,7 @@ static int hrz_init(hrz_dev *dev)

   int buff_count;

-  HDW * mem;
+  uintptr_t offset;

   cell_buf * tx_desc;
   cell_buf * rx_desc;
@@ -1841,8 +1841,8 @@ static int hrz_init(hrz_dev *dev)

   printk (" clearing memory");

-  for (mem = (HDW *) memmap; mem < (HDW *) (memmap + 1); ++mem)
-    wr_mem (dev, mem, 0);
+  for (offset = 0; offset < sizeof(struct MEMMAP); offset++)
+    wr_mem (dev, (HDW *)offset, 0);

   printk (" tx channels");

Re: [PATCH net-next 01/11] atm: horizon: shut up clang null pointer arithmetic warning

[Xie He]

On Tue, Oct 27, 2020 at 6:24 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> Ah, of course. I had looked up the types but mixed up the memmap
> and HDW definitions, but then got confused trying to understand the
> logic in wr_mem() that operates on bytes but expands them into
> multiples of 4.

I think wr_mem() doesn't try to expand the address into multiples of
4. The address is multiplied by "sizeof(HDW)", which is 1. So the
address is not expanded.

I think this driver uses 0-based pointers not as byte-addresses to
access the host memory, but as (32-bit) word-addresses to access the
special hardware address space.

So using pointers in this case is confusing because it makes people
incorrectly consider they are used to access the host memory. It'd be
better that we just use integers.

> I've modified it as below now, will resend along with the other patches
> if you think this makes sense.
>
>         Arnd
>
> --- a/drivers/atm/horizon.c
> +++ b/drivers/atm/horizon.c
> @@ -1815,7 +1815,7 @@ static int hrz_init(hrz_dev *dev)
>
>    int buff_count;
>
> -  HDW * mem;
> +  uintptr_t offset;
>
>    cell_buf * tx_desc;
>    cell_buf * rx_desc;
> @@ -1841,8 +1841,8 @@ static int hrz_init(hrz_dev *dev)
>
>    printk (" clearing memory");
>
> -  for (mem = (HDW *) memmap; mem < (HDW *) (memmap + 1); ++mem)
> -    wr_mem (dev, mem, 0);
> +  for (offset = 0; offset < sizeof(struct MEMMAP); offset++)
> +    wr_mem (dev, (HDW *)offset, 0);
>
>    printk (" tx channels");

This looks good to me. Thanks!

Re: [PATCH net-next 01/11] atm: horizon: shut up clang null pointer arithmetic warning

[Jakub Kicinski]

On Mon, 26 Oct 2020 22:29:48 +0100 Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> Building a "W=1" kernel with clang produces a warning about
> suspicous pointer arithmetic:
> 
> drivers/atm/horizon.c:1844:52: warning: performing pointer arithmetic
> on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
>   for (mem = (HDW *) memmap; mem < (HDW *) (memmap + 1); ++mem)
> 
> The way that the addresses are handled is very obscure, and
> rewriting it to be more conventional seems fairly pointless, given
> that this driver probably has no users.
> Shut up this warning by adding a cast to uintptr_t.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Hi!

I'm not sure what your plan is for re-spinning but when you do could
you please split the wireless changes out? Also we never got patch 3
IDK if that's a coincidence or if it wasn't for networking...

Re: [PATCH net-next 01/11] atm: horizon: shut up clang null pointer arithmetic warning

[Arnd Bergmann]

On Wed, Oct 28, 2020 at 1:42 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon, 26 Oct 2020 22:29:48 +0100 Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > Building a "W=1" kernel with clang produces a warning about
> > suspicous pointer arithmetic:
> >
> > drivers/atm/horizon.c:1844:52: warning: performing pointer arithmetic
> > on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
> >   for (mem = (HDW *) memmap; mem < (HDW *) (memmap + 1); ++mem)
> >
> > The way that the addresses are handled is very obscure, and
> > rewriting it to be more conventional seems fairly pointless, given
> > that this driver probably has no users.
> > Shut up this warning by adding a cast to uintptr_t.
> >
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Hi!
>
> I'm not sure what your plan is for re-spinning but when you do could
> you please split the wireless changes out?

Sure, will do. The easiest for me would be if you just merge the ones
that have been acked or that look obvious enough for you, and I'll
then resend whatever is left after addressing the review comments.

If that causes you extra work, I'll just send everything that should go
through your tree.

> Also we never got patch 3
> IDK if that's a coincidence or if it wasn't for networking...

Yes, that one slipped in when I was sorting my longer series, it
was a block driver change.

      Arnd