RE: wifi freezing (module mwifiex)
Hi Julien, > From: linux-wireless-ow...@vger.kernel.org [mailto:linux-wireless- > ow...@vger.kernel.org] On Behalf Of Julien Cubizolles > Sent: Thursday, July 23, 2015 7:18 PM > To: linux-wireless@vger.kernel.org > Subject: wifi freezing (module mwifiex) > > I'm running vanilla kernel 4.2.0-rc3 on a Microsoft Surface Pro. The > wifi (module mwifiex) freezes the whole system after a few seconds of > use. The problem appeared around kernel 3.19. > > I've tried to get some debug info with the dynamic debugging method, > using the following: > > --8<---cut here---start->8--- > echo "module mwifiex +p" > /sys/kernel/debug/dynamic_debug/control > echo "module mwifiex_sdio +p" > /sys/kernel/debug/dynamic_debug/control > echo "module mwifiex_pcie +p" > /sys/kernel/debug/dynamic_debug/control > echo "module mwifiex_usb +p" > /sys/kernel/debug/dynamic_debug/control > --8<---cut here---end--->8--- > > and getting the messages with > > --8<---cut here---start->8--- > while true; do dmesg -c >> mwifiex_logs.txt; sleep 1; done & > --8<---cut here---end--->8--- > > until the system freezes. > > Surprisingly, there are very few messages related to mwifiex (see the > following logs). Is there something wrong with the dynamic debugging ? > What other information could I provide ? > Thanks for reporting the problem. We now have a separate mechanism for debug logs and don't support dynamic debugging anymore. Issue below command to enable logs and share them. "echo 0x > /sys/kernel/debug/mwifiex/mlan0/debug_mask" Do you have following USB chipset specific fixes included? http://www.spinics.net/lists/linux-wireless/msg129129.html http://www.spinics.net/lists/netdev/msg334367.html Regards, Amitkumar
Re: [PATCH V2 1/3] staging: wilc1000: coreconfigurator.c: remove WILC_MALLOC
> On 2015년 07월 24일 09:44, Dan Carpenter wrote: > >On Fri, Jul 24, 2015 at 08:55:53AM +0900, Chaehyun Lim wrote: > >>Use kmalloc and kmalloc_array instead of WILC_MALLOC. > >> > >>Signed-off-by: Chaehyun Lim > >>--- > >>V2: Use GFP_KERNEL flag instead of GFP_ATOMIC > >This is probably the correct thing but how did you check that we aren't > >holding a spin_lock or in IRQ context? Thanks for the reply Tony, but I was really just trying to see how Chaehyun checks his patches or if they are automatically generated. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rsi: Fix failure to load firmware after memory leak fix and fix the leak
Reviewed-by: Alexey Khoroshilov with small
suggestion. If we restore kmemdup() call, we have to handle ENOMEM
situations:
fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
if (!fw)
return -ENOMEM;
On 27.07.2015 12:43, Mike Looijmans wrote:
> Fixes commit eae79b4f3e82ca63a53478a161b190a0d38fe526 ("rsi: fix memory leak
> in rsi_load_ta_instructions()") which stopped the driver from functioning.
>
> Firmware data has been allocated using vmalloc(), resulting in memory
> that cannot be used for DMA. Hence the firmware was first copied to a
> buffer allocated with kmalloc() in the original code. This patch reverts
> the commit and only calls "kfree()" to release the buffer after sending
> the data. This fixes the memory leak without breaking the driver.
>
> Add a comment to the kmemdup() calls to explain why this is done.
>
> Tested on a Topic Miami-Florida board which contains the rsi SDIO chip.
>
> Also added the same kfree() call to the USB glue driver. This was not
> tested on actual hardware though, as I only have the SDIO version.
>
> Signed-off-by: Mike Looijmans
> Cc: sta...@vger.kernel.org
> ---
> drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 6 +-
> drivers/net/wireless/rsi/rsi_91x_usb_ops.c | 2 ++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
> b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
> index b6cc9ff..5c37a71 100644
> --- a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
> @@ -172,6 +172,7 @@ static int rsi_load_ta_instructions(struct rsi_common
> *common)
> (struct rsi_91x_sdiodev *)adapter->rsi_dev;
> u32 len;
> u32 num_blocks;
> + const u8 *fw;
> const struct firmware *fw_entry = NULL;
> u32 block_size = dev->tx_blk_size;
> int status = 0;
> @@ -200,6 +201,8 @@ static int rsi_load_ta_instructions(struct rsi_common
> *common)
> return status;
> }
>
> + /* Copy firmware into DMA-accessible memory */
> + fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
> len = fw_entry->size;
>
> if (len % 4)
> @@ -210,7 +213,8 @@ static int rsi_load_ta_instructions(struct rsi_common
> *common)
> rsi_dbg(INIT_ZONE, "%s: Instruction size:%d\n", __func__, len);
> rsi_dbg(INIT_ZONE, "%s: num blocks: %d\n", __func__, num_blocks);
>
> - status = rsi_copy_to_card(common, fw_entry->data, len, num_blocks);
> + status = rsi_copy_to_card(common, fw, len, num_blocks);
> + kfree(fw);
> release_firmware(fw_entry);
> return status;
> }
> diff --git a/drivers/net/wireless/rsi/rsi_91x_usb_ops.c
> b/drivers/net/wireless/rsi/rsi_91x_usb_ops.c
> index 1106ce7..088e28e 100644
> --- a/drivers/net/wireless/rsi/rsi_91x_usb_ops.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_usb_ops.c
> @@ -146,6 +146,7 @@ static int rsi_load_ta_instructions(struct rsi_common
> *common)
> return status;
> }
>
> + /* Copy firmware into DMA-accessible memory */
> fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
> len = fw_entry->size;
>
> @@ -158,6 +159,7 @@ static int rsi_load_ta_instructions(struct rsi_common
> *common)
> rsi_dbg(INIT_ZONE, "%s: num blocks: %d\n", __func__, num_blocks);
>
> status = rsi_copy_to_card(common, fw, len, num_blocks);
> + kfree(fw);
> release_firmware(fw_entry);
> return status;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] mac80211: remove always true condition
The outside if statement checks that IEEE80211_TX_INTFL_MLME_CONN_TX is
set so this condition is always true. Checking twice upsets the static
checkers.
Signed-off-by: Dan Carpenter
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 45628f3..8ba5832 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -515,7 +515,7 @@ static void ieee80211_report_used_skb(struct
ieee80211_local *local,
if (!sdata) {
skb->dev = NULL;
- } else if (info->flags & IEEE80211_TX_INTFL_MLME_CONN_TX) {
+ } else {
unsigned int hdr_size =
ieee80211_hdrlen(hdr->frame_control);
@@ -529,9 +529,6 @@ static void ieee80211_report_used_skb(struct
ieee80211_local *local,
ieee80211_mgd_conn_tx_status(sdata,
hdr->frame_control,
acked);
- } else {
- /* we assign ack frame ID for the others */
- WARN_ON(1);
}
rcu_read_unlock();
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-4.2-rc4/drivers/staging/wilc1000/linux_mon.c:264: memory leak ?
Hello there,
[linux-4.2-rc4/drivers/staging/wilc1000/linux_mon.c:264]: (error) Memory leak:
mgmt_tx
Source code is
mgmt_tx->buff = kmalloc(len, GFP_ATOMIC);
if (mgmt_tx->buff == NULL) {
PRINT_ER("Failed to allocate memory for mgmt_tx buff\n");
return WILC_FAIL;
}
Suggest add missing call to kfree.
Regards
David Binderman
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] wl18xx: update statistics acx and debugfs files
From: Eliad Peller
Sync the driver statistics acx and debugfs representation
with the current fw api.
Signed-off-by: Eliad Peller
---
drivers/net/wireless/ti/wl18xx/acx.h | 78 ---
drivers/net/wireless/ti/wl18xx/debugfs.c | 159 ++
2 files changed, 156 insertions(+), 81 deletions(-)
diff --git a/drivers/net/wireless/ti/wl18xx/acx.h
b/drivers/net/wireless/ti/wl18xx/acx.h
index c8a33f4..6c5fef3 100644
--- a/drivers/net/wireless/ti/wl18xx/acx.h
+++ b/drivers/net/wireless/ti/wl18xx/acx.h
@@ -93,11 +93,23 @@ struct wl18xx_acx_checksum_state {
struct wl18xx_acx_error_stats {
- u32 error_frame;
- u32 error_null_Frame_tx_start;
- u32 error_numll_frame_cts_start;
- u32 error_bar_retry;
- u32 error_frame_cts_nul_flid;
+ u32 error_frame_non_ctrl;
+ u32 error_frame_ctrl;
+ u32 error_frame_during_protection;
+ u32 null_frame_tx_start;
+ u32 null_frame_cts_start;
+ u32 bar_retry;
+ u32 num_frame_cts_nul_flid;
+ u32 tx_abort_failure;
+ u32 tx_resume_failure;
+ u32 rx_cmplt_db_overflow_cnt;
+ u32 elp_while_rx_exch;
+ u32 elp_while_tx_exch;
+ u32 elp_while_tx;
+ u32 elp_while_nvic_pending;
+ u32 rx_excessive_frame_len;
+ u32 burst_mismatch;
+ u32 tbc_exch_mismatch;
} __packed;
struct wl18xx_acx_debug_stats {
@@ -114,6 +126,7 @@ struct wl18xx_acx_ring_stats {
u32 tx_cmplt;
} __packed;
+#define NUM_OF_RATES_INDEXES 30
struct wl18xx_acx_tx_stats {
u32 tx_prepared_descs;
u32 tx_cmplt;
@@ -123,7 +136,7 @@ struct wl18xx_acx_tx_stats {
u32 tx_data_programmed;
u32 tx_burst_programmed;
u32 tx_starts;
- u32 tx_imm_resp;
+ u32 tx_stop;
u32 tx_start_templates;
u32 tx_start_int_templates;
u32 tx_start_fw_gen;
@@ -132,13 +145,14 @@ struct wl18xx_acx_tx_stats {
u32 tx_exch;
u32 tx_retry_template;
u32 tx_retry_data;
+ u32 tx_retry_per_rate[NUM_OF_RATES_INDEXES];
u32 tx_exch_pending;
u32 tx_exch_expiry;
u32 tx_done_template;
u32 tx_done_data;
u32 tx_done_int_template;
- u32 tx_frame_checksum;
- u32 tx_checksum_result;
+ u32 tx_cfe1;
+ u32 tx_cfe2;
u32 frag_called;
u32 frag_mpdu_alloc_failed;
u32 frag_init_called;
@@ -166,11 +180,8 @@ struct wl18xx_acx_rx_stats {
u32 rx_cmplt_task;
u32 rx_phy_hdr;
u32 rx_timeout;
+ u32 rx_rts_timeout;
u32 rx_timeout_wa;
- u32 rx_wa_density_dropped_frame;
- u32 rx_wa_ba_not_expected;
- u32 rx_frame_checksum;
- u32 rx_checksum_result;
u32 defrag_called;
u32 defrag_init_called;
u32 defrag_in_process_called;
@@ -180,6 +191,7 @@ struct wl18xx_acx_rx_stats {
u32 decrypt_key_not_found;
u32 defrag_need_decrypt;
u32 rx_tkip_replays;
+ u32 rx_xfr;
} __packed;
struct wl18xx_acx_isr_stats {
@@ -194,6 +206,13 @@ struct wl18xx_acx_pwr_stats {
u32 connection_out_of_sync;
u32 cont_miss_bcns_spread[PWR_STAT_MAX_CONT_MISSED_BCNS_SPREAD];
u32 rcvd_awake_bcns_cnt;
+ u32 sleep_time_count;
+ u32 sleep_time_avg;
+ u32 sleep_cycle_avg;
+ u32 sleep_percent;
+ u32 ap_sleep_active_conf;
+ u32 ap_sleep_user_conf;
+ u32 ap_sleep_counter;
} __packed;
struct wl18xx_acx_event_stats {
@@ -228,11 +247,11 @@ struct wl18xx_acx_rx_rate_stats {
} __packed;
#define AGGR_STATS_TX_AGG 16
-#define AGGR_STATS_TX_RATE 16
#define AGGR_STATS_RX_SIZE_LEN 16
struct wl18xx_acx_aggr_stats {
- u32 tx_agg_vs_rate[AGGR_STATS_TX_AGG * AGGR_STATS_TX_RATE];
+ u32 tx_agg_rate[AGGR_STATS_TX_AGG];
+ u32 tx_agg_len[AGGR_STATS_TX_AGG];
u32 rx_size[AGGR_STATS_RX_SIZE_LEN];
} __packed;
@@ -258,6 +277,7 @@ struct wl18xx_acx_pipeline_stats {
u32 cs_rx_packet_in;
u32 cs_rx_packet_out;
u16 pipeline_fifo_full[PIPE_STATS_HW_FIFO];
+ u16 padding;
} __packed;
struct wl18xx_acx_mem_stats {
@@ -267,21 +287,45 @@ struct wl18xx_acx_mem_stats {
u32 fw_gen_free_mem_blks;
} __packed;
+struct wl18xx_acx_thermal_stats {
+ u16 irq_thr_low;
+ u16 irq_thr_high;
+ u16 tx_stop;
+ u16 tx_resume;
+ u16 false_irq;
+ u16 adc_source_unexpected;
+} __packed;
+
+#define WL18XX_NUM_OF_CALIBRATIONS_ERRORS 18
+struct wl18xx_acx_calib_failure_stats {
+ u16 fail_count[WL18XX_NUM_OF_CALIBRATIONS_ERRORS];
+ u32 calib_count;
+} __packed;
+
+struct wl18xx_roaming_stats {
+ s32 rssi_level;
+} __packed;
+
+struct wl18xx_dfs_stats {
+ u32 num_of_radar_detections;
+} __packed;
+
struct wl18xx_acx_statistics {
struct acx_header header;
struct wl18xx_acx_error_stats error;
- struct wl18xx_acx_debug_stats debug;
struct wl18xx_acx_tx_
[PATCH] mwifiex: corrected README as per the file debugfs.c
Subject: [PATCH] mwifiex: corrected README as per the file debugfs.c
Signed-off-by: Rahul Jain
Signed-off-by: Amit Khatri
---
drivers/net/wireless/mwifiex/README | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mwifiex/README
b/drivers/net/wireless/mwifiex/README
index 2f0f9b5..e0108df 100644
--- a/drivers/net/wireless/mwifiex/README
+++ b/drivers/net/wireless/mwifiex/README
@@ -93,6 +93,7 @@ info
driver_name = "mwifiex"
driver_version =
+ verext =
interface_name = "mlanX"
bss_mode = "Ad-hoc" | "Managed" | "Auto" | "Unknown"
media_state = "Disconnected" | "Connected"
@@ -101,7 +102,7 @@ info
essid =
bssid =
channel =
- region_code =
+ country_code =
multicasr_address[n] =
num_tx_bytes =
num_rx_bytes =
--
1.9.1
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±Â*Þ•ë,Š{ayº ʇڙë,j¢f£¢·hš‹àz¹ ®w¥¢¸
¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾«‘êçzZ+ƒùšŽŠÝ¢j"�ú!¶i
[PATCH 2/2] wl18xx: add diversity statistics
Add diversity statistics and sync the driver
statistics acx and debugfs representation
with the current fw api.
Signed-off-by: Guy Mishol
---
drivers/net/wireless/ti/wl18xx/acx.h | 47 -
drivers/net/wireless/ti/wl18xx/debugfs.c | 21 ++---
2 files changed, 16 insertions(+), 52 deletions(-)
diff --git a/drivers/net/wireless/ti/wl18xx/acx.h
b/drivers/net/wireless/ti/wl18xx/acx.h
index 6c5fef3..342a299 100644
--- a/drivers/net/wireless/ti/wl18xx/acx.h
+++ b/drivers/net/wireless/ti/wl18xx/acx.h
@@ -112,20 +112,6 @@ struct wl18xx_acx_error_stats {
u32 tbc_exch_mismatch;
} __packed;
-struct wl18xx_acx_debug_stats {
- u32 debug1;
- u32 debug2;
- u32 debug3;
- u32 debug4;
- u32 debug5;
- u32 debug6;
-} __packed;
-
-struct wl18xx_acx_ring_stats {
- u32 prepared_descs;
- u32 tx_cmplt;
-} __packed;
-
#define NUM_OF_RATES_INDEXES 30
struct wl18xx_acx_tx_stats {
u32 tx_prepared_descs;
@@ -215,21 +201,6 @@ struct wl18xx_acx_pwr_stats {
u32 ap_sleep_counter;
} __packed;
-struct wl18xx_acx_event_stats {
- u32 calibration;
- u32 rx_mismatch;
- u32 rx_mem_empty;
-} __packed;
-
-struct wl18xx_acx_ps_poll_stats {
- u32 ps_poll_timeouts;
- u32 upsd_timeouts;
- u32 upsd_max_ap_turn;
- u32 ps_poll_max_ap_turn;
- u32 ps_poll_utilization;
- u32 upsd_utilization;
-} __packed;
-
struct wl18xx_acx_rx_filter_stats {
u32 beacon_filter;
u32 arp_filter;
@@ -260,8 +231,6 @@ struct wl18xx_acx_aggr_stats {
struct wl18xx_acx_pipeline_stats {
u32 hs_tx_stat_fifo_int;
u32 hs_rx_stat_fifo_int;
- u32 tcp_tx_stat_fifo_int;
- u32 tcp_rx_stat_fifo_int;
u32 enc_tx_stat_fifo_int;
u32 enc_rx_stat_fifo_int;
u32 rx_complete_stat_fifo_int;
@@ -269,22 +238,19 @@ struct wl18xx_acx_pipeline_stats {
u32 post_proc_swi;
u32 sec_frag_swi;
u32 pre_to_defrag_swi;
- u32 defrag_to_csum_swi;
- u32 csum_to_rx_xfer_swi;
+ u32 defrag_to_rx_xfer_swi;
u32 dec_packet_in;
u32 dec_packet_in_fifo_full;
u32 dec_packet_out;
- u32 cs_rx_packet_in;
- u32 cs_rx_packet_out;
u16 pipeline_fifo_full[PIPE_STATS_HW_FIFO];
u16 padding;
} __packed;
-struct wl18xx_acx_mem_stats {
- u32 rx_free_mem_blks;
- u32 tx_free_mem_blks;
- u32 fwlog_free_mem_blks;
- u32 fw_gen_free_mem_blks;
+#define DIVERSITY_STATS_NUM_OF_ANT 2
+
+struct wl18xx_acx_diversity_stats {
+ u32 num_of_packets_per_ant[DIVERSITY_STATS_NUM_OF_ANT];
+ u32 total_num_of_toggles;
} __packed;
struct wl18xx_acx_thermal_stats {
@@ -322,6 +288,7 @@ struct wl18xx_acx_statistics {
struct wl18xx_acx_rx_rate_stats rx_rate;
struct wl18xx_acx_aggr_statsaggr_size;
struct wl18xx_acx_pipeline_statspipeline;
+ struct wl18xx_acx_diversity_stats diversity;
struct wl18xx_acx_thermal_stats thermal;
struct wl18xx_acx_calib_failure_stats calib;
struct wl18xx_roaming_stats roaming;
diff --git a/drivers/net/wireless/ti/wl18xx/debugfs.c
b/drivers/net/wireless/ti/wl18xx/debugfs.c
index cf71005..4edfe28 100644
--- a/drivers/net/wireless/ti/wl18xx/debugfs.c
+++ b/drivers/net/wireless/ti/wl18xx/debugfs.c
@@ -153,8 +153,6 @@ WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY(aggr_size, rx_size,
AGGR_STATS_RX_SIZE_LEN);
WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, hs_tx_stat_fifo_int, "%u");
-WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, tcp_tx_stat_fifo_int, "%u");
-WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, tcp_rx_stat_fifo_int, "%u");
WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, enc_tx_stat_fifo_int, "%u");
WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, enc_rx_stat_fifo_int, "%u");
WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, rx_complete_stat_fifo_int, "%u");
@@ -162,17 +160,18 @@ WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, pre_proc_swi, "%u");
WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, post_proc_swi, "%u");
WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, sec_frag_swi, "%u");
WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, pre_to_defrag_swi, "%u");
-WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, defrag_to_csum_swi, "%u");
-WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, csum_to_rx_xfer_swi, "%u");
+WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, defrag_to_rx_xfer_swi, "%u");
WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, dec_packet_in, "%u");
WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, dec_packet_in_fifo_full, "%u");
WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, dec_packet_out, "%u");
-WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, cs_rx_packet_in, "%u");
-WL18XX_DEBUGFS_FWSTATS_FILE(pipeline, cs_rx_packet_out, "%u");
WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY(pipeline, pipeline_fifo_full,
PIPE_STATS_HW_FIFO);
+WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY(diversity, num_of_packets_per_ant,
+ DIVERSITY_STATS_NUM_
[PATCH 1/2] wl18xx: update statistics acx and debugfs files
From: Eliad Peller
Sync the driver statistics acx and debugfs representation
with the current fw api.
Signed-off-by: Eliad Peller
---
drivers/net/wireless/ti/wl18xx/acx.h | 78 ---
drivers/net/wireless/ti/wl18xx/debugfs.c | 159 ++
2 files changed, 156 insertions(+), 81 deletions(-)
diff --git a/drivers/net/wireless/ti/wl18xx/acx.h
b/drivers/net/wireless/ti/wl18xx/acx.h
index c8a33f4..6c5fef3 100644
--- a/drivers/net/wireless/ti/wl18xx/acx.h
+++ b/drivers/net/wireless/ti/wl18xx/acx.h
@@ -93,11 +93,23 @@ struct wl18xx_acx_checksum_state {
struct wl18xx_acx_error_stats {
- u32 error_frame;
- u32 error_null_Frame_tx_start;
- u32 error_numll_frame_cts_start;
- u32 error_bar_retry;
- u32 error_frame_cts_nul_flid;
+ u32 error_frame_non_ctrl;
+ u32 error_frame_ctrl;
+ u32 error_frame_during_protection;
+ u32 null_frame_tx_start;
+ u32 null_frame_cts_start;
+ u32 bar_retry;
+ u32 num_frame_cts_nul_flid;
+ u32 tx_abort_failure;
+ u32 tx_resume_failure;
+ u32 rx_cmplt_db_overflow_cnt;
+ u32 elp_while_rx_exch;
+ u32 elp_while_tx_exch;
+ u32 elp_while_tx;
+ u32 elp_while_nvic_pending;
+ u32 rx_excessive_frame_len;
+ u32 burst_mismatch;
+ u32 tbc_exch_mismatch;
} __packed;
struct wl18xx_acx_debug_stats {
@@ -114,6 +126,7 @@ struct wl18xx_acx_ring_stats {
u32 tx_cmplt;
} __packed;
+#define NUM_OF_RATES_INDEXES 30
struct wl18xx_acx_tx_stats {
u32 tx_prepared_descs;
u32 tx_cmplt;
@@ -123,7 +136,7 @@ struct wl18xx_acx_tx_stats {
u32 tx_data_programmed;
u32 tx_burst_programmed;
u32 tx_starts;
- u32 tx_imm_resp;
+ u32 tx_stop;
u32 tx_start_templates;
u32 tx_start_int_templates;
u32 tx_start_fw_gen;
@@ -132,13 +145,14 @@ struct wl18xx_acx_tx_stats {
u32 tx_exch;
u32 tx_retry_template;
u32 tx_retry_data;
+ u32 tx_retry_per_rate[NUM_OF_RATES_INDEXES];
u32 tx_exch_pending;
u32 tx_exch_expiry;
u32 tx_done_template;
u32 tx_done_data;
u32 tx_done_int_template;
- u32 tx_frame_checksum;
- u32 tx_checksum_result;
+ u32 tx_cfe1;
+ u32 tx_cfe2;
u32 frag_called;
u32 frag_mpdu_alloc_failed;
u32 frag_init_called;
@@ -166,11 +180,8 @@ struct wl18xx_acx_rx_stats {
u32 rx_cmplt_task;
u32 rx_phy_hdr;
u32 rx_timeout;
+ u32 rx_rts_timeout;
u32 rx_timeout_wa;
- u32 rx_wa_density_dropped_frame;
- u32 rx_wa_ba_not_expected;
- u32 rx_frame_checksum;
- u32 rx_checksum_result;
u32 defrag_called;
u32 defrag_init_called;
u32 defrag_in_process_called;
@@ -180,6 +191,7 @@ struct wl18xx_acx_rx_stats {
u32 decrypt_key_not_found;
u32 defrag_need_decrypt;
u32 rx_tkip_replays;
+ u32 rx_xfr;
} __packed;
struct wl18xx_acx_isr_stats {
@@ -194,6 +206,13 @@ struct wl18xx_acx_pwr_stats {
u32 connection_out_of_sync;
u32 cont_miss_bcns_spread[PWR_STAT_MAX_CONT_MISSED_BCNS_SPREAD];
u32 rcvd_awake_bcns_cnt;
+ u32 sleep_time_count;
+ u32 sleep_time_avg;
+ u32 sleep_cycle_avg;
+ u32 sleep_percent;
+ u32 ap_sleep_active_conf;
+ u32 ap_sleep_user_conf;
+ u32 ap_sleep_counter;
} __packed;
struct wl18xx_acx_event_stats {
@@ -228,11 +247,11 @@ struct wl18xx_acx_rx_rate_stats {
} __packed;
#define AGGR_STATS_TX_AGG 16
-#define AGGR_STATS_TX_RATE 16
#define AGGR_STATS_RX_SIZE_LEN 16
struct wl18xx_acx_aggr_stats {
- u32 tx_agg_vs_rate[AGGR_STATS_TX_AGG * AGGR_STATS_TX_RATE];
+ u32 tx_agg_rate[AGGR_STATS_TX_AGG];
+ u32 tx_agg_len[AGGR_STATS_TX_AGG];
u32 rx_size[AGGR_STATS_RX_SIZE_LEN];
} __packed;
@@ -258,6 +277,7 @@ struct wl18xx_acx_pipeline_stats {
u32 cs_rx_packet_in;
u32 cs_rx_packet_out;
u16 pipeline_fifo_full[PIPE_STATS_HW_FIFO];
+ u16 padding;
} __packed;
struct wl18xx_acx_mem_stats {
@@ -267,21 +287,45 @@ struct wl18xx_acx_mem_stats {
u32 fw_gen_free_mem_blks;
} __packed;
+struct wl18xx_acx_thermal_stats {
+ u16 irq_thr_low;
+ u16 irq_thr_high;
+ u16 tx_stop;
+ u16 tx_resume;
+ u16 false_irq;
+ u16 adc_source_unexpected;
+} __packed;
+
+#define WL18XX_NUM_OF_CALIBRATIONS_ERRORS 18
+struct wl18xx_acx_calib_failure_stats {
+ u16 fail_count[WL18XX_NUM_OF_CALIBRATIONS_ERRORS];
+ u32 calib_count;
+} __packed;
+
+struct wl18xx_roaming_stats {
+ s32 rssi_level;
+} __packed;
+
+struct wl18xx_dfs_stats {
+ u32 num_of_radar_detections;
+} __packed;
+
struct wl18xx_acx_statistics {
struct acx_header header;
struct wl18xx_acx_error_stats error;
- struct wl18xx_acx_debug_stats debug;
struct wl18xx_acx_tx_
[PATCH 1/2] wl18xx: update statistics acx and debugfs files
From: Eliad Peller
Sync the driver statistics acx and debugfs representation
with the current fw api.
Signed-off-by: Eliad Peller
---
drivers/net/wireless/ti/wl18xx/acx.h | 78 ---
drivers/net/wireless/ti/wl18xx/debugfs.c | 159 ++
2 files changed, 156 insertions(+), 81 deletions(-)
diff --git a/drivers/net/wireless/ti/wl18xx/acx.h
b/drivers/net/wireless/ti/wl18xx/acx.h
index c8a33f4..6c5fef3 100644
--- a/drivers/net/wireless/ti/wl18xx/acx.h
+++ b/drivers/net/wireless/ti/wl18xx/acx.h
@@ -93,11 +93,23 @@ struct wl18xx_acx_checksum_state {
struct wl18xx_acx_error_stats {
- u32 error_frame;
- u32 error_null_Frame_tx_start;
- u32 error_numll_frame_cts_start;
- u32 error_bar_retry;
- u32 error_frame_cts_nul_flid;
+ u32 error_frame_non_ctrl;
+ u32 error_frame_ctrl;
+ u32 error_frame_during_protection;
+ u32 null_frame_tx_start;
+ u32 null_frame_cts_start;
+ u32 bar_retry;
+ u32 num_frame_cts_nul_flid;
+ u32 tx_abort_failure;
+ u32 tx_resume_failure;
+ u32 rx_cmplt_db_overflow_cnt;
+ u32 elp_while_rx_exch;
+ u32 elp_while_tx_exch;
+ u32 elp_while_tx;
+ u32 elp_while_nvic_pending;
+ u32 rx_excessive_frame_len;
+ u32 burst_mismatch;
+ u32 tbc_exch_mismatch;
} __packed;
struct wl18xx_acx_debug_stats {
@@ -114,6 +126,7 @@ struct wl18xx_acx_ring_stats {
u32 tx_cmplt;
} __packed;
+#define NUM_OF_RATES_INDEXES 30
struct wl18xx_acx_tx_stats {
u32 tx_prepared_descs;
u32 tx_cmplt;
@@ -123,7 +136,7 @@ struct wl18xx_acx_tx_stats {
u32 tx_data_programmed;
u32 tx_burst_programmed;
u32 tx_starts;
- u32 tx_imm_resp;
+ u32 tx_stop;
u32 tx_start_templates;
u32 tx_start_int_templates;
u32 tx_start_fw_gen;
@@ -132,13 +145,14 @@ struct wl18xx_acx_tx_stats {
u32 tx_exch;
u32 tx_retry_template;
u32 tx_retry_data;
+ u32 tx_retry_per_rate[NUM_OF_RATES_INDEXES];
u32 tx_exch_pending;
u32 tx_exch_expiry;
u32 tx_done_template;
u32 tx_done_data;
u32 tx_done_int_template;
- u32 tx_frame_checksum;
- u32 tx_checksum_result;
+ u32 tx_cfe1;
+ u32 tx_cfe2;
u32 frag_called;
u32 frag_mpdu_alloc_failed;
u32 frag_init_called;
@@ -166,11 +180,8 @@ struct wl18xx_acx_rx_stats {
u32 rx_cmplt_task;
u32 rx_phy_hdr;
u32 rx_timeout;
+ u32 rx_rts_timeout;
u32 rx_timeout_wa;
- u32 rx_wa_density_dropped_frame;
- u32 rx_wa_ba_not_expected;
- u32 rx_frame_checksum;
- u32 rx_checksum_result;
u32 defrag_called;
u32 defrag_init_called;
u32 defrag_in_process_called;
@@ -180,6 +191,7 @@ struct wl18xx_acx_rx_stats {
u32 decrypt_key_not_found;
u32 defrag_need_decrypt;
u32 rx_tkip_replays;
+ u32 rx_xfr;
} __packed;
struct wl18xx_acx_isr_stats {
@@ -194,6 +206,13 @@ struct wl18xx_acx_pwr_stats {
u32 connection_out_of_sync;
u32 cont_miss_bcns_spread[PWR_STAT_MAX_CONT_MISSED_BCNS_SPREAD];
u32 rcvd_awake_bcns_cnt;
+ u32 sleep_time_count;
+ u32 sleep_time_avg;
+ u32 sleep_cycle_avg;
+ u32 sleep_percent;
+ u32 ap_sleep_active_conf;
+ u32 ap_sleep_user_conf;
+ u32 ap_sleep_counter;
} __packed;
struct wl18xx_acx_event_stats {
@@ -228,11 +247,11 @@ struct wl18xx_acx_rx_rate_stats {
} __packed;
#define AGGR_STATS_TX_AGG 16
-#define AGGR_STATS_TX_RATE 16
#define AGGR_STATS_RX_SIZE_LEN 16
struct wl18xx_acx_aggr_stats {
- u32 tx_agg_vs_rate[AGGR_STATS_TX_AGG * AGGR_STATS_TX_RATE];
+ u32 tx_agg_rate[AGGR_STATS_TX_AGG];
+ u32 tx_agg_len[AGGR_STATS_TX_AGG];
u32 rx_size[AGGR_STATS_RX_SIZE_LEN];
} __packed;
@@ -258,6 +277,7 @@ struct wl18xx_acx_pipeline_stats {
u32 cs_rx_packet_in;
u32 cs_rx_packet_out;
u16 pipeline_fifo_full[PIPE_STATS_HW_FIFO];
+ u16 padding;
} __packed;
struct wl18xx_acx_mem_stats {
@@ -267,21 +287,45 @@ struct wl18xx_acx_mem_stats {
u32 fw_gen_free_mem_blks;
} __packed;
+struct wl18xx_acx_thermal_stats {
+ u16 irq_thr_low;
+ u16 irq_thr_high;
+ u16 tx_stop;
+ u16 tx_resume;
+ u16 false_irq;
+ u16 adc_source_unexpected;
+} __packed;
+
+#define WL18XX_NUM_OF_CALIBRATIONS_ERRORS 18
+struct wl18xx_acx_calib_failure_stats {
+ u16 fail_count[WL18XX_NUM_OF_CALIBRATIONS_ERRORS];
+ u32 calib_count;
+} __packed;
+
+struct wl18xx_roaming_stats {
+ s32 rssi_level;
+} __packed;
+
+struct wl18xx_dfs_stats {
+ u32 num_of_radar_detections;
+} __packed;
+
struct wl18xx_acx_statistics {
struct acx_header header;
struct wl18xx_acx_error_stats error;
- struct wl18xx_acx_debug_stats debug;
struct wl18xx_acx_tx_
RE: linux-4.2-rc4/drivers/staging/wilc1000/linux_mon.c:264: memory leak ?
Hello there,
> but It is not memory leak because If tx queue is complete, kfree() is
> called in mgmt_tx_complete() funtion.
Maybe I've been slightly less than clear. I'll have another go.
There is a call to kmalloc around line 250.
Source code is
mgmt_tx = kmalloc(sizeof(struct tx_complete_mon_data), GFP_ATOMIC);
A few lines later is a second call to kmalloc
mgmt_tx->buff = kmalloc(len, GFP_ATOMIC);
If the second call fails, then proper tidyup would normally include
calling kfree for the first call. This doesn't happen in the error handling
code for the second call.
if (mgmt_tx->buff == NULL) {
PRINT_ER("Failed to allocate memory for mgmt_tx buff\n");
return WILC_FAIL;
}
Not a big bug, I admit, but might be worth fixing.
Something like
if (mgmt_tx->buff == NULL) {
kfree(mgmt);
PRINT_ER("Failed to allocate memory for mgmt_tx buff\n");
return WILC_FAIL;
}
would probably fix it.
My apologies for not being clear earlier.
Regards
David Binderman
>
> Source code is
>
> g_linux_wlan->oup.wlan_add_mgmt_to_tx_que(mgmt_tx, mgmt_tx->buff,
> mgmt_tx->size, mgmt_tx_complete);
>
> static void mgmt_tx_complete(void *priv, int status)
> {
> ...
> kfree(pv_data->buff);
> kfree(pv_data);
> }
>
> BR.
> Chris
>
> On 2015년 07월 27일 17:20, David Binderman wrote:
>
> Hello there,
>
> [linux-4.2-rc4/drivers/staging/wilc1000/linux_mon.c:264]: (error) Memory
> leak: mgmt_tx
>
> Source code is
>
> mgmt_tx->buff = kmalloc(len, GFP_ATOMIC);
> if (mgmt_tx->buff == NULL) {
> PRINT_ER("Failed to allocate memory for mgmt_tx buff\n");
> return WILC_FAIL;
>
> }
>
> Suggest add missing call to kfree.
>
>
> Regards
>
> David Binderman
>
>
>
Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive
Arend van Spriel writes: > On 07/24/2015 07:22 PM, Vineet Gupta wrote: >> On Friday 24 July 2015 08:02 PM, Kalle Valo wrote: >>> Vineet Gupta writes: >>> > There's already a generic implementation so use that instead. > --- > I'm not sure if the driver usage of atomic_or?() is correct in terms of > storage size of @val for 64 bit arches. > > Assuming LP64 programming model for linux on say x86_64: atomic_or() > callers in this driver use long (sana 64 bit) storage and pass it to > atomic_orr/atomic_or which downcasts it to 32 bits. Is that OK ? > --- > Cc: Brett Rudley > Cc: Arend van Spriel > Cc: "Franky (Zhenhui) Lin" > Cc: Hante Meuleman > Cc: Kalle Valo > Cc: Pieter-Paul Giesberts > Cc: Daniel Kim > Cc: linux-wireless@vger.kernel.org > Cc: brcm80211-dev-l...@broadcom.com > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: net...@vger.kernel.org > Cc: linux-a...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Vineet Gupta > > Signed-off-by: Vineet Gupta >>> What's the plan with this patch? Should I take it to my >>> wireless-drivers-next tree or will someone else take it? >> >> >> Per last discussion on this topic, Arend wanted to discuss abt this with >> Hante. >> I'm not taking it anyways so feel free to pick it up if you want ! > > Well, that was before your "timeline" clarification about the generic > function. One what tree is this patch based? Yeah, if this patch depends on another patch I need to know about it. Otherwise I might break something when I apply this patch. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] brcmfmac: dhd_sdio.c: use existing atomic_or primitive
On Monday 27 July 2015 01:08 PM, Kalle Valo wrote: >>> >> Per last discussion on this topic, Arend wanted to discuss abt this with >>> >> Hante. >>> >> I'm not taking it anyways so feel free to pick it up if you want ! >> > >> > Well, that was before your "timeline" clarification about the generic >> > function. One what tree is this patch based? > Yeah, if this patch depends on another patch I need to know about it. > Otherwise I might break something when I apply this patch. It was latest linux-next at the time, 4.1-rcx perhaps, don't remember exactly. But it certainly doesn't depend on any new code - the patch simply makes use of an existing API vs. using a local hard coded version of same. Give it a spin off your existing tree - shdn't be too difficult to test I presume. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rsi: Fix failure to load firmware after memory leak fix and fix the leak
Mike Looijmans writes:
> Fixes commit eae79b4f3e82ca63a53478a161b190a0d38fe526 ("rsi: fix memory leak
> in rsi_load_ta_instructions()") which stopped the driver from functioning.
You can abbreviate the commit id:
Fixes commit eae79b4f3e82 ("rsi: fix memory leak in
rsi_load_ta_instructions()") which stopped the driver from functioning.
> Firmware data has been allocated using vmalloc(), resulting in memory
> that cannot be used for DMA. Hence the firmware was first copied to a
> buffer allocated with kmalloc() in the original code. This patch reverts
> the commit and only calls "kfree()" to release the buffer after sending
> the data. This fixes the memory leak without breaking the driver.
>
> Add a comment to the kmemdup() calls to explain why this is done.
>
> Tested on a Topic Miami-Florida board which contains the rsi SDIO chip.
>
> Also added the same kfree() call to the USB glue driver. This was not
> tested on actual hardware though, as I only have the SDIO version.
>
> Signed-off-by: Mike Looijmans
Add this before Signed-off-by line:
Fixes: eae79b4f3e82 ("rsi: fix memory leak in rsi_load_ta_instructions()")
> Cc: sta...@vger.kernel.org
Also no need to send email to sta...@vger.kernel.org list, this line is
enough and the stable team will pick the commit automatically.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ath9k: export HW random number generator
Am 27.07.2015 um 08:50 schrieb Pan, Miaoqing:
> “fips_run_rng_test” is legacy code, recommend to disable 'FIPS 140-2' test
> if to use 'rngd-tools’.
Ok, lets try simple compression. will it find enough pattern to do
compression?
Here what i get on my system:
output from /dev/random
-rw-rw-r-- 1 lex lex 2501678 Jul 27 12:01 random.out
-rw-rw-r-- 1 lex lex 2512892 Jul 27 12:01 random.out.bz2
after compression we got bigger file. i would expect it since we need to
store bzip header somewhere.
output from /dev/hwrng
-rw-rw-r-- 1 lex lex 2564096 Jul 27 11:36 hwrng.out
-rw-rw-r-- 1 lex lex 2468394 Jul 27 11:36 hwrng.out.bz2
Do i understand it correctly, in case of hwrng bzip was able to find
enough pattern to compressed the data? Even with format overhead?
I'm no an expert, help of an expert would be welcome, added some more
people to CC
> -Miaoqing
>
> -Original Message-
> From: Oleksij Rempel [mailto:li...@rempel-privat.de]
> Sent: Sunday, July 26, 2015 3:41 PM
> To: Pan, Miaoqing; linvi...@tuxdriver.com
> Cc: linux-wireless@vger.kernel.org; ath9k-devel
> Subject: Re: [PATCH 2/2] ath9k: export HW random number generator
>
> Hi all,
>
> i did rngtest on top of this patch. The results are incredibly bad, right now
> it is more a pattern generator not random number generator. Is it possible to
> fix it?
>
> /home/lex# cat /dev/hwrng | rngtest -c 1000 rngtest 5 Copyright (c) 2004 by
> Henrique de Moraes Holschuh This is free software; see the source for copying
> conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS
> FOR A PARTICULAR PURPOSE.
>
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 2032
> rngtest: FIPS 140-2 successes: 0
> rngtest: FIPS 140-2 failures: 1000
> rngtest: FIPS 140-2(2001-10-10) Monobit: 27
> rngtest: FIPS 140-2(2001-10-10) Poker: 1000
> rngtest: FIPS 140-2(2001-10-10) Runs: 1000
> rngtest: FIPS 140-2(2001-10-10) Long run: 2
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=1.879; avg=871.897;
> max=19531250.000)Kibits/s
> rngtest: FIPS tests speed: (min=19.443; avg=48.374; max=70.123)Mibits/s
> rngtest: Program run time: 23423736 microseconds
>
>
>
> Am 15.07.2015 um 09:54 schrieb miaoq...@qti.qualcomm.com:
>> From: Miaoqing Pan
>>
>> We measured the FFT-based entropy in 3 ways, Shannon entropy,
>> collision entropy, and directly measured min-entropy. Just to be
>> conservative, we recommend the estimated min-Entropy to be
>> 10 bits per 16-bit value.
>>
>> Analysis was done by Jacobson,David(djaco...@qti.qualcomm.com).
>>
>> Signed-off-by: Miaoqing Pan
>> ---
>> drivers/net/wireless/ath/ath9k/Kconfig | 7 +++
>> drivers/net/wireless/ath/ath9k/Makefile | 1 +
>> drivers/net/wireless/ath/ath9k/ath9k.h | 23 ++
>> drivers/net/wireless/ath/ath9k/main.c | 4 ++
>> drivers/net/wireless/ath/ath9k/rng.c| 75
>> +
>> 5 files changed, 110 insertions(+)
>> create mode 100644 drivers/net/wireless/ath/ath9k/rng.c
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
>> b/drivers/net/wireless/ath/ath9k/Kconfig
>> index fee0cad..bde62ec9 100644
>> --- a/drivers/net/wireless/ath/ath9k/Kconfig
>> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
>> @@ -176,3 +176,10 @@ config ATH9K_HTC_DEBUGFS
>> depends on ATH9K_HTC && DEBUG_FS
>> ---help---
>>Say Y, if you need access to ath9k_htc's statistics.
>> +
>> +config ATH9K_HWRNG
>> +bool "Random number generator support"
>> +depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
>> +default y
>> +---help---
>> + Provides a hardware random number generator to the kernel.
>> diff --git a/drivers/net/wireless/ath/ath9k/Makefile
>> b/drivers/net/wireless/ath/ath9k/Makefile
>> index ecda613..76f9dc3 100644
>> --- a/drivers/net/wireless/ath/ath9k/Makefile
>> +++ b/drivers/net/wireless/ath/ath9k/Makefile
>> @@ -15,6 +15,7 @@ ath9k-$(CONFIG_ATH9K_DFS_DEBUGFS) += dfs_debug.o
>> ath9k-$(CONFIG_ATH9K_DFS_CERTIFIED) += dfs.o
>> ath9k-$(CONFIG_ATH9K_TX99) += tx99.o
>> ath9k-$(CONFIG_ATH9K_WOW) += wow.o
>> +ath9k-$(CONFIG_ATH9K_HWRNG) += rng.o
>>
>> ath9k-$(CONFIG_ATH9K_DEBUGFS) += debug.o
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
>> b/drivers/net/wireless/ath/ath9k/ath9k.h
>> index a7a81b3..45596e5 100644
>> --- a/drivers/net/wireless/ath/ath9k/ath9k.h
>> +++ b/drivers/net/wireless/ath/ath9k/ath9k.h
>> @@ -23,6 +23,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "common.h"
>> #include "debug.h"
>> @@ -1041,6 +1042,12 @@ struct ath_softc {
>> u32 wow_intr_before_sleep;
>> bool force_wow;
>> #endif
>> +
>> +#ifdef CONFIG_ATH9K_HWRNG
>> +struct hwrng rng;
>> +bool rng_initialized;
>> +u32 rng_last;
>> +#endif
>> };
>>
>> //
>> @@ -1063,6 +1070,22 @@ static inline int ath9k_tx99_send(struct
>> ath_softc *sc, } #endif /* CONFIG_ATH9K_TX99 */
>>
>> +/*
suche intel(R)PRO/Wireless 2200BG - treiber für xubuntu
Bitte um Hilfe, suche einen intel(R)PRO/Wireless 2200BG - treiber für xubuntu... war auf der "http://ipw2200.sourceforge.net/"; - Seite, konnte aber keine verbindung zum Server bekommen...kann man mir helfen. H.seidel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ath9k: export HW random number generator
Am Montag, 27. Juli 2015, 12:45:29 schrieb Oleksij Rempel: Hi Oleksij, >Am 27.07.2015 um 08:50 schrieb Pan, Miaoqing: >> “fips_run_rng_test” is legacy code, recommend to disable 'FIPS 140-2' >> test if to use 'rngd-tools’. >Ok, lets try simple compression. will it find enough pattern to do >compression? >Here what i get on my system: >output from /dev/random >-rw-rw-r-- 1 lex lex 2501678 Jul 27 12:01 random.out >-rw-rw-r-- 1 lex lex 2512892 Jul 27 12:01 random.out.bz2 > >after compression we got bigger file. i would expect it since we need to >store bzip header somewhere. > >output from /dev/hwrng >-rw-rw-r-- 1 lex lex 2564096 Jul 27 11:36 hwrng.out >-rw-rw-r-- 1 lex lex 2468394 Jul 27 11:36 hwrng.out.bz2 > >Do i understand it correctly, in case of hwrng bzip was able to find >enough pattern to compressed the data? Even with format overhead? > >I'm no an expert, help of an expert would be welcome, added some more >people to CC This one does not look good for a claim that the RNG produces white noise. An RNG that is wired up to /dev/hwrng should produce white noise. Either by having an appropriate noise source or by conditioning the output of the noise source. When conditioning the output, you have to be careful about the entropy claim. For example, you cannot state that the data stream from your noise source has close to one bit of entropy for each obtained bit. Thus, the conditioner must ensure that the data from the noise source is collected and its entropy is maintained and accumulated. However, the hwrandom framework does not provide any conditioning logic. And I would say that such conditioner logic should not reside in a driver either. I would say that the discussed RNG does not seem fit for hooking it up with the hwrandom framework. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: suche intel(R)PRO/Wireless 2200BG - treiber für xubuntu
Hi, 2015-07-27 20:36 GMT+10:00 Harald Seidel : > Bitte um Hilfe, > > suche einen intel(R)PRO/Wireless 2200BG - treiber für xubuntu... > war auf der "http://ipw2200.sourceforge.net/"; - Seite, konnte aber keine > verbindung > zum Server bekommen...kann man mir helfen. The driver should be included in your distribution's kernel. It's called "ipw2200" and should have been loaded automatically. You will also need the firmware. Your distribution should have packaged it. In Debian it's in the "firmware-ipw2x00" package. Hope that helps! -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mwifiex: add missing skb_push() in mwifiex_check_uap_capabilties
For PCIe/USB chipsets, preallocated skb buffers are reused for
event handling. mwifiex_check_uap_capabilties() performs
skb_pull(). This patch adds missing skb_push() to restore skb's
data pointer/length.
This bug was introduced by commit debfc6008169 ("mwifiex: update
AP WMM settings from BSS_START event")
Signed-off-by: Amitkumar Karwar
Signed-off-by: Nishant Sarmukadam
---
drivers/net/wireless/mwifiex/uap_event.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/uap_event.c
b/drivers/net/wireless/mwifiex/uap_event.c
index 7bc1f85..4a07476 100644
--- a/drivers/net/wireless/mwifiex/uap_event.c
+++ b/drivers/net/wireless/mwifiex/uap_event.c
@@ -41,6 +41,8 @@ static int mwifiex_check_uap_capabilties(struct
mwifiex_private *priv,
mwifiex_dbg_dump(priv->adapter, EVT_D, "uap capabilties:",
event->data, event->len);
+ skb_push(event, MWIFIEX_BSS_START_EVT_FIX_SIZE);
+
while ((evt_len >= sizeof(tlv_hdr->header))) {
tlv_hdr = (struct mwifiex_ie_types_data *)curr;
tlv_len = le16_to_cpu(tlv_hdr->header.len);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wifi freezing (module mwifiex)
Amitkumar Karwar writes: > Hi Julien, > Thanks for reporting the problem. We now have a separate mechanism for > debug logs and don't support dynamic debugging anymore. > Issue below command to enable logs and share them. > > "echo 0x > /sys/kernel/debug/mwifiex/mlan0/debug_mask" Thanks, I'll give it a try next time I have a similar problem. But I have very good (at least for me) news: > Do you have following USB chipset specific fixes included? > http://www.spinics.net/lists/linux-wireless/msg129129.html This one was already included. > http://www.spinics.net/lists/netdev/msg334367.html This one wasn't. I applied the patch and so far (after several MB downloaded) no freeze. Thanks a lot. I'm surprised that this patch wasn't included in the 4.2.0-rc3. When is it due ? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] wlcore: add antenna diversity reading comments
add comments to the antenna diversity reading Signed-off-by: Guy Mishol --- drivers/net/wireless/ti/wlcore/rx.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/ti/wlcore/rx.c b/drivers/net/wireless/ti/wlcore/rx.c index 7df672a..5b29273 100644 --- a/drivers/net/wireless/ti/wlcore/rx.c +++ b/drivers/net/wireless/ti/wlcore/rx.c @@ -74,6 +74,12 @@ static void wl1271_rx_status(struct wl1271 *wl, if (desc->rate <= wl->hw_min_ht_rate) status->flag |= RX_FLAG_HT; + /* + * Read the signal level and antenna diversity indication. + * The msb in the signal level is always set as it is a + * negative number. + * The antenna indication is the msb of the rssi. + */ status->signal = ((desc->rssi & RSSI_LEVEL_BITMASK) | BIT(7)); status->antenna = ((desc->rssi & ANT_DIVERSITY_BITMASK) >> 7); -- 1.7.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] ath10k: enable raw encap mode and software crypto engine.
Hi Kalle. I reviewed the change and it looks good to me. Thanks David On Fri, Jul 24, 2015 at 10:29 AM, Kalle Valo wrote: > Liu CF/TW writes: > >> From: David Liu >> >> This patch enables raw Rx/Tx encap mode to support software based >> crypto engine. This patch introduces a new module param 'cryptmode'. >> >>cryptmode: >> >> 0: Use hardware crypto engine globally with native Wi-Fi mode TX/RX >> encapsulation to the firmware. This is the default mode. >> 1: Use sofware crypto engine globally with raw mode TX/RX >> encapsulation to the firmware. >> >>Known limitation: >> A-MSDU must be disabled for RAW Tx encap mode to perform well when >> heavy traffic is applied. >> >>Testing: (by Michal Kazior ) >> >> a) Performance Testing >> >> cryptmode=1 >>ap=qca988x sta=killer1525 >> killer1525 -> qca988x 194.496 mbps [tcp1 ip4] >> killer1525 -> qca988x 238.309 mbps [tcp5 ip4] >> killer1525 -> qca988x 266.958 mbps [udp1 ip4] >> killer1525 -> qca988x 477.468 mbps [udp5 ip4] >> qca988x -> killer1525 301.378 mbps [tcp1 ip4] >> qca988x -> killer1525 297.949 mbps [tcp5 ip4] >> qca988x -> killer1525 331.351 mbps [udp1 ip4] >> qca988x -> killer1525 371.528 mbps [udp5 ip4] >>ap=killer1525 sta=qca988x >> qca988x -> killer1525 331.447 mbps [tcp1 ip4] >> qca988x -> killer1525 328.783 mbps [tcp5 ip4] >> qca988x -> killer1525 375.309 mbps [udp1 ip4] >> qca988x -> killer1525 403.379 mbps [udp5 ip4] >> killer1525 -> qca988x 203.689 mbps [tcp1 ip4] >> killer1525 -> qca988x 222.339 mbps [tcp5 ip4] >> killer1525 -> qca988x 264.199 mbps [udp1 ip4] >> killer1525 -> qca988x 479.371 mbps [udp5 ip4] >> >> Note: >>- only open network tested for RAW vs nwifi performance comparison >>- killer1525 (qca6174 hw2.2) is 2x2 device (hence max 866mbps) >>- used iperf >>- OTA, devices a few cm apart from each other, no shielding >>- tcpX/udpX, X - means number of threads used >> >> Overview: >>- relative Tx performance drop is seen but is within reasonable and >> expected threshold (A-MSDU must be disabled with RAW Tx) >> >> b) Connectivity Testing >> >> cryptmode=1 >>ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta OK >>ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta OK >>ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta OK >>ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta OK >>ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta OK >>ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta OK >>ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta OK >>ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta OK >>ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br OK >>ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br OK >>ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br OK >>ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br OK >>ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br OK >>ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br OK >>ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br OK >>ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br OK >>ap=iwl6205 sta1=qca988x crypto=open topology-1ap1sta2br1vlan OK >>ap=iwl6205 sta1=qca988x crypto=wep1 topology-1ap1sta2br1vlan OK >>ap=iwl6205 sta1=qca988x crypto=wpa topology-1ap1sta2br1vlan OK >>ap=iwl6205 sta1=qca988x crypto=wpa-ccmp topology-1ap1sta2br1vlan OK >>ap=qca988x sta1=iwl6205 crypto=open topology-1ap1sta2br1vlan OK >>ap=qca988x sta1=iwl6205 crypto=wep1 topology-1ap1sta2br1vlan OK >>ap=qca988x sta1=iwl6205 crypto=wpa topology-1ap1sta2br1vlan OK >>ap=qca988x sta1=iwl6205 crypto=wpa-ccmp topology-1ap1sta2br1vlan OK >> >> Note: >>- each test takes all possible endpoint pairs and pings >>- each pair-ping flushes arp table >>- ip6 is used >> >> c) Testbed Topology: >> >> 1ap1sta: >> [ap] [sta] >> >> endpoints: ap, sta >> >> 1ap1sta2br: >> [veth0] [ap] [sta] [veth2] >>| | | | >> [veth1] | \ [veth3] >> \ /\ / >> [br0][br1] >> >> endpoints: veth0, veth2, br0, br1 >> note: STA works in 4addr mode, AP has wds_sta=1 >> >> 1ap1sta2br1vlan: >> [veth0] [ap]
Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227
Hi, I wonder if this is a mis-merge on my part (I'm the freebsd maintainer.) can you log the noisefloor calibrated values before and after the patch? I'd like to see how low it calibrrates to. -a On 22 July 2015 at 01:42, Martin Blumenstingl wrote: > The FreeBSD driver [0] uses the same 2G values as for the AR9280 chips. > Using the same values in ath9k results in much better throughput for me. > > Before this patch I had a huge amount of packet loss (sometimes up to > 40%) and the max transfer speed was somewhere around 5Mbit/s. With this > patch applied I have zero packet loss and ten times the throughput. > My device uses a AR9227 which is the PCI variant of the AR9287. > > [0] http://bxr.su/FreeBSD/sys/dev/ath/ath_hal/ar9002/ar9287.h > > Signed-off-by: Martin Blumenstingl > --- > Patch has not changed, I am just CC'ing @linux-wireless (instead of > @ath9k-devel only). > > drivers/net/wireless/ath/ath9k/ar9002_phy.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath9k/ar9002_phy.h > b/drivers/net/wireless/ath/ath9k/ar9002_phy.h > index 6314ae2..9d17a53 100644 > --- a/drivers/net/wireless/ath/ath9k/ar9002_phy.h > +++ b/drivers/net/wireless/ath/ath9k/ar9002_phy.h > @@ -610,8 +610,8 @@ > #define AR_PHY_CCA_MIN_GOOD_VAL_9271_2GHZ -127 > #define AR_PHY_CCA_MAX_GOOD_VAL_9271_2GHZ -116 > > -#define AR_PHY_CCA_NOM_VAL_9287_2GHZ -120 > +#define AR_PHY_CCA_NOM_VAL_9287_2GHZ -112 > #define AR_PHY_CCA_MIN_GOOD_VAL_9287_2GHZ-127 > -#define AR_PHY_CCA_MAX_GOOD_VAL_9287_2GHZ-110 > +#define AR_PHY_CCA_MAX_GOOD_VAL_9287_2GHZ-97 > > #endif > -- > 2.4.6 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ath10k: remove NULL ptr deref in variable init of ath10k_monitor_vdev_start
In ath10k_monitor_vdev_start, chandef is initialized to NULL and then
channel is immediately thereafter initialized to chandef->chan (i.e.
NULL->chan). This appears to be some sort of cut-n-paste error, since
the same assignment is done later (i.e. after chandef has been properly
assigned to a non-NULL value). So, let's just remove this "brown paper
bag" typo/thinko... :-)
Coverity CID #1309505
Signed-off-by: John W. Linville
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index c9a7d5b5dffc..2823222dea92 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -836,7 +836,7 @@ static inline int ath10k_vdev_setup_sync(struct ath10k *ar)
static int ath10k_monitor_vdev_start(struct ath10k *ar, int vdev_id)
{
struct cfg80211_chan_def *chandef = NULL;
- struct ieee80211_channel *channel = chandef->chan;
+ struct ieee80211_channel *channel;
struct wmi_vdev_start_request_arg arg = {};
int ret = 0;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
Hello there, I gave 4.2 rc3 a shot and I discovered the wireless was not working anymore with it. I tried adding irq_mode=1 alongside skip_otp=y in ath10k_core (I assume you need fw api 5 to remove this, is that correct?, I still have fw 4 only). Loading with irq_mode=0 [ 21.130224] ath10k_pci :03:00.0: enabling device ( -> 0002) [ 21.130734] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 irq_mode 0 reset_mode 0 [ 21.277023] ath10k_pci :03:00.0: Direct firmware load for ath10k/cal-pci-:03:00.0.bin failed with error -2 [ 21.278105] ath10k_pci :03:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 [ 21.278109] ath10k_pci :03:00.0: failed to load spec board file, falling back to generic: -2 [ 21.279048] ath10k_pci :03:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 [ 21.279051] ath10k_pci :03:00.0: could not fetch firmware file 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2 [ 22.445285] ath10k_pci :03:00.0: received unsolicited fw crash interrupt [ 22.445319] ath10k_pci :03:00.0: received unsolicited fw crash interrupt [ 23.445028] ath10k_pci :03:00.0: failed to receive control response completion, polling.. [ 23.445183] ath10k_pci :03:00.0: received unsolicited fw crash interrupt [ 23.445247] ath10k_pci :03:00.0: received unsolicited fw crash interrupt [ 24.445040] ath10k_pci :03:00.0: Service connect timeout [ 24.445043] ath10k_pci :03:00.0: failed to connect htt (-110) [ 24.508619] ath10k_pci :03:00.0: could not init core (-110) [ 24.508640] ath10k_pci :03:00.0: could not probe fw (-110) [ 74.965904] ath10k_pci :03:00.0: received unsolicited fw crash interrupt With irq_mode=1 (and debug_mask=0x0432 for ath10k_core... didn't do.. anything?) [ 612.043708] ath10k_pci :03:00.0: limiting irq mode to: 1 [ 612.043711] ath10k_pci :03:00.0: pci irq legacy interrupts 0 irq_mode 1 reset_mode 0 [ 612.249048] ath10k_pci :03:00.0: Direct firmware load for ath10k/cal-pci-:03:00.0.bin failed with error -2 [ 612.249148] ath10k_pci :03:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/board-pci-168c:003e:1a56:1525.bin failed with error -2 [ 612.249150] ath10k_pci :03:00.0: failed to load spec board file, falling back to generic: -2 [ 612.249251] ath10k_pci :03:00.0: Direct firmware load for ath10k/QCA6174/hw2.1/firmware-5.bin failed with error -2 [ 612.249252] ath10k_pci :03:00.0: could not fetch firmware file 'ath10k/QCA6174/hw2.1/firmware-5.bin': -2 [ 613.435568] ath10k_pci :03:00.0: qca6174 hw2.1 (0x0501, 0x003405ff, 168c:003e:1a56:1525 fallback) fw killer-n1525-fw api 4 htt 3.0 wmi 4 cal otp max_sta 32 [ 613.435571] ath10k_pci :03:00.0: debug 0 debugfs 1 tracing 0 dfs 0 testmode 0 [ 613.509157] ath: EEPROM regdomain: 0x6c [ 613.509160] ath: EEPROM indicates we should expect a direct regpair map [ 613.509162] ath: Country alpha2 being used: 00 [ 613.509163] ath: Regpair used: 0x6c [ 613.513311] ath10k_pci :03:00.0 wlp3s0: renamed from wlan0 This is a Dell Alienware 15 (early 2015) laptop. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227
Hi Adrian, On Mon, Jul 27, 2015 at 9:13 PM, Adrian Chadd wrote: > I wonder if this is a mis-merge on my part (I'm the freebsd maintainer.) > > can you log the noisefloor calibrated values before and after the > patch? I'd like to see how low it calibrrates to. Sure, I hope dump_nfcal provides all values you need. result with my patch applied (HT20): # cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal Channel Noise Floor : -95 Chain | privNF | # Readings | NF Readings 0 -1065 -110 -105 -109 -106 -106 1 -97 5 -97 -97 -97 -97 -97 Result before my patch (HT20): # cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal Channel Noise Floor : -91 Chain | privNF | # Readings | NF Readings 0 -120 0 1 -120 0 Result before my patch (HT40): # cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal Channel Noise Floor : -91 Chain | privNF | # Readings | NF Readings 0 -110 5 -110 -110 -110 -110 -110 1 -110 5 -110 -110 -110 -110 -110 3 -110 5 -110 -110 -110 -110 -110 4 -110 5 -110 -110 -110 -110 -110 Let me know if this helps you or if you need more information. Regards, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227
is it never getting any readings before your patch? NF Readings all look empty... -adrian On 27 July 2015 at 15:30, Martin Blumenstingl wrote: > Hi Adrian, > > On Mon, Jul 27, 2015 at 9:13 PM, Adrian Chadd wrote: >> I wonder if this is a mis-merge on my part (I'm the freebsd maintainer.) >> >> can you log the noisefloor calibrated values before and after the >> patch? I'd like to see how low it calibrrates to. > Sure, I hope dump_nfcal provides all values you need. > > result with my patch applied (HT20): > # cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal > Channel Noise Floor : -95 > Chain | privNF | # Readings | NF Readings > 0 -1065 -110 -105 -109 -106 -106 > 1 -97 5 -97 -97 -97 -97 -97 > > Result before my patch (HT20): > # cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal > Channel Noise Floor : -91 > Chain | privNF | # Readings | NF Readings > 0 -120 0 > 1 -120 0 > > Result before my patch (HT40): > # cat /sys/kernel/debug/ieee80211/phy1/ath9k/dump_nfcal > Channel Noise Floor : -91 > Chain | privNF | # Readings | NF Readings > 0 -110 5 -110 -110 -110 -110 -110 > 1 -110 5 -110 -110 -110 -110 -110 > 3 -110 5 -110 -110 -110 -110 -110 > 4 -110 5 -110 -110 -110 -110 -110 > > > Let me know if this helps you or if you need more information. > > > Regards, > Martin -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227
On Tue, Jul 28, 2015 at 1:50 AM, Adrian Chadd wrote: > is it never getting any readings before your patch? NF Readings all > look empty... Yes, looks like it. Unfortunately I haven't saved a complete kernel log (with ath9k debug level = 0x4449) but only a few parts. Here are the interesting bits: <7>[ 449.746679] ath: phy1: NF calibrated [ctl] [chain 0] is -106 <7>[ 449.746697] ath: phy1: NF[0] (-106) > MAX (-110), correcting to MAX <7>[ 449.746714] ath: phy1: NF calibrated [ctl] [chain 1] is -90 <7>[ 449.746731] ath: phy1: NF[1] (-90) > MAX (-110), correcting to MAX <7>[ 449.746748] ath: phy1: NF calibrated [ext] [chain 0] is -103 <7>[ 449.746765] ath: phy1: NF[3] (-103) > MAX (-110), correcting to MAX <7>[ 449.746781] ath: phy1: NF calibrated [ext] [chain 1] is -86 <7>[ 449.746798] ath: phy1: NF[4] (-86) > MAX (-110), correcting to MAX <7>[ 449.746878] ath: phy1: Calibration @37407 finished: long ani, caldone: true I'd assume (because I don't know the ath9k code) that ath9k simply ignores NF readings that are "out of range" (as suggested by those messages). Regards, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ath9k: Fix NF CCA limits for AR9287 and AR9227
Those are some high values (eg from noise/spur somewhere) and the driver is deciding to program in -110. So the radio thinks its deaf. Hm, I think that explains a few other NICs behaving badly too -a On 27 July 2015 at 16:55, Martin Blumenstingl wrote: > On Tue, Jul 28, 2015 at 1:50 AM, Adrian Chadd wrote: >> is it never getting any readings before your patch? NF Readings all >> look empty... > Yes, looks like it. Unfortunately I haven't saved a complete kernel > log (with ath9k debug level = 0x4449) but only a few parts. Here > are the interesting bits: > <7>[ 449.746679] ath: phy1: NF calibrated [ctl] [chain 0] is -106 > <7>[ 449.746697] ath: phy1: NF[0] (-106) > MAX (-110), correcting to MAX > <7>[ 449.746714] ath: phy1: NF calibrated [ctl] [chain 1] is -90 > <7>[ 449.746731] ath: phy1: NF[1] (-90) > MAX (-110), correcting to MAX > <7>[ 449.746748] ath: phy1: NF calibrated [ext] [chain 0] is -103 > <7>[ 449.746765] ath: phy1: NF[3] (-103) > MAX (-110), correcting to MAX > <7>[ 449.746781] ath: phy1: NF calibrated [ext] [chain 1] is -86 > <7>[ 449.746798] ath: phy1: NF[4] (-86) > MAX (-110), correcting to MAX > <7>[ 449.746878] ath: phy1: Calibration @37407 finished: long ani, caldone: > true > > I'd assume (because I don't know the ath9k code) that ath9k simply > ignores NF readings that are "out of range" (as suggested by those > messages). > > > Regards, > Martin -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: QCA6174 hw2.1 irq_mode=0 broken on 4.2-rc3, working on 4.1.2
On 27 July 2015 at 22:08, Enrico Tagliavini wrote: > Hello there, > > I gave 4.2 rc3 a shot and I discovered the wireless was not working > anymore with it. I tried adding irq_mode=1 alongside skip_otp=y in > ath10k_core (I assume you need fw api 5 to remove this, is that > correct?, I still have fw 4 only). > > Loading with irq_mode=0 > > [ 21.130224] ath10k_pci :03:00.0: enabling device ( -> 0002) > [ 21.130734] ath10k_pci :03:00.0: pci irq msi-x interrupts 8 > irq_mode 0 reset_mode 0 There was already a similar report[1]. Just for the record: what number of interrupts did you have before 4.2-rc3? I assume it was "pci irq msi interrupts 1 irq_mode 0 reset_mode 0". My suspicion is that either the firmware is buggy and doesn't play well with multiple MSI interrupts or the MSI interrupt behaviour changed significantly (compared to qca988x) and this remained hidden because not an awful lot of machines seemed to have provided more than 1 msi interrupt for ath10k. [1]: http://lists.infradead.org/pipermail/ath10k/2015-July/005695.html Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: remove NULL ptr deref in variable init of ath10k_monitor_vdev_start
On Tuesday 28 July 2015 12:52 AM, John W. Linville wrote:
In ath10k_monitor_vdev_start, chandef is initialized to NULL and then
channel is immediately thereafter initialized to chandef->chan (i.e.
NULL->chan). This appears to be some sort of cut-n-paste error, since
the same assignment is done later (i.e. after chandef has been properly
assigned to a non-NULL value). So, let's just remove this "brown paper
bag" typo/thinko... :-)
Coverity CID #1309505
Signed-off-by: John W. Linville
---
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index c9a7d5b5dffc..2823222dea92 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -836,7 +836,7 @@ static inline int ath10k_vdev_setup_sync(struct ath10k *ar)
static int ath10k_monitor_vdev_start(struct ath10k *ar, int vdev_id)
{
struct cfg80211_chan_def *chandef = NULL;
- struct ieee80211_channel *channel = chandef->chan;
+ struct ieee80211_channel *channel;
struct wmi_vdev_start_request_arg arg = {};
int ret = 0;
There is a similar change integrated recently,
https://github.com/kvalo/ath/commit/19be9e9a7ac7e6050eab426283d2a87593cf6e82 .
Vasanth
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: linux-4.2-rc4/drivers/staging/wilc1000/linux_mon.c:264: memory leak ?
Hi David.
Sorry, I did not think about that.
This is a very good point and suggestion.
I will check and fix source code.
Thank you for your advice.
BR.
Chris.
-Original Message-
From: David Binderman [mailto:dcb...@hotmail.com]
Sent: Monday, July 27, 2015 7:01 PM
To: Park, Chris; Kim, Johnny; Kim, Rachel; Lee, Dean;
linux-wireless@vger.kernel.org
Subject: RE: linux-4.2-rc4/drivers/staging/wilc1000/linux_mon.c:264: memory
leak ?
Hello there,
> but It is not memory leak because If tx queue is complete, kfree() is
> called in mgmt_tx_complete() funtion.
Maybe I've been slightly less than clear. I'll have another go.
There is a call to kmalloc around line 250.
Source code is
mgmt_tx = kmalloc(sizeof(struct tx_complete_mon_data), GFP_ATOMIC);
A few lines later is a second call to kmalloc
mgmt_tx->buff = kmalloc(len, GFP_ATOMIC);
If the second call fails, then proper tidyup would normally include calling
kfree for the first call. This doesn't happen in the error handling code for
the second call.
if (mgmt_tx->buff == NULL) {
PRINT_ER("Failed to allocate memory for mgmt_tx buff\n");
return WILC_FAIL;
}
Not a big bug, I admit, but might be worth fixing.
Something like
if (mgmt_tx->buff == NULL) {
kfree(mgmt);
PRINT_ER("Failed to allocate memory for mgmt_tx buff\n");
return WILC_FAIL;
}
would probably fix it.
My apologies for not being clear earlier.
Regards
David Binderman
>
> Source code is
>
> g_linux_wlan->oup.wlan_add_mgmt_to_tx_que(mgmt_tx, mgmt_tx->buff,
> mgmt_tx->size, mgmt_tx_complete);
>
> static void mgmt_tx_complete(void *priv, int status)
> {
> ...
> kfree(pv_data->buff);
> kfree(pv_data);
> }
>
> BR.
> Chris
>
> On 2015년 07월 27일 17:20, David Binderman wrote:
>
> Hello there,
>
> [linux-4.2-rc4/drivers/staging/wilc1000/linux_mon.c:264]: (error)
> Memory leak: mgmt_tx
>
> Source code is
>
> mgmt_tx->buff = kmalloc(len, GFP_ATOMIC);
> if (mgmt_tx->buff == NULL) {
> PRINT_ER("Failed to allocate memory for mgmt_tx buff\n");
> return WILC_FAIL;
>
> }
>
> Suggest add missing call to kfree.
>
>
> Regards
>
> David Binderman
>
>
>
[PATCH v2] rsi: Fix failure to load firmware after memory leak fix and fix the leak
Fixes commit eae79b4f3e82 ("rsi: fix memory leak in rsi_load_ta_instructions()")
which stopped the driver from functioning.
Firmware data has been allocated using vmalloc(), resulting in memory
that cannot be used for DMA. Hence the firmware was first copied to a
buffer allocated with kmalloc() in the original code. This patch reverts
the commit and only calls "kfree()" to release the buffer after sending
the data. This fixes the memory leak without breaking the driver.
Add a comment to the kmemdup() calls to explain why this is done, and abort
if memory allocation fails.
Tested on a Topic Miami-Florida board which contains the rsi SDIO chip.
Also added the same kfree() call to the USB glue driver. This was not
tested on actual hardware though, as I only have the SDIO version.
Fixes: eae79b4f3e82 ("rsi: fix memory leak in rsi_load_ta_instructions()")
Signed-off-by: Mike Looijmans
Cc: sta...@vger.kernel.org
---
v2: Add "Fixes:" header and abbreviate git hashes.
Return -ENOMEM if kmemdup() fails.
drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 8 +++-
drivers/net/wireless/rsi/rsi_91x_usb_ops.c | 4
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
index b6cc9ff..1c6788a 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c
@@ -172,6 +172,7 @@ static int rsi_load_ta_instructions(struct rsi_common
*common)
(struct rsi_91x_sdiodev *)adapter->rsi_dev;
u32 len;
u32 num_blocks;
+ const u8 *fw;
const struct firmware *fw_entry = NULL;
u32 block_size = dev->tx_blk_size;
int status = 0;
@@ -200,6 +201,10 @@ static int rsi_load_ta_instructions(struct rsi_common
*common)
return status;
}
+ /* Copy firmware into DMA-accessible memory */
+ fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
+ if (!fw)
+ return -ENOMEM;
len = fw_entry->size;
if (len % 4)
@@ -210,7 +215,8 @@ static int rsi_load_ta_instructions(struct rsi_common
*common)
rsi_dbg(INIT_ZONE, "%s: Instruction size:%d\n", __func__, len);
rsi_dbg(INIT_ZONE, "%s: num blocks: %d\n", __func__, num_blocks);
- status = rsi_copy_to_card(common, fw_entry->data, len, num_blocks);
+ status = rsi_copy_to_card(common, fw, len, num_blocks);
+ kfree(fw);
release_firmware(fw_entry);
return status;
}
diff --git a/drivers/net/wireless/rsi/rsi_91x_usb_ops.c
b/drivers/net/wireless/rsi/rsi_91x_usb_ops.c
index 1106ce7..30c2cf7 100644
--- a/drivers/net/wireless/rsi/rsi_91x_usb_ops.c
+++ b/drivers/net/wireless/rsi/rsi_91x_usb_ops.c
@@ -146,7 +146,10 @@ static int rsi_load_ta_instructions(struct rsi_common
*common)
return status;
}
+ /* Copy firmware into DMA-accessible memory */
fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
+ if (!fw)
+ return -ENOMEM;
len = fw_entry->size;
if (len % 4)
@@ -158,6 +161,7 @@ static int rsi_load_ta_instructions(struct rsi_common
*common)
rsi_dbg(INIT_ZONE, "%s: num blocks: %d\n", __func__, num_blocks);
status = rsi_copy_to_card(common, fw, len, num_blocks);
+ kfree(fw);
release_firmware(fw_entry);
return status;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rsi: Fix failure to load firmware after memory leak fix and fix the leak
On 27-07-15 12:28, Kalle Valo wrote:
Mike Looijmans writes:
Fixes commit eae79b4f3e82ca63a53478a161b190a0d38fe526 ("rsi: fix memory leak
in rsi_load_ta_instructions()") which stopped the driver from functioning.
You can abbreviate the commit id:
Fixes commit eae79b4f3e82 ("rsi: fix memory leak in
rsi_load_ta_instructions()") which stopped the driver from functioning.
Firmware data has been allocated using vmalloc(), resulting in memory
that cannot be used for DMA. Hence the firmware was first copied to a
buffer allocated with kmalloc() in the original code. This patch reverts
the commit and only calls "kfree()" to release the buffer after sending
the data. This fixes the memory leak without breaking the driver.
Add a comment to the kmemdup() calls to explain why this is done.
Tested on a Topic Miami-Florida board which contains the rsi SDIO chip.
Also added the same kfree() call to the USB glue driver. This was not
tested on actual hardware though, as I only have the SDIO version.
Signed-off-by: Mike Looijmans
Add this before Signed-off-by line:
Fixes: eae79b4f3e82 ("rsi: fix memory leak in rsi_load_ta_instructions()")
Cc: sta...@vger.kernel.org
Also no need to send email to sta...@vger.kernel.org list, this line is
enough and the stable team will pick the commit automatically.
I wondered why that happened, and just noticed that git send-email
automatically added this to the recipients. So it happened for v2 as well,
sorry for that.
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
