kernel.git/drivers/net/wireless/ti, branch linux-4.7.y

remove lots of IS_ERR_VALUE abuses

2016-05-27T22:26:11Z

Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann Cc: Andrzej Hajda Cc: Andrew Morton Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla # For nvmem part Signed-off-by: Linus Torvalds

wlcore/wl12xx: Fix fw logger over sdio

2016-05-11T18:26:15Z

The commit fb724ed5c617 ("wlcore: Fix regression in wlcore_set_partition()") fixed wl12xx functionality. However, it reverted the support in fw logger over sdio in wl18xx. This patch reverts the changes made and also fixes the original functionality issue introduced in wl12xx. Fixes: fb724ed5c617 ("wlcore: Fix regression in wlcore_set_partition()") Signed-off-by: Guy Mishol Signed-off-by: Kalle Valo

cfg80211: remove enum ieee80211_band

2016-04-12T13:56:15Z

This enum is already perfectly aliased to enum nl80211_band, and the only reason for it is that we get IEEE80211_NUM_BANDS out of it. There's no really good reason to not declare the number of bands in nl80211 though, so do that and remove the cfg80211 one. Signed-off-by: Johannes Berg

wl1251: use to_delayed_work()

2016-04-07T16:37:37Z

Use to_delayed_work() instead of open-coding it. Signed-off-by: Geliang Tang [Update commit message] Signed-off-by: Julian Calaby Signed-off-by: Kalle Valo

wlcore: use to_delayed_work()

2016-04-07T16:37:35Z

Use to_delayed_work() instead of open-coding it. Signed-off-by: Geliang Tang [Update commit message] Signed-off-by: Julian Calaby Signed-off-by: Kalle Valo

wl12xx: remove redundant null check on wl->scan.ssid

2016-04-06T18:39:23Z

ssid is an array of u8, so it can never be null, so the null check on wl->scan.ssid is redundant and can be removed. Signed-off-by: Colin Ian King Signed-off-by: Kalle Valo

wlcore/wl18xx: add radar_debug_mode handling

2016-03-10T13:00:23Z

Add debugfs key (under CFG80211_CERTIFICATION_ONUS configuration) to set/clear radar_debug_mode. In this mode, the driver simply ignores radar events (but prints them). The fw is notified about this mode through a special generic_cfg_feature command. This mode is relevant only for ap mode. look for it when initializing ap vif. Signed-off-by: Eliad Peller Signed-off-by: Kalle Valo

wlcore: don't WARN_ON in case of existing ROC

2016-03-10T13:00:20Z

When working with AP + P2P, it's possible to get into a state when the AP is in ROC (due to assiciating station) while trying to ROC on the P2P interface. Replace the WARN_ON with wl1271_error to avoid warnings in this case. Signed-off-by: Eliad Peller Signed-off-by: Kalle Valo

Merge tag 'mac80211-next-for-davem-2016-02-26' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next

2016-03-01T22:03:27Z

Johannes Berg says: ==================== Here's another round of updates for -next: * big A-MSDU RX performance improvement (avoid linearize of paged RX) * rfkill changes: cleanups, documentation, platform properties * basic PBSS support in cfg80211 * MU-MIMO action frame processing support * BlockAck reordering & duplicate detection offload support * various cleanups & little fixes ==================== Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2016-02-23T05:09:14Z

Conflicts: drivers/net/phy/bcm7xxx.c drivers/net/phy/marvell.c drivers/net/vxlan.c All three conflicts were cases of simple overlapping changes. Signed-off-by: David S. Miller