Re: Stable request 9374e7d2 rtlwifi: rtl8192cu: Add new device ID
On Tuesday, April 28, 2015 at 03:56:04 PM, Anders Larsen wrote: Hi, commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 Author: Marek Vasut ma...@denx.de Date: 2015-03-26 02:16:06 +0100 rtlwifi: rtl8192cu: Add new device ID Add new ID for ASUS N10 WiFi dongle. in Linus' tree has been tested on 3.16.7 and 3.10.5x and applies cleanly all the way back to 3.2.68 Please consider this patch for the stable trees. Hi, did you check [1] please? I might be wrong, but these are the official -stable submission guidelines to my knowledge. [1] https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt Best regards, Marek Vasut -- 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: Stable request 9374e7d2 rtlwifi: rtl8192cu: Add new device ID
On 2015-04-28 16:10, Marek Vasut wrote: did you check [1] please? I might be wrong, but these are the official -stable submission guidelines to my knowledge. [1] https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt sure I did - networking has its own stable submission guidelines in Documentation/networking/netdev-FAQ.txt Cheers Anders-- 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 1/1] New driver: rtl8723au (mac80211)
Kalle Valo kv...@codeaurora.org writes: jes.soren...@redhat.com writes: From: Jes Sorensen jes.soren...@redhat.com This is an alternate driver for the Realtek 8723AU (rtl8723au) written from scratch utilizing the mac80211 stack. After spending months cleaning up the vendor provided rtl8723au driver, which comes with it's own 802.11 stack included, I decided to rewrite this driver from the bottom up. Where is the vendor driver available, in staging or somewhere else? It would be good to mention that in the commit log. Hi Kalle, Thanks for the feedback, the vendor driver is drivers/staging/rtl8723au/ Many thanks to Johannes Berg for 802.11 insights and help and Larry Finger for help with the vendor driver. The full git log for the development of this driver can be found here: git git://git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git branch rtl8723au-mac80211 This driver is still experimental, but has proven to be rather stable for me. It lacks some features found in the staging driver, such as power management, AMPDU, and 40MHz channel support. In addition there is no AP and monitor support at this point. It's nice to document in the commit log what features are verified to be working. Also I see incosistencies with driver naming, in some places I see RTL8723au and elsewhere rtl8xxxu. And commit log title could be improved, for example something like rtl8xxxu: new wireless mac80211 driver for rtl8723au chipsets The reason for the inconsistencies is that I anticipate adding support for more chips in the future, so the 8723au named functions are ones that are more likely to be chip specific. And I would like to understand the relationship with rtlwifi, can you describe that a bit more? Why a separate driver instead of extending rtlwifi? When I look at the directory drivers/net/wireless/rtlwifi/rtl8723ae I'm confused what's the bigger plan here. Larry? I looked at rtlwifi and while it has changed a lot from the vendor driver, it still has a strong legacy of the vendor codebase. I could have opted to do a smaller mini-driver for rtlwifi, but I felt it was better to start from scratch and write the driver from the bottom up for Linux. MAINTAINERS |8 + drivers/net/wireless/Kconfig | 19 + drivers/net/wireless/Makefile|2 + drivers/net/wireless/rtl8xxxu.c | 4500 ++ drivers/net/wireless/rtl8xxxu.h | 497 drivers/net/wireless/rtl8xxxu_regs.h | 941 +++ I think someone else already mentioned, but it would be better that has it's own directory. Or should this actually be under rtlwifi directory? I didn't see the need here - it's just 3 files, as long as it doesn't have a huge hierachy of files, a new directory doesn't add much value. If it becomes an issue later, we can move it into a subdirectory. --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8297,6 +8297,14 @@ S:Maintained F: drivers/net/wireless/rtlwifi/ F: drivers/net/wireless/rtlwifi/rtl8192ce/ +RTL8XXXU WIRELESS DRIVER (rtl8xxxu) +M: Jes Sorensen jes.soren...@redhat.com +L: linux-wireless@vger.kernel.org +W: http://intellinuxwireless.org The link cannot be right. That is a mistake for sure, I must have copied an entry as a template and forgotten to remove that one. +T: git git://git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git rtl8723au-mac80211 I doubt that this will be in active enough development that a separate git tree is needed. wireless-drivers trees should be enough and this line can be removed. I would like to keep this line, it points to my development tree, which allows users to go back and look through my full development logs, as well as see ongoing work before it's pushed upstream. I'll do more detailed code review later, but my first impression was that there was a lot of #if 0 code which is frowned upon. Johannes already brought up the #if 0 pieces. I left those in because I am not done with the driver, and this helps me map the flow of the vendor driver codebase. Those #if 0 lines are not there to sit and rot, but to help future development. And I pushed this to wireless-drivers-next.git pending branch so that kbuild will run it's tests with this driver. I saw the kbuild warning, it was a false positive, which I do plan to address down the line. Cheers, Jes -- 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
Stable request 9374e7d2 rtlwifi: rtl8192cu: Add new device ID
Hi, commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 Author: Marek Vasut ma...@denx.de Date: 2015-03-26 02:16:06 +0100 rtlwifi: rtl8192cu: Add new device ID Add new ID for ASUS N10 WiFi dongle. in Linus' tree has been tested on 3.16.7 and 3.10.5x and applies cleanly all the way back to 3.2.68 Please consider this patch for the stable trees. Thanks, Anders -- 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: Stable request 9374e7d2 rtlwifi: rtl8192cu: Add new device ID
On Tuesday, April 28, 2015 at 04:22:34 PM, Anders Larsen wrote: On 2015-04-28 16:10, Marek Vasut wrote: did you check [1] please? I might be wrong, but these are the official -stable submission guidelines to my knowledge. [1] https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt sure I did - networking has its own stable submission guidelines in Documentation/networking/netdev-FAQ.txt I apologize, thank you for pointing this out, I will educate myself. Best regards, Marek Vasut -- 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: NFC: CONFIG_NFC_DEBUG not defined
On Mon, Apr 27, 2015 at 9:03 AM, Valentin Rothberg wrote: Hi Clément, your commit dece45855a8b (NFC: nxp-nci: Add support for NXP NCI chips) adds the Makefile drivers/nfc/nxp-nci/Makefile with the following line: +ccflags-$(CONFIG_NFC_DEBUG) := -DDEBUG The Kconfig option NFC_DEBUG is not defined so the line turns out to be a nop. There is another reference in drivers/nfc/Makefile. Is there a patch queued somewhere to add the option? I found this issue with ./scripts/checkkconfigsymbols.py by diffing v4.0 and v4.1-rc1. Hi Valentin, I only included this line because it was present in the upper-level Makefile drivers/nfc/Makefile . As far as I know, there is no plan to add this option to the configuration. What would the most sensible solution to this issue be ? Add the NFC Debug feature to the configuration ? Remove it altogether ? Regards, -- Clément Perrochaud Eff'Innov Technologies Caen, Aix-En-Provence, Grenoble Eff'Innov Technologies Campus EffiScience 2, Esplanade Anton Philips 14460 Colombelles, FRANCE http://www.effinnov.com -- 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: [for,4.1] rtlwifi: rtl8192cu: Fix kernel deadlock
The USB mini-driver in rtlwifi, which is used by rtl8192cu, issues a call to usb_control_msg() with a timeout value of 0. In some instances where the interface is shutting down, this infinite wait results in a CPU deadlock. A one second timeout fixes this problem without affecting any normal operations. This bug is reported at https://bugzilla.novell.com/show_bug.cgi?id=927786. Reported-by: Bernhard Wiedemann bwiedem...@suse.com Tested-by: Bernhard Wiedemann bwiedem...@suse.com Signed-off-by: Larry Finger larry.fin...@lwfinger.net Cc: Stable sta...@vger.kernel.org Cc: Bernhard Wiedemann bwiedem...@suse.com Cc: Takashi Iwaiti...@suse.com Thanks, applied to wireless-drivers.git. 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] rtlwifi: rtl8192cu: Fix some beacon issue
On 04/28/2015 11:40 AM, Taehee Yoo wrote: 2015-04-29 1:21 GMT+09:00 Kalle Valo kv...@codeaurora.org: Taehee Yoo ap420...@gmail.com writes: Sometimes rtl8192cu is not sending beacon frame. This patch fix this issue. Signed-off-by: Taehee Yoo ap420...@gmail.com Larry, what do you think? Should I apply this? https://patchwork.kernel.org/patch/5856761/ -- Kalle Valo i think that it is incomplete patch. because it can not solve Mike's problem. Apologize about incomplete patch. Kalle, I have not been able to reproduce the problem, thus I could not comment as to whether the patch actually fixed anything. Clearly, the patch should be dropped. Thanks, Larry -- 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 1/1] New driver: rtl8723au (mac80211)
Kalle Valo kv...@codeaurora.org writes: And I pushed this to wireless-drivers-next.git pending branch so that kbuild will run it's tests with this driver. There was one warning from kbuild, but I didn't check if it's just a false warning or what: drivers/net/wireless/rtl8xxxu.c: In function 'rtl8723a_phy_lc_calibrate': drivers/net/wireless/rtl8xxxu.c:2457: warning: 'rf_amode' may be used uninitialized in this function -- 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
[PATCH 1/8] iwlwifi: mvm: fix Tx Power firmware API
From: Avri Altman avri.alt...@intel.com
The firmware doesn't relate the scan to a vif. The scan is
run by a separate entity called auxiliary MAC (aka AUX MAC).
This AUX MAC needs to get Tx power limitations that are
not applied on a specific vif, but on the device as a whole.
This can be implemented by using the minimum of all the
values set by the user for all the MACs. But then we need
to ignore the limitations that come from the AP or
regulatory for a specific vif: a specific vif might have
regulatory limitations because of the channel is works on.
This limit is irrelevant for the AUX MAC.
Use the new API from mac80211: the user_power_level in
bss_conf to achieve this.
Firmware -13.ucode has already moved to this API.
Change-Id: Ifba83660f378e91b93bd46d29fe8ba35a7c168a4
Signed-off-by: Avri Altman avri.alt...@intel.com
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
---
drivers/net/wireless/iwlwifi/iwl-fw-file.h | 2 ++
drivers/net/wireless/iwlwifi/mvm/fw-api-power.h | 34 +
drivers/net/wireless/iwlwifi/mvm/fw-api.h | 13 --
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 24 +++--
4 files changed, 58 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-fw-file.h
b/drivers/net/wireless/iwlwifi/iwl-fw-file.h
index bfdf3fa..62db2e5 100644
--- a/drivers/net/wireless/iwlwifi/iwl-fw-file.h
+++ b/drivers/net/wireless/iwlwifi/iwl-fw-file.h
@@ -244,6 +244,7 @@ enum iwl_ucode_tlv_flag {
* longer than the passive one, which is essential for fragmented scan.
* @IWL_UCODE_TLV_API_WIFI_MCC_UPDATE: ucode supports MCC updates with source.
* IWL_UCODE_TLV_API_HDC_PHASE_0: ucode supports finer configuration of LTR
+ * @IWL_UCODE_TLV_API_TX_POWER_DEV: new API for tx power.
* @IWL_UCODE_TLV_API_BASIC_DWELL: use only basic dwell time in scan command,
* regardless of the band or the number of the probes. FW will calculate
* the actual dwell time.
@@ -260,6 +261,7 @@ enum iwl_ucode_tlv_api {
IWL_UCODE_TLV_API_FRAGMENTED_SCAN = BIT(8),
IWL_UCODE_TLV_API_WIFI_MCC_UPDATE = BIT(9),
IWL_UCODE_TLV_API_HDC_PHASE_0 = BIT(10),
+ IWL_UCODE_TLV_API_TX_POWER_DEV = BIT(11),
IWL_UCODE_TLV_API_BASIC_DWELL = BIT(13),
IWL_UCODE_TLV_API_SCD_CFG = BIT(15),
IWL_UCODE_TLV_API_SINGLE_SCAN_EBS = BIT(16),
diff --git a/drivers/net/wireless/iwlwifi/mvm/fw-api-power.h
b/drivers/net/wireless/iwlwifi/mvm/fw-api-power.h
index 4fc0938b..b1baa33 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw-api-power.h
+++ b/drivers/net/wireless/iwlwifi/mvm/fw-api-power.h
@@ -298,6 +298,40 @@ struct iwl_uapsd_misbehaving_ap_notif {
} __packed;
/**
+ * struct iwl_reduce_tx_power_cmd - TX power reduction command
+ * REDUCE_TX_POWER_CMD = 0x9f
+ * @flags: (reserved for future implementation)
+ * @mac_context_id: id of the mac ctx for which we are reducing TX power.
+ * @pwr_restriction: TX power restriction in dBms.
+ */
+struct iwl_reduce_tx_power_cmd {
+ u8 flags;
+ u8 mac_context_id;
+ __le16 pwr_restriction;
+} __packed; /* TX_REDUCED_POWER_API_S_VER_1 */
+
+/**
+ * struct iwl_dev_tx_power_cmd - TX power reduction command
+ * REDUCE_TX_POWER_CMD = 0x9f
+ * @set_mode: 0 - MAC tx power, 1 - device tx power
+ * @mac_context_id: id of the mac ctx for which we are reducing TX power.
+ * @pwr_restriction: TX power restriction in 1/8 dBms.
+ * @dev_24: device TX power restriction in 1/8 dBms
+ * @dev_52_low: device TX power restriction upper band - low
+ * @dev_52_high: device TX power restriction upper band - high
+ */
+struct iwl_dev_tx_power_cmd {
+ __le32 set_mode;
+ __le32 mac_context_id;
+ __le16 pwr_restriction;
+ __le16 dev_24;
+ __le16 dev_52_low;
+ __le16 dev_52_high;
+} __packed; /* TX_REDUCED_POWER_API_S_VER_2 */
+
+#define IWL_DEV_MAX_TX_POWER 0x7FFF
+
+/**
* struct iwl_beacon_filter_cmd
* REPLY_BEACON_FILTERING_CMD = 0xd2 (command)
* @id_and_color: MAC contex identifier
diff --git a/drivers/net/wireless/iwlwifi/mvm/fw-api.h
b/drivers/net/wireless/iwlwifi/mvm/fw-api.h
index aab68cb..01b1da6 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw-api.h
+++ b/drivers/net/wireless/iwlwifi/mvm/fw-api.h
@@ -281,19 +281,6 @@ struct iwl_tx_ant_cfg_cmd {
__le32 valid;
} __packed;
-/**
- * struct iwl_reduce_tx_power_cmd - TX power reduction command
- * REDUCE_TX_POWER_CMD = 0x9f
- * @flags: (reserved for future implementation)
- * @mac_context_id: id of the mac ctx for which we are reducing TX power.
- * @pwr_restriction: TX power restriction in dBms.
- */
-struct iwl_reduce_tx_power_cmd {
- u8 flags;
- u8 mac_context_id;
- __le16 pwr_restriction;
-} __packed; /* TX_REDUCED_POWER_API_S_VER_1 */
-
/*
* Calibration control struct.
* Sent as part of the phy configuration command.
diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c
[PATCH 5/8] iwlwifi: pcie: prevent using unmapped memory in fw monitor
From: Liad Kaufman liad.kauf...@intel.com
In the case of a DMA mapping error on the last iteration of
the loop of the allocation of memory of the FW monitor we
indeed free the pages, but don't NULL out the page variable
thus allowing for the possibility of setting the FW monitor
variables with invalid data to use.
Fixes: c2d202017da1 (iwlwifi: pcie: add firmware monitor capabilities)
Signed-off-by: Liad Kaufman liad.kauf...@intel.com
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
---
drivers/net/wireless/iwlwifi/pcie/trans.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/pcie/trans.c
b/drivers/net/wireless/iwlwifi/pcie/trans.c
index 2de8fbf..6debb0c 100644
--- a/drivers/net/wireless/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/iwlwifi/pcie/trans.c
@@ -5,8 +5,8 @@
*
* GPL LICENSE SUMMARY
*
- * Copyright(c) 2007 - 2014 Intel Corporation. All rights reserved.
- * Copyright(c) 2013 - 2014 Intel Mobile Communications GmbH
+ * Copyright(c) 2007 - 2015 Intel Corporation. All rights reserved.
+ * Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
@@ -31,8 +31,8 @@
*
* BSD LICENSE
*
- * Copyright(c) 2005 - 2014 Intel Corporation. All rights reserved.
- * Copyright(c) 2013 - 2014 Intel Mobile Communications GmbH
+ * Copyright(c) 2005 - 2015 Intel Corporation. All rights reserved.
+ * Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -104,7 +104,7 @@ static void iwl_pcie_free_fw_monitor(struct iwl_trans
*trans)
static void iwl_pcie_alloc_fw_monitor(struct iwl_trans *trans)
{
struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
- struct page *page;
+ struct page *page = NULL;
dma_addr_t phys;
u32 size;
u8 power;
@@ -131,6 +131,7 @@ static void iwl_pcie_alloc_fw_monitor(struct iwl_trans
*trans)
DMA_FROM_DEVICE);
if (dma_mapping_error(trans-dev, phys)) {
__free_pages(page, order);
+ page = NULL;
continue;
}
IWL_INFO(trans,
--
2.1.0
--
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 2/8] iwlwifi: mvm: don't stop the FW monitor too early
When the delay paramatere is provided, we need to stop
the collection only after the delay has elapsed.
Reviewed-by: Johannes Berg johannes.b...@intel.com
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
---
drivers/net/wireless/iwlwifi/mvm/fw.c | 9 -
drivers/net/wireless/iwlwifi/mvm/ops.c | 10 ++
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/fw.c
b/drivers/net/wireless/iwlwifi/mvm/fw.c
index bc5eac4..9c28fe7 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw.c
+++ b/drivers/net/wireless/iwlwifi/mvm/fw.c
@@ -494,15 +494,6 @@ int iwl_mvm_fw_dbg_collect_desc(struct iwl_mvm *mvm,
mvm-fw_dump_desc = desc;
- /* stop recording */
- if (mvm-cfg-device_family == IWL_DEVICE_FAMILY_7000) {
- iwl_set_bits_prph(mvm-trans, MON_BUFF_SAMPLE_CTL, 0x100);
- } else {
- iwl_write_prph(mvm-trans, DBGC_IN_SAMPLE, 0);
- /* wait before we collect the data till the DBGC stop */
- udelay(100);
- }
-
queue_delayed_work(system_wq, mvm-fw_dump_wk, delay);
return 0;
diff --git a/drivers/net/wireless/iwlwifi/mvm/ops.c
b/drivers/net/wireless/iwlwifi/mvm/ops.c
index a08b03d..1c66297 100644
--- a/drivers/net/wireless/iwlwifi/mvm/ops.c
+++ b/drivers/net/wireless/iwlwifi/mvm/ops.c
@@ -865,6 +865,16 @@ static void iwl_mvm_fw_error_dump_wk(struct work_struct
*work)
return;
mutex_lock(mvm-mutex);
+
+ /* stop recording */
+ if (mvm-cfg-device_family == IWL_DEVICE_FAMILY_7000) {
+ iwl_set_bits_prph(mvm-trans, MON_BUFF_SAMPLE_CTL, 0x100);
+ } else {
+ iwl_write_prph(mvm-trans, DBGC_IN_SAMPLE, 0);
+ /* wait before we collect the data till the DBGC stop */
+ udelay(100);
+ }
+
iwl_mvm_fw_error_dump(mvm);
/* start recording again if the firmware is not crashed */
--
2.1.0
--
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 6/8] iwlwifi: mvm: don't power off the device between INIT and OPER firmwares
From: Eran Harary eran.har...@intel.com
Our device needs two different firmwares: the INIT firmware
and the operational (OPER) firmware. The first one is run
when the driver loads and it returns calibrations results
as well as the NVM. The second one implements the WiFi
protocol.
If the wlan interface is not brought up, the device is put
to low power state: no firmware will be running. When the
interface is brought up, we would run the OPER firmware
only and reuse the results of the run of the INIT firmware
when the driver was loaded. This is changing with this
patch.
We now run the INIT firmware every time mac80211 calls
start(). The penalty for that is minimal since the INIT
firwmare run fast. I now also avoid to power down the device
between the INIT and OPER firmware on certains buses.
The motivation for this change is that there are components
on the device (MFUART) that are triggered by the INIT
firmware and need the device to be powered up in order to
keep running. Powering the device down between the INIT and
OPER firmware would stop these components and prevent them
from running again since they are triggered by the INIT
firmware only.
The new flow allows this and also allows to trigger these
components again when the interface is brought up after
it has been brought down.
Signed-off-by: Eran Harary eran.har...@intel.com
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
---
drivers/net/wireless/iwlwifi/iwl-trans.h | 41 ++--
drivers/net/wireless/iwlwifi/mvm/fw.c | 45 +++
drivers/net/wireless/iwlwifi/mvm/mvm.h| 1 -
drivers/net/wireless/iwlwifi/pcie/trans.c | 6 ++---
4 files changed, 51 insertions(+), 42 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-trans.h
b/drivers/net/wireless/iwlwifi/iwl-trans.h
index 6dfed12..56254a8 100644
--- a/drivers/net/wireless/iwlwifi/iwl-trans.h
+++ b/drivers/net/wireless/iwlwifi/iwl-trans.h
@@ -6,7 +6,7 @@
* GPL LICENSE SUMMARY
*
* Copyright(c) 2007 - 2014 Intel Corporation. All rights reserved.
- * Copyright(c) 2013 - 2014 Intel Mobile Communications GmbH
+ * Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of version 2 of the GNU General Public License as
@@ -32,7 +32,7 @@
* BSD LICENSE
*
* Copyright(c) 2005 - 2014 Intel Corporation. All rights reserved.
- * Copyright(c) 2013 - 2014 Intel Mobile Communications GmbH
+ * Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -421,8 +421,9 @@ struct iwl_trans_txq_scd_cfg {
*
* All the handlers MUST be implemented
*
- * @start_hw: starts the HW- from that point on, the HW can send interrupts
- * May sleep
+ * @start_hw: starts the HW. If low_power is true, the NIC needs to be taken
+ * out of a low power state. From that point on, the HW can send
+ * interrupts. May sleep.
* @op_mode_leave: Turn off the HW RF kill indication if on
* May sleep
* @start_fw: allocates and inits all the resources for the transport
@@ -432,10 +433,11 @@ struct iwl_trans_txq_scd_cfg {
* the SCD base address in SRAM, then provide it here, or 0 otherwise.
* May sleep
* @stop_device: stops the whole device (embedded CPU put to reset) and stops
- * the HW. From that point on, the HW will be in low power but will still
- * issue interrupt if the HW RF kill is triggered. This callback must do
- * the right thing and not crash even if start_hw() was called but not
- * start_fw(). May sleep
+ * the HW. If low_power is true, the NIC will be put in low power state.
+ * From that point on, the HW will be stopped but will still issue an
+ * interrupt if the HW RF kill switch is triggered.
+ * This callback must do the right thing and not crash even if %start_hw()
+ * was called but not start_fw(). May sleep.
* @d3_suspend: put the device into the correct mode for WoWLAN during
* suspend. This is optional, if not implemented WoWLAN will not be
* supported. This callback may sleep.
@@ -491,14 +493,14 @@ struct iwl_trans_txq_scd_cfg {
*/
struct iwl_trans_ops {
- int (*start_hw)(struct iwl_trans *iwl_trans);
+ int (*start_hw)(struct iwl_trans *iwl_trans, bool low_power);
void (*op_mode_leave)(struct iwl_trans *iwl_trans);
int (*start_fw)(struct iwl_trans *trans, const struct fw_img *fw,
bool run_in_rfkill);
int (*update_sf)(struct iwl_trans *trans,
struct iwl_sf_region *st_fwrd_space);
void (*fw_alive)(struct iwl_trans *trans, u32 scd_addr);
- void (*stop_device)(struct iwl_trans *trans);
+ void (*stop_device)(struct iwl_trans *trans, bool low_power);
void (*d3_suspend)(struct iwl_trans *trans, bool test);
int
[PATCH 3/8] iwlwifi: mvm: fix scan iteration complete notification handling
From: Avraham Stern avraham.st...@intel.com
Scan iteration complete notification handling uses the wrong FW API
version (version 2 instead of version 3).
Fix that by removing version 2 API which is no longer used, and using
only the updated version.
Signed-off-by: Avraham Stern avraham.st...@intel.com
Reviewed-by: David Spinadel david.spina...@intel.com
Reviewed-by: Johannes Berg johannes.b...@intel.com
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
---
drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h | 44 ++
drivers/net/wireless/iwlwifi/mvm/scan.c| 2 +-
2 files changed, 3 insertions(+), 43 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h
b/drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h
index 4f81dcf..d6cced4 100644
--- a/drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h
+++ b/drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h
@@ -122,46 +122,6 @@ enum iwl_scan_complete_status {
SCAN_COMP_STATUS_ERR_ALLOC_TE = 0x0C,
};
-/**
- * struct iwl_scan_results_notif - scan results for one channel
- * ( SCAN_RESULTS_NOTIFICATION = 0x83 )
- * @channel: which channel the results are from
- * @band: 0 for 5.2 GHz, 1 for 2.4 GHz
- * @probe_status: SCAN_PROBE_STATUS_*, indicates success of probe request
- * @num_probe_not_sent: # of request that weren't sent due to not enough time
- * @duration: duration spent in channel, in usecs
- * @statistics: statistics gathered for this channel
- */
-struct iwl_scan_results_notif {
- u8 channel;
- u8 band;
- u8 probe_status;
- u8 num_probe_not_sent;
- __le32 duration;
- __le32 statistics[SCAN_RESULTS_STATISTICS];
-} __packed; /* SCAN_RESULT_NTF_API_S_VER_2 */
-
-/**
- * struct iwl_scan_complete_notif - notifies end of scanning (all channels)
- * ( SCAN_COMPLETE_NOTIFICATION = 0x84 )
- * @scanned_channels: number of channels scanned (and number of valid results)
- * @status: one of SCAN_COMP_STATUS_*
- * @bt_status: BT on/off status
- * @last_channel: last channel that was scanned
- * @tsf_low: TSF timer (lower half) in usecs
- * @tsf_high: TSF timer (higher half) in usecs
- * @results: array of scan results, only scanned_channels of them are valid
- */
-struct iwl_scan_complete_notif {
- u8 scanned_channels;
- u8 status;
- u8 bt_status;
- u8 last_channel;
- __le32 tsf_low;
- __le32 tsf_high;
- struct iwl_scan_results_notif results[];
-} __packed; /* SCAN_COMPLETE_NTF_API_S_VER_2 */
-
/* scan offload */
#define IWL_SCAN_MAX_BLACKLIST_LEN 64
#define IWL_SCAN_SHORT_BLACKLIST_LEN 16
@@ -554,7 +514,7 @@ struct iwl_scan_req_unified_lmac {
} __packed;
/**
- * struct iwl_lmac_scan_results_notif - scan results for one channel -
+ * struct iwl_scan_results_notif - scan results for one channel -
* SCAN_RESULT_NTF_API_S_VER_3
* @channel: which channel the results are from
* @band: 0 for 5.2 GHz, 1 for 2.4 GHz
@@ -562,7 +522,7 @@ struct iwl_scan_req_unified_lmac {
* @num_probe_not_sent: # of request that weren't sent due to not enough time
* @duration: duration spent in channel, in usecs
*/
-struct iwl_lmac_scan_results_notif {
+struct iwl_scan_results_notif {
u8 channel;
u8 band;
u8 probe_status;
diff --git a/drivers/net/wireless/iwlwifi/mvm/scan.c
b/drivers/net/wireless/iwlwifi/mvm/scan.c
index 74e1c86..1075a21 100644
--- a/drivers/net/wireless/iwlwifi/mvm/scan.c
+++ b/drivers/net/wireless/iwlwifi/mvm/scan.c
@@ -319,7 +319,7 @@ int iwl_mvm_rx_scan_offload_iter_complete_notif(struct
iwl_mvm *mvm,
struct iwl_device_cmd *cmd)
{
struct iwl_rx_packet *pkt = rxb_addr(rxb);
- struct iwl_scan_complete_notif *notif = (void *)pkt-data;
+ struct iwl_lmac_scan_complete_notif *notif = (void *)pkt-data;
IWL_DEBUG_SCAN(mvm,
Scan offload iteration complete: status=0x%x scanned
channels=%d\n,
--
2.1.0
--
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 4/8] iwlwifi: mvm: Avoid signal based decisions if ave beacon RSSI is 0
From: Alexander Bondar alexander.bon...@intel.com
If for some reason statistics notification received from the firmware
reports 0 in average beacon RSSI value, then skip it and avoid signal
based decisions.
Signed-off-by: Alexander Bondar alexander.bon...@intel.com
Reviewed-by: Johannes Berg johannes.b...@intel.com
Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com
---
drivers/net/wireless/iwlwifi/mvm/rx.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/iwlwifi/mvm/rx.c
b/drivers/net/wireless/iwlwifi/mvm/rx.c
index 78ec7db..d6314dd 100644
--- a/drivers/net/wireless/iwlwifi/mvm/rx.c
+++ b/drivers/net/wireless/iwlwifi/mvm/rx.c
@@ -478,6 +478,11 @@ static void iwl_mvm_stat_iterator(void *_data, u8 *mac,
if (vif-type != NL80211_IFTYPE_STATION)
return;
+ if (sig == 0) {
+ IWL_DEBUG_RX(mvm, RSSI is 0 - skip signal based decision\n);
+ return;
+ }
+
mvmvif-bf_data.ave_beacon_signal = sig;
/* BT Coex */
--
2.1.0
--
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 7/8] iwlwifi: mvm: fix typo in CONFIG option
I forgot to rename the CPTCFG_ prefix... Fixes: 484b3d13b4ac (iwlwifi: mvm: add debugfs entry with the number of net-detect scans) Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com --- drivers/net/wireless/iwlwifi/mvm/d3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/iwlwifi/mvm/d3.c b/drivers/net/wireless/iwlwifi/mvm/d3.c index a6c48c7..1b1b2bf 100644 --- a/drivers/net/wireless/iwlwifi/mvm/d3.c +++ b/drivers/net/wireless/iwlwifi/mvm/d3.c @@ -1726,7 +1726,7 @@ iwl_mvm_netdetect_query_results(struct iwl_mvm *mvm, results-matched_profiles = le32_to_cpu(query-matched_profiles); memcpy(results-matches, query-matches, sizeof(results-matches)); -#ifdef CPTCFG_IWLWIFI_DEBUGFS +#ifdef CONFIG_IWLWIFI_DEBUGFS mvm-last_netdetect_scans = le32_to_cpu(query-n_scans_done); #endif -- 2.1.0 -- 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 8/8] iwlwifi: mvm: force quota update update after FW restart
From: Johannes Berg johannes.b...@intel.com During firmware restart, the quota command isn't calculated multiple times, but after the firmware restart it has to be sent, so force it. Otherwise the firmware crashes. Signed-off-by: Johannes Berg johannes.b...@intel.com Signed-off-by: Emmanuel Grumbach emmanuel.grumb...@intel.com --- drivers/net/wireless/iwlwifi/mvm/mac80211.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/iwlwifi/mvm/mac80211.c b/drivers/net/wireless/iwlwifi/mvm/mac80211.c index 7c2d5ac..40265b9 100644 --- a/drivers/net/wireless/iwlwifi/mvm/mac80211.c +++ b/drivers/net/wireless/iwlwifi/mvm/mac80211.c @@ -1322,7 +1322,7 @@ static void iwl_mvm_restart_complete(struct iwl_mvm *mvm) clear_bit(IWL_MVM_STATUS_IN_HW_RESTART, mvm-status); iwl_mvm_d0i3_enable_tx(mvm, NULL); - ret = iwl_mvm_update_quotas(mvm, false, NULL); + ret = iwl_mvm_update_quotas(mvm, true, NULL); if (ret) IWL_ERR(mvm, Failed to update quotas after restart (%d)\n, ret); -- 2.1.0 -- 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
pull request: iwlwifi 2015-04-28
Hi Kalle,
Here is the first round of fixes for 4.1.
As usual, this first round is slightly big. I hope things will settle down
later.
Please pull. Thanks!
The following changes since commit 6c373ca89399c5a3f7ef210ad8f63dc3437da345:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
(2015-04-15 09:00:47 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git
tags/iwlwifi-for-kalle-2015-04-28
for you to fetch changes up to e7afe89fd67d40a7f5fff8130c5f925d99a94b1f:
iwlwifi: mvm: force quota update update after FW restart (2015-04-28 15:02:25
+0300)
* fix firmware API for -13.ucode
* fix RSSI handling that avoid bad roaming decision
* fix firmware debug
* fix MFUART operation
* fix ASSERT while restart the hardware (because of another ASSERT e.g)
Alexander Bondar (1):
iwlwifi: mvm: Avoid signal based decisions if ave beacon RSSI is 0
Avraham Stern (1):
iwlwifi: mvm: fix scan iteration complete notification handling
Avri Altman (1):
iwlwifi: mvm: fix Tx Power firmware API
Emmanuel Grumbach (2):
iwlwifi: mvm: don't stop the FW monitor too early
iwlwifi: mvm: fix typo in CONFIG option
Eran Harary (1):
iwlwifi: mvm: don't power off the device between INIT and OPER firmwares
Johannes Berg (1):
iwlwifi: mvm: force quota update update after FW restart
Liad Kaufman (1):
iwlwifi: pcie: prevent using unmapped memory in fw monitor
drivers/net/wireless/iwlwifi/iwl-fw-file.h | 2 ++
drivers/net/wireless/iwlwifi/iwl-trans.h| 41
+++--
drivers/net/wireless/iwlwifi/mvm/d3.c | 2 +-
drivers/net/wireless/iwlwifi/mvm/fw-api-power.h | 34
++
drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h | 44
++--
drivers/net/wireless/iwlwifi/mvm/fw-api.h | 13 -
drivers/net/wireless/iwlwifi/mvm/fw.c | 54
+-
drivers/net/wireless/iwlwifi/mvm/mac80211.c | 26 +++---
drivers/net/wireless/iwlwifi/mvm/mvm.h | 1 -
drivers/net/wireless/iwlwifi/mvm/ops.c | 10 ++
drivers/net/wireless/iwlwifi/mvm/rx.c | 5 +
drivers/net/wireless/iwlwifi/mvm/scan.c | 2 +-
drivers/net/wireless/iwlwifi/pcie/trans.c | 17 +
13 files changed, 135 insertions(+), 116 deletions(-)
N�r��yb�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH 1/1] New driver: rtl8723au (mac80211)
On 04/28/2015 09:27 AM, Jes Sorensen wrote: Kalle Valo kv...@codeaurora.org writes: jes.soren...@redhat.com writes: From: Jes Sorensen jes.soren...@redhat.com This is an alternate driver for the Realtek 8723AU (rtl8723au) written from scratch utilizing the mac80211 stack. After spending months cleaning up the vendor provided rtl8723au driver, which comes with it's own 802.11 stack included, I decided to rewrite this driver from the bottom up. Where is the vendor driver available, in staging or somewhere else? It would be good to mention that in the commit log. Hi Kalle, Thanks for the feedback, the vendor driver is drivers/staging/rtl8723au/ Many thanks to Johannes Berg for 802.11 insights and help and Larry Finger for help with the vendor driver. The full git log for the development of this driver can be found here: git git://git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git branch rtl8723au-mac80211 This driver is still experimental, but has proven to be rather stable for me. It lacks some features found in the staging driver, such as power management, AMPDU, and 40MHz channel support. In addition there is no AP and monitor support at this point. It's nice to document in the commit log what features are verified to be working. Also I see incosistencies with driver naming, in some places I see RTL8723au and elsewhere rtl8xxxu. And commit log title could be improved, for example something like rtl8xxxu: new wireless mac80211 driver for rtl8723au chipsets The reason for the inconsistencies is that I anticipate adding support for more chips in the future, so the 8723au named functions are ones that are more likely to be chip specific. And I would like to understand the relationship with rtlwifi, can you describe that a bit more? Why a separate driver instead of extending rtlwifi? When I look at the directory drivers/net/wireless/rtlwifi/rtl8723ae I'm confused what's the bigger plan here. Larry? I looked at rtlwifi and while it has changed a lot from the vendor driver, it still has a strong legacy of the vendor codebase. I could have opted to do a smaller mini-driver for rtlwifi, but I felt it was better to start from scratch and write the driver from the bottom up for Linux. MAINTAINERS |8 + drivers/net/wireless/Kconfig | 19 + drivers/net/wireless/Makefile|2 + drivers/net/wireless/rtl8xxxu.c | 4500 ++ drivers/net/wireless/rtl8xxxu.h | 497 drivers/net/wireless/rtl8xxxu_regs.h | 941 +++ I think someone else already mentioned, but it would be better that has it's own directory. Or should this actually be under rtlwifi directory? I didn't see the need here - it's just 3 files, as long as it doesn't have a huge hierachy of files, a new directory doesn't add much value. If it becomes an issue later, we can move it into a subdirectory. --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8297,6 +8297,14 @@ S: Maintained F:drivers/net/wireless/rtlwifi/ F:drivers/net/wireless/rtlwifi/rtl8192ce/ +RTL8XXXU WIRELESS DRIVER (rtl8xxxu) +M: Jes Sorensen jes.soren...@redhat.com +L: linux-wireless@vger.kernel.org +W: http://intellinuxwireless.org The link cannot be right. That is a mistake for sure, I must have copied an entry as a template and forgotten to remove that one. +T: git git://git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git rtl8723au-mac80211 I doubt that this will be in active enough development that a separate git tree is needed. wireless-drivers trees should be enough and this line can be removed. I would like to keep this line, it points to my development tree, which allows users to go back and look through my full development logs, as well as see ongoing work before it's pushed upstream. I'll do more detailed code review later, but my first impression was that there was a lot of #if 0 code which is frowned upon. Johannes already brought up the #if 0 pieces. I left those in because I am not done with the driver, and this helps me map the flow of the vendor driver codebase. Those #if 0 lines are not there to sit and rot, but to help future development. And I pushed this to wireless-drivers-next.git pending branch so that kbuild will run it's tests with this driver. I saw the kbuild warning, it was a false positive, which I do plan to address down the line. Kalle, Jes has covered most of the points very well. I will add just a little explanation from my point of view. There are two major software groups that write the original drivers for the Realtek chips. The PCI group, which is located in China, has worked very hard at their Linux drivers and have written the mac80211 versions found in rtlwifi. I have contributed to cleaning up their code and fixing kernel crashes, but the code is largely theirs. The USB group, which is located in Taiwan, also provide Linux drivers, but their drivers contain their own
Re: Stable request 9374e7d2 rtlwifi: rtl8192cu: Add new device ID
Please note that there are two commits just added to the mainline repo that should be propagated to all stable kernels. Both are addition of new USB IDs for an old driver, thus they will cause to side effects. Unfortunately, the Cc to stable was missed in the first of these, thus the need for this message. The second was Cc for stable, but I include it here for completeness. The two commits in question are commit 9374e7d2fdcad3c36dafc8d3effd554bc702c4b6 Author: Marek Vasut ma...@denx.de Date: Thu Mar 26 02:16:06 2015 +0100 rtlwifi: rtl8192cu: Add new device ID Add new ID for ASUS N10 WiFi dongle. commit 2f92b314f4daff2117847ac5343c54d3d041bf78 Author: Larry Finger larry.fin...@lwfinger.net Date: Mon Mar 23 18:14:10 2015 -0500 rtlwifi: rtl8192cu: Add new USB ID USB ID 2001:330d is used for a D-Link DWA-131. Thanks, Larry -- 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] ath9k: fix per-packet tx power configuration
Lorenzo Bianconi lorenzo.biancon...@gmail.com writes: Do not use ieee80211_vif pointer in ath_get_rate_txpower() since it has been overwritten by setup_frame_info() and it will result in a corrupted tx power configuration. Set per-packet tx power in setup_frame_info() according to current vif tx power. Signed-off-by: Lorenzo Bianconi lorenzo.biancon...@gmail.com I'm planning to send this fix to 4.1, is that ok? -- 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 1/2] mwifiex: sdio: create global list of adapters
Andreas Fenkart afenk...@gmail.com writes:
we need to verify that a an adapter pointer, still points to a
valid adapter. this is not possible through other global structures,
such as net_namespace_list. the problem with the net_namespace_list
is that an adapter can have multiple interfaces, hence we had to
de-reference the maybe invalid pointer to get the interface struct.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/net/wireless/mwifiex/sdio.c | 14 ++
drivers/net/wireless/mwifiex/sdio.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/sdio.c
b/drivers/net/wireless/mwifiex/sdio.c
index 91e36cd..a70e114 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -69,6 +69,12 @@ static struct memory_type_mapping mem_type_mapping_tbl[] =
{
};
/*
+ * list of active cards
+ */
+static LIST_HEAD(cards);
+static DEFINE_MUTEX(cards_mutex);
+
+/*
* SDIO probe.
*
* This function probes an mwifiex device and registers it. It allocates
@@ -130,6 +136,10 @@ mwifiex_sdio_probe(struct sdio_func *func, const struct
sdio_device_id *id)
ret = -1;
}
+ mutex_lock(cards_mutex);
+ list_add(card-next, cards);
+ mutex_unlock(cards_mutex);
+
return ret;
}
@@ -196,6 +206,10 @@ mwifiex_sdio_remove(struct sdio_func *func)
if (!card)
return;
+ mutex_lock(cards_mutex);
+ list_del(card-next);
+ mutex_unlock(cards_mutex);
This is extremely ugly and the commit log doesn't even tell anything
about the issue you trying to fix so it's difficult to even suggest
anything else. For starters can you provide more information, please?
There has to be a better way to solve it.
--
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] rtlwifi: rtl8192cu: Fix some beacon issue
Taehee Yoo ap420...@gmail.com writes: Sometimes rtl8192cu is not sending beacon frame. This patch fix this issue. Signed-off-by: Taehee Yoo ap420...@gmail.com Larry, what do you think? Should I apply this? https://patchwork.kernel.org/patch/5856761/ -- 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] iwl4965: Enable checking of format strings
Rasmus Villemoes li...@rasmusvillemoes.dk writes: Since these fmt_* variables are just const char*, and not const char[], gcc (and smatch) doesn't to type checking of the arguments to the printf functions. Since the linker knows perfectly well to merge identical string constants, there's no point in having three static pointers waste memory and give an extra level of indirection. This removes over 100 non-constant format argument warnings from smatch, accounting for about 20% of all such warnings in an allmodconfig. Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk So what's the conclusion, should I commit this patch or not? Full discussion here: https://patchwork.kernel.org/patch/5814811/ -- 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 07/10] brcmfmac: fix sdio suspend and resume
On 04/28/15 18:14, Kalle Valo wrote:
Ulf Hanssonulf.hans...@linaro.org writes:
On 14 April 2015 at 20:10, Arend van Sprielar...@broadcom.com wrote:
commit 330b4e4be937 (brcmfmac: Add wowl support for SDIO devices.)
changed the behaviour by removing the MMC_PM_KEEP_POWER flag for
non-wowl scenario, which needs to be restored. Another necessary
change is to mark the card as being non-removable. With this in place
the suspend resume test passes successfully doing:
# echo devices /sys/power/pm_test
# echo mem /sys/power/state
Note that power may still be switched off when system is going
in S3 state.
Reported-by: Fu, Zhonghuizhonghui...@linux.intel.com
Reviewed-by: Pieter-Paul Giesbertspiete...@broadcom.com
Reviewed-by: Franky (Zhenhui) Linfran...@broadcom.com
Signed-off-by: Arend van Sprielar...@broadcom.com
---
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
index 9b508bd..8a69544 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
@@ -1011,6 +1011,14 @@ static int brcmf_sdiod_remove(struct brcmf_sdio_dev
*sdiodev)
return 0;
}
+static void brcmf_sdiod_host_fixup(struct mmc_host *host)
+{
+ /* runtime-pm powers off the device */
+ pm_runtime_forbid(host-parent);
That you need this, clearly shows that something is broken in the mmc
core/host layer.
Could you elaborate a bit on what configuration you are using. Like
what mmc host, which SDIO bus speed mode.
And have you tested different configurations? Like what happens if you
use a different SDIO bus speed mode?
So what should I do with this patch? Good to commit still?
I think so, but I am biased ;-) Seriously, this enables people that have
brcmfmac devices hooked up through runtime-pm capable host controllers
to use wifi. So while we need to work to proper runtime-pm support for
SDIO function drivers with proper interaction with the MMC stack this
patch provides a short term solution/workaround at the cost of being a
bit less power efficient.
Regards,
Arend
--
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] rtlwifi: rtl8192cu: Fix some beacon issue
2015-04-29 1:21 GMT+09:00 Kalle Valo kv...@codeaurora.org: Taehee Yoo ap420...@gmail.com writes: Sometimes rtl8192cu is not sending beacon frame. This patch fix this issue. Signed-off-by: Taehee Yoo ap420...@gmail.com Larry, what do you think? Should I apply this? https://patchwork.kernel.org/patch/5856761/ -- Kalle Valo i think that it is incomplete patch. because it can not solve Mike's problem. Apologize about incomplete patch. -- 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] mwifiex: sdio: bug: dead-lock in card reset
Hi Kalle, thanks for reviewing this 2015-04-28 18:04 GMT+02:00 Kalle Valo kv...@codeaurora.org: Amitkumar Karwar akar...@marvell.com writes: Card reset is implemented by removing/re-adding the adapter instance. This is implemented by removing the mmc host, which will then trigger a cascade of removal callbacks including mwifiex_sdio_remove. The dead-lock results in the latter function, trying to cancel the work item executing the mmc host removal. This patch adds a driver level, not adapter level, work struct to break the dead-lock Ok, so we are talking about this commit which apparently fell through the cracks: https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=2f5872b60146 Like I said as a reply to patch 1, using static variables for this is ugly. Isn't there really any better way to handle the problem? The root of the evil is calling internal mmc-host API to solve a problem in mwifiex: target = adapter-card-sdio_func-host; mmc_remove_host(target); mdelay(200); mmc_add_host(target); This code needs to run on a workqueue that is independent of the adapter, since all workqueues of the adapter are destroyed. We can hide the adapter pointer through sdio_set_drvdata, Then from the workqueue, we can iterate over all sdio_func in the system. Must be possible through the device model somehow, then use, a *global* variable to filter out the sdio_func that is ours. That saves us from de-referencing the weak adapter pointer (card could be removed by mmc-core workqueue running in parallel). But it doesn't safe us from a weak mmc host pointer: That particular card has a BT function as well, and if cmd handler is hosed for one function, it's hosed for the other one as well. If they both issue card reset simultaneously we have a race condition. (we can't claim the host we are going to destroy), - unless they both run on the same workqueue, and the workqueue only executes 1 task simultaneously . It's also quite unpolite of one function to reset card before consulting the other functions. Something like request reset / and each function has a veto. (There is also an FM tuner, that can send it's data via I2S, not affected by the sdio cmd handler) The current solution is pragmatic, 99.99% of the cards are non-removable / 1 adapter per system / no-BT? But it might be a bit labor intensive to maintain, since changes in the mmc subsystem might break it by accident. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=81df6cafe28b358739d121205e1ddaeec2ed5b15 /Andi -- 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: NFC: CONFIG_NFC_DEBUG not defined
Hi Clément, thanks for your answer. On Tue, Apr 28, 2015 at 10:23 AM, Clément Perrochaud clement.perroch...@effinnov.com wrote: On Mon, Apr 27, 2015 at 9:03 AM, Valentin Rothberg wrote: Hi Clément, your commit dece45855a8b (NFC: nxp-nci: Add support for NXP NCI chips) adds the Makefile drivers/nfc/nxp-nci/Makefile with the following line: +ccflags-$(CONFIG_NFC_DEBUG) := -DDEBUG The Kconfig option NFC_DEBUG is not defined so the line turns out to be a nop. There is another reference in drivers/nfc/Makefile. Is there a patch queued somewhere to add the option? I found this issue with ./scripts/checkkconfigsymbols.py by diffing v4.0 and v4.1-rc1. Hi Valentin, I only included this line because it was present in the upper-level Makefile drivers/nfc/Makefile . As far as I know, there is no plan to add this option to the configuration. What would the most sensible solution to this issue be ? Add the NFC Debug feature to the configuration ? Remove it altogether ? DEBUG is not used in any of the files in drivers/nfc/ so I think we can safely remove the two lines from the Makefiles. Do you want me to prepare a patch? Kind regards, Valentin Regards, -- Clément Perrochaud Eff'Innov Technologies Caen, Aix-En-Provence, Grenoble Eff'Innov Technologies Campus EffiScience 2, Esplanade Anton Philips 14460 Colombelles, FRANCE http://www.effinnov.com -- 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 1/1] New driver: rtl8723au (mac80211)
jes.soren...@redhat.com writes: From: Jes Sorensen jes.soren...@redhat.com This is an alternate driver for the Realtek 8723AU (rtl8723au) written from scratch utilizing the mac80211 stack. After spending months cleaning up the vendor provided rtl8723au driver, which comes with it's own 802.11 stack included, I decided to rewrite this driver from the bottom up. Where is the vendor driver available, in staging or somewhere else? It would be good to mention that in the commit log. Many thanks to Johannes Berg for 802.11 insights and help and Larry Finger for help with the vendor driver. The full git log for the development of this driver can be found here: git git://git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git branch rtl8723au-mac80211 This driver is still experimental, but has proven to be rather stable for me. It lacks some features found in the staging driver, such as power management, AMPDU, and 40MHz channel support. In addition there is no AP and monitor support at this point. It's nice to document in the commit log what features are verified to be working. Also I see incosistencies with driver naming, in some places I see RTL8723au and elsewhere rtl8xxxu. And commit log title could be improved, for example something like rtl8xxxu: new wireless mac80211 driver for rtl8723au chipsets And I would like to understand the relationship with rtlwifi, can you describe that a bit more? Why a separate driver instead of extending rtlwifi? When I look at the directory drivers/net/wireless/rtlwifi/rtl8723ae I'm confused what's the bigger plan here. Larry? MAINTAINERS |8 + drivers/net/wireless/Kconfig | 19 + drivers/net/wireless/Makefile|2 + drivers/net/wireless/rtl8xxxu.c | 4500 ++ drivers/net/wireless/rtl8xxxu.h | 497 drivers/net/wireless/rtl8xxxu_regs.h | 941 +++ I think someone else already mentioned, but it would be better that has it's own directory. Or should this actually be under rtlwifi directory? --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8297,6 +8297,14 @@ S: Maintained F: drivers/net/wireless/rtlwifi/ F: drivers/net/wireless/rtlwifi/rtl8192ce/ +RTL8XXXU WIRELESS DRIVER (rtl8xxxu) +M: Jes Sorensen jes.soren...@redhat.com +L: linux-wireless@vger.kernel.org +W: http://intellinuxwireless.org The link cannot be right. +T: git git://git.kernel.org/pub/scm/linux/kernel/git/jes/linux.git rtl8723au-mac80211 I doubt that this will be in active enough development that a separate git tree is needed. wireless-drivers trees should be enough and this line can be removed. I'll do more detailed code review later, but my first impression was that there was a lot of #if 0 code which is frowned upon. And I pushed this to wireless-drivers-next.git pending branch so that kbuild will run it's tests with this driver. -- 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] iwl4965: Enable checking of format strings
On Tue, Apr 28, 2015 at 07:19:02PM +0300, Kalle Valo wrote: Rasmus Villemoes li...@rasmusvillemoes.dk writes: Since these fmt_* variables are just const char*, and not const char[], gcc (and smatch) doesn't to type checking of the arguments to the printf functions. Since the linker knows perfectly well to merge identical string constants, there's no point in having three static pointers waste memory and give an extra level of indirection. This removes over 100 non-constant format argument warnings from smatch, accounting for about 20% of all such warnings in an allmodconfig. Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk So what's the conclusion, should I commit this patch or not? Full discussion here: https://patchwork.kernel.org/patch/5814811/ I do not see the point of the patch. If compiler behave not optimally, fix the compiler. NACK. Stanislaw -- 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
TX99 usage
Hi, we are having some troubles using TX99 for our wireless testing. Our goal is to have a system that can modify: - Tx gain - data rate - tx packet length - tx mode (continuous/burst) - specify tx antenna Currently, we're using a 3.10 kernel with all patches needed to provide tx99 functionality. It seems to work fine to. Quick tests with different powers show different occupation in the spectrum. But changing for example the datarate seems to fail. It remains at 6.5M command used: iw dev moni0 set bitrates legacy-5 24 Can anyone provide some pointers on how to change these things? Is there a reference on how to use tx99 to accomplish all the above goals? Kr Mathieu -- 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] drivers/nfc: remove obsolete setting of DEBUG
The CPP identifier 'DEBUG' is not used in the source code of nfc at all, so we can safely remove setting it in both Makefiles. Signed-off-by: Valentin Rothberg valentinrothb...@gmail.com --- I detected this issue with ./scripts/checkkconfigsymbols.py since CONFIG_NFC_DEBUG is not defined in Kconfig. --- drivers/nfc/Makefile | 2 -- drivers/nfc/nxp-nci/Makefile | 2 -- 2 files changed, 4 deletions(-) diff --git a/drivers/nfc/Makefile b/drivers/nfc/Makefile index a4292d790f9b..13b648baf175 100644 --- a/drivers/nfc/Makefile +++ b/drivers/nfc/Makefile @@ -14,5 +14,3 @@ obj-$(CONFIG_NFC_TRF7970A)+= trf7970a.o obj-$(CONFIG_NFC_ST21NFCA) += st21nfca/ obj-$(CONFIG_NFC_ST21NFCB) += st21nfcb/ obj-$(CONFIG_NFC_NXP_NCI) += nxp-nci/ - -ccflags-$(CONFIG_NFC_DEBUG) := -DDEBUG diff --git a/drivers/nfc/nxp-nci/Makefile b/drivers/nfc/nxp-nci/Makefile index c008be30bb18..c9ec7869dbd2 100644 --- a/drivers/nfc/nxp-nci/Makefile +++ b/drivers/nfc/nxp-nci/Makefile @@ -7,5 +7,3 @@ nxp-nci_i2c-objs = i2c.o obj-$(CONFIG_NFC_NXP_NCI) += nxp-nci.o obj-$(CONFIG_NFC_NXP_NCI_I2C) += nxp-nci_i2c.o - -ccflags-$(CONFIG_NFC_DEBUG) := -DDEBUG -- 2.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
