* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Luca Coelho @ 2016-10-13 12:44 UTC (permalink / raw)
To: Paul Bolle, linux-wireless, chris
Cc: linuxwifi, emmanuel.grumbach, johannes, kvalo, oren.givon, netdev,
linux-kernel
In-Reply-To: <1476362194.1999.11.camel@tiscali.nl>
On Thu, 2016-10-13 at 14:36 +0200, Paul Bolle wrote:
> On Thu, 2016-10-13 at 14:30 +0300, Luca Coelho wrote:
> > I forgot to say... could you load the iwlwifi module with debug=0x01
> > (module parameter), so we can see the messages the driver is printing
> > when it doesn't find a proper structure?
>
>
> That makes a lot of noise! Here's the first 100 lines or so, that
> apparently are generated directly after modprobing iwlwifi.
>
> After these 100 lines there's a ten second gap (I guess it took me ten
> seconds to actually use the wifi). I assume you don't care about that
> part of the debug messages.
>
> Have fun!
Thanks, Paul!
Yeah, this is the "INFO" debugging level and it is a sort of fallback
bucket when there is nothing more specific. Sorry for that.
> <7>[ 767.691342] iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
> <7>[ 767.691362] iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
> <7>[ 767.692127] iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load firmware 'iwlwifi-8000C-24.ucode'
> <7>[ 767.692322] iwlwifi 0000:3a:00.0: U splc_get_pwr_limit No element for the WiFi domain returned by the SPLC method.
This is the line I was looking for. :) So everything looks fine now.
Even though there is apparently something wrong with this part of the
ACPI table on you laptop, since it doesn't match our specifications.
In any case, it's mostly harmless.
Thanks for the help!
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH v2] cfg80211: Check radar_detect and num_different_channels with beacon interface combinations.
From: Johannes Berg @ 2016-10-13 12:42 UTC (permalink / raw)
To: Purushottam Kushwaha; +Cc: linux-wireless, jouni, usdutt, amarnath
In-Reply-To: <1476277034-6972-1-git-send-email-pkushwah@qti.qualcomm.com>
On Wed, 2016-10-12 at 18:27 +0530, Purushottam Kushwaha wrote:
> This commit enhances the current beacon interval validation to also
> consider the "radar_detect" and "num_different_channels".
>
> Rename "cfg80211_validate_beacon_int" to
> "cfg80211_validate_beacon_combination"
> as the validation considers other parameters.
Looking at this more closely, I think it's correct, but incomplete.
Consider a case like the following:
interface combinations:
(1) AP=3, beacon_int_gcd=50
(2) AP=2, station=1, beacon_int_gcd=0
AP interfaces A and B are both active, with beacon intervals of 100 and
150 respectively. So far, this is not a problem, falling into the
interface combination (1).
Now, somebody wants to add a station interface, and brings it up.
Because the validation thereof doesn't take the beacon intervals into
account at all, this would be accepted as falling into the interface
combination (2), but is actually incorrect due to the differing beacon
intervals.
As a consequence, I think we need to factor out the beacon interval
information building from cfg80211_validate_beacon_int() as it is right
now (with your other two patches applied), and also apply it when we
call cfg80211_iter_combinations() so that the case above gets verified.
This patch is probably a step in the right direction, but given the
situation above I don't think it's complete.
johannes
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Paul Bolle @ 2016-10-13 12:36 UTC (permalink / raw)
To: Luca Coelho, linux-wireless, chris
Cc: linuxwifi, emmanuel.grumbach, johannes, kvalo, oren.givon, netdev,
linux-kernel
In-Reply-To: <1476358222.3880.21.camel@coelho.fi>
On Thu, 2016-10-13 at 14:30 +0300, Luca Coelho wrote:
> I forgot to say... could you load the iwlwifi module with debug=0x01
> (module parameter), so we can see the messages the driver is printing
> when it doesn't find a proper structure?
That makes a lot of noise! Here's the first 100 lines or so, that
apparently are generated directly after modprobing iwlwifi.
After these 100 lines there's a ten second gap (I guess it took me ten
seconds to actually use the wifi). I assume you don't care about that
part of the debug messages.
Have fun!
Paul Bolle
<7>[ 767.691342] iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
<7>[ 767.691362] iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
<7>[ 767.692127] iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load firmware 'iwlwifi-8000C-24.ucode'
<7>[ 767.692322] iwlwifi 0000:3a:00.0: U splc_get_pwr_limit No element for the WiFi domain returned by the SPLC method.
<7>[ 767.692324] iwlwifi 0000:3a:00.0: U set_dflt_pwr_limit Default power limit set to 0
<4>[ 767.692672] iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-24.ucode failed with error -2
<7>[ 767.692674] iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load firmware 'iwlwifi-8000C-23.ucode'
<4>[ 767.692683] iwlwifi 0000:3a:00.0: Direct firmware load for iwlwifi-8000C-23.ucode failed with error -2
<7>[ 767.692684] iwlwifi 0000:3a:00.0: U iwl_request_firmware attempting to load firmware 'iwlwifi-8000C-22.ucode'
<7>[ 767.693267] iwlwifi 0000:3a:00.0: U iwl_req_fw_callback Loaded firmware file 'iwlwifi-8000C-22.ucode' (2120860 bytes).
<7>[ 767.693271] iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware Found debug memory segment: 0
<7>[ 767.693272] iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware Found debug memory segment: 1
<7>[ 767.693274] iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware Found debug memory segment: 2
<7>[ 767.693276] iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware unknown TLV: 48
<7>[ 767.693278] iwlwifi 0000:3a:00.0: U iwl_parse_tlv_firmware GSCAN is supported but capabilities TLV is unavailable
<6>[ 767.693829] iwlwifi 0000:3a:00.0: loaded firmware version 22.361476.0 op_mode iwlmvm
<6>[ 767.747133] iwlwifi 0000:3a:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
<7>[ 767.747141] iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
<7>[ 767.747168] iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
<7>[ 767.749221] iwlwifi 0000:3a:00.0: U iwl_pcie_apm_init Init card's basic functions
<6>[ 767.749257] iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
<7>[ 767.749855] iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
<7>[ 767.749870] iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
<7>[ 767.749878] iwlwifi 0000:3a:00.0: U iwl_pcie_apm_init Init card's basic functions
<6>[ 767.749896] iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
<7>[ 767.749906] iwlwifi 0000:3a:00.0: U iwl_mvm_nic_config Radio type=0x0-0x2-0x1
<7>[ 767.750608] iwlwifi 0000:3a:00.0: U iwl_pcie_nic_init Enabling shadow registers in device
<7>[ 767.750624] iwlwifi 0000:3a:00.0: U iwl_pcie_rsa_race_bug_wa can't access the RSA semaphore it is write protected
<7>[ 767.810446] iwlwifi 0000:3a:00.0: I iwl_mvm_rx_mfuart_notif MFUART: installed ver: 0x12000415, external ver: 0x12000415, status: 0x00010080, duration: 0x00000006
<7>[ 767.810861] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command BT_CONFIG
<7>[ 767.810862] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command BT_CONFIG
<7>[ 767.810984] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command BT_CONFIG
<7>[ 767.811023] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811025] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811098] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811102] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811103] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811212] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811222] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811223] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811318] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811326] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811327] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811451] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811459] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811460] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811555] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811564] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811565] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811672] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811681] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811682] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811742] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811746] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811747] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811837] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811842] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811843] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811944] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.811952] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.811953] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812011] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812016] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.812017] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812073] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812077] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.812077] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812142] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812146] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.812147] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812201] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812204] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.812205] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812276] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812281] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command NVM_ACCESS_CMD
<7>[ 767.812281] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812344] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command NVM_ACCESS_CMD
<7>[ 767.812366] iwlwifi 0000:3a:00.0: U iwl_nvm_check_version device EEPROM VER=0xe56, CALIB=0xff
<7>[ 767.812368] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command TX_ANT_CONFIGURATION_CMD
<7>[ 767.812369] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command TX_ANT_CONFIGURATION_CMD
<7>[ 767.812422] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command TX_ANT_CONFIGURATION_CMD
<7>[ 767.812425] iwlwifi 0000:3a:00.0: U iwl_send_phy_cfg_cmd Sending Phy CFG command: 0x330018
<7>[ 767.812426] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Attempting to send sync command PHY_CONFIGURATION_CMD
<7>[ 767.812427] iwlwifi 0000:3a:00.0: U iwl_pcie_send_hcmd_sync Setting HCMD_ACTIVE for command PHY_CONFIGURATION_CMD
<7>[ 767.812480] iwlwifi 0000:3a:00.0: I iwl_pcie_hcmd_complete Clearing HCMD_ACTIVE for command PHY_CONFIGURATION_CMD
<7>[ 767.871057] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 1 , Size: 3684
<7>[ 767.871065] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 2 , Size: 4
<7>[ 767.871071] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871108] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871263] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871441] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871607] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871782] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871814] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 5 , Size: 2056
<7>[ 767.871955] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872084] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872216] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872346] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872478] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872622] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872764] iwlwifi 0000:3a:00.0: I iwl_phy_db_set_section iwl_phy_db_set_section(282): [PHYDB]SET: Type 4 , Size: 1552
<7>[ 767.872871] iwlwifi 0000:3a:00.0: U _iwl_trans_pcie_stop_device DEVICE_ENABLED bit was set and is now cleared
<7>[ 767.872961] iwlwifi 0000:3a:00.0: U iwl_pcie_apm_stop Stop card, put in low power state
<7>[ 767.872980] iwlwifi 0000:3a:00.0: U iwl_pcie_apm_stop_master stop master
<7>[ 767.877089] iwlwifi 0000:3a:00.0: U iwl_pcie_prepare_card_hw iwl_trans_prepare_card_hw enter
<7>[ 767.877119] iwlwifi 0000:3a:00.0: U iwl_pcie_set_hw_ready hardware ready
<6>[ 767.905185] iwlwifi 0000:3a:00.0 wlp58s0: renamed from wlan0
^ permalink raw reply
* [PATCH 1/3] rsi: Fix memory leak in module unload
From: Prameela Rani Garnepudi @ 2016-10-13 11:25 UTC (permalink / raw)
To: linux-wireless
Cc: kvalo, johannes.berg, hofrat, xypron.glpk, prameela.garnepudi,
Prameela Rani Garnepudi
Observed crash when module is unloaded if CONFIG_RSI_DEBUGSFS is not set.
Fix: Debugfs entry removal moved inside CONFIG_RSI_DEBUGSFS flag in
function rsi_mac80211_detach()
Memory leak found and fixed for below structures in function rsi_mac80211_detach()
* channel list for each supported band
* rsi debugfs info
Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index dbb2389..58779c0 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -194,6 +194,7 @@ static void rsi_register_rates_channels(struct rsi_hw *adapter, int band)
void rsi_mac80211_detach(struct rsi_hw *adapter)
{
struct ieee80211_hw *hw = adapter->hw;
+ enum nl80211_band band;
if (hw) {
ieee80211_stop_queues(hw);
@@ -201,7 +202,17 @@ void rsi_mac80211_detach(struct rsi_hw *adapter)
ieee80211_free_hw(hw);
}
+ for (band = 0; band < NUM_NL80211_BANDS; band++) {
+ struct ieee80211_supported_band *sband =
+ &adapter->sbands[band];
+
+ kfree(sband->channels);
+ }
+
+#ifdef CONFIG_RSI_DEBUGFS
rsi_remove_dbgfs(adapter);
+ kfree(adapter->dfsentry);
+#endif
}
EXPORT_SYMBOL_GPL(rsi_mac80211_detach);
--
2.4.11
^ permalink raw reply related
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Luca Coelho @ 2016-10-13 11:30 UTC (permalink / raw)
To: Paul Bolle, linux-wireless, chris
Cc: linuxwifi, emmanuel.grumbach, johannes, kvalo, oren.givon, netdev,
linux-kernel
In-Reply-To: <1476358075.1999.5.camel@tiscali.nl>
On Thu, 2016-10-13 at 13:27 +0200, Paul Bolle wrote:
> Luca,
>
> On Thu, 2016-10-13 at 13:21 +0300, Luca Coelho wrote:
> > Could you please give this a spin? I have tested it with some handmade
> > ACPI tables in QEMU and it seems to work fine now.
>
>
> Tested-by: Paul Bolle <pebolle@tiscali.nl>
>
> Not that this test was worth a lot: it builds cleanly (on top of
> 4.8.1), the error at boot is gone, obviously, and wifi still works (as
> you're reading a message that was sent out over wifi). And I haven't
> even tested this on another machine than my XPS 13 (9350).
Thanks for testing!
I forgot to say... could you load the iwlwifi module with debug=0x01
(module parameter), so we can see the messages the driver is printing
when it doesn't find a proper structure?
--
Luca.
^ permalink raw reply
* Re: [PATCH v10] cfg80211: Provision to allow the support for different beacon intervals
From: Johannes Berg @ 2016-10-13 11:46 UTC (permalink / raw)
To: Purushottam Kushwaha; +Cc: linux-wireless, jouni, usdutt, amarnath
In-Reply-To: <1476277011-6937-1-git-send-email-pkushwah@qti.qualcomm.com>
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -421,6 +421,8 @@ static int brcmf_vif_change_validate(struct
> brcmf_cfg80211_info *cfg,
> .num_different_channels = 1,
> .radar_detect = 0,
> .iftype_num = {0},
> + .beacon_gcd = 0,
> + .diff_bi = false,
> };
>
> list_for_each_entry(pos, &cfg->vif_list, list)
> @@ -446,6 +448,8 @@ static int brcmf_vif_add_validate(struct
> brcmf_cfg80211_info *cfg,
> .num_different_channels = 1,
> .radar_detect = 0,
> .iftype_num = {0},
> + .beacon_gcd = 0,
> + .diff_bi = false,
> };
You don't need this now, since the default is 0/false, so we don't have
to touch this file. I already removed some of the other useless
initializers in the previous patch, and will edit this out as well - no
need to resend.
> list_for_each_entry(pos, &cfg->vif_list, list)
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 21bbe44..f0bcd55 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -784,11 +784,15 @@ struct cfg80211_csa_settings {
> * @iftype_num: array with the numbers of interfaces of each
> interface
> * type. The index is the interface type as specified in
> &enum
> * nl80211_iftype.
> + * @beacon_gcd: a value specifying GCD of all beaconing interfaces.
> + * @diff_bi: a flag which denotes beacon intervals are different or
> same.
I think I'll rename both to beacon_* or *_bi, but I don't really like
the difference in naming here.
> */
> struct iface_combination_params {
> int num_different_channels;
> u8 radar_detect;
> int iftype_num[NUM_NL80211_IFTYPES];
> + u32 beacon_gcd;
> + bool diff_bi;
> };
>
> /**
> @@ -3100,6 +3104,12 @@ struct ieee80211_iface_limit {
> * only in special cases.
> * @radar_detect_widths: bitmap of channel widths supported for
> radar detection
> * @radar_detect_regions: bitmap of regions supported for radar
> detection
> + * @beacon_int_min_gcd: This interface combination supports
> different
> + * beacon intervals.
> + * = 0 - all beacon intervals for different interface must be
> same.
> + * > 0 - any beacon interval for the interface part of this
> combination AND
> + * *GCD* of all beacon intervals from beaconing
> interfaces of this
> + * combination must be greator or equal to this value.
typo: greater - will also fix
> * With this structure the driver can describe which interface
> * combinations it supports concurrently.
> @@ -3120,7 +3130,7 @@ struct ieee80211_iface_limit {
> * };
> *
> *
> - * 2. Allow #{AP, P2P-GO} <= 8, channels = 1, 8 total:
> + * 2. Allow #{AP, P2P-GO} <= 8, BI min gcd = 10, channels = 1, 8
> total:
> *
> * struct ieee80211_iface_limit limits2[] = {
> * { .max = 8, .types = BIT(NL80211_IFTYPE_AP) |
> @@ -3131,6 +3141,7 @@ struct ieee80211_iface_limit {
> * .n_limits = ARRAY_SIZE(limits2),
> * .max_interfaces = 8,
> * .num_different_channels = 1,
> + * .beacon_int_min_gcd = 10,
> * };
> *
> *
> @@ -3158,6 +3169,7 @@ struct ieee80211_iface_combination {
> bool beacon_int_infra_match;
> u8 radar_detect_widths;
> u8 radar_detect_regions;
> + u32 beacon_int_min_gcd;
> };
>
> struct ieee80211_txrx_stypes {
> diff --git a/include/uapi/linux/nl80211.h
> b/include/uapi/linux/nl80211.h
> index 56368e9..3c19cca 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -4280,6 +4280,9 @@ enum nl80211_iface_limit_attrs {
> * of supported channel widths for radar detection.
> * @NL80211_IFACE_COMB_RADAR_DETECT_REGIONS: u32 attribute
> containing the bitmap
> * of supported regulatory regions for radar detection.
> + * @NL80211_IFACE_COMB_BI_MIN_GCD: u32 attribute specifying the
> minimum GCD of
> + * different beacon intervals supported by all the interface
> combinations
> + * in this group (if not present, all beacon interval must
> match).
beacon intervals
> * @NUM_NL80211_IFACE_COMB: number of attributes
> * @MAX_NL80211_IFACE_COMB: highest attribute number
> *
> @@ -4287,8 +4290,8 @@ enum nl80211_iface_limit_attrs {
> * limits = [ #{STA} <= 1, #{AP} <= 1 ], matching BI,
> channels = 1, max = 2
> * => allows an AP and a STA that must match BIs
> *
> - * numbers = [ #{AP, P2P-GO} <= 8 ], channels = 1, max = 8
> - * => allows 8 of AP/GO
> + * numbers = [ #{AP, P2P-GO} <= 8 ], BI min gcd, channels =
> 1, max = 8,
> + * => allows 8 of AP/GO that can have BI gcd >= min gcd
> *
> * numbers = [ #{STA} <= 2 ], channels = 2, max = 2
> * => allows two STAs on different channels
> @@ -4314,6 +4317,7 @@ enum nl80211_if_combination_attrs {
> NL80211_IFACE_COMB_NUM_CHANNELS,
> NL80211_IFACE_COMB_RADAR_DETECT_WIDTHS,
> NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
> + NL80211_IFACE_COMB_BI_MIN_GCD,
>
> /* keep last */
> NUM_NL80211_IFACE_COMB,
> diff --git a/net/wireless/core.h b/net/wireless/core.h
> index 08d2e94..21e3188 100644
> --- a/net/wireless/core.h
> +++ b/net/wireless/core.h
> @@ -475,7 +475,7 @@ int ieee80211_get_ratemask(struct
> ieee80211_supported_band *sband,
> u32 *mask);
>
> int cfg80211_validate_beacon_int(struct cfg80211_registered_device
> *rdev,
> - u32 beacon_int);
> + enum nl80211_iftype iftype, u32
> beacon_int);
>
> void cfg80211_update_iface_num(struct cfg80211_registered_device
> *rdev,
> enum nl80211_iftype iftype, int num);
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index c510810..903cd5a 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -1075,6 +1075,10 @@ static int
> nl80211_put_iface_combinations(struct wiphy *wiphy,
> nla_put_u32(msg,
> NL80211_IFACE_COMB_RADAR_DETECT_REGIONS,
> c->radar_detect_regions)))
> goto nla_put_failure;
> + if (c->beacon_int_min_gcd &&
> + nla_put_u32(msg, NL80211_IFACE_COMB_BI_MIN_GCD,
> + c->beacon_int_min_gcd))
> + goto nla_put_failure;
>
> nla_nest_end(msg, nl_combi);
> }
> @@ -3803,7 +3807,8 @@ static int nl80211_start_ap(struct sk_buff
> *skb, struct genl_info *info)
> params.dtim_period =
> nla_get_u32(info->attrs[NL80211_ATTR_DTIM_PERIOD]);
>
> - err = cfg80211_validate_beacon_int(rdev,
> params.beacon_interval);
> + err = cfg80211_validate_beacon_int(rdev, dev->ieee80211_ptr-
> >iftype,
> + params.beacon_interval);
> if (err)
> return err;
>
> @@ -8152,7 +8157,8 @@ static int nl80211_join_ibss(struct sk_buff
> *skb, struct genl_info *info)
> ibss.beacon_interval =
> nla_get_u32(info-
> >attrs[NL80211_ATTR_BEACON_INTERVAL]);
>
> - err = cfg80211_validate_beacon_int(rdev,
> ibss.beacon_interval);
> + err = cfg80211_validate_beacon_int(rdev,
> NL80211_IFTYPE_ADHOC,
> + ibss.beacon_interval);
> if (err)
> return err;
>
> @@ -9417,7 +9423,9 @@ static int nl80211_join_mesh(struct sk_buff
> *skb, struct genl_info *info)
> setup.beacon_interval =
> nla_get_u32(info-
> >attrs[NL80211_ATTR_BEACON_INTERVAL]);
>
> - err = cfg80211_validate_beacon_int(rdev,
> setup.beacon_interval);
> + err = cfg80211_validate_beacon_int(rdev,
> + NL80211_IFTYPE_ME
> SH_POINT,
> + setup.beacon_inte
> rval);
> if (err)
> return err;
> }
> diff --git a/net/wireless/util.c b/net/wireless/util.c
> index 0d69b25..3f3d684 100644
> --- a/net/wireless/util.c
> +++ b/net/wireless/util.c
> @@ -1559,24 +1559,49 @@ bool
> ieee80211_chandef_to_operating_class(struct cfg80211_chan_def
> *chandef,
> EXPORT_SYMBOL(ieee80211_chandef_to_operating_class);
>
> int cfg80211_validate_beacon_int(struct cfg80211_registered_device
> *rdev,
> + enum nl80211_iftype iftype,
> u32 beacon_int)
> {
> struct wireless_dev *wdev;
> int res = 0;
> + u32 bi_prev, tmp_bi;
> + struct iface_combination_params params = {
> + .num_different_channels = 0,
> + .radar_detect = 0,
> + .iftype_num = {0},
> + .beacon_gcd = beacon_int, /* GCD(n) = n */
> + .diff_bi = false,
> + };
>
> if (beacon_int < 10 || beacon_int > 10000)
> return -EINVAL;
>
> + params.iftype_num[iftype] = 1;
> + list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
> + if (!wdev->beacon_interval)
> + continue;
> +
> + params.iftype_num[wdev->iftype]++;
> + }
> +
> list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
> if (!wdev->beacon_interval)
> continue;
> if (wdev->beacon_interval != beacon_int) {
> - res = -EINVAL;
> + params.diff_bi = true;
> + /* Get the GCD */
> + bi_prev = wdev->beacon_interval;
> + while (bi_prev != 0) {
> + tmp_bi = bi_prev;
> + bi_prev = params.beacon_gcd %
> bi_prev;
> + params.beacon_gcd = tmp_bi;
> + }
> break;
> }
> }
>
> - return res;
> + res = cfg80211_check_combinations(&rdev->wiphy, ¶ms);
> + return (res < 0) ? res : 0;
> }
>
> int cfg80211_iter_combinations(struct wiphy *wiphy,
> @@ -1652,6 +1677,14 @@ int cfg80211_iter_combinations(struct wiphy
> *wiphy,
> if ((all_iftypes & used_iftypes) != used_iftypes)
> goto cont;
>
> + if (params->beacon_gcd) {
> + if (c->beacon_int_min_gcd &&
> + params->beacon_gcd < c-
> >beacon_int_min_gcd)
> + return -EINVAL;
> + if (!c->beacon_int_min_gcd && params-
> >diff_bi)
> + goto cont;
> + }
>
Otherwise looks good.
johannes
^ permalink raw reply
* [PATCH 3/3] rsi: Updated boot parameters
From: Prameela Rani Garnepudi @ 2016-10-13 11:27 UTC (permalink / raw)
To: linux-wireless
Cc: kvalo, johannes.berg, hofrat, xypron.glpk, prameela.garnepudi,
Prameela Rani Garnepudi
* Switch clock info is divided in to different clock information fields for
readability and synchronization with firmware code.
* Other parameters are added for future use and to make the frame size in sync
with latest firmware. Otherwise firmware will discard the frame considering
corrupted frame.
Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
---
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 62 ++++++++++++++++++++++++++----
drivers/net/wireless/rsi/rsi_boot_params.h | 45 +++++++++++++++++++++-
2 files changed, 97 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mgmt.c b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
index 30b9d44..10796c2 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
@@ -18,6 +18,7 @@
#include "rsi_mgmt.h"
#include "rsi_common.h"
+/* Bootup Parameters for 20MHz */
static struct bootup_params boot_params_20 = {
.magic_number = cpu_to_le16(0x5aa5),
.crystal_good_time = 0x0,
@@ -28,6 +29,7 @@ static struct bootup_params boot_params_20 = {
.rtls_timestamp_en = 0x0,
.host_spi_intr_cfg = 0x0,
.device_clk_info = {{
+ /* WLAN params */
.pll_config_g = {
.tapll_info_g = {
.pll_reg_1 = cpu_to_le16((TA_PLL_N_VAL_20 << 8)|
@@ -45,12 +47,18 @@ static struct bootup_params boot_params_20 = {
}
},
.switch_clk_g = {
- .switch_clk_info = cpu_to_le16(BIT(3)),
+ .switch_umac_clk = 0x0,
+ .switch_qspi_clk = 0x0,
+ .switch_slp_clk_2_32 = 0x0,
+ .switch_bbp_lmac_clk_reg = 0x1,
+ .switch_mem_ctrl_cfg = 0x0,
+ .reserved = 0x0,
.bbp_lmac_clk_reg_val = cpu_to_le16(0x121),
.umac_clock_reg_config = 0x0,
.qspi_uart_clock_reg_config = 0x0
}
},
+ /* Bluetooth params */
{
.pll_config_g = {
.tapll_info_g = {
@@ -69,12 +77,18 @@ static struct bootup_params boot_params_20 = {
}
},
.switch_clk_g = {
- .switch_clk_info = 0x0,
+ .switch_umac_clk = 0x0,
+ .switch_qspi_clk = 0x0,
+ .switch_slp_clk_2_32 = 0x0,
+ .switch_bbp_lmac_clk_reg = 0x0,
+ .switch_mem_ctrl_cfg = 0x0,
+ .reserved = 0x0,
.bbp_lmac_clk_reg_val = 0x0,
.umac_clock_reg_config = 0x0,
.qspi_uart_clock_reg_config = 0x0
}
},
+ /* Zigbee params */
{
.pll_config_g = {
.tapll_info_g = {
@@ -93,12 +107,18 @@ static struct bootup_params boot_params_20 = {
}
},
.switch_clk_g = {
- .switch_clk_info = 0x0,
+ .switch_umac_clk = 0x0,
+ .switch_qspi_clk = 0x0,
+ .switch_slp_clk_2_32 = 0x0,
+ .switch_bbp_lmac_clk_reg = 0x0,
+ .switch_mem_ctrl_cfg = 0x0,
+ .reserved = 0x0,
.bbp_lmac_clk_reg_val = 0x0,
.umac_clock_reg_config = 0x0,
.qspi_uart_clock_reg_config = 0x0
}
} },
+ /* ULP Params */
.buckboost_wakeup_cnt = 0x0,
.pmu_wakeup_wait = 0x0,
.shutdown_wait_time = 0x0,
@@ -106,9 +126,13 @@ static struct bootup_params boot_params_20 = {
.wdt_prog_value = 0x0,
.wdt_soc_rst_delay = 0x0,
.dcdc_operation_mode = 0x0,
- .soc_reset_wait_cnt = 0x0
+ .soc_reset_wait_cnt = 0x0,
+ .waiting_time_at_fresh_sleep = 0x0,
+ .max_threshold_to_avoid_sleep = 0x0,
+ .beacon_resedue_alg_en = 0,
};
+/* Bootup parameters for 40MHz */
static struct bootup_params boot_params_40 = {
.magic_number = cpu_to_le16(0x5aa5),
.crystal_good_time = 0x0,
@@ -119,6 +143,7 @@ static struct bootup_params boot_params_40 = {
.rtls_timestamp_en = 0x0,
.host_spi_intr_cfg = 0x0,
.device_clk_info = {{
+ /* WLAN params */
.pll_config_g = {
.tapll_info_g = {
.pll_reg_1 = cpu_to_le16((TA_PLL_N_VAL_40 << 8)|
@@ -136,12 +161,18 @@ static struct bootup_params boot_params_40 = {
}
},
.switch_clk_g = {
- .switch_clk_info = cpu_to_le16(0x09),
+ .switch_umac_clk = 0x1,
+ .switch_qspi_clk = 0x0,
+ .switch_slp_clk_2_32 = 0x0,
+ .switch_bbp_lmac_clk_reg = 0x1,
+ .switch_mem_ctrl_cfg = 0x0,
+ .reserved = 0x0,
.bbp_lmac_clk_reg_val = cpu_to_le16(0x1121),
.umac_clock_reg_config = cpu_to_le16(0x48),
.qspi_uart_clock_reg_config = 0x0
}
},
+ /* Bluetooth Params */
{
.pll_config_g = {
.tapll_info_g = {
@@ -160,12 +191,18 @@ static struct bootup_params boot_params_40 = {
}
},
.switch_clk_g = {
- .switch_clk_info = 0x0,
+ .switch_umac_clk = 0x0,
+ .switch_qspi_clk = 0x0,
+ .switch_slp_clk_2_32 = 0x0,
+ .switch_bbp_lmac_clk_reg = 0x0,
+ .switch_mem_ctrl_cfg = 0x0,
+ .reserved = 0x0,
.bbp_lmac_clk_reg_val = 0x0,
.umac_clock_reg_config = 0x0,
.qspi_uart_clock_reg_config = 0x0
}
},
+ /* Zigbee Params */
{
.pll_config_g = {
.tapll_info_g = {
@@ -184,12 +221,18 @@ static struct bootup_params boot_params_40 = {
}
},
.switch_clk_g = {
- .switch_clk_info = 0x0,
+ .switch_umac_clk = 0x0,
+ .switch_qspi_clk = 0x0,
+ .switch_slp_clk_2_32 = 0x0,
+ .switch_bbp_lmac_clk_reg = 0x0,
+ .switch_mem_ctrl_cfg = 0x0,
+ .reserved = 0x0,
.bbp_lmac_clk_reg_val = 0x0,
.umac_clock_reg_config = 0x0,
.qspi_uart_clock_reg_config = 0x0
}
} },
+ /* ULP Params */
.buckboost_wakeup_cnt = 0x0,
.pmu_wakeup_wait = 0x0,
.shutdown_wait_time = 0x0,
@@ -197,7 +240,10 @@ static struct bootup_params boot_params_40 = {
.wdt_prog_value = 0x0,
.wdt_soc_rst_delay = 0x0,
.dcdc_operation_mode = 0x0,
- .soc_reset_wait_cnt = 0x0
+ .soc_reset_wait_cnt = 0x0,
+ .waiting_time_at_fresh_sleep = 0x0,
+ .max_threshold_to_avoid_sleep = 0x0,
+ .beacon_resedue_alg_en = 0,
};
static u16 mcs[] = {13, 26, 39, 52, 78, 104, 117, 130};
diff --git a/drivers/net/wireless/rsi/rsi_boot_params.h b/drivers/net/wireless/rsi/rsi_boot_params.h
index 5e2721f..c1be104 100644
--- a/drivers/net/wireless/rsi/rsi_boot_params.h
+++ b/drivers/net/wireless/rsi/rsi_boot_params.h
@@ -81,7 +81,13 @@ struct pll_config {
/* structure to store configs related to UMAC clk programming */
struct switch_clk {
- __le16 switch_clk_info;
+ __le16 switch_umac_clk : 1; /* If set rest is valid */
+ __le16 switch_qspi_clk : 1; /* If set qspi clk will be changed */
+ __le16 switch_slp_clk_2_32 : 1;
+ __le16 switch_bbp_lmac_clk_reg : 1;
+ __le16 switch_mem_ctrl_cfg : 1;
+ __le16 reserved : 11;
+
/* If switch_bbp_lmac_clk_reg is set then this value will be programmed
* into reg
*/
@@ -99,11 +105,43 @@ struct device_clk_info {
struct bootup_params {
__le16 magic_number;
+#define LOADED_TOKEN 0x5AA5 /* Bootup params are installed by host
+ * or OTP/FLASH (Bootloader)
+ */
+#define ROM_TOKEN 0x55AA /* Bootup params are taken from ROM
+ * itself in MCU mode.
+ */
__le16 crystal_good_time;
__le32 valid;
+#define CRYSTAL_GOOD_TIME BIT(0)
+#define BOOTUP_MODE_INFO BIT(1)
+#define DIGITAL_LOOP_BACK_PARAMS BIT(2)
+#define RTLS_TIMESTAMP_EN BIT(3)
+#define HOST_SPI_INTR_CFG BIT(4)
+#define WIFI_TAPLL_CONFIGS BIT(5)
+#define WIFI_PLL960_CONFIGS BIT(6)
+#define WIFI_AFEPLL_CONFIGS BIT(7)
+#define WIFI_SWITCH_CLK_CONFIGS BIT(8)
+#define BT_TAPLL_CONFIGS BIT(9)
+#define BT_PLL960_CONFIGS BIT(10)
+#define BT_AFEPLL_CONFIGS BIT(11)
+#define BT_SWITCH_CLK_CONFIGS BIT(12)
+#define ZB_TAPLL_CONFIGS BIT(13)
+#define ZB_PLL960_CONFIGS BIT(14)
+#define ZB_AFEPLL_CONFIGS BIT(15)
+#define ZB_SWITCH_CLK_CONFIGS BIT(16)
+#define BUCKBOOST_WAIT_INFO BIT(17)
+#define PMU_WAKEUP_SHUTDOWN_W BIT(18)
+#define WDT_PROG_VALUES BIT(19)
+#define WDT_RESET_DELAY_VALUE BIT(20)
+#define DCDC_OPERATION_MODE_VALID BIT(21)
+#define PMU_SLP_CLKOUT_SEL BIT(22)
+#define SOC_RESET_WAIT_CNT BIT(23)
__le32 reserved_for_valids;
__le16 bootup_mode_info;
- /* configuration used for digital loop back */
+#define BT_COEXIST BIT(0)
+#define BOOTUP_MODE (BIT(2) | BIT(1))
+#define CUR_DEV_MODE (bootup_params.bootup_mode_info >> 1)
__le16 digital_loop_back_params;
__le16 rtls_timestamp_en;
__le16 host_spi_intr_cfg;
@@ -122,5 +160,8 @@ struct bootup_params {
/* dcdc modes configs */
__le32 dcdc_operation_mode;
__le32 soc_reset_wait_cnt;
+ __le32 waiting_time_at_fresh_sleep;
+ __le32 max_threshold_to_avoid_sleep;
+ u8 beacon_resedue_alg_en;
} __packed;
#endif
--
2.4.11
^ permalink raw reply related
* Re: [PATCH v2] cfg80211: Create structure for combination check/iter function parameters
From: Johannes Berg @ 2016-10-13 11:41 UTC (permalink / raw)
To: Purushottam Kushwaha; +Cc: linux-wireless, jouni, usdutt, amarnath
In-Reply-To: <1476276935-6902-1-git-send-email-pkushwah@qti.qualcomm.com>
On Wed, 2016-10-12 at 18:25 +0530, Purushottam Kushwaha wrote:
> Move growing parameter list to a structure for check/iter combination
> functions in cfg80211 and mac80211.
>
Thanks, applied.
johannes
^ permalink raw reply
* Re: [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Paul Bolle @ 2016-10-13 11:27 UTC (permalink / raw)
To: Luca Coelho, linux-wireless, chris
Cc: linuxwifi, emmanuel.grumbach, johannes, kvalo, oren.givon, netdev,
linux-kernel
In-Reply-To: <20161013102155.14547-1-luca@coelho.fi>
Luca,
On Thu, 2016-10-13 at 13:21 +0300, Luca Coelho wrote:
> Could you please give this a spin? I have tested it with some handmade
> ACPI tables in QEMU and it seems to work fine now.
Tested-by: Paul Bolle <pebolle@tiscali.nl>
Not that this test was worth a lot: it builds cleanly (on top of
4.8.1), the error at boot is gone, obviously, and wifi still works (as
you're reading a message that was sent out over wifi). And I haven't
even tested this on another machine than my XPS 13 (9350).
Thanks!
Paul Bolle
^ permalink raw reply
* Re: ath6k1: add Dell OEM SDIO I/O for the Venue 8 Pro
From: Kalle Valo @ 2016-10-13 11:20 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-wireless
In-Reply-To: <147629570687.26062.4786752681864367162.stgit@localhost.localdomain>
Alan Cox <alan@linux.intel.com> wrote:
> From: Adam Williamson <adamw@happyassassin.net>
>
> SDIO ID 0271:0418
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> Bugzilla-ID: https://bugzilla.kernel.org/show_bug.cgi?id=67921
> Reviewed-by: Steve deRosier <steve.derosier@lairdtech.com>
>
> diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
> index eab0ab9..76eb336 100644
> --- a/drivers/net/wireless/ath/ath6kl/sdio.c
> +++ b/drivers/net/wireless/ath/ath6kl/sdio.c
> @@ -1401,6 +1401,7 @@ static const struct sdio_device_id ath6kl_sdio_devices[] = {
> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x0))},
> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x1))},
> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x2))},
> + {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x18))},
> {},
> };
>
Patch applied to ath-current branch of ath.git, thanks.
1ea2643961b0 ath6kl: add Dell OEM SDIO I/O for the Venue 8 Pro
--
https://patchwork.kernel.org/patch/9373725/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: Revert "ath9k_hw: implement temperature compensation support for AR9003+"
From: Kalle Valo @ 2016-10-13 11:15 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, kvalo
In-Reply-To: <20161011174649.19210-1-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> wrote:
> This reverts commit 171f6402e4aa5cd3b8407f82501f7ea21fa54ccc.
> Some users report that this commit causes a regression in performance
> under some conditions.
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
Patch applied to ath-current branch of ath.git, thanks.
304e5ac118cc Revert "ath9k_hw: implement temperature compensation support for AR9003+"
--
https://patchwork.kernel.org/patch/9371479/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v3] ath10k: cache calibration data when the core is stopped
From: Kalle Valo @ 2016-10-13 11:08 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless, Marty Faltesek
In-Reply-To: <1476115204-7385-1-git-send-email-kvalo@qca.qualcomm.com>
Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> From: Marty Faltesek <mfaltesek@google.com>
>
> Commit 0b8e3c4ca29f ("ath10k: move cal data len to hw_params") broke retrieving
> the calibration data from cal_data debugfs file. The length of file was always
> zero. The reason is:
>
> static ssize_t ath10k_debug_cal_data_read(struct file *file,
> char __user *user_buf,
> size_t count, loff_t *ppos)
> {
> struct ath10k *ar = file->private_data;
> void *buf = file->private_data;
>
>
> This is obviously bogus, private_data cannot contain both struct ath10k and the
> buffer. Fix it by caching calibration data to ar->debug.cal_data. This also
> allows it to be accessed when the device is not active (interface is down).
>
> The cal_data buffer is fixed size because during the first firmware probe we
> don't yet know what will be the lenght of the calibration data. It was simplest
> just to use a fixed length. There's a WARN_ON() in
> ath10k_debug_cal_data_fetch() if the buffer is too small.
>
> Tested with qca988x and firmware 10.2.4.70.56.
>
> Reported-by: Nikolay Martynov <mar.kolya@gmail.com>
> Fixes: 0b8e3c4ca29f ("ath10k: move cal data len to hw_params")
> Cc: stable@vger.kernel.org # 4.7+
> Signed-off-by: Marty Faltesek <mfaltesek@google.com>
> [kvalo@qca.qualcomm.com: improve commit log and minor other changes]
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-current branch of ath.git, thanks.
f67b107d4ced ath10k: cache calibration data when the core is stopped
--
https://patchwork.kernel.org/patch/9369685/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V2] rtlwifi: Fix regression caused by commit d86e64768859
From: Kalle Valo @ 2016-10-13 10:22 UTC (permalink / raw)
To: Larry Finger; +Cc: devel, linux-wireless, Larry Finger, Stable, Julia Lawall
In-Reply-To: <20161012185404.26441-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In commit d86e64768859 ("rtlwifi: rtl818x: constify local structures"),
> the configuration struct for most of the drivers was changed to be
> constant. The problem is that five of the modified drivers need to be
> able to update the firmware name based on the exact model of the card.
> As the file names were stored in one of the members of that struct,
> these drivers would fail with a kernel BUG splat when they tried to
> update the firmware name.
>
> Rather than reverting the previous commit, I used a suggestion by
> Johannes Berg and made the firmware file name pointers be local to
> the routines that update the software variables.
>
> The configuration struct of rtl8192cu, which was not touched in the
> previous patch, is now constantfied.
>
> Fixes: d86e64768859 ("rtlwifi: rtl818x: constify local structures")
> Suggested-by: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org> # 4.8
> Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Patch applied to wireless-drivers.git, thanks.
cf4747d7535a rtlwifi: Fix regression caused by commit d86e64768859
--
https://patchwork.kernel.org/patch/9373717/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] iwlwifi: pcie: fix SPLC structure parsing
From: Luca Coelho @ 2016-10-13 10:21 UTC (permalink / raw)
To: linux-wireless, chris, pebolle
Cc: linuxwifi, emmanuel.grumbach, johannes, kvalo, oren.givon, netdev,
linux-kernel
In-Reply-To: <1476349269.3880.18.camel@coelho.fi>
From: Luca Coelho <luciano.coelho@intel.com>
The SPLC data parsing is too restrictive and was not trying find the
correct element for WiFi. This causes problems with some BIOSes where
the SPLC method exists, but doesn't have a WiFi entry on the first
element of the list. The domain type values are also incorrect
according to the specification.
Fix this by complying with the actual specification.
Additionally, replace all occurrences of SPLX to SPLC, since SPLX is
only a structure internal to the ACPI tables, and may not even exist.
Fixes: bcb079a14d75 ("iwlwifi: pcie: retrieve and parse ACPI power limitations")
Reported-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
Paul, Chris,
Could you please give this a spin? I have tested it with some handmade
ACPI tables in QEMU and it seems to work fine now.
Thanks!
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 79 ++++++++++++++++-----------
1 file changed, 48 insertions(+), 31 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 001be40..da4810f 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -541,48 +541,64 @@ static const struct pci_device_id iwl_hw_card_ids[] = {
MODULE_DEVICE_TABLE(pci, iwl_hw_card_ids);
#ifdef CONFIG_ACPI
-#define SPL_METHOD "SPLC"
-#define SPL_DOMAINTYPE_MODULE BIT(0)
-#define SPL_DOMAINTYPE_WIFI BIT(1)
-#define SPL_DOMAINTYPE_WIGIG BIT(2)
-#define SPL_DOMAINTYPE_RFEM BIT(3)
+#define ACPI_SPLC_METHOD "SPLC"
+#define ACPI_SPLC_DOMAIN_WIFI (0x07)
-static u64 splx_get_pwr_limit(struct iwl_trans *trans, union acpi_object *splx)
+static u64 splc_get_pwr_limit(struct iwl_trans *trans, union acpi_object *splc)
{
- union acpi_object *limits, *domain_type, *power_limit;
-
- if (splx->type != ACPI_TYPE_PACKAGE ||
- splx->package.count != 2 ||
- splx->package.elements[0].type != ACPI_TYPE_INTEGER ||
- splx->package.elements[0].integer.value != 0) {
- IWL_ERR(trans, "Unsupported splx structure\n");
+ union acpi_object *data_pkg, *dflt_pwr_limit;
+ int i;
+
+ /* We need at least two elemets, one for the revision and one
+ * for the data itself. Also check that the revision is
+ * supported (currently only revision 0).
+ */
+ if (splc->type != ACPI_TYPE_PACKAGE ||
+ splc->package.count < 2 ||
+ splc->package.elements[0].type != ACPI_TYPE_INTEGER ||
+ splc->package.elements[0].integer.value != 0) {
+ IWL_DEBUG_INFO(trans,
+ "Unsupported structure returned by the SPLC method. Ignoring.\n");
return 0;
}
- limits = &splx->package.elements[1];
- if (limits->type != ACPI_TYPE_PACKAGE ||
- limits->package.count < 2 ||
- limits->package.elements[0].type != ACPI_TYPE_INTEGER ||
- limits->package.elements[1].type != ACPI_TYPE_INTEGER) {
- IWL_ERR(trans, "Invalid limits element\n");
- return 0;
+ /* loop through all the packages to find the one for WiFi */
+ for (i = 1; i < splc->package.count; i++) {
+ union acpi_object *domain;
+
+ data_pkg = &splc->package.elements[i];
+
+ /* Skip anything that is not a package with the right
+ * amount of elements (i.e. at least 2 integers).
+ */
+ if (data_pkg->type != ACPI_TYPE_PACKAGE ||
+ data_pkg->package.count < 2 ||
+ data_pkg->package.elements[0].type != ACPI_TYPE_INTEGER ||
+ data_pkg->package.elements[1].type != ACPI_TYPE_INTEGER)
+ continue;
+
+ domain = &data_pkg->package.elements[0];
+ if (domain->integer.value == ACPI_SPLC_DOMAIN_WIFI)
+ break;
+
+ data_pkg = NULL;
}
- domain_type = &limits->package.elements[0];
- power_limit = &limits->package.elements[1];
- if (!(domain_type->integer.value & SPL_DOMAINTYPE_WIFI)) {
- IWL_DEBUG_INFO(trans, "WiFi power is not limited\n");
+ if (!data_pkg) {
+ IWL_DEBUG_INFO(trans,
+ "No element for the WiFi domain returned by the SPLC method.\n");
return 0;
}
- return power_limit->integer.value;
+ dflt_pwr_limit = &data_pkg->package.elements[1];
+ return dflt_pwr_limit->integer.value;
}
static void set_dflt_pwr_limit(struct iwl_trans *trans, struct pci_dev *pdev)
{
acpi_handle pxsx_handle;
acpi_handle handle;
- struct acpi_buffer splx = {ACPI_ALLOCATE_BUFFER, NULL};
+ struct acpi_buffer splc = {ACPI_ALLOCATE_BUFFER, NULL};
acpi_status status;
pxsx_handle = ACPI_HANDLE(&pdev->dev);
@@ -593,23 +609,24 @@ static void set_dflt_pwr_limit(struct iwl_trans *trans, struct pci_dev *pdev)
}
/* Get the method's handle */
- status = acpi_get_handle(pxsx_handle, (acpi_string)SPL_METHOD, &handle);
+ status = acpi_get_handle(pxsx_handle, (acpi_string)ACPI_SPLC_METHOD,
+ &handle);
if (ACPI_FAILURE(status)) {
- IWL_DEBUG_INFO(trans, "SPL method not found\n");
+ IWL_DEBUG_INFO(trans, "SPLC method not found\n");
return;
}
/* Call SPLC with no arguments */
- status = acpi_evaluate_object(handle, NULL, NULL, &splx);
+ status = acpi_evaluate_object(handle, NULL, NULL, &splc);
if (ACPI_FAILURE(status)) {
IWL_ERR(trans, "SPLC invocation failed (0x%x)\n", status);
return;
}
- trans->dflt_pwr_limit = splx_get_pwr_limit(trans, splx.pointer);
+ trans->dflt_pwr_limit = splc_get_pwr_limit(trans, splc.pointer);
IWL_DEBUG_INFO(trans, "Default power limit set to %lld\n",
trans->dflt_pwr_limit);
- kfree(splx.pointer);
+ kfree(splc.pointer);
}
#else /* CONFIG_ACPI */
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] iwlwifi: pcie: reduce "unsupported splx" to a warning
From: Luca Coelho @ 2016-10-13 9:01 UTC (permalink / raw)
To: Chris Rorvick, Paul Bolle
Cc: Intel Linux Wireless, Emmanuel Grumbach, Johannes Berg,
Kalle Valo, Oren Givon, linux-wireless, netdev, linux-kernel
In-Reply-To: <CAEUsAPYYJ3Gmh0T16veCn3wnzdD8bTxE+_U-AUYQpMo3TUd4Mg@mail.gmail.com>
On Wed, 2016-10-12 at 12:50 -0500, Chris Rorvick wrote:
> Hi Luca,
>
> FYI, It seems that Google does not like your email as I'm not
> receiving any of your messages in gmail. Some responses below:
That's odd. It works for me. Replied privately to try to sort this
out.
> On Wed, 2016-10-12 at 15:24 +0300, Luca Coelho wrote:
> > Hi Chris,
> > On Tue, 2016-10-11 at 09:09 -0500, Chris Rorvick wrote:
> > > On Tue, Oct 11, 2016 at 5:11 AM, Paul Bolle <pebolle [at] tiscali> wrote:
> > > > > This is not coming from the NIC itself, but from the platform's ACPI
> > > > > tables. Can you tell us which platform you are using?
> > >
> > >
> > > Interesting. I'm running a Dell XPS 13 9350. I replaced the
> > > factory-provided Broadcom card with an AC 8260. I can update the
> > > commit log to reflect this.
> >
> >
> > Okay, so this makes sense. Those entries are probably formatted for
> > the Broadcom card, which the iwlwifi driver obviously doesn't
> > understand. The best we can do, as I already said, is to ignore values
> > we don't understand.
>
>
> This may already be apparent, but Dell sells two versions of the 9350:
> one with the Broadcom adapter and one with the AC 8260. I just
> happened to find the former version at a deep discount at Costco so
> decided to chance it. Turns out the Broadcom card is not so good even
> with new kernels so I upgraded. Anyway, since Paul is seeing the same
> issue I don't think the values are intended to be Broadcom-specific.
Right, this is not for Broadcom. I found out that this is something
Intel specifies as part of the entire platform's ACPI recommendations.
> On Wed, 2016-10-12 at 17:21 +0300, Luca Coelho wrote:
> > And, the values in the SPLX structs are being changed here, to DOM1,
> > LIM1, TIM1 etc., before being returned. Â This also matches your
> > description that, at runtime, you got something different than the pure
> > dump. Â If you follow these DOM*, LIM*, TIM* symbols, you'll probably
> > end up getting the values you observed at runtime.
>
>
> Probably not important, but it seems that there is some additional
> indirection. The only values I'm seeing associated with those symbols
> are 8 and 16:
>
> $ grep -e 'DOM[0-9]' -e 'LIM[0-9]' -e 'TIM[0-9]' dsdt.dsl | grep -v Store
> DOM1, 8,
> LIM1, 16,
> TIM1, 16,
> DOM2, 8,
> LIM2, 16,
> TIM2, 16,
> DOM3, 8,
> LIM3, 16,
> TIM3, 16,
Yeah, there are often many levels of indirection. These settings can
be also tied to the configuration that is reachable by the user in the
BIOS setup, so you never know.
The easiest way is probably to run the ASL with acpiexec and execute
the method...
> > I'll send you a patch for testing soon.
>
>
> I will keep an eye on the list archive, thanks!
I'll ping you from my Intel address and provide you with a link to the
patch, to make it easier for you. ;)
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCHv4] mac80211: fix A-MSDU outer SA/DA
From: Johannes Berg @ 2016-10-13 7:23 UTC (permalink / raw)
To: Felix Fietkau, Michael Braun; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <fc2ae46b-f049-41de-3eec-465e83b5ecef@nbd.name>
> > + /* h_80211_src/dst is addr* field within hdr */
> > + h_80211_src = data + fast_tx->sa_offs;
> > + h_80211_dst = data + fast_tx->da_offs;
[...]
> > + if (bssid && ieee80211_has_fromds(hdr->frame_control))
> > + memcpy(h_80211_src, bssid, ETH_ALEN);
> > +
> > + if (bssid && ieee80211_has_tods(hdr->frame_control))
> > + memcpy(h_80211_dst, bssid, ETH_ALEN);
> I think this is probably wrong for 4-addr, since there both FromDS
> and ToDS are set. Maybe you should use !ieee80211_has_tods instead of
> ieee80211_has_fromds and vice versa.
It helps to look at the spec ;-)
For 4-addr frames, dest/src are addr 3/4 respectively, and in the spec
both *should* actually be set to the BSSID.
It's kinda pointless to be doing that and using a 4-addr frame here,
but I suppose it would be expected by the receiver in 4-addr mode, so
makes some sense.
johannes
^ permalink raw reply
* Re: [PATCHv4] mac80211: fix A-MSDU outer SA/DA
From: Felix Fietkau @ 2016-10-13 7:19 UTC (permalink / raw)
To: Michael Braun, johannes; +Cc: linux-wireless, projekt-wlan
In-Reply-To: <1476337315-26845-1-git-send-email-michael-dev@fami-braun.de>
On 2016-10-13 07:41, Michael Braun wrote:
> According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer SA/DA
> of A-MSDU frames need to be changed depending on FromDS/ToDS values.
>
> Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
>
> --
> v4:
> - h_80211_src/dst has been memmove'd and thus needs to be fixed
> v3:
> - write to outer 802.11 header instead of inner amsdu subframe header
> v2:
> - avoid the extra write to amsdu_hdr
> - avoid copy of asmdu_hdr into skb, use ptr instead
> ---
> net/mac80211/tx.c | 46 ++++++++++++++++++++++++++++++++++++----------
> 1 file changed, 36 insertions(+), 10 deletions(-)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 5023966..5f80b94 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -3058,19 +3059,44 @@ static bool ieee80211_amsdu_prepare_head(struct ieee80211_sub_if_data *sdata,
> if (info->control.flags & IEEE80211_TX_CTRL_AMSDU)
> return true;
>
> - if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(amsdu_hdr),
> + if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(*amsdu_hdr),
> &subframe_len))
> return false;
>
> - amsdu_hdr.h_proto = cpu_to_be16(subframe_len);
> - memcpy(amsdu_hdr.h_source, skb->data + fast_tx->sa_offs, ETH_ALEN);
> - memcpy(amsdu_hdr.h_dest, skb->data + fast_tx->da_offs, ETH_ALEN);
> + data = skb_push(skb, sizeof(*amsdu_hdr));
> + memmove(data, data + sizeof(*amsdu_hdr), hdr_len);
> + hdr = data;
> + amsdu_hdr = data + hdr_len;
> + /* h_80211_src/dst is addr* field within hdr */
> + h_80211_src = data + fast_tx->sa_offs;
> + h_80211_dst = data + fast_tx->da_offs;
> +
> + amsdu_hdr->h_proto = cpu_to_be16(subframe_len);
> + memcpy(amsdu_hdr->h_source, h_80211_src, ETH_ALEN);
> + memcpy(amsdu_hdr->h_dest, h_80211_dst, ETH_ALEN);
> +
> + /* according to IEEE 802.11-2012 8.3.2 table 8-19, the outer SA/DA
> + * fields needs to be changed to BSSID for A-MSDU frames depending
> + * on FromDS/ToDS values.
> + */
> + switch (sdata->vif.type) {
> + case NL80211_IFTYPE_STATION:
> + bssid = sdata->u.mgd.bssid;
> + break;
> + case NL80211_IFTYPE_AP:
> + case NL80211_IFTYPE_AP_VLAN:
> + bssid = sdata->vif.addr;
> + break;
> + default:
> + bssid = NULL;
> + }
>
> - data = skb_push(skb, sizeof(amsdu_hdr));
> - memmove(data, data + sizeof(amsdu_hdr), hdr_len);
> - memcpy(data + hdr_len, &amsdu_hdr, sizeof(amsdu_hdr));
> + if (bssid && ieee80211_has_fromds(hdr->frame_control))
> + memcpy(h_80211_src, bssid, ETH_ALEN);
> +
> + if (bssid && ieee80211_has_tods(hdr->frame_control))
> + memcpy(h_80211_dst, bssid, ETH_ALEN);
I think this is probably wrong for 4-addr, since there both FromDS and
ToDS are set. Maybe you should use !ieee80211_has_tods instead of
ieee80211_has_fromds and vice versa.
- Felix
^ permalink raw reply
* Re: [PATCHv4] mac80211: fix A-MSDU outer SA/DA
From: Johannes Berg @ 2016-10-13 6:56 UTC (permalink / raw)
To: Michael Braun; +Cc: linux-wireless, projekt-wlan, Felix Fietkau
In-Reply-To: <1476337315-26845-1-git-send-email-michael-dev@fami-braun.de>
Hi,
I think this looks good now. I'd prefer, however, doing the reorg that
gets rid of the memcpy() separately, that's now more or less orthogonal
to the changes you're making. I suspect it's due to you having just
edited the original, rather than starting from scratch, but I think it
makes sense to split it.
> + memcpy(amsdu_hdr->h_source, h_80211_src, ETH_ALEN);
> + memcpy(amsdu_hdr->h_dest, h_80211_dst, ETH_ALEN);
ether_addr_copy()? Alignment should be OK here.
johannes
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Johannes Berg @ 2016-10-13 6:02 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Sergey Senozhatsky, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <CALCETrXg9-OpJx5Rqz8afyaug+0DjzxvpdbOV9q6i01=zCZbcQ@mail.gmail.com>
On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote:
> In a pinch, I have these patches sitting around:
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
That truly sounds like something we'd rather avoid in the TX/RX paths
though, which should perform well.
> I don't like them, though. I think it's rather silly that we can't
> just pass virtual addresses to the crypto code.
I don't really understand it either, hence my question about the actual
crash. I'll try to reproduce it in a VM.
johannes
^ permalink raw reply
* Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)
From: Andy Lutomirski @ 2016-10-13 5:39 UTC (permalink / raw)
To: Johannes Berg
Cc: Sergey Senozhatsky, Andy Lutomirski, David S. Miller,
Linux Wireless List, Network Development,
linux-kernel@vger.kernel.org, Sergey Senozhatsky,
linux-next@vger.kernel.org, Stephen Rothwell, Herbert Xu
In-Reply-To: <1476282127.5271.30.camel@sipsolutions.net>
On Wed, Oct 12, 2016 at 7:22 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
>
>> > Can you elaborate on how exactly it kills your system?
>>
>> the last time I saw it it was a NULL deref at
>> ieee80211_aes_ccm_decrypt.
>
> Hm. I was expecting something within the crypto code would cause the
> crash, this seems strange.
>
> Anyway, I'm surely out of my depth wrt. the actual cause. Something
> like the patch below probably works around it, but it's horribly
> inefficient due to the locking and doesn't cover CMAC/GMAC either.
In a pinch, I have these patches sitting around:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8
I don't like them, though. I think it's rather silly that we can't
just pass virtual addresses to the crypto code.
^ permalink raw reply
* [PATCHv4] mac80211: fix A-MSDU outer SA/DA
From: Michael Braun @ 2016-10-13 5:41 UTC (permalink / raw)
To: johannes; +Cc: Michael Braun, linux-wireless, projekt-wlan, Felix Fietkau
According to IEEE 802.11-2012 section 8.3.2 table 8-19, the outer SA/DA
of A-MSDU frames need to be changed depending on FromDS/ToDS values.
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
--
v4:
- h_80211_src/dst has been memmove'd and thus needs to be fixed
v3:
- write to outer 802.11 header instead of inner amsdu subframe header
v2:
- avoid the extra write to amsdu_hdr
- avoid copy of asmdu_hdr into skb, use ptr instead
---
net/mac80211/tx.c | 46 ++++++++++++++++++++++++++++++++++++----------
1 file changed, 36 insertions(+), 10 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 5023966..5f80b94 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -3046,11 +3046,12 @@ static bool ieee80211_amsdu_prepare_head(struct ieee80211_sub_if_data *sdata,
struct ieee80211_local *local = sdata->local;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr;
- struct ethhdr amsdu_hdr;
+ struct ethhdr *amsdu_hdr;
int hdr_len = fast_tx->hdr_len - sizeof(rfc1042_header);
int subframe_len = skb->len - hdr_len;
void *data;
- u8 *qc;
+ u8 *qc, *h_80211_src, *h_80211_dst;
+ const u8 *bssid;
if (info->flags & IEEE80211_TX_CTL_RATE_CTRL_PROBE)
return false;
@@ -3058,19 +3059,44 @@ static bool ieee80211_amsdu_prepare_head(struct ieee80211_sub_if_data *sdata,
if (info->control.flags & IEEE80211_TX_CTRL_AMSDU)
return true;
- if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(amsdu_hdr),
+ if (!ieee80211_amsdu_realloc_pad(local, skb, sizeof(*amsdu_hdr),
&subframe_len))
return false;
- amsdu_hdr.h_proto = cpu_to_be16(subframe_len);
- memcpy(amsdu_hdr.h_source, skb->data + fast_tx->sa_offs, ETH_ALEN);
- memcpy(amsdu_hdr.h_dest, skb->data + fast_tx->da_offs, ETH_ALEN);
+ data = skb_push(skb, sizeof(*amsdu_hdr));
+ memmove(data, data + sizeof(*amsdu_hdr), hdr_len);
+ hdr = data;
+ amsdu_hdr = data + hdr_len;
+ /* h_80211_src/dst is addr* field within hdr */
+ h_80211_src = data + fast_tx->sa_offs;
+ h_80211_dst = data + fast_tx->da_offs;
+
+ amsdu_hdr->h_proto = cpu_to_be16(subframe_len);
+ memcpy(amsdu_hdr->h_source, h_80211_src, ETH_ALEN);
+ memcpy(amsdu_hdr->h_dest, h_80211_dst, ETH_ALEN);
+
+ /* according to IEEE 802.11-2012 8.3.2 table 8-19, the outer SA/DA
+ * fields needs to be changed to BSSID for A-MSDU frames depending
+ * on FromDS/ToDS values.
+ */
+ switch (sdata->vif.type) {
+ case NL80211_IFTYPE_STATION:
+ bssid = sdata->u.mgd.bssid;
+ break;
+ case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_AP_VLAN:
+ bssid = sdata->vif.addr;
+ break;
+ default:
+ bssid = NULL;
+ }
- data = skb_push(skb, sizeof(amsdu_hdr));
- memmove(data, data + sizeof(amsdu_hdr), hdr_len);
- memcpy(data + hdr_len, &amsdu_hdr, sizeof(amsdu_hdr));
+ if (bssid && ieee80211_has_fromds(hdr->frame_control))
+ memcpy(h_80211_src, bssid, ETH_ALEN);
+
+ if (bssid && ieee80211_has_tods(hdr->frame_control))
+ memcpy(h_80211_dst, bssid, ETH_ALEN);
- hdr = data;
qc = ieee80211_get_qos_ctl(hdr);
*qc |= IEEE80211_QOS_CTL_A_MSDU_PRESENT;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] ath6k1: add Dell OEM SDIO I/O for the Venue 8 Pro
From: Kalle Valo @ 2016-10-13 4:50 UTC (permalink / raw)
To: Steve deRosier; +Cc: Alan, linux-wireless
In-Reply-To: <CALupW3D2dsTeixs3z+e9JC_D2D_Bd_AHquHKttCf17OhMqEFUg@mail.gmail.com>
Steve deRosier <derosier@gmail.com> writes:
> Sorry to quibble, but the subsystem label on the commit subject line
> should be "ath6kl:" it's a lower-case "L", not a one.
Heh, I missed that :) I can fix it before I commit.
>> --- a/drivers/net/wireless/ath/ath6kl/sdio.c
>> +++ b/drivers/net/wireless/ath/ath6kl/sdio.c
>> @@ -1401,6 +1401,7 @@ static const struct sdio_device_id ath6kl_sdio_devices[] = {
>> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x0))},
>> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x1))},
>> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x2))},
>> + {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x18))},
>> {},
>> };
>>
>>
>
> I see nothing wrong with this if the chip does indeed identify itself
> this way. So please fix the subject and you can add:
>
> Reviewed-by: Steve deRosier <steve.derosier@lairdtech.com>
Thanks.
--
Kalle Valo
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-10-12 22:50 UTC (permalink / raw)
To: Arend Van Spriel
Cc: brcm80211-dev-list, Brett Rudley, Franky Lin, Hante Meuleman,
linux-wireless, Franky Lin, Arend van Spriel
In-Reply-To: <CAF7Mx6pD5VZ57PHy5DSj8yLOLY4vir2JhEdEL8SB3kr91OqFsQ@mail.gmail.com>
On Thu, 2016-10-13 at 00:25 +0200, Arend Van Spriel wrote:
> Op 12 okt. 2016 23:19 schreef "Jörg Krause" <joerg.krause@embedded.ro
> cks>:
> >
> > On Wed, 2016-10-12 at 23:08 +0200, Arend Van Spriel wrote:
> > > Op 12 okt. 2016 21:30 schreef "Jörg Krause" <joerg.krause@embedde
> > > d.ro
> > > cks>:
> > > >
> > > > On Mi, 2016-10-12 at 21:08 +0200, Arend van Spriel wrote:
> > > >
> > > > [snip]
> > > >
> > > > > On 12-10-16 16:27, Jörg Krause wrote:
> > > > > >
> > > > > > It is running the iperf server. It is running in station
> > > > > > mode
> > > > > > as
> > > > > > well
> > > > > > as in AP mode, depending on the use case. The wireshark
> > > > > > dump
> > > > > > was
> > > > > > taken
> > > > > > when the bcm43362 is operating in AP mode.
> > > > > >
> > > > > > >
> > > > > > > What specs does the ARM on your custom board have?
> > > > > >
> > > > > > Which specs do you mean?
> > > > > >
> > > > > > >
> > > > > > > The trace shows that it does not do
> > > > > > > aggregation. What it does not show is whether A-MPDU was
> > > > > > > setup,
> > > > > > > ie.
> > > > > > > ADDBA message exchange. So could you create a similar
> > > > > > > capture
> > > > > > > including
> > > > > > > connection setup, ie. AUTH/ASSOC, etc.
> > > > > >
> > > > > > Yes, I can do that. Note, that I am using wpa_supplicant
> > > > > > 2.5
> > > > > > for AP
> > > > > > mode operation (not hostapd).
> > > > >
> > > > > ok. unchartered territory for me. In the beacon frame I see
> > > > >
> > > > > .... ..01 = Maximum Rx A-MPDU Length: 0x1 (16383[Bytes])
> > > > > ...1 10.. = MPDU Density: 8 [usec] (0x6)
> > > > >
> > > > > In the trace it is only ~1500 bytes so no A-MPDU.
> > > >
> > > > The issue is not only valid for operating the BCM43362 in AP
> > > > mode,
> > > > but
> > > > also in station mode. The TCP throughput is the same for both
> > > > modes.
> > > >
> > > > > What device is in the notebook?
> > > >
> > > > It is a Broadcom 43225. However, the low TCP throughput is not
> > > > specific
> > > > to this device but with all kind of devices including
> > > > Smartphones,
> > > > Notebooks, PCs running the iperf client.
> > > >
> > > > > Can you use 'iw list' there to obtain info.
> > > >
> > > > $ iw list
> > > > Wiphy phy0
> > > > max # scan SSIDs: 4
> > > > max scan IEs length: 2257 bytes
> > > > max # sched scan SSIDs: 0
> > > > max # match sets: 0
> > > > max # scan plans: 1
> > > > max scan plan interval: -1
> > > > max scan plan iterations: 0
> > > > Retry short limit: 7
> > > > Retry long limit: 4
> > > > Coverage class: 0 (up to 0m)
> > > > Device supports RSN-IBSS.
> > > > Supported Ciphers:
> > > > * WEP40 (00-0f-ac:1)
> > > > * WEP104 (00-0f-ac:5)
> > > > * TKIP (00-0f-ac:2)
> > > > * CCMP (00-0f-ac:4)
> > > > * 00-0f-ac:10
> > > > * GCMP (00-0f-ac:8)
> > > > * 00-0f-ac:9
> > > > Available Antennas: TX 0 RX 0
> > > > Supported interface modes:
> > > > * IBSS
> > > > * managed
> > > > * AP
> > > > * AP/VLAN
> > > > * monitor
> > > > Band 1:
> > > > Capabilities: 0x70
> > > > HT20
> > > > Static SM Power Save
> > > > RX Greenfield
> > > > RX HT20 SGI
> > > > RX HT40 SGI
> > > > No RX STBC
> > > > Max AMSDU length: 3839 bytes
> > > > No DSSS/CCK HT40
> > > > Maximum RX AMPDU length 65535 bytes
> > > > (exponent:
> > > > 0x003)
> > > > Minimum RX AMPDU time spacing: 8 usec
> > > > (0x06)
> > > > HT Max RX data rate: 500 Mbps
> > > > HT TX/RX MCS rate indexes supported: 0-15
> > > > Bitrates (non-HT):
> > > > * 1.0 Mbps
> > > > * 2.0 Mbps (short preamble
> > > > supported)
> > > > * 5.5 Mbps (short preamble
> > > > supported)
> > > > * 11.0 Mbps (short preamble
> > > > supported)
> > > > * 6.0 Mbps
> > > > * 9.0 Mbps
> > > > * 12.0 Mbps
> > > > * 18.0 Mbps
> > > > * 24.0 Mbps
> > > > * 36.0 Mbps
> > > > * 48.0 Mbps
> > > > * 54.0 Mbps
> > > > Frequencies:
> > > > * 2412 MHz [1] (19.0 dBm)
> > > > * 2417 MHz [2] (19.0 dBm)
> > > > * 2422 MHz [3] (19.0 dBm)
> > > > * 2427 MHz [4] (19.0 dBm)
> > > > * 2432 MHz [5] (19.0 dBm)
> > > > * 2437 MHz [6] (19.0 dBm)
> > > > * 2442 MHz [7] (19.0 dBm)
> > > > * 2447 MHz [8] (19.0 dBm)
> > > > * 2452 MHz [9] (19.0 dBm)
> > > > * 2457 MHz [10] (19.0 dBm)
> > > > * 2462 MHz [11] (19.0 dBm)
> > > > * 2467 MHz [12] (19.0 dBm) (no IR)
> > > > * 2472 MHz [13] (19.0 dBm) (no IR)
> > > > * 2484 MHz [14] (disabled)
> > > > Supported commands:
> > > > * new_interface
> > > > * set_interface
> > > > * new_key
> > > > * start_ap
> > > > * new_station
> > > > * new_mpath
> > > > * set_mesh_config
> > > > * set_bss
> > > > * authenticate
> > > > * associate
> > > > * deauthenticate
> > > > * disassociate
> > > > * join_ibss
> > > > * join_mesh
> > > > * set_tx_bitrate_mask
> > > > * frame
> > > > * frame_wait_cancel
> > > > * set_wiphy_netns
> > > > * set_channel
> > > > * set_wds_peer
> > > > * probe_client
> > > > * set_noack_map
> > > > * register_beacons
> > > > * start_p2p_device
> > > > * set_mcast_rate
> > > > * set_qos_map
> > > > * connect
> > > > * disconnect
> > > > Supported TX frame types:
> > > > * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60
> > > > 0x70 0x80
> > > > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * managed: 0x00 0x10 0x20 0x30 0x40 0x50
> > > > 0x60
> > > > 0x70
> > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60
> > > > 0x70
> > > > 0x80
> > > > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50
> > > > 0x60
> > > > 0x70
> > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * mesh point: 0x00 0x10 0x20 0x30 0x40
> > > > 0x50
> > > > 0x60 0x70
> > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * P2P-client: 0x00 0x10 0x20 0x30 0x40
> > > > 0x50
> > > > 0x60 0x70
> > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50
> > > > 0x60
> > > > 0x70
> > >
> > > 0x80
> > > > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > * P2P-device: 0x00 0x10 0x20 0x30 0x40
> > > > 0x50
> > > > 0x60 0x70
> > > > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > > > Supported RX frame types:
> > > > * IBSS: 0x40 0xb0 0xc0 0xd0
> > > > * managed: 0x40 0xd0
> > > > * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
> > > > * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0
> > > > 0xd0
> > > > * mesh point: 0xb0 0xc0 0xd0
> > > > * P2P-client: 0x40 0xd0
> > > > * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0
> > > > 0xd0
> > > > * P2P-device: 0x40 0xd0
> > > > software interface modes (can always be added):
> > > > * AP/VLAN
> > > > * monitor
> > > > interface combinations are not supported
> > > > HT Capability overrides:
> > > > * MCS: ff ff ff ff ff ff ff ff ff ff
> > > > * maximum A-MSDU length
> > > > * supported channel width
> > > > * short GI for 40 MHz
> > > > * max A-MPDU length exponent
> > > > * min MPDU start spacing
> > > > Device supports TX status socket option.
> > > > Device supports HT-IBSS.
> > > > Device supports SAE with AUTHENTICATE command
> > > > Device supports low priority scan.
> > > > Device supports scan flush.
> > > > Device supports AP scan.
> > > > Device supports per-vif TX power setting
> > > > Driver supports a userspace MPM
> > > > Device supports configuring vdev MAC-addr on
> > > > create.
> > > >
> > > > > >
> > > > > > >
> > > > > > > Just to confirm. You are using the firmware from linux-
> > > > > > > firmware,
> > > > > > > right?
> > > > > >
> > > > > > Right.
> > > > > >
> > > > > > >
> > > > > > > Or are you using firmware from the wiced dev kit?
> > > > > >
> > > > > > No. I guess you mean bcmdhd?
> > > > >
> > > > > You referred to 20 Mbps claim on wiced dev kit page at mouser
> > > > > so
> > > > > I
> > > > > assumed you were using that and it includes firmware. As you
> > > > > confirmed
> > > > > using firmware from linux-firmware repo this question does
> > > > > not
> > > > > matter.
> > > >
> > > > I see! Note, that I measured >20MB throughput on the
> > > > Cubietruck,
> > > > which
> > > > is using the AP6210, but also the brcmfmac driver.
> > >
> > > So does your custom ARM board have an Ethernet socket, ie. run
> > > iperf
> > > server
> > > on another device hooked up to the AP over Ethernet.
> >
> > Yes, it does have Ethernet. I hope that I have understand you
> > correctly, so I run an iperf server an my PC and on my ARM board
> > the
> > iperf client. Both devices are connected via Ethernet to the Router
> > (using a Powerline adaptor):
> >
> > # iperf3 -c 192.168.178.41 -i 1 -t 10
> > Connecting to host 192.168.178.41, port 5201
> > [ 4] local 192.168.178.40 port 36130 connected to 192.168.178.41
> > port
> > 5201
> > [ ID] Interval Transfer Bandwidth Retr Cwnd
> > [ 4] 0.00-1.09 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 1.09-2.21 sec 2.50 MBytes 18.8 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 2.21-3.30 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 3.30-4.39 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 4.39-5.48 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 5.48-6.02 sec 1.25 MBytes 19.3 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 6.02-7.11 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 7.11-8.20 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 8.20-9.43 sec 2.50 MBytes 17.1 Mbits/sec 0 14.1
> > KBytes
> > [ 4] 9.43-10.51 sec 2.50 MBytes 19.4 Mbits/sec 0 14.1
> > KBytes
> > - - - - - - - - - - - - - - - - - - - - - - - - -
> > [ ID] Interval Transfer Bandwidth Retr
> > [ 4] 0.00-10.51 sec 23.8 MBytes 19.0
> > Mbits/sec 0 sender
> > [ 4] 0.00-10.51 sec 23.8 MBytes 19.0
> > Mbits/sec receiver
> >
> > iperf Done.
>
> Sorry. I meant not running iperf server nor client on AP. A bit more
> graphic:
>
> Notebook --> AP --> PC
>
> Iperf client on notebook and iperf server on PC. Notebook to AP is
> wireless, AP to PC is wired.
I see! Howver, this needs routing on the AP, which I have not done yet.
What do you expect from this test?
I compared the values from the Ethernet test with an Application Note
[1] I found at NXP for the i.MX28. Running iperf shows an throughput of
>60 MBits/sec. I run the test cases again without Powerline adapter by
connecting both devices directly to the Router and even installed iperf
(instead of iperf3). Nevertheless, I am stuck with 20 MBits/sec. Note,
that the Application Note was done with a legacy Linux Kernel 2.6
whereas I use mainline Linux Kernel 4.7. Maybe something is missing in
mainline?
For now, I will consider that brcmfmac is not responsible for the low
throughput and I will move this issue to the ARM linux mailing list.
Many thanks so far for the support! I will keep you in the loop.
[1] http://cache.freescale.com/files/32bit/doc/app_note/AN4544.pdf
Best regards
Jörg Krause
^ permalink raw reply
* Re: [PATCH] ath6k1: add Dell OEM SDIO I/O for the Venue 8 Pro
From: Steve deRosier @ 2016-10-12 21:32 UTC (permalink / raw)
To: Alan; +Cc: linux-wireless
In-Reply-To: <147629570687.26062.4786752681864367162.stgit@localhost.localdomain>
Hi Alan,
Sorry to quibble, but the subsystem label on the commit subject line
should be "ath6kl:" it's a lower-case "L", not a one.
On Wed, Oct 12, 2016 at 11:08 AM, Alan <alan@linux.intel.com> wrote:
> From: Adam Williamson <adamw@happyassassin.net>
>
> SDIO ID 0271:0418
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> Bugzilla-ID: https://bugzilla.kernel.org/show_bug.cgi?id=67921
>
> diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c b/drivers/net/wireless/ath/ath6kl/sdio.c
> index eab0ab9..76eb336 100644
> --- a/drivers/net/wireless/ath/ath6kl/sdio.c
> +++ b/drivers/net/wireless/ath/ath6kl/sdio.c
> @@ -1401,6 +1401,7 @@ static const struct sdio_device_id ath6kl_sdio_devices[] = {
> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x0))},
> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x1))},
> {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x2))},
> + {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x18))},
> {},
> };
>
>
I see nothing wrong with this if the chip does indeed identify itself
this way. So please fix the subject and you can add:
Reviewed-by: Steve deRosier <steve.derosier@lairdtech.com>
- Steve
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-10-12 21:19 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Franky Lin, Brett Rudley, brcm80211-dev-list, Hante Meuleman,
Franky Lin, linux-wireless, Arend van Spriel
In-Reply-To: <CAF7Mx6rqfbhDL-MRZ93vzCdSskgqi_bVNn=1SGb_WKV=DZZ+YQ@mail.gmail.com>
On Wed, 2016-10-12 at 23:08 +0200, Arend Van Spriel wrote:
> Op 12 okt. 2016 21:30 schreef "Jörg Krause" <joerg.krause@embedded.ro
> cks>:
> >
> > On Mi, 2016-10-12 at 21:08 +0200, Arend van Spriel wrote:
> >
> > [snip]
> >
> > > On 12-10-16 16:27, Jörg Krause wrote:
> > > >
> > > > It is running the iperf server. It is running in station mode
> > > > as
> > > > well
> > > > as in AP mode, depending on the use case. The wireshark dump
> > > > was
> > > > taken
> > > > when the bcm43362 is operating in AP mode.
> > > >
> > > > >
> > > > > What specs does the ARM on your custom board have?
> > > >
> > > > Which specs do you mean?
> > > >
> > > > >
> > > > > The trace shows that it does not do
> > > > > aggregation. What it does not show is whether A-MPDU was
> > > > > setup,
> > > > > ie.
> > > > > ADDBA message exchange. So could you create a similar capture
> > > > > including
> > > > > connection setup, ie. AUTH/ASSOC, etc.
> > > >
> > > > Yes, I can do that. Note, that I am using wpa_supplicant 2.5
> > > > for AP
> > > > mode operation (not hostapd).
> > >
> > > ok. unchartered territory for me. In the beacon frame I see
> > >
> > > .... ..01 = Maximum Rx A-MPDU Length: 0x1 (16383[Bytes])
> > > ...1 10.. = MPDU Density: 8 [usec] (0x6)
> > >
> > > In the trace it is only ~1500 bytes so no A-MPDU.
> >
> > The issue is not only valid for operating the BCM43362 in AP mode,
> > but
> > also in station mode. The TCP throughput is the same for both
> > modes.
> >
> > > What device is in the notebook?
> >
> > It is a Broadcom 43225. However, the low TCP throughput is not
> > specific
> > to this device but with all kind of devices including Smartphones,
> > Notebooks, PCs running the iperf client.
> >
> > > Can you use 'iw list' there to obtain info.
> >
> > $ iw list
> > Wiphy phy0
> > max # scan SSIDs: 4
> > max scan IEs length: 2257 bytes
> > max # sched scan SSIDs: 0
> > max # match sets: 0
> > max # scan plans: 1
> > max scan plan interval: -1
> > max scan plan iterations: 0
> > Retry short limit: 7
> > Retry long limit: 4
> > Coverage class: 0 (up to 0m)
> > Device supports RSN-IBSS.
> > Supported Ciphers:
> > * WEP40 (00-0f-ac:1)
> > * WEP104 (00-0f-ac:5)
> > * TKIP (00-0f-ac:2)
> > * CCMP (00-0f-ac:4)
> > * 00-0f-ac:10
> > * GCMP (00-0f-ac:8)
> > * 00-0f-ac:9
> > Available Antennas: TX 0 RX 0
> > Supported interface modes:
> > * IBSS
> > * managed
> > * AP
> > * AP/VLAN
> > * monitor
> > Band 1:
> > Capabilities: 0x70
> > HT20
> > Static SM Power Save
> > RX Greenfield
> > RX HT20 SGI
> > RX HT40 SGI
> > No RX STBC
> > Max AMSDU length: 3839 bytes
> > No DSSS/CCK HT40
> > Maximum RX AMPDU length 65535 bytes (exponent:
> > 0x003)
> > Minimum RX AMPDU time spacing: 8 usec (0x06)
> > HT Max RX data rate: 500 Mbps
> > HT TX/RX MCS rate indexes supported: 0-15
> > Bitrates (non-HT):
> > * 1.0 Mbps
> > * 2.0 Mbps (short preamble supported)
> > * 5.5 Mbps (short preamble supported)
> > * 11.0 Mbps (short preamble supported)
> > * 6.0 Mbps
> > * 9.0 Mbps
> > * 12.0 Mbps
> > * 18.0 Mbps
> > * 24.0 Mbps
> > * 36.0 Mbps
> > * 48.0 Mbps
> > * 54.0 Mbps
> > Frequencies:
> > * 2412 MHz [1] (19.0 dBm)
> > * 2417 MHz [2] (19.0 dBm)
> > * 2422 MHz [3] (19.0 dBm)
> > * 2427 MHz [4] (19.0 dBm)
> > * 2432 MHz [5] (19.0 dBm)
> > * 2437 MHz [6] (19.0 dBm)
> > * 2442 MHz [7] (19.0 dBm)
> > * 2447 MHz [8] (19.0 dBm)
> > * 2452 MHz [9] (19.0 dBm)
> > * 2457 MHz [10] (19.0 dBm)
> > * 2462 MHz [11] (19.0 dBm)
> > * 2467 MHz [12] (19.0 dBm) (no IR)
> > * 2472 MHz [13] (19.0 dBm) (no IR)
> > * 2484 MHz [14] (disabled)
> > Supported commands:
> > * new_interface
> > * set_interface
> > * new_key
> > * start_ap
> > * new_station
> > * new_mpath
> > * set_mesh_config
> > * set_bss
> > * authenticate
> > * associate
> > * deauthenticate
> > * disassociate
> > * join_ibss
> > * join_mesh
> > * set_tx_bitrate_mask
> > * frame
> > * frame_wait_cancel
> > * set_wiphy_netns
> > * set_channel
> > * set_wds_peer
> > * probe_client
> > * set_noack_map
> > * register_beacons
> > * start_p2p_device
> > * set_mcast_rate
> > * set_qos_map
> > * connect
> > * disconnect
> > Supported TX frame types:
> > * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60
> > 0x70 0x80
> > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60
> > 0x70
> > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70
> > 0x80
> > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60
> > 0x70
> > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50
> > 0x60 0x70
> > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50
> > 0x60 0x70
> > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60
> > 0x70
>
> 0x80
> > 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50
> > 0x60 0x70
> > 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
> > Supported RX frame types:
> > * IBSS: 0x40 0xb0 0xc0 0xd0
> > * managed: 0x40 0xd0
> > * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
> > * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
> > * mesh point: 0xb0 0xc0 0xd0
> > * P2P-client: 0x40 0xd0
> > * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
> > * P2P-device: 0x40 0xd0
> > software interface modes (can always be added):
> > * AP/VLAN
> > * monitor
> > interface combinations are not supported
> > HT Capability overrides:
> > * MCS: ff ff ff ff ff ff ff ff ff ff
> > * maximum A-MSDU length
> > * supported channel width
> > * short GI for 40 MHz
> > * max A-MPDU length exponent
> > * min MPDU start spacing
> > Device supports TX status socket option.
> > Device supports HT-IBSS.
> > Device supports SAE with AUTHENTICATE command
> > Device supports low priority scan.
> > Device supports scan flush.
> > Device supports AP scan.
> > Device supports per-vif TX power setting
> > Driver supports a userspace MPM
> > Device supports configuring vdev MAC-addr on create.
> >
> > > >
> > > > >
> > > > > Just to confirm. You are using the firmware from linux-
> > > > > firmware,
> > > > > right?
> > > >
> > > > Right.
> > > >
> > > > >
> > > > > Or are you using firmware from the wiced dev kit?
> > > >
> > > > No. I guess you mean bcmdhd?
> > >
> > > You referred to 20 Mbps claim on wiced dev kit page at mouser so
> > > I
> > > assumed you were using that and it includes firmware. As you
> > > confirmed
> > > using firmware from linux-firmware repo this question does not
> > > matter.
> >
> > I see! Note, that I measured >20MB throughput on the Cubietruck,
> > which
> > is using the AP6210, but also the brcmfmac driver.
>
> So does your custom ARM board have an Ethernet socket, ie. run iperf
> server
> on another device hooked up to the AP over Ethernet.
Yes, it does have Ethernet. I hope that I have understand you
correctly, so I run an iperf server an my PC and on my ARM board the
iperf client. Both devices are connected via Ethernet to the Router
(using a Powerline adaptor):
# iperf3 -c 192.168.178.41 -i 1 -t 10
Connecting to host 192.168.178.41, port 5201
[ 4] local 192.168.178.40 port 36130 connected to 192.168.178.41 port
5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.09 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1
KBytes
[ 4] 1.09-2.21 sec 2.50 MBytes 18.8 Mbits/sec 0 14.1
KBytes
[ 4] 2.21-3.30 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1
KBytes
[ 4] 3.30-4.39 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1
KBytes
[ 4] 4.39-5.48 sec 2.50 MBytes 19.2 Mbits/sec 0 14.1
KBytes
[ 4] 5.48-6.02 sec 1.25 MBytes 19.3 Mbits/sec 0 14.1
KBytes
[ 4] 6.02-7.11 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1
KBytes
[ 4] 7.11-8.20 sec 2.50 MBytes 19.3 Mbits/sec 0 14.1
KBytes
[ 4] 8.20-9.43 sec 2.50 MBytes 17.1 Mbits/sec 0 14.1
KBytes
[ 4] 9.43-10.51 sec 2.50 MBytes 19.4 Mbits/sec 0 14.1
KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.51 sec 23.8 MBytes 19.0
Mbits/sec 0 sender
[ 4] 0.00-10.51 sec 23.8 MBytes 19.0
Mbits/sec receiver
iperf Done.
Best regards
Jörg Krause
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox