* RE: [PATCH] cfg80211: don't start p2p device while in RFKILL
From: Grumbach, Emmanuel @ 2013-09-17 12:25 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <1379420619-6123-1-git-send-email-emmanuel.grumbach@intel.com>
> -----Original Message-----
> From: Grumbach, Emmanuel
> Sent: Tuesday, September 17, 2013 3:24 PM
> To: linux-wireless@vger.kernel.org
> Cc: Grumbach, Emmanuel
> Subject: [PATCH] cfg80211: don't start p2p device while in RFKILL
>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> ---
> net/wireless/nl80211.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index
> 316503f..6bb03b5 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -8666,6 +8666,9 @@ static int nl80211_start_p2p_device(struct sk_buff
> *skb, struct genl_info *info)
> if (err)
> return err;
>
> + if (rfkill_blocked(rdev->rfkill))
> + return -ERFKILL;
> +
> err = rdev_start_p2p_device(rdev, wdev);
> if (err)
> return err;
This is bad... obviously I need to test that before I add the interface... v2 on the way
^ permalink raw reply
* [PATCH] cfg80211: don't start p2p device while in RFKILL
From: Emmanuel Grumbach @ 2013-09-17 12:23 UTC (permalink / raw)
To: linux-wireless; +Cc: Emmanuel Grumbach
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
---
net/wireless/nl80211.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 316503f..6bb03b5 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -8666,6 +8666,9 @@ static int nl80211_start_p2p_device(struct sk_buff *skb, struct genl_info *info)
if (err)
return err;
+ if (rfkill_blocked(rdev->rfkill))
+ return -ERFKILL;
+
err = rdev_start_p2p_device(rdev, wdev);
if (err)
return err;
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC] mac80211: correctly close cancelled scans
From: Eliad Peller @ 2013-09-17 11:30 UTC (permalink / raw)
To: Grumbach, Emmanuel; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB301DB0B1C@HASMSX103.ger.corp.intel.com>
On Tue, Sep 17, 2013 at 2:28 PM, Grumbach, Emmanuel
<emmanuel.grumbach@intel.com> wrote:
>> On Tue, Sep 17, 2013 at 8:48 AM, Emmanuel Grumbach
>> <emmanuel.grumbach@intel.com> wrote:
>> > __ieee80211_scan_completed is called from a worker. This means that
>> > the following flow is possible.
>> >
>> > * driver calls ieee80211_scan_completed
>> > * mac80211 cancels the scan (that is already complete)
>> > * __ieee80211_scan_complete runs
>> >
>> > When scan_work will finally run, it will see that the scan hasn't been
>> > aborted and might even trigger another scan on another band. This
>> > leads to a situation where cfg80211's scan is not done and no further
>> > scan can be issued.
>> >
>> > Fix this by setting a new flag when a HW scan is being cancelled so
>> > that no other scan will be triggered.
>> >
>> > Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
>> > ---
>> [...]
>>
>> > if (test_bit(SCAN_HW_SCANNING, &local->scanning)) {
>> > - if (local->ops->cancel_hw_scan)
>> > + /*
>> > + * Make sure that __ieee80211_scan_completed doesn't trigger a
>> > + * scan on another band.
>> > + */
>> > + set_bit(SCAN_HW_CANCELLED, &local->scanning);
>> > + if (local->ops->cancel_hw_scan) {
>> > drv_cancel_hw_scan(local,
>> > rcu_dereference_protected(local->scan_sdata,
>> >
>> > lockdep_is_held(&local->mtx)));
>> > + }
>> > goto out;
>> > }
>>
>> you don't seem to clear this flag anywhere...
>>
>
> Yeah - just like SCAN_HW_SCANNING isn't cleared anywhere... but... in __ieee80211_scan_completed:
>
> local->scanning = 0;
> local->scan_chandef.chan = NULL;
>
> yes I know. Don't ask.
oh, right, i overlooked it :)
Eliad.
^ permalink raw reply
* RE: [RFC] mac80211: correctly close cancelled scans
From: Grumbach, Emmanuel @ 2013-09-17 11:28 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAB3XZEc-h=mS-etjvm_zeJ2czsLj9yseq+jpsXOR=smy5+7Rdg@mail.gmail.com>
> On Tue, Sep 17, 2013 at 8:48 AM, Emmanuel Grumbach
> <emmanuel.grumbach@intel.com> wrote:
> > __ieee80211_scan_completed is called from a worker. This means that
> > the following flow is possible.
> >
> > * driver calls ieee80211_scan_completed
> > * mac80211 cancels the scan (that is already complete)
> > * __ieee80211_scan_complete runs
> >
> > When scan_work will finally run, it will see that the scan hasn't been
> > aborted and might even trigger another scan on another band. This
> > leads to a situation where cfg80211's scan is not done and no further
> > scan can be issued.
> >
> > Fix this by setting a new flag when a HW scan is being cancelled so
> > that no other scan will be triggered.
> >
> > Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> > ---
> [...]
>
> > if (test_bit(SCAN_HW_SCANNING, &local->scanning)) {
> > - if (local->ops->cancel_hw_scan)
> > + /*
> > + * Make sure that __ieee80211_scan_completed doesn't trigger a
> > + * scan on another band.
> > + */
> > + set_bit(SCAN_HW_CANCELLED, &local->scanning);
> > + if (local->ops->cancel_hw_scan) {
> > drv_cancel_hw_scan(local,
> > rcu_dereference_protected(local->scan_sdata,
> >
> > lockdep_is_held(&local->mtx)));
> > + }
> > goto out;
> > }
>
> you don't seem to clear this flag anywhere...
>
Yeah - just like SCAN_HW_SCANNING isn't cleared anywhere... but... in __ieee80211_scan_completed:
local->scanning = 0;
local->scan_chandef.chan = NULL;
yes I know. Don't ask.
^ permalink raw reply
* Re: [RFC] mac80211: correctly close cancelled scans
From: Eliad Peller @ 2013-09-17 11:22 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1379396919-11983-1-git-send-email-emmanuel.grumbach@intel.com>
On Tue, Sep 17, 2013 at 8:48 AM, Emmanuel Grumbach
<emmanuel.grumbach@intel.com> wrote:
> __ieee80211_scan_completed is called from a worker. This
> means that the following flow is possible.
>
> * driver calls ieee80211_scan_completed
> * mac80211 cancels the scan (that is already complete)
> * __ieee80211_scan_complete runs
>
> When scan_work will finally run, it will see that the scan
> hasn't been aborted and might even trigger another scan on
> another band. This leads to a situation where cfg80211's
> scan is not done and no further scan can be issued.
>
> Fix this by setting a new flag when a HW scan is being
> cancelled so that no other scan will be triggered.
>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> ---
[...]
> if (test_bit(SCAN_HW_SCANNING, &local->scanning)) {
> - if (local->ops->cancel_hw_scan)
> + /*
> + * Make sure that __ieee80211_scan_completed doesn't trigger a
> + * scan on another band.
> + */
> + set_bit(SCAN_HW_CANCELLED, &local->scanning);
> + if (local->ops->cancel_hw_scan) {
> drv_cancel_hw_scan(local,
> rcu_dereference_protected(local->scan_sdata,
> lockdep_is_held(&local->mtx)));
> + }
> goto out;
> }
you don't seem to clear this flag anywhere...
Eliad.
^ permalink raw reply
* [PATCH 3.12] ath9k: don't use BAW tracking on PS responses for non-AMPDU packets
From: Felix Fietkau @ 2013-09-17 10:05 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
When .release_buffered_frames was implemented, only A-MPDU packets were
buffered internally. Now that this has changed, the BUF_AMPDU flag needs
to be checked before calling ath_tx_addto_baw
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 5849960..9b3736e 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1556,8 +1556,10 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
__skb_unlink(bf->bf_mpdu, tid_q);
list_add_tail(&bf->list, &bf_q);
ath_set_rates(tid->an->vif, tid->an->sta, bf);
- ath_tx_addto_baw(sc, tid, bf);
- bf->bf_state.bf_type &= ~BUF_AGGR;
+ if (bf_isampdu(bf)) {
+ ath_tx_addto_baw(sc, tid, bf);
+ bf->bf_state.bf_type &= ~BUF_AGGR;
+ }
if (bf_tail)
bf_tail->bf_next = bf;
--
1.8.0.2
^ permalink raw reply related
* [PATCH 3.12] mac80211: drop spoofed packets in ad-hoc mode
From: Felix Fietkau @ 2013-09-17 9:15 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, thomas
If an Ad-Hoc node receives packets with the Cell ID or its own MAC
address as source address, it hits a WARN_ON in sta_info_insert_check()
With many packets, this can massively spam the logs. One way that this
can easily happen is through having Cisco APs in the area with rouge AP
detection and countermeasures enabled.
Such Cisco APs will regularly send fake beacons, disassoc and deauth
packets that trigger these warnings.
To fix this issue, drop such spoofed packets early in the rx path.
Cc: stable@vger.kernel.org
Reported-by: Thomas Huehn <thomas@net.t-labs.tu-berlin.de>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
net/mac80211/rx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 54395d7..674eac1 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -3056,6 +3056,9 @@ static int prepare_for_handlers(struct ieee80211_rx_data *rx,
case NL80211_IFTYPE_ADHOC:
if (!bssid)
return 0;
+ if (ether_addr_equal(sdata->vif.addr, hdr->addr2) ||
+ ether_addr_equal(sdata->u.ibss.bssid, hdr->addr2))
+ return 0;
if (ieee80211_is_beacon(hdr->frame_control)) {
return 1;
} else if (!ieee80211_bssid_match(bssid, sdata->u.ibss.bssid)) {
--
1.8.0.2
^ permalink raw reply related
* RE: [PATCH 8/8 V2] rtlwifi: Remove variable 'noise' from rtl_stats struct
From: David Laight @ 2013-09-17 8:48 UTC (permalink / raw)
To: Larry Finger, linville; +Cc: linux-wireless, netdev
In-Reply-To: <1379357722-17687-9-git-send-email-Larry.Finger@lwfinger.net>
> diff --git a/drivers/net/wireless/rtlwifi/wifi.h b/drivers/net/wireless/rtlwifi/wifi.h
> index cc03e7c..284ee8d 100644
> --- a/drivers/net/wireless/rtlwifi/wifi.h
> +++ b/drivers/net/wireless/rtlwifi/wifi.h
> @@ -1535,7 +1535,6 @@ struct rtl_stats {
> u32 mac_time[2];
> s8 rssi;
> u8 signal;
> - u8 noise;
> u8 rate; /* hw desc rate */
> u8 received_channel;
> u8 control;
> --
Is 'struct rtl_stats' exposed to userspace?
(or even to loadable drivers)
If so you probably ought to replace 'noise' with an explicit
pad in order to avoid changing the offsets of the other fields.
David
^ permalink raw reply
* RT3573 wpa_supplicant: "nl80211: Delete station $my_ap" after "SME: Send 20/40 BSS Coexistence to $my_ap"
From: Peter Stuge @ 2013-09-17 8:43 UTC (permalink / raw)
To: linux-wireless, users, hostap
Xose Vazquez Perez wrote:
> 0x0846, 0x9012 NETGEAR WNDA4100 N900 Wireless Dual Band USB Adapter
I'm testing the WNDA4100 with torvalds/linux.git and as of a day or
two ago and wpa_supplicant-2.0.
I haven't measured throughput. Latency is really bad for interactive
connections, but at least the packets are flowing on all bands. Yay!
Ping to the access point is around 3 ms with the odd 20+ ms when the
kernel goes off to do something else.
Here's my problem:
After wpa_supplicant -Dnl80211 -ddd sees scan results and says
"SME: Send 20/40 BSS Coexistence to $my_ap" and that frame is acked,
wpa_supplicant seems to receive a "link up" event which causes it to
delete the existing association for no good reason. It blacklists my
ap so I need to reconnect manually with iw dev wlan1 connect -w $ssid.
(Oh, and iw dev wlan1 connect -w consistently says "Unspecified failure"
even though the connection is established fine by wpa_supplicant. Other
problem though.)
My AP is hidden, so it isn't included in the scan results. But
wpa_supplicant is connected to it fine when the scan results arrive.
wpa_supplicant does *not* disconnect if I manually initiate a scan
when there is no other link activity, this only happens for
"Scan requested (ret=0) - scan timeout 30 seconds" scans.
--8<-- wpa_supplicant -ddd log snippet with MAC address replaced with $my_ap.
wlan1: New scan results available
SME: Send 20/40 BSS Coexistence to $my_ap
nl80211: Send Action frame (ifindex=6, freq=2417 MHz wait=0 ms no_cck=0)
nl80211: CMD_FRAME freq=2417 wait=0 no_cck=0 no_ack=0 offchanok=1
nl80211: Frame TX command accepted; cookie 0xffff880039f70700
wlan1: Checking for other virtual interfaces sharing same radio (phy1) in event_scan_results
nl80211: Event message available
nl80211: MLME event 60
nl80211: MLME event frame - hexdump(len=34): d0 00 da 00 $my_ap 84 1b 5e 7e e1 bc $my_ap d0 72 04 00 48 01 00 49 03 00 06 05
nl80211: Frame TX status event
nl80211: Action TX status: cookie=0ffff880039f70700 (match) (ack=1)
wlan1: Event TX_STATUS (18) received
wlan1: EVENT_TX_STATUS dst=$my_ap type=0 stype=13
RTM_NEWLINK: operstate=1 ifi_flags=0x1003 ([UP])
RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan1' added
nl80211: if_removed already cleared - ignore event
nl80211: Event message available
nl80211: Delete station $my_ap
nl80211: Event message available
nl80211: MLME event 39
nl80211: MLME event frame - hexdump(len=26): c0 00 00 00 $my_ap 84 1b 5e 7e e1 bc $my_ap 00 00 04 00
nl80211: Deauthenticate event
wlan1: Event DEAUTH (12) received
wlan1: Deauthentication notification
wlan1: * reason 4 (locally generated)
wlan1: * address $my_ap
Deauthentication frame IE(s) - hexdump(len=0): [NULL]
wlan1: CTRL-EVENT-DISCONNECTED bssid=$my_ap reason=4 locally_generated=1
wlan1: Auto connect enabled: try to reconnect (wps=0 wpa_state=9)
wlan1: Setting scan request: 0 sec 100000 usec
Added BSSID $my_ap into blacklist
wlan1: Blacklist count 1 --> request scan in 100 ms
wlan1: Setting scan request: 0 sec 100000 usec
wlan1: Disconnect event - remove keys
wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=(nil) key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=(nil) key_idx=1 set_tx=0 seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=(nil) key_idx=2 set_tx=0 seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=(nil) key_idx=3 set_tx=0 seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=6 alg=0 addr=0x112f828 key_idx=0 set_tx=0 seq_len=0 key_len=0
addr=$my_ap
wlan1: State: COMPLETED -> DISCONNECTED
-->8--
What's the problem? wpa_supplicant or rt2800usb or mac80211 or all of
the above?
Thanks
//Peter
^ permalink raw reply
* [PATCH] cfg80211: parse dfs region for internal regdb option
From: Janusz Dziedzic @ 2013-09-17 6:25 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, rodrigue, Janusz Dziedzic
Add support for parsing and setting the dfs region (ETSI, FCC, JP)
when the internal regulatory database is used. Before this
the DFS region was being ignored even if present on the used
db.txt
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
net/wireless/genregdb.awk | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/wireless/genregdb.awk b/net/wireless/genregdb.awk
index 9392f8c..42ed274 100644
--- a/net/wireless/genregdb.awk
+++ b/net/wireless/genregdb.awk
@@ -46,6 +46,12 @@ BEGIN {
sub(/:/, "", country)
printf "static const struct ieee80211_regdomain regdom_%s = {\n", country
printf "\t.alpha2 = \"%s\",\n", country
+ if ($NF ~ /DFS-ETSI/)
+ printf "\t.dfs_region = NL80211_DFS_ETSI,\n"
+ else if ($NF ~ /DFS-FCC/)
+ printf "\t.dfs_region = NL80211_DFS_FCC,\n"
+ else if ($NF ~ /DFS-JP/)
+ printf "\t.dfs_region = NL80211_DFS_JP,\n"
printf "\t.reg_rules = {\n"
active = 1
regdb = regdb "\t®dom_" country ",\n"
--
1.7.9.5
^ permalink raw reply related
* [RFC] mac80211: correctly close cancelled scans
From: Emmanuel Grumbach @ 2013-09-17 5:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Emmanuel Grumbach
__ieee80211_scan_completed is called from a worker. This
means that the following flow is possible.
* driver calls ieee80211_scan_completed
* mac80211 cancels the scan (that is already complete)
* __ieee80211_scan_complete runs
When scan_work will finally run, it will see that the scan
hasn't been aborted and might even trigger another scan on
another band. This leads to a situation where cfg80211's
scan is not done and no further scan can be issued.
Fix this by setting a new flag when a HW scan is being
cancelled so that no other scan will be triggered.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
---
net/mac80211/ieee80211_i.h | 3 +++
net/mac80211/scan.c | 22 +++++++++++++++++++++-
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index d604e16..a523e5a 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -893,6 +893,8 @@ struct tpt_led_trigger {
* that the scan completed.
* @SCAN_ABORTED: Set for our scan work function when the driver reported
* a scan complete for an aborted scan.
+ * @SCAN_HW_CANCELLED: Set for our scan work function when the scan is being
+ * cancelled.
*/
enum {
SCAN_SW_SCANNING,
@@ -900,6 +902,7 @@ enum {
SCAN_ONCHANNEL_SCANNING,
SCAN_COMPLETED,
SCAN_ABORTED,
+ SCAN_HW_CANCELLED,
};
/**
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index 08afe74..67f81a4 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -238,6 +238,9 @@ static bool ieee80211_prep_hw_scan(struct ieee80211_local *local)
enum ieee80211_band band;
int i, ielen, n_chans;
+ if (test_bit(SCAN_HW_CANCELLED, &local->scanning))
+ return false;
+
do {
if (local->hw_scan_band == IEEE80211_NUM_BANDS)
return false;
@@ -940,11 +943,28 @@ void ieee80211_scan_cancel(struct ieee80211_local *local)
if (!local->scan_req)
goto out;
+ /*
+ * We have a scan running and the driver already reported completion,
+ * but the worker hasn't run yet or is stuck on the mutex - mark it as
+ * cancelled.
+ */
+ if (test_bit(SCAN_HW_SCANNING, &local->scanning) &&
+ test_bit(SCAN_COMPLETED, &local->scanning)) {
+ set_bit(SCAN_HW_CANCELLED, &local->scanning);
+ goto out;
+ }
+
if (test_bit(SCAN_HW_SCANNING, &local->scanning)) {
- if (local->ops->cancel_hw_scan)
+ /*
+ * Make sure that __ieee80211_scan_completed doesn't trigger a
+ * scan on another band.
+ */
+ set_bit(SCAN_HW_CANCELLED, &local->scanning);
+ if (local->ops->cancel_hw_scan) {
drv_cancel_hw_scan(local,
rcu_dereference_protected(local->scan_sdata,
lockdep_is_held(&local->mtx)));
+ }
goto out;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC 3/4] ath10k: cleanup RX decap handling
From: Michal Kazior @ 2013-09-17 5:19 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <8738p4laid.fsf@qca.qualcomm.com>
On 16 September 2013 23:30, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> Native Wifi frames are always decapped as non-QoS
>> data frames meaning mac80211 couldn't set sk_buff
>> priority properly. The patch fixes this by using
>> the original 802.11 header.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>
> The patch title doesn't seem to match with the content. Unless I'm
> mistaken it looks like you are adding native wifi frame format support
> and doing some cleanup at the same time. They should be in separate
> patches.
You're right. I'll split it up.
Nwifi was supported, however QoS Data frames were reported as Data
frames though.
>> @@ -652,6 +652,19 @@ static void ath10k_htt_rx_amsdu(struct ath10k_htt *htt,
>> skb_trim(skb, skb->len - FCS_LEN);
>> break;
>> case RX_MSDU_DECAP_NATIVE_WIFI:
>> + hdr = (struct ieee80211_hdr *)skb->data;
>> + hdr_len = ieee80211_hdrlen(hdr->frame_control);
>> + memcpy(addr, ieee80211_get_DA(hdr), ETH_ALEN);
>> + skb_pull(skb, hdr_len);
>> +
>> + hdr = (struct ieee80211_hdr *)hdr_buf;
>> + hdr_len = ieee80211_hdrlen(hdr->frame_control);
>> + memcpy(skb_push(skb, hdr_len), hdr, hdr_len);
>> +
>> + hdr = (struct ieee80211_hdr *)skb->data;
>> + qos = ieee80211_get_qos_ctl(hdr);
>> + qos[0] &= ~IEEE80211_QOS_CTL_A_MSDU_PRESENT;
>> + memcpy(ieee80211_get_DA(hdr), addr, ETH_ALEN);
>> break;
>
> It would be good to have small comments what each part is doing("remove
> the native wifi header", "copy the real 802.11 header", "copy correct
> destination address" etc), makes it a lot faster to skim the code. Also
> document why IEEE80211_QOS_CTL_A_MSDU_PRESENT needs to be cleared.
Okay.
>> case RX_MSDU_DECAP_RAW:
>> - /* remove trailing FCS */
>> - skb_trim(skb, skb->len - 4);
>> + skb_trim(skb, skb->len - FCS_LEN);
>> break;
>
> Please keep the comment still
Why? The point of the comment was to explain the literal "4". Using
define makes the comment redundant.
>
>> case RX_MSDU_DECAP_NATIVE_WIFI:
>> - /* nothing to do here */
>> + hdr = (struct ieee80211_hdr *)skb->data;
>> + hdr_len = ieee80211_hdrlen(hdr->frame_control);
>> + memcpy(addr, ieee80211_get_DA(hdr), ETH_ALEN);
>> + skb_pull(skb, hdr_len);
>> +
>> + hdr = (struct ieee80211_hdr *)rxd->rx_hdr_status;
>> + hdr_len = ieee80211_hdrlen(hdr->frame_control);
>> + memcpy(skb_push(skb, hdr_len), hdr, hdr_len);
>> +
>> + hdr = (struct ieee80211_hdr *)skb->data;
>> + memcpy(ieee80211_get_DA(hdr), addr, ETH_ALEN);
>> break;
>
> Again add small comments describing how we are modifying the headers.
Okay.
>> case RX_MSDU_DECAP_ETHERNET2_DIX:
>> - /* macaddr[6] + macaddr[6] + ethertype[2] */
>> - skb_pull(skb, 6 + 6 + 2);
>> + rfc1042 = hdr;
>> + rfc1042 += roundup(hdr_len, 4);
>> + rfc1042 += roundup(ath10k_htt_rx_crypto_param_len(enctype), 4);
>> +
>> + skb_pull(skb, sizeof(struct ethhdr));
>> + memcpy(skb_push(skb, sizeof(struct rfc1042_hdr)),
>> + rfc1042, sizeof(struct rfc1042_hdr));
>> + memcpy(skb_push(skb, hdr_len), hdr, hdr_len);
>> break;
>
> Ditto.
Comment was supposed to explain where those numbers come from. Using
structures explains it now.
>> case RX_MSDU_DECAP_8023_SNAP_LLC:
>> - /* macaddr[6] + macaddr[6] + len[2] */
>> - /* we don't need this for non-A-MSDU */
>> - skb_pull(skb, 6 + 6 + 2);
>> + skb_pull(skb, sizeof(struct amsdu_subframe_hdr));
>> + memcpy(skb_push(skb, hdr_len), hdr, hdr_len);
>> break;
>
> And here.
Ditto.
Michał.
^ permalink raw reply
* Re: [PATCH 1/1] mwifiex: queue main work from main process when bailing on races
From: Daniel Mack @ 2013-09-16 23:00 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-wireless@vger.kernel.org, s.neumann@raumfeld.com,
afenkart@gmail.com, linville@tuxdriver.com,
johannes.berg@intel.com, stable@vger.kernel.org
In-Reply-To: <477F20668A386D41ADCC57781B1F70430F44C5849E@SC-VEXCH1.marvell.com>
Hi Bing,
On 16.09.2013 23:14, Bing Zhao wrote:
>> diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
>> index ff4ed96..0700bc2 100644
>> --- a/drivers/net/wireless/mwifiex/main.c
>> +++ b/drivers/net/wireless/mwifiex/main.c
>> @@ -235,6 +235,7 @@ int mwifiex_main_process(struct mwifiex_adapter *adapter)
>> /* Check if already processing */
>> if (adapter->mwifiex_processing) {
>> spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
>> + queue_work(adapter->workqueue, &adapter->main_work);
>
> This is specific to SDIO interface,
Is it really? By checking adapter->mwifiex_processing, the driver seems
to expect mwifiex_main_process() to be called from multiple execution
paths, and in that case, we will always loose one execution cycle in
case we bail early. I actually wonder why this didn't hit us earlier,
but I might miss a detail.
OTOH, the worst thing that can happen if the function is executed too
often is that it exits early and does nothing.
> + if (adapter->iface_type == MWIFIEX_SDIO)
> + queue_work(adapter->workqueue, &adapter->main_work);
I can of course add this, but I don't fully understand why the driver
takes care of concurrently running executing paths and then just bails
silently in case a race is detected.
Best regards,
Daniel
^ permalink raw reply
* Re: [PATCH 2/8 V2] rtlwifi: rtl8192de: Fix smatch warnings in rtl8192de/hw.c
From: Kalle Valo @ 2013-09-16 21:44 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, netdev
In-Reply-To: <1379357722-17687-3-git-send-email-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> Smatch lists the following:
> CHECK drivers/net/wireless/rtlwifi/rtl8192de/hw.c
> drivers/net/wireless/rtlwifi/rtl8192de/hw.c:1200 rtl92de_set_qos() info: ignoring unreachable code.
> drivers/net/wireless/rtlwifi/rtl8192de/hw.c:1200 rtl92de_set_qos() info: ignoring unreachable code.
>
> Dead code is commented out. It has not been deleted in case I find a need for
> it later.
We should not have any commented out code. It's better to remove it and
if it's ever needed it can be found from the git history.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH v4] Bluetooth: btmrvl: add calibration data download support
From: Bing Zhao @ 2013-09-16 21:17 UTC (permalink / raw)
To: Marcel Holtmann
Cc: linux-bluetooth@vger.kernel.org, Gustavo Padovan, Johan Hedberg,
linux-wireless@vger.kernel.org, Mike Frysinger, Hyuckjoo Lee,
Amitkumar Karwar
In-Reply-To: <525C3DAD-2AD3-468F-8309-630EEE54A3CE@holtmann.org>
Hi Marcel,
Thanks for your comment.
> > + bt_cb(skb)->pkt_type = MRVL_VENDOR_PKT;
> > + skb_put(skb, sizeof(*cmd));
> > + skb->dev = (void *)priv->btmrvl_dev.hcidev;
> > + skb_queue_head(&priv->adapter->tx_queue, skb);
> > + priv->btmrvl_dev.sendcmdflag = true;
> > + priv->adapter->cmd_complete = false;
>
> since the Bluetooth HCI core got ->setup() support with proper synchronous HCI request handling
> available for every single driver (see the Intel support in btusb.c), why not start using that with
> this driver as well.
We will convert btmrvl driver to use ->setup() callback.
Thanks,
Bing
^ permalink raw reply
* Re: [RFC 3/4] ath10k: cleanup RX decap handling
From: Kalle Valo @ 2013-09-16 21:30 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1379335757-15180-4-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Native Wifi frames are always decapped as non-QoS
> data frames meaning mac80211 couldn't set sk_buff
> priority properly. The patch fixes this by using
> the original 802.11 header.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
The patch title doesn't seem to match with the content. Unless I'm
mistaken it looks like you are adding native wifi frame format support
and doing some cleanup at the same time. They should be in separate
patches.
> @@ -652,6 +652,19 @@ static void ath10k_htt_rx_amsdu(struct ath10k_htt *htt,
> skb_trim(skb, skb->len - FCS_LEN);
> break;
> case RX_MSDU_DECAP_NATIVE_WIFI:
> + hdr = (struct ieee80211_hdr *)skb->data;
> + hdr_len = ieee80211_hdrlen(hdr->frame_control);
> + memcpy(addr, ieee80211_get_DA(hdr), ETH_ALEN);
> + skb_pull(skb, hdr_len);
> +
> + hdr = (struct ieee80211_hdr *)hdr_buf;
> + hdr_len = ieee80211_hdrlen(hdr->frame_control);
> + memcpy(skb_push(skb, hdr_len), hdr, hdr_len);
> +
> + hdr = (struct ieee80211_hdr *)skb->data;
> + qos = ieee80211_get_qos_ctl(hdr);
> + qos[0] &= ~IEEE80211_QOS_CTL_A_MSDU_PRESENT;
> + memcpy(ieee80211_get_DA(hdr), addr, ETH_ALEN);
> break;
It would be good to have small comments what each part is doing("remove
the native wifi header", "copy the real 802.11 header", "copy correct
destination address" etc), makes it a lot faster to skim the code. Also
document why IEEE80211_QOS_CTL_A_MSDU_PRESENT needs to be cleared.
> case RX_MSDU_DECAP_RAW:
> - /* remove trailing FCS */
> - skb_trim(skb, skb->len - 4);
> + skb_trim(skb, skb->len - FCS_LEN);
> break;
Please keep the comment still
> case RX_MSDU_DECAP_NATIVE_WIFI:
> - /* nothing to do here */
> + hdr = (struct ieee80211_hdr *)skb->data;
> + hdr_len = ieee80211_hdrlen(hdr->frame_control);
> + memcpy(addr, ieee80211_get_DA(hdr), ETH_ALEN);
> + skb_pull(skb, hdr_len);
> +
> + hdr = (struct ieee80211_hdr *)rxd->rx_hdr_status;
> + hdr_len = ieee80211_hdrlen(hdr->frame_control);
> + memcpy(skb_push(skb, hdr_len), hdr, hdr_len);
> +
> + hdr = (struct ieee80211_hdr *)skb->data;
> + memcpy(ieee80211_get_DA(hdr), addr, ETH_ALEN);
> break;
Again add small comments describing how we are modifying the headers.
> case RX_MSDU_DECAP_ETHERNET2_DIX:
> - /* macaddr[6] + macaddr[6] + ethertype[2] */
> - skb_pull(skb, 6 + 6 + 2);
> + rfc1042 = hdr;
> + rfc1042 += roundup(hdr_len, 4);
> + rfc1042 += roundup(ath10k_htt_rx_crypto_param_len(enctype), 4);
> +
> + skb_pull(skb, sizeof(struct ethhdr));
> + memcpy(skb_push(skb, sizeof(struct rfc1042_hdr)),
> + rfc1042, sizeof(struct rfc1042_hdr));
> + memcpy(skb_push(skb, hdr_len), hdr, hdr_len);
> break;
Ditto.
> case RX_MSDU_DECAP_8023_SNAP_LLC:
> - /* macaddr[6] + macaddr[6] + len[2] */
> - /* we don't need this for non-A-MSDU */
> - skb_pull(skb, 6 + 6 + 2);
> + skb_pull(skb, sizeof(struct amsdu_subframe_hdr));
> + memcpy(skb_push(skb, hdr_len), hdr, hdr_len);
> break;
And here.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH] mwifiex: Remove casting the return value which is a void pointer
From: Bing Zhao @ 2013-09-16 21:26 UTC (permalink / raw)
To: Jingoo Han, 'John W. Linville'
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
'David Miller'
In-Reply-To: <004d01cead1d$3058dcf0$910a96d0$%han@samsung.com>
Hi Jingoo,
Thanks for the patch.
> Casting the return value which is a void pointer is redundant.
> The conversion from void pointer to any other pointer type is
> guaranteed by the C programming language.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
Thanks,
Bing
> ---
> drivers/net/wireless/mwifiex/pcie.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
^ permalink raw reply
* RE: [PATCH 1/1] mwifiex: queue main work from main process when bailing on races
From: Bing Zhao @ 2013-09-16 21:14 UTC (permalink / raw)
To: Daniel Mack, linux-wireless@vger.kernel.org
Cc: s.neumann@raumfeld.com, afenkart@gmail.com,
linville@tuxdriver.com, johannes.berg@intel.com,
stable@vger.kernel.org
In-Reply-To: <1379331546-30617-2-git-send-email-zonque@gmail.com>
Hi Daniel,
Thanks for the patch.
> Queue main_work in case mwifiex_main_process() bails due to an already
> processed transaction. This is particularly necessary because
> mwifiex_main_process() is called from both the SDIO interrupt handler
> and the workqueue. In case an interrupt occurs while the main process
> is currently executed from the workqueue, the interrupt is lost,
> resulting in a command timeout and consequently a card reset.
>
> I'm marking this for stable kernel in version 3.7+, because on our
> platform, the issue appears since 601216e12c ("mwifiex: process RX
> packets in SDIO IRQ thread directly") went in.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> Reported-by: Sven Neumann <s.neumann@raumfeld.com>
> Reported-by: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
> Cc: Bing Zhao <bzhao@marvell.com>
> Cc: <stable@vger.kernel.org> [v3.7+]
> ---
> drivers/net/wireless/mwifiex/main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
> index ff4ed96..0700bc2 100644
> --- a/drivers/net/wireless/mwifiex/main.c
> +++ b/drivers/net/wireless/mwifiex/main.c
> @@ -235,6 +235,7 @@ int mwifiex_main_process(struct mwifiex_adapter *adapter)
> /* Check if already processing */
> if (adapter->mwifiex_processing) {
> spin_unlock_irqrestore(&adapter->main_proc_lock, flags);
> + queue_work(adapter->workqueue, &adapter->main_work);
This is specific to SDIO interface, so we'd add a check here.
+ if (adapter->iface_type == MWIFIEX_SDIO)
+ queue_work(adapter->workqueue, &adapter->main_work);
Thanks,
Bing
> goto exit_main_proc;
> } else {
> adapter->mwifiex_processing = true;
> --
> 1.8.3.1
^ permalink raw reply
* Re: guidance on struct alignment for rtl8192cu driver
From: Larry Finger @ 2013-09-16 19:40 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: Seth Forshee, Jason Andrews, linux-wireless@vger.kernel.org
In-Reply-To: <CANUX_P3iBywud0SxXtnwUWby0DNm-UoB-CP=X+tdsS7MbmVg=Q@mail.gmail.com>
On 09/16/2013 02:29 PM, Emmanuel Grumbach wrote:
>>>> Index: wireless-testing-save/drivers/net/wireless/rtlwifi/wifi.h
>>>> ===================================================================
>>>> --- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/wifi.h
>>>> +++ wireless-testing-save/drivers/net/wireless/rtlwifi/wifi.h
>>>> @@ -2057,7 +2057,7 @@ struct rtl_priv {
>>>> that it points to the data allocated
>>>> beyond this structure like:
>>>> rtl_pci_priv or rtl_usb_priv */
>>>> - u8 priv[0];
>>>> + u8 __aligned(4) priv[0];
>>>> };
>>>
>>>
>>> __attribute__((aligned)) might be a safer bet, as this will align it to
>>> the largest alignment that could possibly be needed.
>
> Or copy the code from mac80211.h:
>
> u8 drv_priv[0] __aligned(sizeof(void *));
>
> I did the same in iwlwifi.
> Note the new way to add the __aligned thing. Joe will tell you that is
> better than __attribute__ blablabla
Thanks. I had noticed that checkpatch.pl complains about the __attribute
construction.
Larry
^ permalink raw reply
* Re: guidance on struct alignment for rtl8192cu driver
From: Emmanuel Grumbach @ 2013-09-16 19:29 UTC (permalink / raw)
To: Larry Finger; +Cc: Seth Forshee, Jason Andrews, linux-wireless@vger.kernel.org
In-Reply-To: <523724AF.8040506@lwfinger.net>
>>> Index: wireless-testing-save/drivers/net/wireless/rtlwifi/wifi.h
>>> ===================================================================
>>> --- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/wifi.h
>>> +++ wireless-testing-save/drivers/net/wireless/rtlwifi/wifi.h
>>> @@ -2057,7 +2057,7 @@ struct rtl_priv {
>>> that it points to the data allocated
>>> beyond this structure like:
>>> rtl_pci_priv or rtl_usb_priv */
>>> - u8 priv[0];
>>> + u8 __aligned(4) priv[0];
>>> };
>>
>>
>> __attribute__((aligned)) might be a safer bet, as this will align it to
>> the largest alignment that could possibly be needed.
Or copy the code from mac80211.h:
u8 drv_priv[0] __aligned(sizeof(void *));
I did the same in iwlwifi.
Note the new way to add the __aligned thing. Joe will tell you that is
better than __attribute__ blablabla
^ permalink raw reply
* Re: [PATCH 5/8 V2] [PATCH 5/7: rtlwifi: Fix smatch warning in pci.c
From: Sergei Shtylyov @ 2013-09-16 19:11 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, netdev
In-Reply-To: <5237562D.4080509@cogentembedded.com>
On 09/16/2013 11:04 PM, Sergei Shtylyov wrote:
>> Smatch reports the following:
>> CHECK drivers/net/wireless/rtlwifi/pci.c
>> drivers/net/wireless/rtlwifi/pci.c:739 _rtl_pci_rx_interrupt() warn:
>> assigning (-98) to unsigned variable 'stats.noise'
>> This variable is not used and is removed.
> It is not a variable but a structure field initializer you're removing.
Meant to also write that your subject is spoiled but forgot. :-)
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 4/8 V2] rtlwifi: rtl8192_common: Fix smatch errors and warnings in rtl8192c/dm_common.c
From: Sergei Shtylyov @ 2013-09-16 19:10 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, netdev
In-Reply-To: <523756DB.90507@lwfinger.net>
Hello.
On 09/16/2013 11:07 PM, Larry Finger wrote:
>>> Smatch lists the following:
>>> CHECK drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:551 rtl92c_dm_pwdb_monitor()
>>> info: ignoring unreachable code.
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:551 rtl92c_dm_pwdb_monitor()
>>> info: ignoring unreachable code.
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:870
>>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>>> 'txpwr_level' 2 <= 2
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:870
>>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>>> 'txpwr_level' 2 <= 2
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:882
>>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>>> 'txpwr_level' 2 <= 2
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:883
>>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>>> 'txpwr_level' 2 <= 2
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:891
>>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>>> 'txpwr_level' 2 <= 2
>>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:892
>>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>>> 'txpwr_level' 2 <= 2
>>> The unreachable code message is fixed by commenting out the code that follows
>>> a return.
>> You've commented out the whole function body, where is the *return* you're
>> talking about?
> The return is in the middle of the function body just after the variable
> declarations. It does not show in the diff listing, but it is there. What
> should I do?
Just describe what you really did, I guess.
> Larry
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 6/8 V2] rtlwifi: Fix smatch warnings in usb.c
From: Sergei Shtylyov @ 2013-09-16 19:07 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, netdev
In-Reply-To: <1379357722-17687-7-git-send-email-Larry.Finger@lwfinger.net>
On 09/16/2013 10:55 PM, Larry Finger wrote:
> Smatch displays the following:
> CHECK drivers/net/wireless/rtlwifi/usb.c
> drivers/net/wireless/rtlwifi/usb.c:458 _rtl_usb_rx_process_agg() warn: assigning (-98) to unsigned variable 'stats.noise'
> drivers/net/wireless/rtlwifi/usb.c:503 _rtl_usb_rx_process_noagg() warn: assigning (-98) to unsigned variable 'stats.noise'
> drivers/net/wireless/rtlwifi/usb.c:596 _rtl_rx_get_padding() info: ignoring unreachable code.
> drivers/net/wireless/rtlwifi/usb.c:596 _rtl_rx_get_padding() info: ignoring unreachable code.
> The negative number to an unsigned quantity is fixed by removing the variable
> as it is no longer used.
You're removing only structure field initializer, not a variable.
> The unreachable code info is fixed by including the
> appropriate section inside #ifdef .. #endif constructions.
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/net/wireless/rtlwifi/usb.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
> diff --git a/drivers/net/wireless/rtlwifi/usb.c b/drivers/net/wireless/rtlwifi/usb.c
> index e56778c..60cb0b4 100644
> --- a/drivers/net/wireless/rtlwifi/usb.c
> +++ b/drivers/net/wireless/rtlwifi/usb.c
> @@ -455,7 +455,6 @@ static void _rtl_usb_rx_process_agg(struct ieee80211_hw *hw,
> struct ieee80211_rx_status rx_status = {0};
> struct rtl_stats stats = {
> .signal = 0,
> - .noise = -98,
> .rate = 0,
> };
>
> @@ -498,7 +497,6 @@ static void _rtl_usb_rx_process_noagg(struct ieee80211_hw *hw,
> struct ieee80211_rx_status rx_status = {0};
> struct rtl_stats stats = {
> .signal = 0,
> - .noise = -98,
> .rate = 0,
> };
>
> @@ -582,12 +580,15 @@ static void _rtl_rx_work(unsigned long param)
> static unsigned int _rtl_rx_get_padding(struct ieee80211_hdr *hdr,
> unsigned int len)
> {
> +#if NET_IP_ALIGN != 0
> unsigned int padding = 0;
> +#endif
>
> /* make function no-op when possible */
> - if (NET_IP_ALIGN == 0 || len < sizeof(*hdr))
> + if (NET_IP_ALIGN == 0 || len < sizeof(struct ieee80211_hdr))
Hm, I thought you were going to remove this collateral change.
> return 0;
WBR, Sergei
^ permalink raw reply
* Re: [PATCH 4/8 V2] rtlwifi: rtl8192_common: Fix smatch errors and warnings in rtl8192c/dm_common.c
From: Larry Finger @ 2013-09-16 19:07 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linville, linux-wireless, netdev
In-Reply-To: <523755D1.2010003@cogentembedded.com>
On 09/16/2013 02:02 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 09/16/2013 10:55 PM, Larry Finger wrote:
>
>> Smatch lists the following:
>> CHECK drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:551 rtl92c_dm_pwdb_monitor()
>> info: ignoring unreachable code.
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:551 rtl92c_dm_pwdb_monitor()
>> info: ignoring unreachable code.
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:870
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>> 'txpwr_level' 2 <= 2
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:870
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>> 'txpwr_level' 2 <= 2
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:882
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>> 'txpwr_level' 2 <= 2
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:883
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>> 'txpwr_level' 2 <= 2
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:891
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>> 'txpwr_level' 2 <= 2
>> drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c:892
>> rtl92c_dm_txpower_tracking_callback_thermalmeter() error: buffer overflow
>> 'txpwr_level' 2 <= 2
>
>> The unreachable code message is fixed by commenting out the code that follows
>> a return.
>
> You've commented out the whole function body, where is the *return* you're
> talking about?
The return is in the middle of the function body just after the variable
declarations. It does not show in the diff listing, but it is there. What should
I do?
Larry
^ permalink raw reply
* Re: [PATCH 3/8 V2] rtlwifi: rtl8192cu: Fix smatch warning in rtl8192cu/trx.c
From: Sergei Shtylyov @ 2013-09-16 19:05 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, netdev
In-Reply-To: <1379357722-17687-4-git-send-email-Larry.Finger@lwfinger.net>
On 09/16/2013 10:55 PM, Larry Finger wrote:
> Smatch lists the following:
> CHECK drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
> drivers/net/wireless/rtlwifi/rtl8192cu/trx.c:367 _rtl_rx_process() warn: assigning (-98) to unsigned variable 'stats.noise'
> This variable is unused, thus it is removed.
It's a structure field initializer you're removing, not a variable. And
also a comment.
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> ---
> drivers/net/wireless/rtlwifi/rtl8192cu/trx.c | 2 --
> 1 file changed, 2 deletions(-)
> diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
> index 763cf1d..04c7e57 100644
> --- a/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
> +++ b/drivers/net/wireless/rtlwifi/rtl8192cu/trx.c
> @@ -349,7 +349,6 @@ bool rtl92cu_rx_query_desc(struct ieee80211_hw *hw,
> }
> /*rx_status->qual = stats->signal; */
> rx_status->signal = stats->rssi + 10;
> - /*rx_status->noise = -stats->noise; */
> return true;
> }
>
> @@ -364,7 +363,6 @@ static void _rtl_rx_process(struct ieee80211_hw *hw, struct sk_buff *skb)
> u8 *rxdesc;
> struct rtl_stats stats = {
> .signal = 0,
> - .noise = -98,
> .rate = 0,
> };
WBR, Sergei
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox