* [v2 2/3] rsi: sdio: Add WOWLAN support for S4 hibernate state
From: Amitkumar Karwar @ 2017-10-25 13:44 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi,
Karun Eagalapati
From: Karun Eagalapati <karun256@gmail.com>
We are disabling of interrupts from firmware in freeze handler.
Also setting power management capability KEEP_MMC_POWER to make
device wakeup for WoWLAN trigger.
At restore, we observed a device reset on some platforms. Hence
reloading of firmware and device initialization is performed.
Signed-off-by: Karun Eagalapati <karun256@gmail.com>
Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
---
drivers/net/wireless/rsi/rsi_91x_core.c | 2 +
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 9 +++
drivers/net/wireless/rsi/rsi_91x_main.c | 1 +
drivers/net/wireless/rsi/rsi_91x_mgmt.c | 7 +-
drivers/net/wireless/rsi/rsi_91x_sdio.c | 111 ++++++++++++++++++++++++++++
drivers/net/wireless/rsi/rsi_main.h | 4 +
drivers/net/wireless/rsi/rsi_sdio.h | 1 +
7 files changed, 134 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_core.c b/drivers/net/wireless/rsi/rsi_91x_core.c
index 87e023d..d0d2201 100644
--- a/drivers/net/wireless/rsi/rsi_91x_core.c
+++ b/drivers/net/wireless/rsi/rsi_91x_core.c
@@ -276,6 +276,8 @@ void rsi_core_qos_processor(struct rsi_common *common)
rsi_dbg(DATA_TX_ZONE, "%s: No More Pkt\n", __func__);
break;
}
+ if (common->hibernate_resume)
+ break;
mutex_lock(&common->tx_lock);
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index 2bcf412..8be24b1 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -17,6 +17,7 @@
#include <linux/etherdevice.h>
#include "rsi_debugfs.h"
#include "rsi_mgmt.h"
+#include "rsi_sdio.h"
#include "rsi_common.h"
#include "rsi_ps.h"
@@ -325,6 +326,11 @@ static int rsi_mac80211_start(struct ieee80211_hw *hw)
rsi_dbg(ERR_ZONE, "===> Interface UP <===\n");
mutex_lock(&common->mutex);
+ if (common->hibernate_resume) {
+ common->reinit_hw = true;
+ adapter->host_intf_ops->reinit_device(adapter);
+ wait_for_completion(&adapter->priv->wlan_init_completion);
+ }
common->iface_down = false;
wiphy_rfkill_start_polling(hw->wiphy);
rsi_send_rx_filter_frame(common, 0);
@@ -1846,6 +1852,9 @@ static int rsi_mac80211_resume(struct ieee80211_hw *hw)
rsi_dbg(INFO_ZONE, "%s: mac80211 resume\n", __func__);
+ if (common->hibernate_resume)
+ return 0;
+
mutex_lock(&common->mutex);
rsi_send_wowlan_request(common, 0, 0);
diff --git a/drivers/net/wireless/rsi/rsi_91x_main.c b/drivers/net/wireless/rsi/rsi_91x_main.c
index 71b8cfb..2d19733 100644
--- a/drivers/net/wireless/rsi/rsi_91x_main.c
+++ b/drivers/net/wireless/rsi/rsi_91x_main.c
@@ -265,6 +265,7 @@ struct rsi_hw *rsi_91x_init(void)
common->roc_timer.data = (unsigned long)common;
common->roc_timer.function = (void *)&rsi_roc_timeout;
init_timer(&common->roc_timer);
+ init_completion(&common->wlan_init_completion);
common->init_done = true;
return adapter;
diff --git a/drivers/net/wireless/rsi/rsi_91x_mgmt.c b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
index 1446ee3..d38a09f 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mgmt.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mgmt.c
@@ -1761,7 +1761,11 @@ static int rsi_handle_ta_confirm_type(struct rsi_common *common,
common->bb_rf_prog_count--;
if (!common->bb_rf_prog_count) {
common->fsm_state = FSM_MAC_INIT_DONE;
- return rsi_mac80211_attach(common);
+ if (common->reinit_hw) {
+ complete(&common->wlan_init_completion);
+ } else {
+ return rsi_mac80211_attach(common);
+ }
}
} else {
rsi_dbg(INFO_ZONE,
@@ -1839,6 +1843,7 @@ int rsi_mgmt_pkt_recv(struct rsi_common *common, u8 *msg)
case TA_CONFIRM_TYPE:
return rsi_handle_ta_confirm_type(common, msg);
case CARD_READY_IND:
+ common->hibernate_resume = false;
rsi_dbg(FSM_ZONE, "%s: Card ready indication received\n",
__func__);
return rsi_handle_card_ready(common, msg);
diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c
index fa6af7b..3f683d8 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
@@ -880,6 +880,7 @@ static struct rsi_host_intf_ops sdio_host_intf_ops = {
.master_reg_read = rsi_sdio_master_reg_read,
.master_reg_write = rsi_sdio_master_reg_write,
.load_data_master_write = rsi_sdio_load_data_master_write,
+ .reinit_device = rsi_sdio_reinit_device,
};
/**
@@ -936,6 +937,8 @@ static int rsi_probe(struct sdio_func *pfunction,
return -EIO;
}
+ adapter->priv->hibernate_resume = false;
+ adapter->priv->reinit_hw = false;
return 0;
fail:
rsi_91x_deinit(adapter);
@@ -1198,9 +1201,117 @@ static int rsi_resume(struct device *dev)
return 0;
}
+static int rsi_freeze(struct device *dev)
+{
+ int ret;
+ struct sdio_func *pfunction = dev_to_sdio_func(dev);
+ struct rsi_hw *adapter = sdio_get_drvdata(pfunction);
+ struct rsi_common *common;
+ struct rsi_91x_sdiodev *sdev;
+
+ rsi_dbg(INFO_ZONE, "SDIO Bus freeze ===>\n");
+
+ if (!adapter) {
+ rsi_dbg(ERR_ZONE, "Device is not ready\n");
+ return -ENODEV;
+ }
+ common = adapter->priv;
+ sdev = (struct rsi_91x_sdiodev *)adapter->rsi_dev;
+
+#ifdef CONFIG_RSI_WOW
+ if ((common->wow_flags & RSI_WOW_ENABLED) &&
+ (common->wow_flags & RSI_WOW_NO_CONNECTION))
+ rsi_dbg(ERR_ZONE,
+ "##### Device can not wake up through WLAN\n");
+#endif
+ ret = rsi_sdio_disable_interrupts(pfunction);
+
+ if (sdev->write_fail)
+ rsi_dbg(INFO_ZONE, "###### Device is not ready #######\n");
+
+ ret = rsi_set_sdio_pm_caps(adapter);
+ if (ret)
+ rsi_dbg(INFO_ZONE, "Setting power management caps failed\n");
+
+ rsi_dbg(INFO_ZONE, "***** RSI module freezed *****\n");
+
+ return 0;
+}
+
+static int rsi_thaw(struct device *dev)
+{
+ struct sdio_func *pfunction = dev_to_sdio_func(dev);
+ struct rsi_hw *adapter = sdio_get_drvdata(pfunction);
+ struct rsi_common *common = adapter->priv;
+
+ rsi_dbg(ERR_ZONE, "SDIO Bus thaw =====>\n");
+
+ common->hibernate_resume = true;
+ common->fsm_state = FSM_CARD_NOT_READY;
+ common->iface_down = true;
+
+ rsi_sdio_enable_interrupts(pfunction);
+
+ rsi_dbg(INFO_ZONE, "***** RSI module thaw done *****\n");
+
+ return 0;
+}
+
+int rsi_sdio_reinit_device(struct rsi_hw *adapter)
+{
+ struct rsi_91x_sdiodev *sdev = adapter->rsi_dev;
+ struct sdio_func *pfunction = sdev->pfunction;
+ int ii;
+
+ for (ii = 0; ii < NUM_SOFT_QUEUES; ii++)
+ skb_queue_purge(&adapter->priv->tx_queue[ii]);
+
+ /* Initialize device again */
+ sdio_claim_host(pfunction);
+
+ sdio_release_irq(pfunction);
+ rsi_reset_card(pfunction);
+
+ sdio_enable_func(pfunction);
+ rsi_setupcard(adapter);
+ rsi_init_sdio_slave_regs(adapter);
+ sdio_claim_irq(pfunction, rsi_handle_interrupt);
+ rsi_hal_device_init(adapter);
+
+ sdio_release_host(pfunction);
+
+ return 0;
+}
+
+static int rsi_restore(struct device *dev)
+{
+ struct sdio_func *pfunction = dev_to_sdio_func(dev);
+ struct rsi_hw *adapter = sdio_get_drvdata(pfunction);
+ struct rsi_common *common = adapter->priv;
+
+ rsi_dbg(INFO_ZONE, "SDIO Bus restore ======>\n");
+ common->hibernate_resume = true;
+ common->fsm_state = FSM_FW_NOT_LOADED;
+ common->iface_down = true;
+
+ adapter->sc_nvifs = 0;
+ ieee80211_restart_hw(adapter->hw);
+
+#ifdef CONFIG_RSI_WOW
+ common->wow_flags = 0;
+#endif
+ common->iface_down = false;
+
+ rsi_dbg(INFO_ZONE, "RSI module restored\n");
+
+ return 0;
+}
static const struct dev_pm_ops rsi_pm_ops = {
.suspend = rsi_suspend,
.resume = rsi_resume,
+ .freeze = rsi_freeze,
+ .thaw = rsi_thaw,
+ .restore = rsi_restore,
};
#endif
diff --git a/drivers/net/wireless/rsi/rsi_main.h b/drivers/net/wireless/rsi/rsi_main.h
index 44a199f..8cab630 100644
--- a/drivers/net/wireless/rsi/rsi_main.h
+++ b/drivers/net/wireless/rsi/rsi_main.h
@@ -214,6 +214,7 @@ struct rsi_common {
struct rsi_thread tx_thread;
struct sk_buff_head tx_queue[NUM_EDCA_QUEUES + 2];
+ struct completion wlan_init_completion;
/* Mutex declaration */
struct mutex mutex;
/* Mutex used for tx thread */
@@ -272,6 +273,8 @@ struct rsi_common {
u8 obm_ant_sel_val;
int tx_power;
u8 ant_in_use;
+ bool hibernate_resume;
+ bool reinit_hw;
u8 wow_flags;
u16 beacon_interval;
u8 dtim_cnt;
@@ -362,5 +365,6 @@ struct rsi_host_intf_ops {
int (*load_data_master_write)(struct rsi_hw *adapter, u32 addr,
u32 instructions_size, u16 block_size,
u8 *fw);
+ int (*reinit_device)(struct rsi_hw *adapter);
};
#endif
diff --git a/drivers/net/wireless/rsi/rsi_sdio.h b/drivers/net/wireless/rsi/rsi_sdio.h
index 49c549b..8fbf90e 100644
--- a/drivers/net/wireless/rsi/rsi_sdio.h
+++ b/drivers/net/wireless/rsi/rsi_sdio.h
@@ -131,4 +131,5 @@ int rsi_sdio_master_access_msword(struct rsi_hw *adapter, u16 ms_word);
void rsi_sdio_ack_intr(struct rsi_hw *adapter, u8 int_bit);
int rsi_sdio_determine_event_timeout(struct rsi_hw *adapter);
int rsi_sdio_check_buffer_status(struct rsi_hw *adapter, u8 q_num);
+int rsi_sdio_reinit_device(struct rsi_hw *adapter);
#endif
--
2.7.4
^ permalink raw reply related
* [v2 3/3] rsi: sdio: Add WOWLAN support for S5 shutdown state
From: Amitkumar Karwar @ 2017-10-25 13:44 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi,
Karun Eagalapati
From: Karun Eagalapati <karun256@gmail.com>
Unlike other power states, WoWLAN configuration does not come from
mac80211 for shutdown. Hence configuring the WoWLAN from shut down
callback it self. Remaining steps of disabling SDIO interrupts,
setting 'MMC_PM_KEEP_POWER' flag are same as other power states.
Signed-off-by: Karun Eagalapati <karun256@gmail.com>
Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 1 +
drivers/net/wireless/rsi/rsi_91x_sdio.c | 31 +++++++++++++++++++++++++----
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index 8be24b1..879e844 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -1822,6 +1822,7 @@ int rsi_config_wowlan(struct rsi_hw *adapter, struct cfg80211_wowlan *wowlan)
return 0;
}
+EXPORT_SYMBOL(rsi_config_wowlan);
#ifdef CONFIG_PM
static int rsi_mac80211_suspend(struct ieee80211_hw *hw,
diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c
index 3f683d8..3288fb6 100644
--- a/drivers/net/wireless/rsi/rsi_91x_sdio.c
+++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c
@@ -1218,12 +1218,11 @@ static int rsi_freeze(struct device *dev)
common = adapter->priv;
sdev = (struct rsi_91x_sdiodev *)adapter->rsi_dev;
-#ifdef CONFIG_RSI_WOW
if ((common->wow_flags & RSI_WOW_ENABLED) &&
(common->wow_flags & RSI_WOW_NO_CONNECTION))
rsi_dbg(ERR_ZONE,
"##### Device can not wake up through WLAN\n");
-#endif
+
ret = rsi_sdio_disable_interrupts(pfunction);
if (sdev->write_fail)
@@ -1257,6 +1256,31 @@ static int rsi_thaw(struct device *dev)
return 0;
}
+static void rsi_shutdown(struct device *dev)
+{
+ struct sdio_func *pfunction = dev_to_sdio_func(dev);
+ struct rsi_hw *adapter = sdio_get_drvdata(pfunction);
+ struct rsi_91x_sdiodev *sdev =
+ (struct rsi_91x_sdiodev *)adapter->rsi_dev;
+ struct ieee80211_hw *hw = adapter->hw;
+ struct cfg80211_wowlan *wowlan = hw->wiphy->wowlan_config;
+
+ rsi_dbg(ERR_ZONE, "SDIO Bus shutdown =====>\n");
+
+ if (rsi_config_wowlan(adapter, wowlan))
+ rsi_dbg(ERR_ZONE, "Failed to configure WoWLAN\n");
+
+ rsi_sdio_disable_interrupts(sdev->pfunction);
+
+ if (sdev->write_fail)
+ rsi_dbg(INFO_ZONE, "###### Device is not ready #######\n");
+
+ if (rsi_set_sdio_pm_caps(adapter))
+ rsi_dbg(INFO_ZONE, "Setting power management caps failed\n");
+
+ rsi_dbg(INFO_ZONE, "***** RSI module shut down *****\n");
+}
+
int rsi_sdio_reinit_device(struct rsi_hw *adapter)
{
struct rsi_91x_sdiodev *sdev = adapter->rsi_dev;
@@ -1297,9 +1321,7 @@ static int rsi_restore(struct device *dev)
adapter->sc_nvifs = 0;
ieee80211_restart_hw(adapter->hw);
-#ifdef CONFIG_RSI_WOW
common->wow_flags = 0;
-#endif
common->iface_down = false;
rsi_dbg(INFO_ZONE, "RSI module restored\n");
@@ -1331,6 +1353,7 @@ static struct sdio_driver rsi_driver = {
#ifdef CONFIG_PM
.drv = {
.pm = &rsi_pm_ops,
+ .shutdown = rsi_shutdown,
}
#endif
};
--
2.7.4
^ permalink raw reply related
* pull-request: mac80211 2017-10-25
From: Johannes Berg @ 2017-10-25 14:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Here are a few more fixes for net, we started comprehensive testing
for the security issues and found that the problem wasn't addressed
in TKIP, so that's included, along with a handful other fixes.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 1b72bf5a0777d7cec6c2d857ac15599022b3c123:
Merge tag 'mac80211-for-davem-2017-10-16' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2017-10-16 21:27:16 +0100)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-10-25
for you to fetch changes up to cfbb0d90a7abb289edc91833d0905931f8805f12:
mac80211: don't compare TKIP TX MIC key in reinstall prevention (2017-10-25 11:04:45 +0200)
----------------------------------------------------------------
Here are:
* follow-up fixes for the WoWLAN security issue, to fix a
partial TKIP key material problem and to use crypto_memneq()
* a change for better enforcement of FQ's memory limit
* a disconnect/connect handling fix, and
* a user rate mask validation fix
----------------------------------------------------------------
Jason A. Donenfeld (1):
mac80211: use constant time comparison with keys
Johannes Berg (3):
cfg80211: fix connect/disconnect edge cases
mac80211: validate user rate mask before configuring driver
mac80211: don't compare TKIP TX MIC key in reinstall prevention
Toke Høiland-Jørgensen (1):
fq_impl: Properly enforce memory limit
include/net/fq_impl.h | 9 ++++++---
net/mac80211/cfg.c | 12 ++++++------
net/mac80211/key.c | 37 +++++++++++++++++++++++++++++++++++--
net/wireless/sme.c | 50 +++++++++++++++++++++++++++++++++++++++++---------
4 files changed, 88 insertions(+), 20 deletions(-)
^ permalink raw reply
* Re: A good way to get CSI info to user-space?
From: Zefir Kurtisi @ 2017-10-25 14:30 UTC (permalink / raw)
To: Johannes Berg, Ben Greear, linux-wireless@vger.kernel.org
In-Reply-To: <1508853316.2639.31.camel@sipsolutions.net>
Hi Ben,
On 10/24/2017 03:55 PM, Johannes Berg wrote:
> On Tue, 2017-10-24 at 06:50 -0700, Ben Greear wrote:
> [...]
>> Anyone know if there is a useful way to stream events from debugfs
>> and/or sysfs w/out having to busy-poll on it?
>
> There's relayfs, which is kinda built for that. You could even use
> netlink vendor events, but I don't really think netlink is appropriate
> here.
>
This is what I would also suggest, alas it is not clear if the events need to be
processed realtime.
The relayfs is used to stream the spectral data from ath9k (and afaik also from
ath10k) to userspace. Very easy to implement: kernel pushes TLVs into the relayfs,
userspace pulls them.
It is 'realtime-enough' to display realtime spectral graphs, but since you are
reading the stream in buffer-slices, you have to wait for a slice to fill up
before it is available at userspace (or you flush every TLV at kernel side, which
kills efficiency).
That is: if you need to immediately process events, relayfs is maybe not the right
choice, if you can process them in bulk, that's the most efficient way to go.
Cheers,
Zefir
> johannes
>
^ permalink raw reply
* Re: A good way to get CSI info to user-space?
From: Ben Greear @ 2017-10-25 14:43 UTC (permalink / raw)
To: Zefir Kurtisi, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <4e1f9cc5-5689-93fb-0c02-115e03268c1d@neratec.com>
On 10/25/2017 07:30 AM, Zefir Kurtisi wrote:
> Hi Ben,
>
> On 10/24/2017 03:55 PM, Johannes Berg wrote:
>> On Tue, 2017-10-24 at 06:50 -0700, Ben Greear wrote:
>> [...]
>>> Anyone know if there is a useful way to stream events from debugfs
>>> and/or sysfs w/out having to busy-poll on it?
>>
>> There's relayfs, which is kinda built for that. You could even use
>> netlink vendor events, but I don't really think netlink is appropriate
>> here.
>>
> This is what I would also suggest, alas it is not clear if the events need to be
> processed realtime.
>
> The relayfs is used to stream the spectral data from ath9k (and afaik also from
> ath10k) to userspace. Very easy to implement: kernel pushes TLVs into the relayfs,
> userspace pulls them.
>
> It is 'realtime-enough' to display realtime spectral graphs, but since you are
> reading the stream in buffer-slices, you have to wait for a slice to fill up
> before it is available at userspace (or you flush every TLV at kernel side, which
> kills efficiency).
>
> That is: if you need to immediately process events, relayfs is maybe not the right
> choice, if you can process them in bulk, that's the most efficient way to go.
The netlink vendor API seems to do exactly what I was hoping for earlier,
so I have started poking at that.
There is at least one other set of 'per-peer tx-beamforming' data that might be worth
exporting via the same mechanism.
Any particular reason why relayfs would be better than netlink?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Setting single rate in ath10k broken by "reject/clear user rate mask if not usable"
From: Johannes Berg @ 2017-10-25 15:17 UTC (permalink / raw)
To: Ben Greear, Oleksij Rempel, linux-wireless@vger.kernel.org,
ath10k, kirtika
In-Reply-To: <0bfb289d-a9fa-03d9-f9c7-cc0d01b0bd43@candelatech.com>
Hi,
So I fixed the part about the rate setting calling into the driver
before rejecting.
> If a user specifies a specific rate or rate-set, then I do not think we
> should quietly change it out from under them. So, we could check at the
> time the rate-set is applied (all current peers). We can reject the change
> at that point if one of the peers does not support any common rates.
> And, whenever a peer tries to be associated, we can check that there is some common rateset
> in place. If there is no common rateset, then reject the association
> one way or another.
It's not trivial to do in the kernel, but if we reject adding the
station then hostapd will turn around and reject the association. This
might not end up being done nicely, but I think it does still happen
before the association response, so a negative one would result.
> > We'll need to be a little careful what happens with client-mode
> > interfaces, which is where we actually observed hitting the WARN_ON()
> > about not having any rates at all, but I think I already put a reset of
> > the rates there anyway if they're not compatible with the AP. At least
> > that's easier because there's only one client.
>
> It would be easy to configure a station to do VHT MCS 8 only, and then
> it would never be able to associate with an HT AP, for instance. I don't
> think this should be a WARN_ON event, just a failure.
Well it resulted in a WARN_ON because if the AP didn't have those
rates, we'd not find any usable rates while trying to transmit a frame,
and then ended up warning and falling down to the lowest possible rate.
I don't think I agree that configuring this should reject the
association, and I've already implemented the behaviour of dropping the
user's rate set in this case in the patch we're discussing.
> It would be great
> if we could get a useful error message back to the caller, but I am not
> sure how feasible that is with the current netlink and mac80211 code.
If we reject the user setting, then we can easily more useful return
error messages now that we have generic netlink extack support. The
more "interesting" case is when the user set this and then reconnects.
This kind of problem is why I absolutely dislike out-of-band state that
affects the connection, rather than giving it in the connection
command(s) (connect, auth, associate, whatever). We're stuck with it
now, and needed to redefine that this selection may be dropped if not
usable.
> If your main concern is hitting a WARN_ON, maybe just change it to a
> quieter error message or remove it entirely and just return a failure
> code?
No, the warning serves a useful purpose, it's not useful to fall back
to the lowest rate, even if the user selected something completely
unusable. Arguably we should simply reject transmitting in that case,
but that's not really better either ...
johannes
^ permalink raw reply
* Re: A good way to get CSI info to user-space?
From: Zefir Kurtisi @ 2017-10-25 15:35 UTC (permalink / raw)
To: Ben Greear, Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <73fbd13f-50bb-b8c1-657b-ab2cfe015dc8@candelatech.com>
On 10/25/2017 04:43 PM, Ben Greear wrote:
>
>
> On 10/25/2017 07:30 AM, Zefir Kurtisi wrote:
>> Hi Ben,
>>
>> On 10/24/2017 03:55 PM, Johannes Berg wrote:
>>> On Tue, 2017-10-24 at 06:50 -0700, Ben Greear wrote:
>>> [...]
>>>> Anyone know if there is a useful way to stream events from debugfs
>>>> and/or sysfs w/out having to busy-poll on it?
>>>
>>> There's relayfs, which is kinda built for that. You could even use
>>> netlink vendor events, but I don't really think netlink is appropriate
>>> here.
>>>
>> This is what I would also suggest, alas it is not clear if the events need to be
>> processed realtime.
>>
>> The relayfs is used to stream the spectral data from ath9k (and afaik also from
>> ath10k) to userspace. Very easy to implement: kernel pushes TLVs into the relayfs,
>> userspace pulls them.
>>
>> It is 'realtime-enough' to display realtime spectral graphs, but since you are
>> reading the stream in buffer-slices, you have to wait for a slice to fill up
>> before it is available at userspace (or you flush every TLV at kernel side, which
>> kills efficiency).
>>
>> That is: if you need to immediately process events, relayfs is maybe not the right
>> choice, if you can process them in bulk, that's the most efficient way to go.
>
> The netlink vendor API seems to do exactly what I was hoping for earlier,
> so I have started poking at that.
>
> There is at least one other set of 'per-peer tx-beamforming' data that might be worth
> exporting via the same mechanism.
>
> Any particular reason why relayfs would be better than netlink?
>
>
'Better' depends on type of the data. relayfs is better for continuous and
high-bandwidth data. With spectral there are up to 80k measurements per second
with each TLV holding ~70-150 bytes (depending on HT20/40) - that won't be doable
as netlink events.
If the netlink vendor API suffices for the CSI data, no need to change.
Aside from data type dependency, relayfs has at least some noteworthy positive
aspects:
* works lock-free at kernel side
* independent of any API at userspace
=> just open the file from {C, python, shell, ...} and process the data
Cheers,
Zefir
^ permalink raw reply
* Re: Searching help for Linux support for RTL8812AU
From: Larry Finger @ 2017-10-25 16:10 UTC (permalink / raw)
To: txt.file, linux-wireless, driverdev-devel
In-Reply-To: <8a62a06d-8a80-6df7-4f30-160a0231dac9@txtfile.eu>
On 10/24/2017 08:24 AM, txt.file wrote:
> Hey Linux wireless list,
>
> A while ago I bought an ALFA Network AWUS036AC[0] which does not yet
> seem to be supported in Linux mainline. I would like to get it supported.
>
> The problem is that I have not that much experience doing software
> development.
>
> kind regards
> txt.file
>
> PS: Please keep me in CC as I am not subscribed to the lists.
>
> [0] https://wikidevi.com/wiki/ALFA_Network_AWUS036AC
I can provide you with an out-of-kernel driver for the RTL8812AU. Please be
aware that these Realtek USB drivers require many changes before they can be
accepted into even the staging tree of the kernel. One other consideration is
that staging drivers should (must?) have a definite path for inclusion into the
main kernel trees. For wireless, this means using mac80211. For these Realtek
drivers with their own MAC code, that is a major change.
My suggestion is that you work to get your device handled by driver rtl8xxxu,
which is in the kernel. I have no idea how much effort that would be, but
certainly a lot less than converting the Realtek driver.
Larry
PS: Please keep the list in the Cc as I tend to disregard private requests for
consulting!
^ permalink raw reply
* Re: Setting single rate in ath10k broken by "reject/clear user rate mask if not usable"
From: Ben Greear @ 2017-10-25 16:13 UTC (permalink / raw)
To: Johannes Berg, Oleksij Rempel, linux-wireless@vger.kernel.org,
ath10k, kirtika
In-Reply-To: <1508944670.2421.49.camel@sipsolutions.net>
On 10/25/2017 08:17 AM, Johannes Berg wrote:
> Hi,
>
> So I fixed the part about the rate setting calling into the driver
> before rejecting.
>
>> If a user specifies a specific rate or rate-set, then I do not think we
>> should quietly change it out from under them. So, we could check at the
>> time the rate-set is applied (all current peers). We can reject the change
>> at that point if one of the peers does not support any common rates.
>> And, whenever a peer tries to be associated, we can check that there is some common rateset
>> in place. If there is no common rateset, then reject the association
>> one way or another.
>
> It's not trivial to do in the kernel, but if we reject adding the
> station then hostapd will turn around and reject the association. This
> might not end up being done nicely, but I think it does still happen
> before the association response, so a negative one would result.
>
>>> We'll need to be a little careful what happens with client-mode
>>> interfaces, which is where we actually observed hitting the WARN_ON()
>>> about not having any rates at all, but I think I already put a reset of
>>> the rates there anyway if they're not compatible with the AP. At least
>>> that's easier because there's only one client.
>>
>> It would be easy to configure a station to do VHT MCS 8 only, and then
>> it would never be able to associate with an HT AP, for instance. I don't
>> think this should be a WARN_ON event, just a failure.
>
> Well it resulted in a WARN_ON because if the AP didn't have those
> rates, we'd not find any usable rates while trying to transmit a frame,
> and then ended up warning and falling down to the lowest possible rate.
>
> I don't think I agree that configuring this should reject the
> association, and I've already implemented the behaviour of dropping the
> user's rate set in this case in the patch we're discussing.
So, as long as we are associating to a VHT AP, then we could still set the
tx-rateset to (only) VHT MCS 8 and allow association, even if there are no additional
rates set. There is at least one common rate, so theoretically, the
station and AP can communicate.
If we tried to associate this same station to an HT AP, then your work-around
code could kick in and throw away the user's rateset configuration, preferably
with a fairly noticeable warning message since you are overriding the user's
preferred tx rateset?
>> It would be great
>> if we could get a useful error message back to the caller, but I am not
>> sure how feasible that is with the current netlink and mac80211 code.
>
> If we reject the user setting, then we can easily more useful return
> error messages now that we have generic netlink extack support. The
> more "interesting" case is when the user set this and then reconnects.
>
> This kind of problem is why I absolutely dislike out-of-band state that
> affects the connection, rather than giving it in the connection
> command(s) (connect, auth, associate, whatever). We're stuck with it
> now, and needed to redefine that this selection may be dropped if not
> usable.
You could start allowing the user to configure the full advertised and
transmit rateset for each of these actions (and probe too), and user-space can add the fields
to their netlink commands. At least going forward, this might help
make the behaviour more as expected. If you would like to implement at
least the basics in cfg/mac80211, I would be happy to work on the supplicant
end of things.
>
>> If your main concern is hitting a WARN_ON, maybe just change it to a
>> quieter error message or remove it entirely and just return a failure
>> code?
>
> No, the warning serves a useful purpose, it's not useful to fall back
> to the lowest rate, even if the user selected something completely
> unusable. Arguably we should simply reject transmitting in that case,
> but that's not really better either ...
>
> johannes
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* brcmfmac on Inventek 43341 module over sdio
From: Dennis Millard @ 2017-10-25 17:33 UTC (permalink / raw)
To: linux-wireless
I've been trying to bring up this BRC43341 module on an nVidia TX1
plugged into the uSD card slot and I'm having some trouble with the
driver. First of all, the uSD card slot works fine with uSD memory
cards. Now I've got this eval board from Inventek, the
ISM43340-L77-EVB which plugs into the uSD card slot.
I've enabled brcmfmac in the kernel config and things started off very
well. I had to modify the driver code to add support for the 43341
firmware and nvram filenames, but that all seems to be working. I got
the firmware and nvram files directly from Inventek. When I insert
the card, I can see it detected, and the driver starts talking to it.
It configures a few registers, and then the firmware and nvram are
getting loaded successfully, as evidenced by this:
[ 31.935443] brcmfmac: [2] brcmf_sdio_download_code_file Enter
[ 32.122020] brcmfmac: [4] brcmf_sdio_verifymemory Compare RAM dl &
ul at 0x00000000; size=368538
[ 32.497360] brcmfmac: [2] brcmf_sdio_download_nvram Enter
[ 32.504947] brcmfmac: [4] brcmf_sdio_verifymemory Compare RAM dl &
ul at 0x0007fa48; size=1464
[ 32.516009] brcmfmac: [2] brcmf_chip_set_active Enter
[ 32.523964] brcmfmac: [2] brcmf_sdiod_change_state 0 -> 1
[ 32.529422] brcmfmac: [2] brcmf_bus_change_state 0 -> 1
What happens next, as near as I can tell, is that the inband interrupt
gets configured, and then pretty quickly I get an interrupt for a bad
CRC, then a register dump.
[ 32.664411] brcmfmac: [131072] brcmf_sdio_bus_sleep Enter: request
WAKE currently WAKE
[ 32.664413] brcmfmac: [131072] brcmf_sdio_clkctl Enter
[ 32.664415] brcmfmac: [131072] brcmf_sdio_bus_sleep new state WAKE
[ 32.664416] brcmfmac: [131072] brcmf_sdio_bus_sleep Exit: err=0
[ 32.664418] brcmfmac: [131072] brcmf_sdio_hostmail Enter
[ 32.664610] brcmfmac: [131072] brcmf_sdio_hostmail Dongle ready,
protocol version 4
[ 32.664612] brcmfmac: [131072] brcmf_sdio_bus_sleep Enter: request
WAKE currently WAKE
[ 32.664614] brcmfmac: [131072] brcmf_sdio_clkctl Enter
[ 32.664615] brcmfmac: [131072] brcmf_sdio_bus_sleep new state WAKE
[ 32.664617] brcmfmac: [131072] brcmf_sdio_bus_sleep Exit: err=0
[ 32.664618] brcmfmac: [2] brcmf_chip_sr_capable Enter
[ 32.665150] brcmfmac: [4] brcmf_sdio_readshared sdpcm_shared
address 0x0003D538
[ 32.665519] brcmfmac: [2] brcmf_sdio_readframes Enter
[ 32.665524] brcmfmac: [131072] brcmf_sdiod_recv_pkt addr =
0x18000000, size = 64
[ 32.665591] mmc1: sdhci_cmd_irq 2634 SDHCI_INT_CRC intmask: 20001
Interface clock = 6000000Hz
[ 32.665592] sdhci: =========== REGISTER DUMP (mmc1)===========
[ 32.665597] sdhci: Sys addr: 0x00000000 | Version: 0x00000303
[ 32.665601] sdhci: Blk size: 0x00007040 | Blk cnt: 0x00000001
[ 32.665605] sdhci: Argument: 0x21000040 | Trn mode: 0x00000013
[ 32.665608] sdhci: Present: 0x01db0008 | Host ctl: 0x00000016
[ 32.665612] sdhci: Power: 0x00000001 | Blk gap: 0x00000000
[ 32.665616] sdhci: Wake-up: 0x00000000 | Clock: 0x00000007
[ 32.665619] sdhci: Timeout: 0x0000000e | Int stat: 0x00000000
[ 32.665623] sdhci: Int enab: 0x02ff000b | Sig enab: 0x02fc000b
[ 32.665626] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
[ 32.665630] sdhci: Caps: 0x376cd08c | Caps_1: 0x10006f73
[ 32.665634] sdhci: Cmd: 0x0000353a | Max curr: 0x00000000
[ 32.665636] sdhci: Host ctl2: 0x0000308b
[ 32.665641] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x0000000080000010
[ 32.665642] sdhci: ===========================================
[ 32.665658] brcmfmac: brcmf_err- brcmf_sdio_readframes: RXHEADER FAILED: -84
[ 32.665660] brcmfmac: brcmf_err- brcmf_sdio_rxfail: abort command,
terminate frame, send NAK
[ 32.665662] brcmfmac: [131072] brcmf_sdiod_abort Enter
A short time after this, there's another register dump, and then the
kernel crashes.
I had trouble figuring out how to enable specific logging modes in the
driver, so I just hacked it to spit out everything. I have a pretty
detailed log showing the driver communication that I can post if it
will help. I'm not sure about the etiquette on this mailing list, so
I didn't want to start off with posting the whole log right away.
Any help on this would be much appreciated.
-Dennis
^ permalink raw reply
* RTL usb adapter question
From: David Ashley @ 2017-10-25 18:43 UTC (permalink / raw)
To: linux-wireless
I'm trying to understand how the linux kernel loads RTL8188CUS firmware
rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
when that file isn't available anywhere in my embedded system's filesystem.
Basically I'm trying to understand the theory. We have a product that
is making use of the device
Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd
EW-7811Un802.11n Wireless Adapter [Realtek RTL8188CUS]
It has not been especially reliable. I've never provided firmware
files for the device in the root filesystem. I've started to pay
attention to the kernel error messages. Now the kernel drivers seem to
be loading the rtlwifi/rtl8192cufw_TMSC.bin file and I'm trying to
understand if this is actually working, if it makes any difference in
reliability...
It's like I can't figure out how the usb dongle even worked without
its firmware file...
My working theory is that the usb dongle comes from the factory with a
hardcoded firmware file (rtlwifi/rtl8192cufw.bin) but it is buggy or
inferior. And the performance and reliability can be improved if the
driver successfully manages to load the rtl8192cufw_TMSC.bin file. I
don't know if the firmware load persists across a power cycle (my
assumption is it doesn't).
Thanks for any insight anyone can provide.
-Dave
^ permalink raw reply
* Re: RTL usb adapter question
From: Larry Finger @ 2017-10-25 19:35 UTC (permalink / raw)
To: David Ashley, linux-wireless
In-Reply-To: <CABkE59DHPoLD5PGRHpKMAwy0w3vR9M_qoHEQ1AkK-ELDcUXD9Q@mail.gmail.com>
On 10/25/2017 01:43 PM, David Ashley wrote:
> I'm trying to understand how the linux kernel loads RTL8188CUS firmware
> rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
> when that file isn't available anywhere in my embedded system's filesystem.
>
> Basically I'm trying to understand the theory. We have a product that
> is making use of the device
>
> Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd
> EW-7811Un802.11n Wireless Adapter [Realtek RTL8188CUS]
>
> It has not been especially reliable. I've never provided firmware
> files for the device in the root filesystem. I've started to pay
> attention to the kernel error messages. Now the kernel drivers seem to
> be loading the rtlwifi/rtl8192cufw_TMSC.bin file and I'm trying to
> understand if this is actually working, if it makes any difference in
> reliability...
>
> It's like I can't figure out how the usb dongle even worked without
> its firmware file...
>
> My working theory is that the usb dongle comes from the factory with a
> hardcoded firmware file (rtlwifi/rtl8192cufw.bin) but it is buggy or
> inferior. And the performance and reliability can be improved if the
> driver successfully manages to load the rtl8192cufw_TMSC.bin file. I
> don't know if the firmware load persists across a power cycle (my
> assumption is it doesn't).
There is NO firmware coded by the factory in the device. It only has enough
intelligence to load the real firmware. The exact file that it loads is
determined by the model. If you provide the appropriate section of the output of
dmesg where the above firmware messages occur, and a file listing of
/lib/firmware/rtlwifi/, I can tell you what firmware is being loaded.
No, firmware will not persist across a power failure.
The driver has never been particularly reliable, and the USB group at Realtek
seems not to care. You might try their other driver, but you will be on your
own, as I will not support that particular piece of ****.
Please reply to all on any followups.
Larry
^ permalink raw reply
* Re: RTL usb adapter question
From: Mark Greer @ 2017-10-25 22:03 UTC (permalink / raw)
To: David Ashley; +Cc: linux-wireless
In-Reply-To: <CABkE59DHPoLD5PGRHpKMAwy0w3vR9M_qoHEQ1AkK-ELDcUXD9Q@mail.gmail.com>
On Wed, Oct 25, 2017 at 01:43:55PM -0500, David Ashley wrote:
> I'm trying to understand how the linux kernel loads RTL8188CUS firmware
> rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
> when that file isn't available anywhere in my embedded system's filesystem.
>
> Basically I'm trying to understand the theory. We have a product that
> is making use of the device
To get a general understanding of how fw loading works in Linux, read this:
https://www.kernel.org/doc/html/latest/driver-api/firmware/index.html
Mark
--
^ permalink raw reply
* [PATCH] cfg80211: initialize regulatory keys/database later
From: Johannes Berg @ 2017-10-26 9:28 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
When cfg80211 is built as a module, everything is fine, and we
can keep the code as is; in fact, we have to, because there can
only be a single module_init().
When cfg80211 is built-in, however, it needs to initialize
before drivers (device_initcall/module_init), and thus used to
be at subsys_initcall(). I'd moved it to fs_initcall() earlier,
where it can remain. However, this is still too early because at
that point the key infrastructure hasn't been initialized yet,
so X.509 certificates can't be parsed yet.
To work around this problem, load the regdb keys only later in
a late_initcall(), at which point the necessary infrastructure
has been initialized.
Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking")
Reported-by: Xiaolong Ye <xiaolong.ye@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/reg.c | 42 +++++++++++++++++++++++++++---------------
1 file changed, 27 insertions(+), 15 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 3871998059de..78e71b0390be 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -3644,27 +3644,14 @@ void regulatory_propagate_dfs_state(struct wiphy *wiphy,
}
}
-int __init regulatory_init(void)
+static int __init regulatory_init_db(void)
{
- int err = 0;
+ int err;
err = load_builtin_regdb_keys();
if (err)
return err;
- reg_pdev = platform_device_register_simple("regulatory", 0, NULL, 0);
- if (IS_ERR(reg_pdev))
- return PTR_ERR(reg_pdev);
-
- spin_lock_init(®_requests_lock);
- spin_lock_init(®_pending_beacons_lock);
- spin_lock_init(®_indoor_lock);
-
- rcu_assign_pointer(cfg80211_regdomain, cfg80211_world_regdom);
-
- user_alpha2[0] = '9';
- user_alpha2[1] = '7';
-
/* We always try to get an update for the static regdomain */
err = regulatory_hint_core(cfg80211_world_regdom->alpha2);
if (err) {
@@ -3692,6 +3679,31 @@ int __init regulatory_init(void)
return 0;
}
+#ifndef MODULE
+late_initcall(regulatory_init_db);
+#endif
+
+int __init regulatory_init(void)
+{
+ reg_pdev = platform_device_register_simple("regulatory", 0, NULL, 0);
+ if (IS_ERR(reg_pdev))
+ return PTR_ERR(reg_pdev);
+
+ spin_lock_init(®_requests_lock);
+ spin_lock_init(®_pending_beacons_lock);
+ spin_lock_init(®_indoor_lock);
+
+ rcu_assign_pointer(cfg80211_regdomain, cfg80211_world_regdom);
+
+ user_alpha2[0] = '9';
+ user_alpha2[1] = '7';
+
+#ifdef MODULE
+ return regulatory_init_db();
+#else
+ return 0;
+#endif
+}
void regulatory_exit(void)
{
--
2.14.2
^ permalink raw reply related
* Activity LED does not work on TL-WN823N 2.0 WLAN dongle
From: sonofagun @ 2017-10-26 11:50 UTC (permalink / raw)
To: linux-wireless
VGhlIFRMLVdOODIzTiBVU0IgMi4wIFdMQU4gZG9uZ2xlIGJhc2VkIG9uIFJUTDgxOTJFVSBoYXMg
aXRzIGdyZWVuIExFRCB0dXJuZWQgb2ZmIGFsd2F5cy4gVHJpZWQgdmFyaW91cyBkaXN0cmlidXRp
b25zKGRlYmlhbiwgdWJ1bnR1KSBidXQgbm9uZSB3b3JrZWQgOigKCk9uIHdpbmRvd3MgNyBTUDEg
aXRzIExFRCB3b3JrcyBmaW5lIGFuZCBpdCBpcyBtdWNoIGZhc3Rlci4KCklzIGl0IHBvc3NpYmxl
IHRvIG1ha2UgaXQgd29yayB1bmRlciBsaW51eD8=
^ permalink raw reply
* [RFC PATCH v8 0/7] PCI: rockchip: Move PCIe WAKE# handling into pci core
From: Jeffy Chen @ 2017-10-26 13:28 UTC (permalink / raw)
To: linux-kernel, bhelgaas
Cc: linux-pm, tony, shawn.lin, briannorris, rjw, dianders, Jeffy Chen,
Xinming Hu, linux-wireless, linux-pci, Rob Herring,
Catalin Marinas, Kalle Valo, Heiko Stuebner, linux-acpi,
linux-rockchip, Nishant Sarmukadam, Will Deacon,
Matthias Kaehlcke, devicetree, Ganapathi Bhat, Frank Rowand,
Len Brown, linux-arm-kernel, netdev, Amitkumar Karwar,
Caesar Wang, Mark Rutland
Currently we are handling wake irq in mrvl wifi driver. Move it into
pci core.
Tested on my chromebook bob(with cros 4.4 kernel and mrvl wifi).
Changes in v8:
Add optional "pci", and rewrite commit message.
Rewrite the commit message.
Add pci-of.c and use platform_pm_ops to handle the PCIe WAKE# signal.
Changes in v7:
Move PCIE_WAKE handling into pci core.
Changes in v6:
Fix device_init_wake error handling, and add some comments.
Changes in v5:
Move to pci.txt
Use "wakeup" instead of "wake"
Rebase.
Changes in v3:
Fix error handling.
Changes in v2:
Use dev_pm_set_dedicated_wake_irq.
Jeffy Chen (7):
dt-bindings: PCI: Add definition of PCIe WAKE# irq and PCI irq
mwifiex: Disable wakeup irq handling for pcie
arm64: dts: rockchip: Handle PCIe WAKE# signal in pcie driver for Gru
of/irq: Adjust of pci irq parsing for multiple interrupts
PCI: Make pci_platform_pm_ops's callbacks optional
PCI / PM: Move acpi wakeup code to pci core
PCI / PM: Add support for the PCIe WAKE# signal for OF
Documentation/devicetree/bindings/pci/pci.txt | 3 +
arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 15 +--
drivers/net/wireless/marvell/mwifiex/main.c | 4 +
drivers/of/of_pci_irq.c | 13 ++-
drivers/pci/Makefile | 2 +-
drivers/pci/pci-acpi.c | 121 +++++++++++------------
drivers/pci/pci-driver.c | 9 ++
drivers/pci/pci-of.c | 136 ++++++++++++++++++++++++++
drivers/pci/pci.c | 112 +++++++++++++++++----
drivers/pci/pci.h | 31 ++++--
drivers/pci/probe.c | 12 ++-
drivers/pci/remove.c | 2 +
include/linux/pci.h | 2 +
13 files changed, 365 insertions(+), 97 deletions(-)
create mode 100644 drivers/pci/pci-of.c
--
2.11.0
^ permalink raw reply
* [RFC PATCH v8 2/7] mwifiex: Disable wakeup irq handling for pcie
From: Jeffy Chen @ 2017-10-26 13:28 UTC (permalink / raw)
To: linux-kernel, bhelgaas
Cc: linux-pm, tony, shawn.lin, briannorris, rjw, dianders, Jeffy Chen,
Xinming Hu, Kalle Valo, Ganapathi Bhat, Amitkumar Karwar,
linux-wireless, Nishant Sarmukadam, netdev
In-Reply-To: <20171026132840.20946-1-jeffy.chen@rock-chips.com>
We are going to handle the wakeup irq in the pci core.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v3: None
Changes in v2: None
drivers/net/wireless/marvell/mwifiex/main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index ee40b739b289..ba081c16f85c 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1568,6 +1568,10 @@ static void mwifiex_probe_of(struct mwifiex_adapter *adapter)
goto err_exit;
adapter->dt_node = dev->of_node;
+
+ if (adapter->iface_type != MWIFIEX_PCIE)
+ goto err_exit;
+
adapter->irq_wakeup = irq_of_parse_and_map(adapter->dt_node, 0);
if (!adapter->irq_wakeup) {
dev_dbg(dev, "fail to parse irq_wakeup from device tree\n");
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2] wireless-regdb: Add 5 Ghz rules for Kazakhstan (KZ)
From: WoWz89 @ 2017-10-26 16:17 UTC (permalink / raw)
To: Seth Forshee, wireless-regdb, linux-wireless
In-Reply-To: <20171020150651.32424-1-seth.forshee@canonical.com>
=C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5, Seth.
=C2=FB =EF=E8=F1=E0=EB=E8 20 =EE=EA=F2=FF=E1=F0=FF 2017 =E3., 21:06:51:
> Add rules for 5150-5250 MHz, 5250-5350 MHz, and 5470-5725 Mhz
> based on the documents at [1] and [2].
> v2: Also add DFS region
Hello, you mean the patch for Kazakhstan is not forgotten ?
> [1]
> http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_cha=
stot_no34.pdf
> [2] http://adilet.zan.kz/rus/docs/P000001379_
> Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
> ---
> db.txt | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
> diff --git a/db.txt b/db.txt
> index 9d129f2e542b..10c84ee1ca5d 100644
> --- a/db.txt
> +++ b/db.txt
> @@ -691,8 +691,14 @@ country KY: DFS-FCC
> (5490 - 5730 @ 160), (24), DFS
> (5735 - 5835 @ 80), (30)
> =20
> -country KZ:
> +# Source:
> +#
> http://mic.gov.kz/sites/default/files/pages/pravila_prisvoeniya_polos_cha=
stot_no34.pdf
> +# http://adilet.zan.kz/rus/docs/P000001379_
> +country KZ: DFS-ETSI
> (2402 - 2482 @ 40), (20)
> + (5150 - 5250 @ 80), (20), NO-OUTDOOR, AUTO-BW
> + (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW
> + (5470 - 5725 @ 80), (20), NO-OUTDOOR, DFS
> =20
> country LB: DFS-FCC
> (2402 - 2482 @ 40), (20)
--=20
=D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC,
WoWz89 mailto:wowz89@mail.ru
^ permalink raw reply
* [PATCH v3] ath10k: rebuild crypto header in rx data frames
From: Kalle Valo @ 2017-10-26 16:36 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Vasanthakumar Thiagarajan
From: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and
HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done
on host (mac80211) rather than firmware. Rebuild cipher header
in every received data frames (that are notified through those
HTT interfaces) from the rx_hdr_status tlv available in the
rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED
flag for the packets which requires mac80211 PN/TSC check support
and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X,
QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the
rebuilding of cipher header to perform PN/TSC check for replay
attack.
Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers
in raw mode needs to be fixed. Since Rx with these ciphers in raw
mode does not work in the current form even without this patch and
removing crypto tail for these chipers needs clean up, raw mode related
issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up
patches.
Tested-by: Manikanta Pubbisetty <mpubbise@qti.qualcomm.com>
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
---
v3:
* Fix cipher header construction for CCMP-256, GCMP and GCMP-256
ciphers.
* Fix bug in raw mode when RX_FLAG_IV_STRIPPED is set.
v2:
* Construct cipher header from rx_hdr_status tlv rather than from
the msdu_start and mpdu_start tlvs. This fixes connection
issues, also reduces the amount of code change.
* Make sure the frame is qos data before clearing AMSDU_PRESENT
bit of qos control field.
* Fix traffic issue with QCA988X and QCA9887 hw by taking care of
padding bytes added for 4-byte alignment before the cipher
header.
drivers/net/wireless/ath/ath10k/htt_rx.c | 105 +++++++++++++++++++++++++-----
drivers/net/wireless/ath/ath10k/rx_desc.h | 3 +
2 files changed, 92 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index a3f5dc78353f..5beb6ee0f091 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -550,6 +550,11 @@ static int ath10k_htt_rx_crypto_param_len(struct ath10k *ar,
return IEEE80211_TKIP_IV_LEN;
case HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2:
return IEEE80211_CCMP_HDR_LEN;
+ case HTT_RX_MPDU_ENCRYPT_AES_CCM256_WPA2:
+ return IEEE80211_CCMP_256_HDR_LEN;
+ case HTT_RX_MPDU_ENCRYPT_AES_GCMP_WPA2:
+ case HTT_RX_MPDU_ENCRYPT_AES_GCMP256_WPA2:
+ return IEEE80211_GCMP_HDR_LEN;
case HTT_RX_MPDU_ENCRYPT_WEP128:
case HTT_RX_MPDU_ENCRYPT_WAPI:
break;
@@ -575,6 +580,11 @@ static int ath10k_htt_rx_crypto_tail_len(struct ath10k *ar,
return IEEE80211_TKIP_ICV_LEN;
case HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2:
return IEEE80211_CCMP_MIC_LEN;
+ case HTT_RX_MPDU_ENCRYPT_AES_CCM256_WPA2:
+ return IEEE80211_CCMP_256_MIC_LEN;
+ case HTT_RX_MPDU_ENCRYPT_AES_GCMP_WPA2:
+ case HTT_RX_MPDU_ENCRYPT_AES_GCMP256_WPA2:
+ return IEEE80211_GCMP_MIC_LEN;
case HTT_RX_MPDU_ENCRYPT_WEP128:
case HTT_RX_MPDU_ENCRYPT_WAPI:
break;
@@ -1051,9 +1061,21 @@ static void ath10k_htt_rx_h_undecap_raw(struct ath10k *ar,
hdr = (void *)msdu->data;
/* Tail */
- if (status->flag & RX_FLAG_IV_STRIPPED)
+ if (status->flag & RX_FLAG_IV_STRIPPED) {
skb_trim(msdu, msdu->len -
ath10k_htt_rx_crypto_tail_len(ar, enctype));
+ } else {
+ /* MIC */
+ if ((status->flag & RX_FLAG_MIC_STRIPPED) &&
+ enctype == HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+ skb_trim(msdu, msdu->len - 8);
+
+ /* ICV */
+ if (status->flag & RX_FLAG_ICV_STRIPPED &&
+ enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2)
+ skb_trim(msdu, msdu->len -
+ ath10k_htt_rx_crypto_tail_len(ar, enctype));
+ }
/* MMIC */
if ((status->flag & RX_FLAG_MMIC_STRIPPED) &&
@@ -1075,7 +1097,8 @@ static void ath10k_htt_rx_h_undecap_raw(struct ath10k *ar,
static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k *ar,
struct sk_buff *msdu,
struct ieee80211_rx_status *status,
- const u8 first_hdr[64])
+ const u8 first_hdr[64],
+ enum htt_rx_mpdu_encrypt_type enctype)
{
struct ieee80211_hdr *hdr;
struct htt_rx_desc *rxd;
@@ -1083,6 +1106,7 @@ static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k *ar,
u8 da[ETH_ALEN];
u8 sa[ETH_ALEN];
int l3_pad_bytes;
+ int bytes_aligned = ar->hw_params.decap_align_bytes;
/* Delivered decapped frame:
* [nwifi 802.11 header] <-- replaced with 802.11 hdr
@@ -1111,6 +1135,14 @@ static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k *ar,
/* push original 802.11 header */
hdr = (struct ieee80211_hdr *)first_hdr;
hdr_len = ieee80211_hdrlen(hdr->frame_control);
+
+ if (!(status->flag & RX_FLAG_IV_STRIPPED)) {
+ memcpy(skb_push(msdu,
+ ath10k_htt_rx_crypto_param_len(ar, enctype)),
+ (void *)hdr + round_up(hdr_len, bytes_aligned),
+ ath10k_htt_rx_crypto_param_len(ar, enctype));
+ }
+
memcpy(skb_push(msdu, hdr_len), hdr, hdr_len);
/* original 802.11 header has a different DA and in
@@ -1171,6 +1203,7 @@ static void ath10k_htt_rx_h_undecap_eth(struct ath10k *ar,
u8 sa[ETH_ALEN];
int l3_pad_bytes;
struct htt_rx_desc *rxd;
+ int bytes_aligned = ar->hw_params.decap_align_bytes;
/* Delivered decapped frame:
* [eth header] <-- replaced with 802.11 hdr & rfc1042/llc
@@ -1199,6 +1232,14 @@ static void ath10k_htt_rx_h_undecap_eth(struct ath10k *ar,
/* push original 802.11 header */
hdr = (struct ieee80211_hdr *)first_hdr;
hdr_len = ieee80211_hdrlen(hdr->frame_control);
+
+ if (!(status->flag & RX_FLAG_IV_STRIPPED)) {
+ memcpy(skb_push(msdu,
+ ath10k_htt_rx_crypto_param_len(ar, enctype)),
+ (void *)hdr + round_up(hdr_len, bytes_aligned),
+ ath10k_htt_rx_crypto_param_len(ar, enctype));
+ }
+
memcpy(skb_push(msdu, hdr_len), hdr, hdr_len);
/* original 802.11 header has a different DA and in
@@ -1212,12 +1253,14 @@ static void ath10k_htt_rx_h_undecap_eth(struct ath10k *ar,
static void ath10k_htt_rx_h_undecap_snap(struct ath10k *ar,
struct sk_buff *msdu,
struct ieee80211_rx_status *status,
- const u8 first_hdr[64])
+ const u8 first_hdr[64],
+ enum htt_rx_mpdu_encrypt_type enctype)
{
struct ieee80211_hdr *hdr;
size_t hdr_len;
int l3_pad_bytes;
struct htt_rx_desc *rxd;
+ int bytes_aligned = ar->hw_params.decap_align_bytes;
/* Delivered decapped frame:
* [amsdu header] <-- replaced with 802.11 hdr
@@ -1233,6 +1276,14 @@ static void ath10k_htt_rx_h_undecap_snap(struct ath10k *ar,
hdr = (struct ieee80211_hdr *)first_hdr;
hdr_len = ieee80211_hdrlen(hdr->frame_control);
+
+ if (!(status->flag & RX_FLAG_IV_STRIPPED)) {
+ memcpy(skb_push(msdu,
+ ath10k_htt_rx_crypto_param_len(ar, enctype)),
+ (void *)hdr + round_up(hdr_len, bytes_aligned),
+ ath10k_htt_rx_crypto_param_len(ar, enctype));
+ }
+
memcpy(skb_push(msdu, hdr_len), hdr, hdr_len);
}
@@ -1267,13 +1318,15 @@ static void ath10k_htt_rx_h_undecap(struct ath10k *ar,
is_decrypted);
break;
case RX_MSDU_DECAP_NATIVE_WIFI:
- ath10k_htt_rx_h_undecap_nwifi(ar, msdu, status, first_hdr);
+ ath10k_htt_rx_h_undecap_nwifi(ar, msdu, status, first_hdr,
+ enctype);
break;
case RX_MSDU_DECAP_ETHERNET2_DIX:
ath10k_htt_rx_h_undecap_eth(ar, msdu, status, first_hdr, enctype);
break;
case RX_MSDU_DECAP_8023_SNAP_LLC:
- ath10k_htt_rx_h_undecap_snap(ar, msdu, status, first_hdr);
+ ath10k_htt_rx_h_undecap_snap(ar, msdu, status, first_hdr,
+ enctype);
break;
}
}
@@ -1316,7 +1369,8 @@ static void ath10k_htt_rx_h_csum_offload(struct sk_buff *msdu)
static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
struct sk_buff_head *amsdu,
- struct ieee80211_rx_status *status)
+ struct ieee80211_rx_status *status,
+ bool fill_crypt_header)
{
struct sk_buff *first;
struct sk_buff *last;
@@ -1326,7 +1380,6 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
enum htt_rx_mpdu_encrypt_type enctype;
u8 first_hdr[64];
u8 *qos;
- size_t hdr_len;
bool has_fcs_err;
bool has_crypto_err;
bool has_tkip_err;
@@ -1351,15 +1404,17 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
* decapped header. It'll be used for undecapping of each MSDU.
*/
hdr = (void *)rxd->rx_hdr_status;
- hdr_len = ieee80211_hdrlen(hdr->frame_control);
- memcpy(first_hdr, hdr, hdr_len);
+ memcpy(first_hdr, hdr, RX_HTT_HDR_STATUS_LEN);
/* Each A-MSDU subframe will use the original header as the base and be
* reported as a separate MSDU so strip the A-MSDU bit from QoS Ctl.
*/
hdr = (void *)first_hdr;
- qos = ieee80211_get_qos_ctl(hdr);
- qos[0] &= ~IEEE80211_QOS_CTL_A_MSDU_PRESENT;
+
+ if (ieee80211_is_data_qos(hdr->frame_control)) {
+ qos = ieee80211_get_qos_ctl(hdr);
+ qos[0] &= ~IEEE80211_QOS_CTL_A_MSDU_PRESENT;
+ }
/* Some attention flags are valid only in the last MSDU. */
last = skb_peek_tail(amsdu);
@@ -1406,9 +1461,14 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
status->flag |= RX_FLAG_DECRYPTED;
if (likely(!is_mgmt))
- status->flag |= RX_FLAG_IV_STRIPPED |
- RX_FLAG_MMIC_STRIPPED;
-}
+ status->flag |= RX_FLAG_MMIC_STRIPPED;
+
+ if (fill_crypt_header)
+ status->flag |= RX_FLAG_MIC_STRIPPED |
+ RX_FLAG_ICV_STRIPPED;
+ else
+ status->flag |= RX_FLAG_IV_STRIPPED;
+ }
skb_queue_walk(amsdu, msdu) {
ath10k_htt_rx_h_csum_offload(msdu);
@@ -1424,6 +1484,9 @@ static void ath10k_htt_rx_h_mpdu(struct ath10k *ar,
if (is_mgmt)
continue;
+ if (fill_crypt_header)
+ continue;
+
hdr = (void *)msdu->data;
hdr->frame_control &= ~__cpu_to_le16(IEEE80211_FCTL_PROTECTED);
}
@@ -1434,6 +1497,9 @@ static void ath10k_htt_rx_h_deliver(struct ath10k *ar,
struct ieee80211_rx_status *status)
{
struct sk_buff *msdu;
+ struct sk_buff *first_subframe;
+
+ first_subframe = skb_peek(amsdu);
while ((msdu = __skb_dequeue(amsdu))) {
/* Setup per-MSDU flags */
@@ -1442,6 +1508,13 @@ static void ath10k_htt_rx_h_deliver(struct ath10k *ar,
else
status->flag |= RX_FLAG_AMSDU_MORE;
+ if (msdu == first_subframe) {
+ first_subframe = NULL;
+ status->flag &= ~RX_FLAG_ALLOW_SAME_PN;
+ } else {
+ status->flag |= RX_FLAG_ALLOW_SAME_PN;
+ }
+
ath10k_process_rx(ar, status, msdu);
}
}
@@ -1584,7 +1657,7 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
ath10k_htt_rx_h_unchain(ar, &amsdu);
ath10k_htt_rx_h_filter(ar, &amsdu, rx_status);
- ath10k_htt_rx_h_mpdu(ar, &amsdu, rx_status);
+ ath10k_htt_rx_h_mpdu(ar, &amsdu, rx_status, true);
ath10k_htt_rx_h_deliver(ar, &amsdu, rx_status);
return num_msdus;
@@ -1923,7 +1996,7 @@ static int ath10k_htt_rx_in_ord_ind(struct ath10k *ar, struct sk_buff *skb,
budget_left -= skb_queue_len(&amsdu);
ath10k_htt_rx_h_ppdu(ar, &amsdu, status, vdev_id);
ath10k_htt_rx_h_filter(ar, &amsdu, status);
- ath10k_htt_rx_h_mpdu(ar, &amsdu, status);
+ ath10k_htt_rx_h_mpdu(ar, &amsdu, status, false);
ath10k_htt_rx_h_deliver(ar, &amsdu, status);
break;
case -EAGAIN:
diff --git a/drivers/net/wireless/ath/ath10k/rx_desc.h b/drivers/net/wireless/ath/ath10k/rx_desc.h
index c1022a1cf855..28da14398951 100644
--- a/drivers/net/wireless/ath/ath10k/rx_desc.h
+++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
@@ -239,6 +239,9 @@ enum htt_rx_mpdu_encrypt_type {
HTT_RX_MPDU_ENCRYPT_WAPI = 5,
HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2 = 6,
HTT_RX_MPDU_ENCRYPT_NONE = 7,
+ HTT_RX_MPDU_ENCRYPT_AES_CCM256_WPA2 = 8,
+ HTT_RX_MPDU_ENCRYPT_AES_GCMP_WPA2 = 9,
+ HTT_RX_MPDU_ENCRYPT_AES_GCMP256_WPA2 = 10,
};
#define RX_MPDU_START_INFO0_PEER_IDX_MASK 0x000007ff
--
2.7.4
^ permalink raw reply related
* Re: [linuxwifi] Support Help on WiFi driver
From: Luciano Coelho @ 2017-10-26 19:20 UTC (permalink / raw)
To: Edwin Amurao, linux-wireless@vger.kernel.org; +Cc: linuxwifi@intel.com
In-Reply-To: <1509045513.4492.80.camel@intel.com>
BTW, all mailing lists @vger.kernel.org drop emails sent in HTML
format, so your original email didn't reach it.
--
Cheers,
Luca.
On Thu, 2017-10-26 at 22:18 +0300, Luciano Coelho wrote:
> Hi Edwin,
>
> Please give us a bit more information. What is the kernel version
> that your distro uses? And what is the WiFi card that yo have in this
> machine?
>
> Also, a dmesg output can help us start the investigation.
>
> --
> Cheers,
> Luca.
>
> On Thu, 2017-10-26 at 13:44 +0000, Edwin Amurao wrote:
> > Hi!
> >
> > I have an INTEL NUC5CFYPH and have installed Linux Mint 17.3. The
> > wifi cannot be detected by the system. What driver should I
> > download and how to make it work?
> >
> > Thank you,
> > Edwin Amurao
^ permalink raw reply
* Re: Commit 0711d638 breaks mwifiex
From: Brian Norris @ 2017-10-26 21:13 UTC (permalink / raw)
To: Johannes Berg
Cc: Jesse Sung, Amitkumar Karwar, Nishant Sarmukadam, Ilan Peer,
Anthony Wong, Jason Yen, Terry.Wey, linux-wireless,
Ganapathi Bhat
In-Reply-To: <1508237298.10607.76.camel@sipsolutions.net>
Hi,
I'm not sure I've followed all the problems here, but I wanted to point
some things out:
On Tue, Oct 17, 2017 at 12:48:18PM +0200, Johannes Berg wrote:
> On Tue, 2017-10-17 at 18:18 +0800, Jesse Sung wrote:
>
> > > Does mwifiex treat this -EALREADY as *keeping* an old connection,
> > > or tearing it down entirely?
> >
> > From the call trace:
>
> Well, the call trace can't really answer that :-)
> Does mwifiex firmware stay connected?
IIUC, mwifiex hasn't told the firmware to do anything at this point --
the -EALREADY check is practically the first thing it does within
connect(). So it just quits the connect() request and tries to carry on
as usual. It will only do something different if the upper layers tell
it to do so afterward (e.g., calling disconnect()).
> > 139.451318: nl80211_get_valid_chan <-nl80211_connect
> > 139.451321: cfg80211_connect <-nl80211_connect
> > 139.451322: cfg80211_oper_and_ht_capa <-cfg80211_connect
> > 139.451323: mwifiex_cfg80211_connect <-cfg80211_connect
> > 139.451337: nl80211_post_doit <-genl_family_rcv_msg
> > 139.451423: nl80211_pre_doit <-genl_family_rcv_msg
> > 139.451425: nl80211_disconnect <-genl_family_rcv_msg
> > 139.451426: cfg80211_disconnect <-nl80211_disconnect
> > 139.451430: mwifiex_cfg80211_disconnect <-cfg80211_disconnect
> >
> > mwifiex_cfg80211_disconnect() would be called after
> > mwifiex_cfg80211_connect(), though I'm not sure if it's triggered by
> > the error returned.
>
> I think so - it's probably wpa_supplicant trying to get back to a well-
> known state (of being disconnected).
Yes, that's definitely what's happening. And it's explicitly called out
in the supplicant's nl80211 driver that this is intentional:
static int wpa_driver_nl80211_connect(
struct wpa_driver_nl80211_data *drv,
struct wpa_driver_associate_params *params)
{
...
ret = wpa_driver_nl80211_try_connect(drv, params);
if (ret == -EALREADY) {
/*
* cfg80211 does not currently accept new connections if
* we are already connected. As a workaround, force
* disconnection and try again.
*/
wpa_printf(MSG_DEBUG, "nl80211: Explicitly "
"disconnecting before reassociation "
"attempt");
if (wpa_driver_nl80211_disconnect(
drv, WLAN_REASON_PREV_AUTH_NOT_VALID))
return -1;
ret = wpa_driver_nl80211_try_connect(drv, params);
}
return ret;
}
This is the main code path for supplicant commands like "Reattach",
which boil down to (for non SME drivers):
wpas_request_connection()
...
-> wpa_supplicant_connect()
-> wpa_supplicant_associate()
-> wpas_start_assoc_cb()
-> wpa_drv_associate()
-> wpa_driver_nl80211_associate()
-> wpa_driver_nl80211_connect()
Now for the part I'm not so familiar with: is this really the *expected*
flow for full-MAC drivers in reattach, reassociate, and roaming flows?
All of those seem to boil down to this same connect() (and fallback to
disconnect()+connect() if -EALREADY) flow.
But it doesn't seem like all full-MAC drivers do the same thing. Some
seem to just blaze ahead with a connect attempt (maybe some firmwares
automatically interpret this for us?) and never return -EALREADY at all.
Sorry if this is slightly off-topic, but I'm trying to understand what
the general expectations are here, based on my relatively narrow
experience with a few drivers.
Brian
^ permalink raw reply
* Re: RTL usb adapter question
From: David Ashley @ 2017-10-26 21:45 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <5f907d16-b889-f7c0-0873-880e5c812ab9@lwfinger.net>
OK I'm completely baffled.
I have explicitly removed all rtlwifi/ firmware files from the root
filesystem and yet the usb dongle still works, even after a power
cycle. How can it possibly be getting its firmware file????????
Here are the relevant kernel messages. There is no file
rtl8192cufw.bin anywhere for the kernel to find...
root@30046:~# ls -l /lib/firmware/rtlwifi/
total 0
I have ensured there is no *OTHER* route to the internet such that the
driver (or udev) can magically get the firmware file from the
internet...
Here's other info that may be useful...
root@30046:~# zcat /proc/config.gz | grep FIRM
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE="am335x-pm-firmware.elf
am335x-bone-scale-data.bin am335x-evm-scale-data.bin
am43x-evm-scale-data.bin"
CONFIG_EXTRA_FIRMWARE_DIR="firmware"
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_FIRMWARE_MEMMAP is not set
# CONFIG_TEST_FIRMWARE is not set
root@30046:~# cat /proc/version
Linux version 4.1.19-bone20 (dash@DaveDesktop) (gcc version 5.4.0
20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #2 Tue Oct 3
17:25:35 CDT 2017
root@30046:~# lsusb
Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
802.11n Wireless Adapter [Realtek RTL8188CUS]
... ifconfig
wlan0 Link encap:Ethernet HWaddr 74:da:38:61:f1:2c
inet addr:192.168.10.31 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fe80::76da:38ff:fe61:f12c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:509 errors:0 dropped:0 overruns:0 frame:0
TX packets:146 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:60812 (59.3 KiB) TX bytes:16365 (15.9 KiB)
[ 9.663796] rtl8192cu: Chip version 0x10
[ 9.745394] cfg80211: Calling CRDA to update world regulatory domain
[ 9.844311] random: nonblocking pool is initialized
[ 9.877851] rtl8192cu: MAC address: 74:da:38:61:f1:2c
[ 9.877883] rtl8192cu: Board Type 0
[ 9.877989] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[ 9.878098] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[ 9.878249] usb 1-1: Direct firmware load for
rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
[ 9.889781] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[ 9.890862] usbcore: registered new interface driver rtl8192cu
[ 9.897667] usb 1-1: Direct firmware load for
rtlwifi/rtl8192cufw.bin failed with error -2
[ 9.906030] rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
[ 9.906037] rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not available
[ 11.316476] rtl8192cu: MAC auto ON okay!
[ 11.333847] rtl8192cu: Tx queue select: 0x05
[ 12.364722] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 12.905367] cfg80211: Calling CRDA to update world regulatory domain
[ 13.413043] rtl8192cu: MAC auto ON okay!
[ 13.430371] rtl8192cu: Tx queue select: 0x05
[ 15.795679] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 16.065356] cfg80211: Calling CRDA to update world regulatory domain
[ 19.225333] cfg80211: Calling CRDA to update world regulatory domain
[ 21.582749] wlan0: authenticate with 70:4d:7b:1d:91:40
[ 21.600676] wlan0: send auth to 70:4d:7b:1d:91:40 (try 1/3)
[ 21.605390] wlan0: authenticated
[ 21.615431] wlan0: associate with 70:4d:7b:1d:91:40 (try 1/3)
[ 21.667523] wlan0: RX AssocResp from 70:4d:7b:1d:91:40 (capab=0x411
status=0 aid=5)
[ 21.669000] wlan0: associated
[ 21.669671] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 22.385320] cfg80211: Calling CRDA to update world regulatory domain
[ 25.545336] cfg80211: Calling CRDA to update world regulatory domain
[ 28.705312] cfg80211: Calling CRDA to update world regulatory domain
[ 31.865335] cfg80211: Calling CRDA to update world regulatory domain
[ 35.025348] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
Thanks!!!!!!
-Dave
On 10/25/17, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 10/25/2017 01:43 PM, David Ashley wrote:
>> I'm trying to understand how the linux kernel loads RTL8188CUS firmware
>> rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
>> when that file isn't available anywhere in my embedded system's
>> filesystem.
>>
>> Basically I'm trying to understand the theory. We have a product that
>> is making use of the device
>>
>> Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd
>> EW-7811Un802.11n Wireless Adapter [Realtek RTL8188CUS]
>>
>> It has not been especially reliable. I've never provided firmware
>> files for the device in the root filesystem. I've started to pay
>> attention to the kernel error messages. Now the kernel drivers seem to
>> be loading the rtlwifi/rtl8192cufw_TMSC.bin file and I'm trying to
>> understand if this is actually working, if it makes any difference in
>> reliability...
>>
>> It's like I can't figure out how the usb dongle even worked without
>> its firmware file...
>>
>> My working theory is that the usb dongle comes from the factory with a
>> hardcoded firmware file (rtlwifi/rtl8192cufw.bin) but it is buggy or
>> inferior. And the performance and reliability can be improved if the
>> driver successfully manages to load the rtl8192cufw_TMSC.bin file. I
>> don't know if the firmware load persists across a power cycle (my
>> assumption is it doesn't).
>
> There is NO firmware coded by the factory in the device. It only has enough
>
> intelligence to load the real firmware. The exact file that it loads is
> determined by the model. If you provide the appropriate section of the
> output of
> dmesg where the above firmware messages occur, and a file listing of
> /lib/firmware/rtlwifi/, I can tell you what firmware is being loaded.
>
> No, firmware will not persist across a power failure.
>
> The driver has never been particularly reliable, and the USB group at
> Realtek
> seems not to care. You might try their other driver, but you will be on your
>
> own, as I will not support that particular piece of ****.
>
> Please reply to all on any followups.
>
> Larry
>
>
^ permalink raw reply
* Re: RTL usb adapter question
From: James Cameron @ 2017-10-26 22:00 UTC (permalink / raw)
To: David Ashley; +Cc: linux-wireless
In-Reply-To: <CABkE59A2Cr5mx3W_rkHj+qDtu6t-MQ2V_sJPfuuqF4vbJ7YfmQ@mail.gmail.com>
Base on your evidence, I'd say the device is different to others and
has firmware included.
On Thu, Oct 26, 2017 at 04:45:54PM -0500, David Ashley wrote:
> OK I'm completely baffled.
>
> I have explicitly removed all rtlwifi/ firmware files from the root
> filesystem and yet the usb dongle still works, even after a power
> cycle. How can it possibly be getting its firmware file????????
>
> Here are the relevant kernel messages. There is no file
> rtl8192cufw.bin anywhere for the kernel to find...
> root@30046:~# ls -l /lib/firmware/rtlwifi/
> total 0
>
> I have ensured there is no *OTHER* route to the internet such that the
> driver (or udev) can magically get the firmware file from the
> internet...
>
> Here's other info that may be useful...
>
> root@30046:~# zcat /proc/config.gz | grep FIRM
> CONFIG_PREVENT_FIRMWARE_BUILD=y
> CONFIG_FIRMWARE_IN_KERNEL=y
> CONFIG_EXTRA_FIRMWARE="am335x-pm-firmware.elf
> am335x-bone-scale-data.bin am335x-evm-scale-data.bin
> am43x-evm-scale-data.bin"
> CONFIG_EXTRA_FIRMWARE_DIR="firmware"
> # CONFIG_LIBERTAS_THINFIRM is not set
> # CONFIG_FIRMWARE_MEMMAP is not set
> # CONFIG_TEST_FIRMWARE is not set
> root@30046:~# cat /proc/version
> Linux version 4.1.19-bone20 (dash@DaveDesktop) (gcc version 5.4.0
> 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #2 Tue Oct 3
> 17:25:35 CDT 2017
> root@30046:~# lsusb
> Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
> 802.11n Wireless Adapter [Realtek RTL8188CUS]
>
> ... ifconfig
> wlan0 Link encap:Ethernet HWaddr 74:da:38:61:f1:2c
> inet addr:192.168.10.31 Bcast:192.168.10.255 Mask:255.255.255.0
> inet6 addr: fe80::76da:38ff:fe61:f12c/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:509 errors:0 dropped:0 overruns:0 frame:0
> TX packets:146 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:60812 (59.3 KiB) TX bytes:16365 (15.9 KiB)
>
>
>
>
> [ 9.663796] rtl8192cu: Chip version 0x10
> [ 9.745394] cfg80211: Calling CRDA to update world regulatory domain
> [ 9.844311] random: nonblocking pool is initialized
> [ 9.877851] rtl8192cu: MAC address: 74:da:38:61:f1:2c
> [ 9.877883] rtl8192cu: Board Type 0
> [ 9.877989] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
> [ 9.878098] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
> [ 9.878249] usb 1-1: Direct firmware load for
> rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
> [ 9.889781] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
> [ 9.890862] usbcore: registered new interface driver rtl8192cu
> [ 9.897667] usb 1-1: Direct firmware load for
> rtlwifi/rtl8192cufw.bin failed with error -2
> [ 9.906030] rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
> [ 9.906037] rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not available
> [ 11.316476] rtl8192cu: MAC auto ON okay!
> [ 11.333847] rtl8192cu: Tx queue select: 0x05
> [ 12.364722] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 12.905367] cfg80211: Calling CRDA to update world regulatory domain
> [ 13.413043] rtl8192cu: MAC auto ON okay!
> [ 13.430371] rtl8192cu: Tx queue select: 0x05
> [ 15.795679] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
> [ 16.065356] cfg80211: Calling CRDA to update world regulatory domain
> [ 19.225333] cfg80211: Calling CRDA to update world regulatory domain
> [ 21.582749] wlan0: authenticate with 70:4d:7b:1d:91:40
> [ 21.600676] wlan0: send auth to 70:4d:7b:1d:91:40 (try 1/3)
> [ 21.605390] wlan0: authenticated
> [ 21.615431] wlan0: associate with 70:4d:7b:1d:91:40 (try 1/3)
> [ 21.667523] wlan0: RX AssocResp from 70:4d:7b:1d:91:40 (capab=0x411
> status=0 aid=5)
> [ 21.669000] wlan0: associated
> [ 21.669671] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> [ 22.385320] cfg80211: Calling CRDA to update world regulatory domain
> [ 25.545336] cfg80211: Calling CRDA to update world regulatory domain
> [ 28.705312] cfg80211: Calling CRDA to update world regulatory domain
> [ 31.865335] cfg80211: Calling CRDA to update world regulatory domain
> [ 35.025348] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
>
>
> Thanks!!!!!!
> -Dave
>
> On 10/25/17, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > On 10/25/2017 01:43 PM, David Ashley wrote:
> >> I'm trying to understand how the linux kernel loads RTL8188CUS firmware
> >> rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
> >> when that file isn't available anywhere in my embedded system's
> >> filesystem.
> >>
> >> Basically I'm trying to understand the theory. We have a product that
> >> is making use of the device
> >>
> >> Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd
> >> EW-7811Un802.11n Wireless Adapter [Realtek RTL8188CUS]
> >>
> >> It has not been especially reliable. I've never provided firmware
> >> files for the device in the root filesystem. I've started to pay
> >> attention to the kernel error messages. Now the kernel drivers seem to
> >> be loading the rtlwifi/rtl8192cufw_TMSC.bin file and I'm trying to
> >> understand if this is actually working, if it makes any difference in
> >> reliability...
> >>
> >> It's like I can't figure out how the usb dongle even worked without
> >> its firmware file...
> >>
> >> My working theory is that the usb dongle comes from the factory with a
> >> hardcoded firmware file (rtlwifi/rtl8192cufw.bin) but it is buggy or
> >> inferior. And the performance and reliability can be improved if the
> >> driver successfully manages to load the rtl8192cufw_TMSC.bin file. I
> >> don't know if the firmware load persists across a power cycle (my
> >> assumption is it doesn't).
> >
> > There is NO firmware coded by the factory in the device. It only has enough
> >
> > intelligence to load the real firmware. The exact file that it loads is
> > determined by the model. If you provide the appropriate section of the
> > output of
> > dmesg where the above firmware messages occur, and a file listing of
> > /lib/firmware/rtlwifi/, I can tell you what firmware is being loaded.
> >
> > No, firmware will not persist across a power failure.
> >
> > The driver has never been particularly reliable, and the USB group at
> > Realtek
> > seems not to care. You might try their other driver, but you will be on your
> >
> > own, as I will not support that particular piece of ****.
> >
> > Please reply to all on any followups.
> >
> > Larry
> >
> >
--
James Cameron
http://quozl.netrek.org/
^ permalink raw reply
* Re: rtlwifi oops
From: nirinA raseliarison @ 2017-10-27 1:08 UTC (permalink / raw)
To: Larry Finger, James Cameron, linux-wireless
In-Reply-To: <d9e6052f-cc92-813b-6cd6-9907f5bd82be@gmail.com>
hi all,
i applied the patch against 4.13.8. i still got some trouble, dmesg is
below.
after i plugged the device, it seems to be detected and all modules loaded,
but when i tried to connect to an access point, by using wicd, it halted
after
a while. at this point, all usb ports are broken, there was no more log
in dmesg,
lsusb still showed the device even after being unplugged. it got even
worse as
reboot failed.
i cannot really trace the error as right now all thing works fine.
##
[101297.211119] usb 2-1.4: new high-speed USB device number 6 using ehci-pci
[101297.290836] usb 2-1.4: New USB device found, idVendor=0bda,
idProduct=8178
[101297.290839] usb 2-1.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[101297.290840] usb 2-1.4: Product: 802.11n WLAN Adapter
[101297.290841] usb 2-1.4: Manufacturer: Realtek
[101297.290842] usb 2-1.4: SerialNumber: 00e04c000001
[101297.841845] rtl8192cu: Chip version 0x11
[101297.973333] rtl8192cu: Board Type 0
[101297.973581] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[101297.973621] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[101297.973743] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[101297.973923] usbcore: registered new interface driver rtl8192cu
[101298.013513] usbcore: registered new interface driver rtl8xxxu
[101298.113014] rtl8192cu 2-1.4:1.0 wlan125: renamed from wlan0
[101298.116255] rtl8192cu 2-1.4:1.0 wlan4: renamed from wlan125
[101298.319580] usb 2-1.4: USB disconnect, device number 6
[101298.508120] usb 2-1.4: new high-speed USB device number 7 using ehci-pci
[101298.748134] usb 2-1.4: new high-speed USB device number 8 using ehci-pci
[101298.827700] usb 2-1.4: New USB device found, idVendor=0bda,
idProduct=8178
[101298.827702] usb 2-1.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[101298.827703] usb 2-1.4: Product: 802.11n WLAN Adapter
[101298.827704] usb 2-1.4: Manufacturer: Realtek
[101298.827705] usb 2-1.4: SerialNumber: 00e04c000001
[101298.828320] rtl8192cu: Chip version 0x11
[101298.907705] rtl8192cu: Board Type 0
[101298.907945] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[101298.907976] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[101298.908145] ieee80211 phy1: Selected rate control algorithm 'rtl_rc'
[101298.922774] rtl8192cu 2-1.4:1.0 wlan124: renamed from wlan0
[101298.926242] rtl8192cu 2-1.4:1.0 wlan4: renamed from wlan124
[101312.904723] rtl8192cu: MAC auto ON okay!
[101312.939101] rtl8192cu: Tx queue select: 0x05
[101313.541630] IPv6: ADDRCONF(NETDEV_UP): wlan4: link is not ready
[101322.297910] rtl8192cu: MAC auto ON okay!
[101322.331036] rtl8192cu: Tx queue select: 0x05
[101322.933065] IPv6: ADDRCONF(NETDEV_UP): wlan4: link is not ready
[101323.089905] rtl8192cu: MAC auto ON okay!
[101323.122907] rtl8192cu: Tx queue select: 0x05
[101323.730181] IPv6: ADDRCONF(NETDEV_UP): wlan4: link is not ready
[101325.455267] usb 2-1.4: USB disconnect, device number 8
[101325.460166] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut!
status:0xffffffed value=0xf90000
[101325.460168] rtl_usb: reg 0x422, usbctrl_vendorreq TimeOut!
status:0xffffffed value=0x1000000
[101325.460171] rtl_usb: reg 0x542, usbctrl_vendorreq TimeOut!
status:0xffffffed value=0x3fd0000
[101325.460186] rtl_usb: reg 0x102, usbctrl_vendorreq TimeOut!
status:0xffffffed value=0xf90000
[101325.655146] usb 2-1.4: new high-speed USB device number 9 using ehci-pci
[101325.734893] usb 2-1.4: New USB device found, idVendor=0bda,
idProduct=8178
[101325.734897] usb 2-1.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[101325.734898] usb 2-1.4: Product: 802.11n WLAN Adapter
[101325.734899] usb 2-1.4: Manufacturer: Realtek
[101325.734900] usb 2-1.4: SerialNumber: 00e04c000001
[101325.735636] rtl8192cu: Chip version 0x11
[101325.812035] rtl8192cu: Board Type 0
[101325.812394] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[101325.812470] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[101325.812725] ieee80211 phy2: Selected rate control algorithm 'rtl_rc'
[101325.827120] rtl8192cu 2-1.4:1.0 wlan123: renamed from wlan0
[101325.832254] rtl8192cu 2-1.4:1.0 wlan4: renamed from wlan123
[101332.879463] usb 2-1.4: USB disconnect, device number 9
[101333.072149] usb 2-1.4: new high-speed USB device number 10 using
ehci-pci
[101333.151841] usb 2-1.4: New USB device found, idVendor=0bda,
idProduct=8178
[101333.151843] usb 2-1.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[101333.151845] usb 2-1.4: Product: 802.11n WLAN Adapter
[101333.151846] usb 2-1.4: Manufacturer: Realtek
[101333.151847] usb 2-1.4: SerialNumber: 00e04c000001
[101333.152585] rtl8192cu: Chip version 0x11
[101333.229738] rtl8192cu: Board Type 0
[101333.229963] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[101333.230038] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[101333.230298] ieee80211 phy3: Selected rate control algorithm 'rtl_rc'
[101333.491111] rtl8192cu 2-1.4:1.0 wlan122: renamed from wlan0
[101333.496349] rtl8192cu 2-1.4:1.0 wlan4: renamed from wlan122
[101334.226575] rtl8192cu: MAC auto ON okay!
[101334.260084] rtl8192cu: Tx queue select: 0x05
[101334.859863] IPv6: ADDRCONF(NETDEV_UP): wlan4: link is not ready
[101335.962440] wlan4: authenticate with 16:6b:72:6d:9d:fc
[101335.986731] wlan4: send auth to 16:6b:72:6d:9d:fc (try 1/3)
[101335.990957] wlan4: authenticated
[101335.991154] wlan4: associate with 16:6b:72:6d:9d:fc (try 1/3)
[101336.001221] wlan4: RX AssocResp from 16:6b:72:6d:9d:fc (capab=0x431
status=0 aid=1)
[101336.103329] wlan4: associated
[101336.103374] IPv6: ADDRCONF(NETDEV_CHANGE): wlan4: link becomes ready
[101340.303166] usb 2-1.4: USB disconnect, device number 10
[101340.307127] wlan4: deauthenticating from 16:6b:72:6d:9d:fc by local
choice (Reason: 3=DEAUTH_LEAVING)
[101340.512116] usb 2-1.4: new high-speed USB device number 11 using
ehci-pci
[101340.591917] usb 2-1.4: New USB device found, idVendor=0bda,
idProduct=8178
[101340.591919] usb 2-1.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[101340.591920] usb 2-1.4: Product: 802.11n WLAN Adapter
[101340.591921] usb 2-1.4: Manufacturer: Realtek
[101340.591922] usb 2-1.4: SerialNumber: 00e04c000001
[101340.592659] rtl8192cu: Chip version 0x11
[101340.674039] rtl8192cu: Board Type 0
[101340.674283] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[101340.674313] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[101340.674430] ieee80211 phy4: Selected rate control algorithm 'rtl_rc'
[101340.684805] rtl8192cu 2-1.4:1.0 wlan121: renamed from wlan0
[101340.689245] rtl8192cu 2-1.4:1.0 wlan4: renamed from wlan121
[101340.695908] rtl8192cu: MAC auto ON okay!
[101340.735041] rtl8192cu: Tx queue select: 0x05
[101341.500551] rtl8192c_common: Polling FW ready fail!
REG_MCUFWDL:0x00030006.
[101341.500552] rtl8192c_common: Firmware is not ready to run!
[101341.855695] IPv6: ADDRCONF(NETDEV_UP): wlan4: link is not ready
[101342.201571] rtl8192cu: 8051 reset failed!.........................
[101343.273517] rtl8192cu: MAC auto ON okay!
[101343.306265] rtl8192cu: Tx queue select: 0x05
[101343.917002] IPv6: ADDRCONF(NETDEV_UP): wlan4: link is not ready
[101347.486500] rtl8192cu: MAC auto ON okay!
[101348.239112] usb 2-1.4: USB disconnect, device number 11
[101348.240514] rtl8192cu: Tx queue select: 0x05
##
--
nirinA
^ permalink raw reply
* Re: RTL usb adapter question
From: David Ashley @ 2017-10-27 1:28 UTC (permalink / raw)
To: James Cameron; +Cc: linux-wireless
In-Reply-To: <20171026220013.GC9888@us.netrek.org>
I opened up the dongle, it has these things inside (aside from 2 coils
and various resistors and capacitors)
1)
48 pin chip (9 pins, 15 pins, 9 pins, 15 pins)
REALTEK
RTL8188CUS
F6J23P2
GF27 TAIWAN
6 pin chip (3 pins,3 pins)
BZ5JA
40.0 mhz crystal oscillator
I was thinking maybe some serial eeprom would be included, but there wasn't one.
-Dave
On 10/26/17, James Cameron <quozl@laptop.org> wrote:
> Base on your evidence, I'd say the device is different to others and
> has firmware included.
>
> On Thu, Oct 26, 2017 at 04:45:54PM -0500, David Ashley wrote:
>> OK I'm completely baffled.
>>
>> I have explicitly removed all rtlwifi/ firmware files from the root
>> filesystem and yet the usb dongle still works, even after a power
>> cycle. How can it possibly be getting its firmware file????????
>>
>> Here are the relevant kernel messages. There is no file
>> rtl8192cufw.bin anywhere for the kernel to find...
>> root@30046:~# ls -l /lib/firmware/rtlwifi/
>> total 0
>>
>> I have ensured there is no *OTHER* route to the internet such that the
>> driver (or udev) can magically get the firmware file from the
>> internet...
>>
>> Here's other info that may be useful...
>>
>> root@30046:~# zcat /proc/config.gz | grep FIRM
>> CONFIG_PREVENT_FIRMWARE_BUILD=y
>> CONFIG_FIRMWARE_IN_KERNEL=y
>> CONFIG_EXTRA_FIRMWARE="am335x-pm-firmware.elf
>> am335x-bone-scale-data.bin am335x-evm-scale-data.bin
>> am43x-evm-scale-data.bin"
>> CONFIG_EXTRA_FIRMWARE_DIR="firmware"
>> # CONFIG_LIBERTAS_THINFIRM is not set
>> # CONFIG_FIRMWARE_MEMMAP is not set
>> # CONFIG_TEST_FIRMWARE is not set
>> root@30046:~# cat /proc/version
>> Linux version 4.1.19-bone20 (dash@DaveDesktop) (gcc version 5.4.0
>> 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4) ) #2 Tue Oct 3
>> 17:25:35 CDT 2017
>> root@30046:~# lsusb
>> Bus 001 Device 002: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
>> 802.11n Wireless Adapter [Realtek RTL8188CUS]
>>
>> ... ifconfig
>> wlan0 Link encap:Ethernet HWaddr 74:da:38:61:f1:2c
>> inet addr:192.168.10.31 Bcast:192.168.10.255
>> Mask:255.255.255.0
>> inet6 addr: fe80::76da:38ff:fe61:f12c/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:509 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:146 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:60812 (59.3 KiB) TX bytes:16365 (15.9 KiB)
>>
>>
>>
>>
>> [ 9.663796] rtl8192cu: Chip version 0x10
>> [ 9.745394] cfg80211: Calling CRDA to update world regulatory domain
>> [ 9.844311] random: nonblocking pool is initialized
>> [ 9.877851] rtl8192cu: MAC address: 74:da:38:61:f1:2c
>> [ 9.877883] rtl8192cu: Board Type 0
>> [ 9.877989] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
>> [ 9.878098] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
>> [ 9.878249] usb 1-1: Direct firmware load for
>> rtlwifi/rtl8192cufw_TMSC.bin failed with error -2
>> [ 9.889781] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
>> [ 9.890862] usbcore: registered new interface driver rtl8192cu
>> [ 9.897667] usb 1-1: Direct firmware load for
>> rtlwifi/rtl8192cufw.bin failed with error -2
>> [ 9.906030] rtlwifi: Loading alternative firmware
>> rtlwifi/rtl8192cufw.bin
>> [ 9.906037] rtlwifi: Firmware rtlwifi/rtl8192cufw_TMSC.bin not
>> available
>> [ 11.316476] rtl8192cu: MAC auto ON okay!
>> [ 11.333847] rtl8192cu: Tx queue select: 0x05
>> [ 12.364722] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [ 12.905367] cfg80211: Calling CRDA to update world regulatory domain
>> [ 13.413043] rtl8192cu: MAC auto ON okay!
>> [ 13.430371] rtl8192cu: Tx queue select: 0x05
>> [ 15.795679] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> [ 16.065356] cfg80211: Calling CRDA to update world regulatory domain
>> [ 19.225333] cfg80211: Calling CRDA to update world regulatory domain
>> [ 21.582749] wlan0: authenticate with 70:4d:7b:1d:91:40
>> [ 21.600676] wlan0: send auth to 70:4d:7b:1d:91:40 (try 1/3)
>> [ 21.605390] wlan0: authenticated
>> [ 21.615431] wlan0: associate with 70:4d:7b:1d:91:40 (try 1/3)
>> [ 21.667523] wlan0: RX AssocResp from 70:4d:7b:1d:91:40 (capab=0x411
>> status=0 aid=5)
>> [ 21.669000] wlan0: associated
>> [ 21.669671] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>> [ 22.385320] cfg80211: Calling CRDA to update world regulatory domain
>> [ 25.545336] cfg80211: Calling CRDA to update world regulatory domain
>> [ 28.705312] cfg80211: Calling CRDA to update world regulatory domain
>> [ 31.865335] cfg80211: Calling CRDA to update world regulatory domain
>> [ 35.025348] cfg80211: Exceeded CRDA call max attempts. Not calling
>> CRDA
>>
>>
>> Thanks!!!!!!
>> -Dave
>>
>> On 10/25/17, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> > On 10/25/2017 01:43 PM, David Ashley wrote:
>> >> I'm trying to understand how the linux kernel loads RTL8188CUS
>> >> firmware
>> >> rtlwifi: Loading alternative firmware rtlwifi/rtl8192cufw.bin
>> >> when that file isn't available anywhere in my embedded system's
>> >> filesystem.
>> >>
>> >> Basically I'm trying to understand the theory. We have a product that
>> >> is making use of the device
>> >>
>> >> Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd
>> >> EW-7811Un802.11n Wireless Adapter [Realtek RTL8188CUS]
>> >>
>> >> It has not been especially reliable. I've never provided firmware
>> >> files for the device in the root filesystem. I've started to pay
>> >> attention to the kernel error messages. Now the kernel drivers seem to
>> >> be loading the rtlwifi/rtl8192cufw_TMSC.bin file and I'm trying to
>> >> understand if this is actually working, if it makes any difference in
>> >> reliability...
>> >>
>> >> It's like I can't figure out how the usb dongle even worked without
>> >> its firmware file...
>> >>
>> >> My working theory is that the usb dongle comes from the factory with a
>> >> hardcoded firmware file (rtlwifi/rtl8192cufw.bin) but it is buggy or
>> >> inferior. And the performance and reliability can be improved if the
>> >> driver successfully manages to load the rtl8192cufw_TMSC.bin file. I
>> >> don't know if the firmware load persists across a power cycle (my
>> >> assumption is it doesn't).
>> >
>> > There is NO firmware coded by the factory in the device. It only has
>> > enough
>> >
>> > intelligence to load the real firmware. The exact file that it loads is
>> > determined by the model. If you provide the appropriate section of the
>> > output of
>> > dmesg where the above firmware messages occur, and a file listing of
>> > /lib/firmware/rtlwifi/, I can tell you what firmware is being loaded.
>> >
>> > No, firmware will not persist across a power failure.
>> >
>> > The driver has never been particularly reliable, and the USB group at
>> > Realtek
>> > seems not to care. You might try their other driver, but you will be on
>> > your
>> >
>> > own, as I will not support that particular piece of ****.
>> >
>> > Please reply to all on any followups.
>> >
>> > Larry
>> >
>> >
>
> --
> James Cameron
> http://quozl.netrek.org/
>
^ 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