* [PATCH] cfg80211: allow scanning on specified frequencies when using wext-compatibility
From: Holger Schurig @ 2009-09-09 11:09 UTC (permalink / raw)
To: John W Linville, linux-wireless, Johannes Berg
Handles the case when SIOCSIWSCAN specified iw_scan_req.num_channels and
iw_scan_req.channels[].
Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Index: linux-wl/net/wireless/scan.c
===================================================================
--- linux-wl.orig/net/wireless/scan.c 2009-09-09 10:38:58.000000000 +0200
+++ linux-wl/net/wireless/scan.c 2009-09-09 11:59:39.000000000 +0200
@@ -607,6 +607,9 @@ int cfg80211_wext_siwscan(struct net_dev
if (!netif_running(dev))
return -ENETDOWN;
+ if (wrqu->data.length == sizeof(struct iw_scan_req))
+ wreq = (struct iw_scan_req *)extra;
+
rdev = cfg80211_get_dev_from_ifindex(dev_net(dev), dev->ifindex);
if (IS_ERR(rdev))
@@ -619,9 +622,14 @@ int cfg80211_wext_siwscan(struct net_dev
wiphy = &rdev->wiphy;
- for (band = 0; band < IEEE80211_NUM_BANDS; band++)
- if (wiphy->bands[band])
- n_channels += wiphy->bands[band]->n_channels;
+ /* Determine number of channels, needed to allocate creq */
+ if (wreq && wreq->num_channels)
+ n_channels = wreq->num_channels;
+ else {
+ for (band = 0; band < IEEE80211_NUM_BANDS; band++)
+ if (wiphy->bands[band])
+ n_channels += wiphy->bands[band]->n_channels;
+ }
creq = kzalloc(sizeof(*creq) + sizeof(struct cfg80211_ssid) +
n_channels * sizeof(void *),
@@ -638,22 +646,41 @@ int cfg80211_wext_siwscan(struct net_dev
creq->n_channels = n_channels;
creq->n_ssids = 1;
- /* all channels */
+ /* translate "Scan on frequencies" request */
i = 0;
for (band = 0; band < IEEE80211_NUM_BANDS; band++) {
int j;
if (!wiphy->bands[band])
continue;
for (j = 0; j < wiphy->bands[band]->n_channels; j++) {
+
+ /* If we have a wireless request structure and the
+ * wireless request specifies frequencies, then search
+ * for the matching hardware channel.
+ */
+ if (wreq && wreq->num_channels) {
+ int k;
+ int wiphy_freq = wiphy->bands[band]->channels[j].center_freq;
+ for (k = 0; k < wreq->num_channels; k++) {
+ int wext_freq = wreq->channel_list[k].m / 100000;
+ if (wext_freq == wiphy_freq)
+ goto wext_freq_found;
+ }
+ goto wext_freq_not_found;
+ }
+
+ wext_freq_found:
creq->channels[i] = &wiphy->bands[band]->channels[j];
i++;
+ wext_freq_not_found: ;
}
}
- /* translate scan request */
- if (wrqu->data.length == sizeof(struct iw_scan_req)) {
- wreq = (struct iw_scan_req *)extra;
+ /* Set real number of channels specified in creq->channels[] */
+ creq->n_channels = i;
+ /* translate "Scan for SSID" request */
+ if (wreq) {
if (wrqu->data.flags & IW_SCAN_THIS_ESSID) {
if (wreq->essid_len > IEEE80211_MAX_SSID_LEN)
return -EINVAL;
^ permalink raw reply
* [PATCH 4/4] ath9k: Initialize the priority gpio for BT coex 3-wire
From: Vasanthakumar Thiagarajan @ 2009-09-09 9:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
In-Reply-To: <1252490152-19284-3-git-send-email-vasanth@atheros.com>
Oops, a stupid mistake in the original patch which adds coex 3-wire
support. Bluetooth priority gpio needs to be gpio 7.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/btcoex.h | 1 +
drivers/net/wireless/ath/ath9k/hw.c | 6 ++++--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/btcoex.h b/drivers/net/wireless/ath/ath9k/btcoex.h
index f1baf66..297b027 100644
--- a/drivers/net/wireless/ath/ath9k/btcoex.h
+++ b/drivers/net/wireless/ath/ath9k/btcoex.h
@@ -19,6 +19,7 @@
#define ATH_WLANACTIVE_GPIO 5
#define ATH_BTACTIVE_GPIO 6
+#define ATH_BTPRIORITY_GPIO 7
#define ATH_BTCOEX_DEF_BT_PERIOD 45
#define ATH_BTCOEX_DEF_DUTY_CYCLE 55
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index c39693b..b6c6cca 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -3691,10 +3691,12 @@ void ath9k_hw_fill_cap_info(struct ath_hw *ah)
btcoex_info->btactive_gpio = ATH_BTACTIVE_GPIO;
btcoex_info->wlanactive_gpio = ATH_WLANACTIVE_GPIO;
- if (AR_SREV_9285(ah))
+ if (AR_SREV_9285(ah)) {
btcoex_info->btcoex_scheme = ATH_BTCOEX_CFG_3WIRE;
- else
+ btcoex_info->btpriority_gpio = ATH_BTPRIORITY_GPIO;
+ } else {
btcoex_info->btcoex_scheme = ATH_BTCOEX_CFG_2WIRE;
+ }
} else {
btcoex_info->btcoex_scheme = ATH_BTCOEX_CFG_NONE;
}
--
1.5.5.1
^ permalink raw reply related
* [PATCH 3/4] ath9k: Get rid of the modparam btcoex_enable
From: Vasanthakumar Thiagarajan @ 2009-09-09 9:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
In-Reply-To: <1252490152-19284-2-git-send-email-vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 8d77817..c39693b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -21,10 +21,6 @@
#include "ath9k.h"
#include "initvals.h"
-static int btcoex_enable;
-module_param(btcoex_enable, bool, 0);
-MODULE_PARM_DESC(btcoex_enable, "Enable Bluetooth coexistence support");
-
#define ATH9K_CLOCK_RATE_CCK 22
#define ATH9K_CLOCK_RATE_5GHZ_OFDM 40
#define ATH9K_CLOCK_RATE_2GHZ_OFDM 44
--
1.5.5.1
^ permalink raw reply related
* [PATCH 2/4] ath9k: Enable btcoex based on the subsystem id of the device
From: Vasanthakumar Thiagarajan @ 2009-09-09 9:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
In-Reply-To: <1252490152-19284-1-git-send-email-vasanth@atheros.com>
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/btcoex.c | 23 +++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/btcoex.h | 1 +
drivers/net/wireless/ath/ath9k/hw.c | 3 ++-
drivers/net/wireless/ath/ath9k/hw.h | 4 ++++
4 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/btcoex.c b/drivers/net/wireless/ath/ath9k/btcoex.c
index e8bfb01..55f607b 100644
--- a/drivers/net/wireless/ath/ath9k/btcoex.c
+++ b/drivers/net/wireless/ath/ath9k/btcoex.c
@@ -19,6 +19,29 @@
static const struct ath_btcoex_config ath_bt_config = { 0, true, true,
ATH_BT_COEX_MODE_SLOTTED, true, true, 2, 5, true };
+static const u16 ath_subsysid_tbl[] = {
+ AR9280_COEX2WIRE_SUBSYSID,
+ AT9285_COEX3WIRE_SA_SUBSYSID,
+ AT9285_COEX3WIRE_DA_SUBSYSID
+};
+
+/*
+ * Checks the subsystem id of the device to see if it
+ * supports btcoex
+ */
+bool ath_btcoex_supported(u16 subsysid)
+{
+ int i;
+
+ if (!subsysid)
+ return false;
+
+ for (i = 0; i < ARRAY_SIZE(ath_subsysid_tbl); i++)
+ if (subsysid == ath_subsysid_tbl[i])
+ return true;
+
+ return false;
+}
/*
* Detects if there is any priority bt traffic
diff --git a/drivers/net/wireless/ath/ath9k/btcoex.h b/drivers/net/wireless/ath/ath9k/btcoex.h
index 4556819..f1baf66 100644
--- a/drivers/net/wireless/ath/ath9k/btcoex.h
+++ b/drivers/net/wireless/ath/ath9k/btcoex.h
@@ -79,6 +79,7 @@ struct ath_btcoex_info {
struct ath_gen_timer *no_stomp_timer; /*Timer for no BT stomping*/
};
+bool ath_btcoex_supported(u16 subsysid);
int ath9k_hw_btcoex_init(struct ath_hw *ah);
void ath9k_hw_btcoex_enable(struct ath_hw *ah);
void ath9k_hw_btcoex_disable(struct ath_hw *ah);
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 97a09db..8d77817 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -3690,7 +3690,8 @@ void ath9k_hw_fill_cap_info(struct ath_hw *ah)
pCap->num_antcfg_2ghz =
ah->eep_ops->get_num_ant_config(ah, ATH9K_HAL_FREQ_BAND_2GHZ);
- if (AR_SREV_9280_10_OR_LATER(ah) && btcoex_enable) {
+ if (AR_SREV_9280_10_OR_LATER(ah) &&
+ ath_btcoex_supported(ah->hw_version.subsysid)) {
btcoex_info->btactive_gpio = ATH_BTACTIVE_GPIO;
btcoex_info->wlanactive_gpio = ATH_WLANACTIVE_GPIO;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 64ea547..9106a0b 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -45,6 +45,10 @@
#define AR5416_DEVID_AR9287_PCI 0x002D
#define AR5416_DEVID_AR9287_PCIE 0x002E
+#define AR9280_COEX2WIRE_SUBSYSID 0x309b
+#define AT9285_COEX3WIRE_SA_SUBSYSID 0x30aa
+#define AT9285_COEX3WIRE_DA_SUBSYSID 0x30ab
+
/* Register read/write primitives */
#define REG_WRITE(_ah, _reg, _val) ath9k_iowrite32((_ah), (_reg), (_val))
#define REG_READ(_ah, _reg) ath9k_ioread32((_ah), (_reg))
--
1.5.5.1
^ permalink raw reply related
* [PATCH 1/4] ath9k: Store subsystem id in struct hw_version
From: Vasanthakumar Thiagarajan @ 2009-09-09 9:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis.Rodriguez, Jouni.Malinen, ath9k-devel
This subsystem id will be used later to turn on the btcoex
support.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
---
drivers/net/wireless/ath/ath9k/ahb.c | 2 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/main.c | 7 ++++---
drivers/net/wireless/ath/ath9k/pci.c | 4 +++-
5 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ahb.c b/drivers/net/wireless/ath/ath9k/ahb.c
index 7dc6301..2ad7d02 100644
--- a/drivers/net/wireless/ath/ath9k/ahb.c
+++ b/drivers/net/wireless/ath/ath9k/ahb.c
@@ -119,7 +119,7 @@ static int ath_ahb_probe(struct platform_device *pdev)
sc->bus_ops = &ath_ahb_bus_ops;
sc->irq = irq;
- ret = ath_init_device(AR5416_AR9100_DEVID, sc);
+ ret = ath_init_device(AR5416_AR9100_DEVID, sc, 0x0);
if (ret) {
dev_err(&pdev->dev, "failed to initialize device\n");
goto err_free_hw;
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 1c68a9d..1d59f10 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -658,7 +658,7 @@ extern struct ieee80211_ops ath9k_ops;
irqreturn_t ath_isr(int irq, void *dev);
void ath_cleanup(struct ath_softc *sc);
-int ath_init_device(u16 devid, struct ath_softc *sc);
+int ath_init_device(u16 devid, struct ath_softc *sc, u16 subsysid);
void ath_detach(struct ath_softc *sc);
const char *ath_mac_bb_name(u32 mac_bb_version);
const char *ath_rf_name(u16 rf_version);
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index a592f1a..64ea547 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -390,6 +390,7 @@ struct ath9k_hw_version {
u16 phyRev;
u16 analog5GhzRev;
u16 analog2GhzRev;
+ u16 subsysid;
};
/* Generic TSF timer definitions */
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index ce011ab..3dc7b5a 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1310,7 +1310,7 @@ static int ath9k_reg_notifier(struct wiphy *wiphy,
* to allow the separation between hardware specific
* variables (now in ath_hw) and driver specific variables.
*/
-static int ath_init_softc(u16 devid, struct ath_softc *sc)
+static int ath_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid)
{
struct ath_hw *ah = NULL;
int r = 0, i;
@@ -1348,6 +1348,7 @@ static int ath_init_softc(u16 devid, struct ath_softc *sc)
ah->ah_sc = sc;
ah->hw_version.devid = devid;
+ ah->hw_version.subsysid = subsysid;
sc->sc_ah = ah;
r = ath9k_hw_init(ah);
@@ -1577,7 +1578,7 @@ void ath_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
}
/* Device driver core initialization */
-int ath_init_device(u16 devid, struct ath_softc *sc)
+int ath_init_device(u16 devid, struct ath_softc *sc, u16 subsysid)
{
struct ieee80211_hw *hw = sc->hw;
int error = 0, i;
@@ -1585,7 +1586,7 @@ int ath_init_device(u16 devid, struct ath_softc *sc)
DPRINTF(sc, ATH_DBG_CONFIG, "Attach ATH hw\n");
- error = ath_init_softc(devid, sc);
+ error = ath_init_softc(devid, sc, subsysid);
if (error != 0)
return error;
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 8b28814..903dd8a 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -88,6 +88,7 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
struct ath_softc *sc;
struct ieee80211_hw *hw;
u8 csz;
+ u16 subsysid;
u32 val;
int ret = 0;
struct ath_hw *ah;
@@ -178,7 +179,8 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
sc->mem = mem;
sc->bus_ops = &ath_pci_bus_ops;
- ret = ath_init_device(id->device, sc);
+ pci_read_config_word(pdev, PCI_SUBSYSTEM_ID, &subsysid);
+ ret = ath_init_device(id->device, sc, subsysid);
if (ret) {
dev_err(&pdev->dev, "failed to initialize device\n");
goto bad3;
--
1.5.5.1
^ permalink raw reply related
* Re: b43 dma error
From: Dave Young @ 2009-09-09 8:05 UTC (permalink / raw)
To: Larry Finger
Cc: Gábor Stefanik, John Daiker, Michael Buesch, linville,
linux-wireless, bcm43xx-dev
In-Reply-To: <4AA6A2B3.2010300@lwfinger.net>
2009/9/9 Larry Finger <Larry.Finger@lwfinger.net>:
> Gábor Stefanik wrote:
>> On Tue, Sep 8, 2009 at 8:16 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
>>> Your PHY and your radio are the same as mine. In fact, the one thing I
>>> noticed is that you are using i386 architecture, whereas mine is
>>> x86_64. I have not tested with i386.
>>>
>>> Has anyone run the LP PHY modifications with 32-bit architecture?
>>
>> Yes, me. (With the exact same card as John.)
>
> Is it a maximum memory issue? How much for you?
1G memory for me.
>
> John and Dave: Same question.
>
> Larry
>
--
Regards
dave
^ permalink raw reply
* Re: b43 dma error
From: Dave Young @ 2009-09-09 8:02 UTC (permalink / raw)
To: Larry Finger
Cc: Michael Buesch, linville, netrolller.3d, linux-wireless,
bcm43xx-dev
In-Reply-To: <4AA67009.4020400@lwfinger.net>
On Tue, Sep 8, 2009 at 10:54 PM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> Michael Buesch wrote:
>> On Tuesday 08 September 2009 15:47:32 Dave Young wrote:
>>> I tested wireless-testing b43 driver, but got "Fatal DMA error"
>>> then the controller keep restarting...
>>>
>>> Please tell what I can provide or test, Thanks.
>>
>> Is this a regression? If so, please bisect.
>
> It is something specific to his system as I don't see anything like
> this. In addition, there are some users on the openSUSE forums that
> have implemented the latest compat-wireless and switched away from
> Broadcom wl to b43 on their LP PHY devices. So far, no complaints from
> them.
>
> Please reboot so that we see the ssb output as well. Use the command
>
> dmesg | egrep "ssb|b43"
>
> That way we will be able to see exactly what kind of device you have
> and what revisions are in it. AFAIK, the testing to date has been
> limited to Rev 1 PHYs and Rev 2 radios.
I use a public pc and I have no lan access for my laptop, so just hand
copy something:
b43-pci-bridge 0000:0c:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
b43-pci-bridge 0000:0c:00.0: setting latency timer to 64
ssb SInics Silicon Backplane found on PCI device 0000:0c:00.0
b43-phy0: Broadcom 4312 WLAN found (core revision 15)
b43-phy0 debug: Found PHY: Analog 6, Type 5, Revision 1
b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2
>
> Larry
>
>
>
--
Regards
dave
^ permalink raw reply
* Re: AP: ath5k + hostapd occasionally sulks
From: Jon Fairbairn @ 2009-09-09 8:01 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4AA69A0D.3040608@redfish-solutions.com>
Philip Prindeville
<philipp_subx@redfish-solutions.com> writes:
> I pulled compat-wireless from GIT last night (or about 1:30am mountain,
> really) and rebuilt a 2.6.27.29 kernel.
>
> I'm seeing a lot of:
>
> Sep 8 11:44:09 pbx user.err kernel: ath5k phy0: no further txbuf available, dropping packet
> Is this a known issue? Jon posted the same question, but I didn't see an
> answer to his question...
Most of the time it works and I don't see anything in the logs, so your
problem is worse than mine... I'm now running
compat-wireless-2009-09-07, but I doubt if that's any different.
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
^ permalink raw reply
* Re: b43 dma error
From: Markus Mueller @ 2009-09-09 7:41 UTC (permalink / raw)
To: Larry Finger
Cc: Gábor Stefanik, John Daiker, Michael Buesch, Dave Young,
linville, linux-wireless, bcm43xx-dev
In-Reply-To: <4AA70DD6.8040905@lwfinger.net>
On Tue, Sep 08, 2009 at 09:07:18PM -0500, Larry Finger wrote:
> After some tests with the 32-bit architecture, I'm now thoroughly
> confused. I tried different memory models including PAE - everything
> worked. I even generated a 2.6.31-rc9-wl kernel with John's config and
> it worked. Whatever is happening is not related to his configuration.
> I'm not sure what the problem is.
>
> I'm going to be offline for a few days - I hope the solution will be
> in my mailbox by the weekend.
I hope so, too :)
I have the same b4312 dma errors.
$ dmesg | tail -7
Registered led device: b43-phy0::rx
Registered led device: b43-phy0::radio
__ratelimit: 8 callbacks suppressed
b43-phy0 ERROR: Fatal DMA error: 0x00000400, 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
b43-phy0: Controller RESET (DMA error) ...
b43-phy0: Controller restarted
b43-phy0: Controller restarted
I built b43 from daily tarball compat-wireless-2009-09-07,tar.bz2 .
Card: B4312 low-power phy,
BCM4312 802.11b/g [14e4:4315] (rev 01) (on a Dell Mini 10, N-Series).
Kernel: 2.6.31-rc9 . 32bit.
Hyperthreading Patch: I assume this means
http://bu3sch.de/patches/wireless-testing/20090816-1535/patches/002-b43-threaded-irq-handler.patch
I did not actually apply this patch, i just checked the source for a few
lines added in this patch and assumed it is merged in the daily tarball
already. Is this correct?
Firmware: Debian Sid. b43-fwcutter version 012 comes with 4.150 fw it
seems. On Openwrt I only found the afore mentioned "v478" firmware
http://downloads.openwrt.org/sources/broadcom-wl-4.178.10.4.tar.bz2 .
b43-fwcutter does not work with it. Is there documentation as to how
to extract newer firmware?
I couldn't find the v5xx firmware. It's nowhere on your sites, is it?
Let me know if there is something I can do to help, but be aware I am
not knowledgeable with linux-wireless, it's my first WLAN Device in
Years. And your site is a bit.. confused.. errm confusing ;)
Cheers,
Markus
^ permalink raw reply
* Re: b43 dma error
From: Dave Young @ 2009-09-09 7:56 UTC (permalink / raw)
To: Michael Buesch; +Cc: linville, netrolller.3d, linux-wireless, bcm43xx-dev
In-Reply-To: <200909081638.36897.mb@bu3sch.de>
On Tue, Sep 8, 2009 at 10:38 PM, Michael Buesch<mb@bu3sch.de> wrote:
> On Tuesday 08 September 2009 15:47:32 Dave Young wrote:
>> I tested wireless-testing b43 driver, but got "Fatal DMA error"
>> then the controller keep restarting...
>>
>> Please tell what I can provide or test, Thanks.
>
> Is this a regression? If so, please bisect.
Not sure, It's the first time for me to use b43 with the lp-phy
because I happend to know it is supported now.
If it's a regression I can do bisection.
>
> --
> Greetings, Michael.
>
--
Regards
dave
^ permalink raw reply
* Re: b43 dma error
From: Dave Young @ 2009-09-09 7:54 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: mb, linville, linux-wireless, bcm43xx-dev
In-Reply-To: <69e28c910909080708n5233a6cfue555bfce170eb145@mail.gmail.com>
2009/9/8 Gábor Stefanik <netrolller.3d@gmail.com>:
> Do you have the threaded-IRQ patches applied?
Could you point the url? where can I get them?
> Also, what card is this?
> (BCM4312?) Try upgrading your firmare (use v478 or the new v5xx one).
>
Yes, BCM4312, I use the firmware according to the guide in
linux-wireless web page, where is the v5xx, could you tell more?
--
Regards
dave
^ permalink raw reply
* ath_tx_start+0xa6 kmemleak -- mac80211 traceb
From: Luis R. Rodriguez @ 2009-09-09 6:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
unreferenced object 0xffff88003a905720 (size 96):
comm "softirq", pid 0, jiffies 4295254599
hex dump (first 32 bytes):
40 98 9e 19 00 88 ff ff 00 00 00 00 00 00 00 00 @...............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff814ea375>] kmemleak_alloc+0x25/0x60
[<ffffffff81118c1b>] kmem_cache_alloc+0x14b/0x1c0
[<ffffffffa03e6cd6>] ath_tx_start+0xa6/0x8d0 [ath9k]
[<ffffffffa03dfc13>] ath9k_tx+0x133/0x2a0 [ath9k]
[<ffffffffa0247e2b>] __ieee80211_tx+0xfb/0x190 [mac80211]
[<ffffffffa0249589>] ieee80211_tx+0xf9/0x2e0 [mac80211]
[<ffffffffa0249886>] ieee80211_xmit+0x116/0x2c0 [mac80211]
[<ffffffffa0249a81>] ieee80211_tx_skb+0x51/0x70 [mac80211]
[<ffffffffa023df3d>] ieee80211_sta_work+0x6fd/0x10d0 [mac80211]
[<ffffffff8106de60>] worker_thread+0x1d0/0x380
[<ffffffff81073246>] kthread+0xa6/0xb0
[<ffffffff810130ca>] child_rip+0xa/0x20
[<ffffffffffffffff>] 0xffffffffffffffff
But gdb shows me:
(gdb) l *(ath_tx_start+0xa6)
0x22d06 is in ath_tx_start (include/trace/events/kmem.h:47).
42 {(unsigned long)__GFP_THISNODE,
"GFP_THISNODE"}, \
43 {(unsigned long)__GFP_RECLAIMABLE,
"GFP_RECLAIMABLE"}, \
44 {(unsigned long)__GFP_MOVABLE, "GFP_MOVABLE"}
\
45 ) : "GFP_NOWAIT"
46
47 TRACE_EVENT(kmalloc,
48
49 TP_PROTO(unsigned long call_site,
50 const void *ptr,
51 size_t bytes_req,
But I don't have the mac80211 tracer enabled.
Luis
^ permalink raw reply
* Re: ar9271 TX/RX buffer management
From: Luis R. Rodriguez @ 2009-09-09 5:39 UTC (permalink / raw)
To: Denis Kirjanov, Benoit PAPILLAULT, Benoit PAPILLAULT
Cc: devel, ath9k-devel, Felix Fietkau, Christian Lamparter,
linux-wireless
Adding linux-wireless as I review ath9k/ar9170 tx/rx buffer management here.
On Tue, Sep 8, 2009 at 1:54 PM, Denis Kirjanov<kirjanov@gmail.com> wrote:
> Looks like tx/rx engine initialization code is very similar to ath9k
> driver.
I expect most of the driver to be very similar to ath9k, what changes
here is the transport and because of it support for HTC/HIF. What also
changes with the new transport requirements is the need to sleep
during read/writes. This is actually the main reason for a new
mac80211 driver interface. We could have mucked with ath9k itself but
feared that the changes are too intrusive so instead we'll work on a
different driver core where this is done. Technically it may be
possible in the future to have ath9k rely on the same driver core, who
knows but for now the job is to get ar9271 support up.
> The question is where to obtain some values such as the number of TX|RX
> buffers? Will these values are the same as that of the previous driver?
That's yet to be determined/developed and I'm glad you asked. First
let me review ath9k's TX/RX buffer management, then I'll review ar9170
buffer management and explain why I think we should consider doing
something a little different for ath9k_htc. Note I wrote ar9170, not
ar9271.
ath9k TX buffer management
========================
ath9k allocates a preset of TX buffers structs (struct ath_buf) upon
init and stuffs them into a spare buffer linked list. When mac80211
informs us it wants to TX an skb, ath9k_tx(), a buffer is taken from
this spare list, the skb is linked to the ath_buf, DMA'd and then the
ath_buf added onto the appropriate tx queue linked list depending on
the skb priority/TID. Upon TX completion the ath_buf is reset and put
back into the spare buffer list. When we are are low on spare ath_buf
buffers we ask mac80211 to stop sending us data, once we have enough
free spare buffers we wake the queues up again. We guarantee that we
will at some point tell mac80211 to send us data again as we only tell
mac80211 to stop sending us data if we have at least one pending
completion buffer list.
ath9k RX buffer management
=========================
ath9k allocates a preset of RX buffers and stuffs them into a linked
list. The buffers are DMA'd so that the hardware can stuff into each
buffer data for us to retrieve and send up to mac80211. Upon RX we
always allocate a new buffer prior to sending a frame up to mac80211
so that we can fill in the gap for the missing skb of the current skb
and if there is no more memory we stuff the buffer we currently are
processing into the free RX buffers linked list and disregard the
DMA'd data. We then tell the hardware it can use that same buffer
space again. If we were able to allocate a new buffer in place for the
current one we send it to mac80211 for processing. We use a
predetermined RX buffer size. This RX buffer size is the space
required to receive the biggest frame possible on the ath9k 802.11n
hardware -- which happens to be the biggest AMSDU frame. I should note
that although AMSDU frames are typically not received as I don't think
many devices or drivers support sending AMDSU frames I believe wifi
cert requires you to RX AMSDU frames. Anyway this AMSDU size
requirement pushes our RX buffer size close to 4 KB and because the
kernel only gaurantees it'll *at least* allocate the requested size we
sometimes end up allocating 8KB per buffer on some systems. We could
potentially improve upon this, I believe we'd have to link AMSDU data
together across different descriptors, and I think that's possible.
ar9170 TX buffer management
=========================
ar9170 uses a tx_pending skb_buf_head for stashing skbs mac80211 sends
it. Contrary to ath9k it uses the skb to place the private driver tx
control info for the skb to indicate to the hardware how to transmit
that frame. Aggregates are put into an another skb_queue_head for the
destination TID for the destination sta and that TID is added to a
linked list of pending TIDs which need processing. It later iterates
through the list of TIDs, and queues pending buffers ont the
tx_pending skb_buf_head. Eventually we peg the skb->data onto a urb
and submit it to the device on the endpoint.
ar9170 RX buffer management
==========================
ar9170 uses a USB stream mode to receive buffers. This means a single
urb received being processed can contain more than one data buffer.
This gets untangled by ar9170_rx() and handled individually on
ar9170_handle_mpdu(). Because the data is tangled on a stream it means
we have to allocate an skb for each frame and then copy the data onto
it. This is done on ar9170_rx_copy_data().
-------------
What I'd like to eventually see is a common shared buffer management
for TX for aggregation for drivers like ar9170 or ath9k where
aggregation is done in software. Then we won't have such different
implementations. Using the skb_buf_head usage on ar9170 seems
appealing over ath9k's linked list of buffers, however not that this
is easily possible on ar9170 as the skb->data is simply filled with
the ar9170_tx_control info. I can't think of a way to do the same on
ath9k. If we can figure out a way it'd be great so we can try to
eventually share buffer management for aggregation on mac80211. I
shall note some aspects of aggregation is handled in firmware for
ar9271, haven't gotten to review what exactly yet.
One thing which I think we should learn from how ar9170 is implemented
for ar9271 is using urb anchors.
Luis
^ permalink raw reply
* Re: [PATCH] ath5k: do not free irq after resume when card has been removed
From: Bob Copeland @ 2009-09-09 3:32 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: ath5k-devel, linux-wireless, netdev, linux-kernel, lrodriguez,
mickflemm, jirislaby, linville, johannes
In-Reply-To: <1252457551-4909-1-git-send-email-cascardo@holoscopio.com>
On Tue, Sep 08, 2009 at 09:52:31PM -0300, Thadeu Lima de Souza Cascardo wrote:
> ath5k will try to request irq when resuming and fails if the device
> (like a PCMCIA card) has been removed.
That's not true, ath5k no longer requests an irq when resuming.
> This solves this issue defining a new flag for the status bitmap to
> indicate when irq has been successfully requested and does not try to
> release it if not.
I'd rather not fix it with a status bit. What kernel is this against?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [ANN] wireless-regdb: master-2009-09-08
From: wireless @ 2009-09-09 3:10 UTC (permalink / raw)
To: linux-wireless
A new release of wireless-regdb (master-2009-09-08) is available at:
http://wireless.kernel.org/download/wireless-regdb/wireless-regdb-2009.09.08.tar.bz2
SHA1 sum: 182af543939be630f2d106028966aabffc145b91
For your convenience the individual regulatory.bin file can be downloaded from:
http://wireless.kernel.org/download/wireless-regdb/regulatory.bins/2009.09.08-regulatory.bin
SHA1 sum 9a4b9cdb1d9147dba37a4d44b0d73e3015574a2e
Here is the short log of the changes included in this
release:
John W. Linville (1):
wireless-regdb: update regulatory.bin based on preceding changes.
Luis R. Rodriguez (1):
wireless-regdb: TH gets 5 GHz enabled as of new regulatory rules
^ permalink raw reply
* Re: b43 dma error
From: Larry Finger @ 2009-09-09 2:07 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Daiker, Michael Buesch, Dave Young, linville, linux-wireless,
bcm43xx-dev
In-Reply-To: <69e28c910909081132l464c2effq31665b22365de1c2@mail.gmail.com>
After some tests with the 32-bit architecture, I'm now thoroughly
confused. I tried different memory models including PAE - everything
worked. I even generated a 2.6.31-rc9-wl kernel with John's config and
it worked. Whatever is happening is not related to his configuration.
I'm not sure what the problem is.
I'm going to be offline for a few days - I hope the solution will be
in my mailbox by the weekend.
Larry
^ permalink raw reply
* [PATCH] ath5k: do not free irq after resume when card has been removed
From: Thadeu Lima de Souza Cascardo @ 2009-09-09 0:52 UTC (permalink / raw)
To: ath5k-devel
Cc: linux-wireless, netdev, linux-kernel, me, lrodriguez, mickflemm,
jirislaby, linville, johannes, Thadeu Lima de Souza Cascardo
ath5k will try to request irq when resuming and fails if the device
(like a PCMCIA card) has been removed. The driver remove function will,
then, be called, trying to free the failed requested irq, resulting in
a warning.
This solves this issue defining a new flag for the status bitmap to
indicate when irq has been successfully requested and does not try to
release it if not.
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
---
drivers/net/wireless/ath/ath5k/base.c | 13 +++++++++++--
drivers/net/wireless/ath/ath5k/base.h | 3 ++-
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 029c1bc..c5e2d5b 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -553,6 +553,7 @@ ath5k_pci_probe(struct pci_dev *pdev,
ATH5K_ERR(sc, "request_irq failed\n");
goto err_free;
}
+ __set_bit(ATH_STAT_IRQREQUESTED, sc->status);
/* Initialize device */
sc->ah = ath5k_hw_attach(sc, id->driver_data);
@@ -628,6 +629,7 @@ ath5k_pci_probe(struct pci_dev *pdev,
err_ah:
ath5k_hw_detach(sc->ah);
err_irq:
+ __clear_bit(ATH_STAT_IRQREQUESTED, sc->status);
free_irq(pdev->irq, sc);
err_free:
ieee80211_free_hw(hw);
@@ -650,7 +652,10 @@ ath5k_pci_remove(struct pci_dev *pdev)
ath5k_debug_finish_device(sc);
ath5k_detach(pdev, hw);
ath5k_hw_detach(sc->ah);
- free_irq(pdev->irq, sc);
+ if (test_bit(ATH_STAT_IRQREQUESTED, sc->status)) {
+ __clear_bit(ATH_STAT_IRQREQUESTED, sc->status);
+ free_irq(pdev->irq, sc);
+ }
pci_iounmap(pdev, sc->iobase);
pci_release_region(pdev, 0);
pci_disable_device(pdev);
@@ -666,7 +671,10 @@ ath5k_pci_suspend(struct pci_dev *pdev, pm_message_t state)
ath5k_led_off(sc);
- free_irq(pdev->irq, sc);
+ if (test_bit(ATH_STAT_IRQREQUESTED, sc->status)) {
+ __clear_bit(ATH_STAT_IRQREQUESTED, sc->status);
+ free_irq(pdev->irq, sc);
+ }
pci_save_state(pdev);
pci_disable_device(pdev);
pci_set_power_state(pdev, PCI_D3hot);
@@ -699,6 +707,7 @@ ath5k_pci_resume(struct pci_dev *pdev)
ATH5K_ERR(sc, "request_irq failed\n");
goto err_no_irq;
}
+ __set_bit(ATH_STAT_IRQREQUESTED, sc->status);
ath5k_led_enable(sc);
return 0;
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index f9b7f2f..4a71437 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -137,12 +137,13 @@ struct ath5k_softc {
size_t desc_len; /* size of TX/RX descriptors */
u16 cachelsz; /* cache line size */
- DECLARE_BITMAP(status, 5);
+ DECLARE_BITMAP(status, 6);
#define ATH_STAT_INVALID 0 /* disable hardware accesses */
#define ATH_STAT_MRRETRY 1 /* multi-rate retry support */
#define ATH_STAT_PROMISC 2
#define ATH_STAT_LEDSOFT 3 /* enable LED gpio status */
#define ATH_STAT_STARTED 4 /* opened & irqs enabled */
+#define ATH_STAT_IRQREQUESTED 5 /* irq requested */
unsigned int filter_flags; /* HW flags, AR5K_RX_FILTER_* */
unsigned int curmode; /* current phy mode */
--
1.6.3.3
^ permalink raw reply related
* Re: ipw2200: firmware DMA loading rework
From: Simon Kitching @ 2009-09-08 20:39 UTC (permalink / raw)
To: Mel Gorman
Cc: Theodore Tso, Luis R. Rodriguez, Bartlomiej Zolnierkiewicz,
Aneesh Kumar K.V, Zhu Yi, Andrew Morton, Johannes Weiner,
Pekka Enberg, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Mel Gorman, netdev@vger.kernel.org,
linux-mm@kvack.org, James Ketrenos, Chatre, Reinette,
linux-wireless@vger.kernel.org,
ipw2100-devel@lists.sourceforge.net
In-Reply-To: <20090908110041.GE28127@csn.ul.ie>
On Tue, 2009-09-08 at 12:00 +0100, Mel Gorman wrote:
> On Sat, Sep 05, 2009 at 10:28:37AM -0400, Theodore Tso wrote:
> > On Thu, Sep 03, 2009 at 01:49:14PM +0100, Mel Gorman wrote:
> > > >
> > > > This looks very similar to the kmemleak ext4 reports upon a mount. If
> > > > it is the same issue, which from the trace it seems it is, then this
> > > > is due to an extra kmalloc() allocation and this apparently will not
> > > > get fixed on 2.6.31 due to the closeness of the merge window and the
> > > > non-criticalness this issue has been deemed.
> >
> > No, it's a different problem.
> >
> > > I suspect the more pressing concern is why is this kmalloc() resulting in
> > > an order-5 allocation request? What size is the buffer being requested?
> > > Was that expected? What is the contents of /proc/slabinfo in case a buffer
> > > that should have required order-1 or order-2 is using a higher order for
> > > some reason.
> >
> > It's allocating 68,000 bytes for the mb_history structure, which is
> > used for debugging purposes. That's why it's optional and we continue
> > if it's not allocated. We should fix it to use vmalloc()
>
> You could call with kmalloc(FLAGS|GFP_NOWARN) with a fallback to
> vmalloc() and a disable if vmalloc() fails as well. Maybe check out what
> kernel/profile.c#profile_init() to allocate a large buffer and do something
> similar?
>
> > and I'm
> > inclined to turn it off by default since it's not worth the overhead,
> > and most ext4 users won't find it useful or interesting.
> >
>
> I can't comment as I don't know what sort of debugging it's useful for.
>
Perhaps this is a suitable use for the new proposed flex_array? From an
initial glance, I can't see why the allocated memory has to be
contiguous..
http://lwn.net/Articles/345273/
Cheers, Simon
^ permalink raw reply
* Re: driver_nl80211 broken again
From: Maxim Levitsky @ 2009-09-08 20:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Jouni Malinen
In-Reply-To: <1252423769.3806.4.camel@johannes.local>
On Tue, 2009-09-08 at 17:29 +0200, Johannes Berg wrote:
> On Sat, 2009-09-05 at 05:08 +0300, Maxim Levitsky wrote:
>
> > 1 - when connecting again to the access point (same or another),
> > wpa_supplicant does the following:
> >
> > deassoc
> > auth
> > assoc
> >
> > So it assumes that deassoc command disconnects completely, but it not
> > longer true.
> > Yet, I have tried to make its dissassoc function do both, but it failed.
> > I used following patch:
> >
> >
> > diff --git a/wpa_supplicant/wpa_supplicant.c b/wpa_supplicant/wpa_supplicant.c
> > index c68dd82..50afeeb 100644
> > --- a/wpa_supplicant/wpa_supplicant.c
> > +++ b/wpa_supplicant/wpa_supplicant.c
> > @@ -1278,8 +1278,10 @@ void wpa_supplicant_disassociate(struct wpa_supplicant *wpa_s,
> > if (!is_zero_ether_addr(wpa_s->bssid)) {
> > if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_USER_SPACE_MLME)
> > ieee80211_sta_disassociate(wpa_s, reason_code);
> > - else
> > + else {
> > wpa_drv_disassociate(wpa_s, wpa_s->bssid, reason_code);
> > + wpa_drv_deauthenticate(wpa_s, wpa_s->bssid, reason_code);
> > + }
> > addr = wpa_s->bssid;
> > }
> > wpa_clear_keys(wpa_s, addr);
>
> Right, this is a known problem. I still think it should be handled in
> wpa_s, but I'm not sure whether that patch should have worked or not.
>
> > EAPOL: startWhen --> 0
> > EAPOL: disable timer tick
> > wpa_driver_nl80211_disassociate
> > wpa_driver_nl80211_deauthenticate
> > nl80211: MLME command failed: ret=-67 (Link has been severed)
>
> Ok so it was called, but got -ENOLINK? That's rather odd. But I suspect
> that it had already internally cleared the BSSID, so that it was asking
> to deauth from 00:...:00 -- could you check that?
I figure that out, but the wpa_drv_disassociate and
wpa_drv_deauthenticate are direct wrappers over nl80211 calls.
>
> > 2 - independent of the above, the ieee80211_set_disassoc
> > doesn't work right if deauth==false.
> >
> >
> > If it is, then a work item is added to station work thread, and it is
> > never removed:
> >
> > } else {
> > struct ieee80211_mgd_work *wk = ifmgd->old_associate_work;
> >
> > wk->state = IEEE80211_MGD_STATE_IDLE;
> > list_add(&wk->list, &ifmgd->work_list);
> > }
> >
> >
> > iee80211_sta_work just ignores the IEEE80211_MGD_STATE_IDLE, thus it
> > work item remains forever.
> >
> > This breaks scanning, since __ieee80211_start_scan will refuses to run
> > until, ifmgd->work_list is empty.
>
> That's intentional, that work item represents the authentication state
> we still have -- the required cleanup should be done by cfg80211 or
> wpa_supplicant.
But isn't it too much?
This means, the wpa_supplicant can lock the device.
>
> Can you try to figure out what the parameters are that
> wpa_drv_deauthenticate() is sending to the kernel, and why it's getting
> -ENOLINK?
Sure!
Very soon will do
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [rt2x00-users] rt2x00: Hardcode TX ack timeout and consume time
From: Richard Zidlicky @ 2009-09-08 12:06 UTC (permalink / raw)
To: rt2x00 Users List; +Cc: John Linville, linux-wireless
In-Reply-To: <200909061514.23611.IvDoorn@gmail.com>
On Sun, Sep 06, 2009 at 03:14:23PM +0200, Ivo van Doorn wrote:
> rt2x00: Hardcode TX ack timeout and consume time
Hi,
it does significantly improve rt73usb performance and stability of ping times.
I can still get almost the double performance and much better ping times when
setting the rate manually.
> John, this patch has not yet been confirmed by any of the above bugzilla reports,
> but I do think this should be merged as soon as possible to 2.6.31 since this issue
> has been marked as regression for quite some time now. :)
imho it should be merged even if it does not fully fix every imaginable problem.
Actually I would wish critical fixes would be merged much more aggressively,
eg rt73usb was critically broken before Pavel Roskin' recent off-by-1 register
access fix - causing all kinds of weird problems probably including filesystem
damage.
Seems some other fixes are also critical - it would be nice to have all important
fixes in eg in 2.6.30.6 (if it ever comes) as it is not quite trivial to cherrypick
them from the list when the code diverges too much from mainline.
Richard
^ permalink raw reply
* Re: [rt2x00-users] rt2x00: Hardcode TX ack timeout and consume time
From: Richard Zidlicky @ 2009-09-08 12:53 UTC (permalink / raw)
To: rt2x00 Users List; +Cc: John Linville, linux-wireless
In-Reply-To: <20090908120608.GA4296@linux-m68k.org>
On Tue, Sep 08, 2009 at 02:06:09PM +0200, Richard Zidlicky wrote:
>
> it does significantly improve rt73usb performance and stability of ping times.
further data.. downloads improve significantly but uploads still require manual rate
setting else they fall back to 1MBit immediately.
Richard
^ permalink raw reply
* Re: Stop using tasklets for bottom halves
From: Michael Buesch @ 2009-09-08 19:12 UTC (permalink / raw)
To: matthieu castet; +Cc: linux-wireless
In-Reply-To: <loom.20090908T210153-638@post.gmane.org>
On Tuesday 08 September 2009 21:07:32 matthieu castet wrote:
> Michael Buesch <mb@...> writes:
> >
> > I recently converted the b43 driver to threaded interrupt handlers and
> > a workqueue based TX mechanism. (My motivation was porting b43 to the SDIO bus
> that
> > needs to sleep, so requires process context).
> Well you can do busy wait : for sending small sd command, the overhead of
> sleep ( context switch) can be bigger than the sleep.
The bus is _really_ slow and we push the whole network load through it.
So we really don't want to busywait. It would effectively lockup the machine
on network traffic.
And besides that, the SDIO subsystem requires process context. I was not going
to rewrite that.
> It depends of architecture. For example on older arm (armv5) context switch can
> be slow (need tlb and cache flush). It is not really true for kernel thread that
> keeps the same mmu mapping and don't need all those flush,
Yeah, but that's what it is. A kernel thread.
> but there still a
> visible performance hit.
That's the initial question. How big is it?
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] wireless: mark prism54 as deprecated and mark for removal
From: Luis R. Rodriguez @ 2009-09-08 19:09 UTC (permalink / raw)
To: John W. Linville
Cc: Luis Rodriguez, Larry Finger, linux-wireless@vger.kernel.org,
aquilaver@yahoo.com, linux-kernel@vger.kernel.org, Dan Williams,
Kai Engert, Jean Tourrilhes, Tim de Waal, Roy Marples, Alan Cox,
Christian Lamparter, Björn Steinbrink, Tim Gardner,
Johannes Berg
In-Reply-To: <20090908183337.GD2617@tuxdriver.com>
On Tue, Sep 08, 2009 at 11:33:37AM -0700, John W. Linville wrote:
> On Tue, Sep 01, 2009 at 09:15:13AM -0700, Luis R. Rodriguez wrote:
> > On Tue, Sep 01, 2009 at 09:06:51AM -0700, Larry Finger wrote:
>
> > > Otherwise, ACK.
> >
> > Thanks for the review, will resend with the changes.
> >
> > Luis
>
> Ahem? :-)
Thanks for the poke, here it is:
From: Luis R. Rodriguez <lrodriguez@atheros.com>
Subject: [PATCH] wireless: mark prism54 as deprecated and mark for removal
The preferred module is p54pci which also supports FullMAC
PCI / Cardbus devices. We schedule removal for 2.6.34. Reason
to remove this is no one really is testing prism54 anymore,
and while it works p54pci provides support for the same hardware.
It should be noted I have been told some FullMAC devices may not
have worked with the SoftMAC driver but to date we have yet to
recieve a single bug report regarding this. If there are users
out there please let us know!
Cc: aquilaver@yahoo.com
Cc: linux-kernel@vger.kernel.org
Cc: Dan Williams <dcbw@redhat.com>
Cc: Kai Engert <kengert@redhat.com>
Cc: Jean Tourrilhes <jt@hpl.hp.com>
Cc: Tim de Waal<tim.dewaal@yahoo.com>
Cc: Roy Marples <uberlord@gentoo.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Christian Lamparter <chunkeey@web.de>
Cc: Björn Steinbrink <B.Steinbrink@gmx.de>
Cc: Tim Gardner <tim.gardner@canonical.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
Documentation/feature-removal-schedule.txt | 29 ++++++++++++++
drivers/net/wireless/Kconfig | 57 ++++++++--------------------
2 files changed, 45 insertions(+), 41 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 09e031c..ad522e3 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -6,6 +6,35 @@ be removed from this file.
---------------------------
+What: PRISM54
+When: 2.6.34
+
+Why: prism54 FullMAC PCI / Cardbus devices used to be supported only by the
+ prism54 wireless driver. After Intersil stopped selling these
+ devices in preference for the newer more flexible SoftMAC devices
+ a SoftMAC device driver was required and prism54 did not support
+ them. The p54pci driver now exists and has been present in the kernel for
+ a while. This driver supports both SoftMAC devices and FullMAC devices.
+ The main difference between these devices was the amount of memory which
+ could be used for the firmware. The SoftMAC devices support a smaller
+ amount of memory. Because of this the SoftMAC firmware fits into FullMAC
+ devices's memory. p54pci supports not only PCI / Cardbus but also USB
+ and SPI. Since p54pci supports all devices prism54 supports
+ you will have a conflict. I'm not quite sure how distributions are
+ handling this conflict right now. prism54 was kept around due to
+ claims users may experience issues when using the SoftMAC driver.
+ Time has passed users have not reported issues. If you use prism54
+ and for whatever reason you cannot use p54pci please let us know!
+ E-mail us at: linux-wireless@vger.kernel.org
+
+ For more information see the p54 wiki page:
+
+ http://wireless.kernel.org/en/users/Drivers/p54
+
+Who: Luis R. Rodriguez <lrodriguez@atheros.com>
+
+---------------------------
+
What: IRQF_SAMPLE_RANDOM
Check: IRQF_SAMPLE_RANDOM
When: July 2009
diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index a8871a8..ad89d23 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -275,51 +275,26 @@ config PCMCIA_WL3501
micro support for ethtool.
config PRISM54
- tristate 'Intersil Prism GT/Duette/Indigo PCI/Cardbus'
+ tristate 'Intersil Prism GT/Duette/Indigo PCI/Cardbus (DEPRECATED)'
depends on PCI && EXPERIMENTAL && WLAN_80211
select WIRELESS_EXT
select FW_LOADER
---help---
- Enable PCI and Cardbus support for the following chipset based cards:
-
- ISL3880 - Prism GT 802.11 b/g
- ISL3877 - Prism Indigo 802.11 a
- ISL3890 - Prism Duette 802.11 a/b/g
-
- For a complete list of supported cards visit <http://prism54.org>.
- Here is the latest confirmed list of supported cards:
-
- 3com OfficeConnect 11g Cardbus Card aka 3CRWE154G72 (version 1)
- Allnet ALL0271 PCI Card
- Compex WL54G Cardbus Card
- Corega CG-WLCB54GT Cardbus Card
- D-Link Air Plus Xtreme G A1 Cardbus Card aka DWL-g650
- I-O Data WN-G54/CB Cardbus Card
- Kobishi XG-300 aka Z-Com Cardbus Card
- Netgear WG511 Cardbus Card
- Ovislink WL-5400PCI PCI Card
- Peabird WLG-PCI PCI Card
- Sitecom WL-100i Cardbus Card
- Sitecom WL-110i PCI Card
- SMC2802W - EZ Connect g 2.4GHz 54 Mbps Wireless PCI Card
- SMC2835W - EZ Connect g 2.4GHz 54 Mbps Wireless Cardbus Card
- SMC2835W-V2 - EZ Connect g 2.4GHz 54 Mbps Wireless Cardbus Card
- Z-Com XG-900 PCI Card
- Zyxel G-100 Cardbus Card
-
- If you enable this you will need a firmware file as well.
- You will need to copy this to /usr/lib/hotplug/firmware/isl3890.
- You can get this non-GPL'd firmware file from the Prism54 project page:
- <http://prism54.org>
- You will also need the /etc/hotplug/firmware.agent script from
- a current hotplug package.
-
- Note: You need a motherboard with DMA support to use any of these cards
-
- If you want to compile the driver as a module ( = code which can be
- inserted in and removed from the running kernel whenever you want),
- say M here and read <file:Documentation/kbuild/modules.txt>.
- The module will be called prism54.
+ This enables support for FullMAC PCI/Cardbus prism54 devices. This
+ driver is now deprecated in favor for the SoftMAC driver, p54pci.
+ p54pci supports FullMAC PCI/Cardbus devices as well. For details on
+ the scheduled removal of this driver on the kernel see the feature
+ removal schedule:
+
+ Documentation/feature-removal-schedule.txt
+
+ For more information refer to the p54 wiki:
+
+ http://wireless.kernel.org/en/users/Drivers/p54
+
+ Note: You need a motherboard with DMA support to use any of these cards
+
+ When built as module you get the module prism54
config USB_ZD1201
tristate "USB ZD1201 based Wireless device support"
--
1.6.3.3
^ permalink raw reply related
* Re: Stop using tasklets for bottom halves
From: matthieu castet @ 2009-09-08 19:07 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <200909080650.43181.mb@bu3sch.de>
Michael Buesch <mb@...> writes:
>
> I recently converted the b43 driver to threaded interrupt handlers and
> a workqueue based TX mechanism. (My motivation was porting b43 to the SDIO bus
that
> needs to sleep, so requires process context).
Well you can do busy wait : for sending small sd command, the overhead of
sleep ( context switch) can be bigger than the sleep.
>
> I think there's no real reason for process context being slow in general. It's
just that
> we have additional context switches. But these are fast on Linux.
>
It depends of architecture. For example on older arm (armv5) context switch can
be slow (need tlb and cache flush). It is not really true for kernel thread that
keeps the same mmu mapping and don't need all those flush, but there still a
visible performance hit.
Matthieu
^ permalink raw reply
* Re: [gNewSense-users] firmware development Fwd: convocatoria (pagada) a desarrollo
From: Gábor Stefanik @ 2009-09-08 19:01 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Quiliro Ordóñez, linux-wireless
In-Reply-To: <43e72e890909080906g264fd5d5oc74a90aa4c1cd33d@mail.gmail.com>
On Tue, Sep 8, 2009 at 6:06 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Sun, Sep 6, 2009 at 9:00 AM, Quiliro Ordóñez<quiliro@gmail.com> wrote:
>> Dear folks.
>>
>> I have like to have libre (free as in freedom) firmware for rt2561
>> wireless chipset. And forward this email for your consideration and
>> quote.
>
> I think we can poke ralink, but anyway in the meantime be aware that
> if you want a wireless device for which there are open upstream
> drivers and either open firmware or no firmware requirement you can
> refer to:
>
> These devices require no firmware:
>
> http://wireless.kernel.org/en/users/Drivers/ath5k
> http://wireless.kernel.org/en/users/Drivers/ath9k
>
> This driver has open firmware available:
>
> http://wireless.kernel.org/en/users/Drivers/ar9170
> http://wireless.kernel.org/en/users/Drivers/ar9170.fw
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
OpenFWWF for b43 is also worth looking at. (It only supports rev.5
cards, though.)
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ 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