/openbmc/linux/drivers/net/wireless/ath/ath6kl/ |
H A D | wmi.c | diff 970fdfa89babb5a6f1a3d345e8cb54d92c1e3a8f Mon Aug 11 05:29:57 CDT 2014 Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> cfg80211: remove @gfp parameter from cfg80211_rx_mgmt()
In the cfg80211_rx_mgmt(), parameter @gfp was used for the memory allocation. But, memory get allocated under spin_lock_bh(), this implies atomic context. So, one can't use GFP_KERNEL, only variants with no __GFP_WAIT. Actually, in all occurrences GFP_ATOMIC is used (wil6210 use GFP_KERNEL by mistake), and it should be this way or warning triggered in the memory allocation code.
Remove @gfp parameter as no actual choice exist, and use hard coded GFP_ATOMIC for memory allocation.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
/openbmc/linux/drivers/net/wireless/ath/wil6210/ |
H A D | wmi.c | diff 970fdfa89babb5a6f1a3d345e8cb54d92c1e3a8f Mon Aug 11 05:29:57 CDT 2014 Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> cfg80211: remove @gfp parameter from cfg80211_rx_mgmt()
In the cfg80211_rx_mgmt(), parameter @gfp was used for the memory allocation. But, memory get allocated under spin_lock_bh(), this implies atomic context. So, one can't use GFP_KERNEL, only variants with no __GFP_WAIT. Actually, in all occurrences GFP_ATOMIC is used (wil6210 use GFP_KERNEL by mistake), and it should be this way or warning triggered in the memory allocation code.
Remove @gfp parameter as no actual choice exist, and use hard coded GFP_ATOMIC for memory allocation.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
/openbmc/linux/net/wireless/ |
H A D | mlme.c | diff 970fdfa89babb5a6f1a3d345e8cb54d92c1e3a8f Mon Aug 11 05:29:57 CDT 2014 Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> cfg80211: remove @gfp parameter from cfg80211_rx_mgmt()
In the cfg80211_rx_mgmt(), parameter @gfp was used for the memory allocation. But, memory get allocated under spin_lock_bh(), this implies atomic context. So, one can't use GFP_KERNEL, only variants with no __GFP_WAIT. Actually, in all occurrences GFP_ATOMIC is used (wil6210 use GFP_KERNEL by mistake), and it should be this way or warning triggered in the memory allocation code.
Remove @gfp parameter as no actual choice exist, and use hard coded GFP_ATOMIC for memory allocation.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
/openbmc/linux/include/net/ |
H A D | cfg80211.h | diff 970fdfa89babb5a6f1a3d345e8cb54d92c1e3a8f Mon Aug 11 05:29:57 CDT 2014 Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> cfg80211: remove @gfp parameter from cfg80211_rx_mgmt()
In the cfg80211_rx_mgmt(), parameter @gfp was used for the memory allocation. But, memory get allocated under spin_lock_bh(), this implies atomic context. So, one can't use GFP_KERNEL, only variants with no __GFP_WAIT. Actually, in all occurrences GFP_ATOMIC is used (wil6210 use GFP_KERNEL by mistake), and it should be this way or warning triggered in the memory allocation code.
Remove @gfp parameter as no actual choice exist, and use hard coded GFP_ATOMIC for memory allocation.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
/openbmc/linux/net/mac80211/ |
H A D | rx.c | diff 970fdfa89babb5a6f1a3d345e8cb54d92c1e3a8f Mon Aug 11 05:29:57 CDT 2014 Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> cfg80211: remove @gfp parameter from cfg80211_rx_mgmt()
In the cfg80211_rx_mgmt(), parameter @gfp was used for the memory allocation. But, memory get allocated under spin_lock_bh(), this implies atomic context. So, one can't use GFP_KERNEL, only variants with no __GFP_WAIT. Actually, in all occurrences GFP_ATOMIC is used (wil6210 use GFP_KERNEL by mistake), and it should be this way or warning triggered in the memory allocation code.
Remove @gfp parameter as no actual choice exist, and use hard coded GFP_ATOMIC for memory allocation.
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|