* [PATCH 4/6] wl1271: Add retry implementation for PSM entries
From: Luciano Coelho @ 2009-11-02 18:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1257186133-18367-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
PSM entries can fail (transmitting the corresponding null-func may not
be heard by the AP.) Previously, this scenario was not detected, and
out-of-sync between STA and AP could occur.
Add retry implementation for the entries to recover from the situation.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271.h | 3 ++
drivers/net/wireless/wl12xx/wl1271_boot.c | 3 +-
drivers/net/wireless/wl12xx/wl1271_conf.h | 8 ++++
drivers/net/wireless/wl12xx/wl1271_event.c | 53 ++++++++++++++++++++++++++++
drivers/net/wireless/wl12xx/wl1271_event.h | 7 ++++
drivers/net/wireless/wl12xx/wl1271_main.c | 5 ++-
6 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271.h b/drivers/net/wireless/wl12xx/wl1271.h
index 566f152..94359b1 100644
--- a/drivers/net/wireless/wl12xx/wl1271.h
+++ b/drivers/net/wireless/wl12xx/wl1271.h
@@ -417,6 +417,9 @@ struct wl1271 {
/* PSM mode requested */
bool psm_requested;
+ /* retry counter for PSM entries */
+ u8 psm_entry_retry;
+
/* in dBm */
int power_level;
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.c b/drivers/net/wireless/wl12xx/wl1271_boot.c
index 8678bea..b7c9645 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.c
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.c
@@ -407,7 +407,8 @@ static int wl1271_boot_run_firmware(struct wl1271 *wl)
/* unmask required mbox events */
wl->event_mask = BSS_LOSE_EVENT_ID |
- SCAN_COMPLETE_EVENT_ID;
+ SCAN_COMPLETE_EVENT_ID |
+ PS_REPORT_EVENT_ID;
ret = wl1271_event_unmask(wl);
if (ret < 0) {
diff --git a/drivers/net/wireless/wl12xx/wl1271_conf.h b/drivers/net/wireless/wl12xx/wl1271_conf.h
index 061d475..565373e 100644
--- a/drivers/net/wireless/wl12xx/wl1271_conf.h
+++ b/drivers/net/wireless/wl12xx/wl1271_conf.h
@@ -712,6 +712,14 @@ struct conf_conn_settings {
* Range 0 - 255
*/
u8 bet_max_consecutive;
+
+ /*
+ * Specifies the maximum number of times to try PSM entry if it fails
+ * (if sending the appropriate null-func message fails.)
+ *
+ * Range 0 - 255
+ */
+ u8 psm_entry_retries;
};
#define CONF_SR_ERR_TBL_MAX_VALUES 14
diff --git a/drivers/net/wireless/wl12xx/wl1271_event.c b/drivers/net/wireless/wl12xx/wl1271_event.c
index 31d396b..e135d89 100644
--- a/drivers/net/wireless/wl12xx/wl1271_event.c
+++ b/drivers/net/wireless/wl12xx/wl1271_event.c
@@ -68,6 +68,40 @@ static int wl1271_event_scan_complete(struct wl1271 *wl,
return 0;
}
+static int wl1271_event_ps_report(struct wl1271 *wl,
+ struct event_mailbox *mbox,
+ bool *beacon_loss)
+{
+ int ret = 0;
+
+ wl1271_debug(DEBUG_EVENT, "ps_status: 0x%x", mbox->ps_status);
+
+ switch (mbox->ps_status) {
+ case EVENT_ENTER_POWER_SAVE_FAIL:
+ if (wl->psm_entry_retry < wl->conf.conn.psm_entry_retries) {
+ wl->psm_entry_retry++;
+ wl1271_error("PSM entry failed, retrying %d\n",
+ wl->psm_entry_retry);
+ ret = wl1271_ps_set_mode(wl, STATION_POWER_SAVE_MODE);
+ } else {
+ wl->psm_entry_retry = 0;
+ *beacon_loss = true;
+ }
+ break;
+ case EVENT_ENTER_POWER_SAVE_SUCCESS:
+ wl->psm_entry_retry = 0;
+ break;
+ case EVENT_EXIT_POWER_SAVE_FAIL:
+ wl1271_info("PSM exit failed");
+ break;
+ case EVENT_EXIT_POWER_SAVE_SUCCESS:
+ default:
+ break;
+ }
+
+ return ret;
+}
+
static void wl1271_event_mbox_dump(struct event_mailbox *mbox)
{
wl1271_debug(DEBUG_EVENT, "MBOX DUMP:");
@@ -79,6 +113,7 @@ static int wl1271_event_process(struct wl1271 *wl, struct event_mailbox *mbox)
{
int ret;
u32 vector;
+ bool beacon_loss = false;
wl1271_event_mbox_dump(mbox);
@@ -101,7 +136,25 @@ static int wl1271_event_process(struct wl1271 *wl, struct event_mailbox *mbox)
wl1271_debug(DEBUG_EVENT, "BSS_LOSE_EVENT");
/* indicate to the stack, that beacons have been lost */
+ beacon_loss = true;
+ }
+
+ if (vector & PS_REPORT_EVENT_ID) {
+ wl1271_debug(DEBUG_EVENT, "PS_REPORT_EVENT");
+ ret = wl1271_event_ps_report(wl, mbox, &beacon_loss);
+ if (ret < 0)
+ return ret;
+ }
+
+ if (beacon_loss) {
+ /* Obviously, it's dangerous to release the mutex while
+ we are holding many of the variables in the wl struct.
+ That's why it's done last in the function, and care must
+ be taken that nothing more is done after this function
+ returns. */
+ mutex_unlock(&wl->mutex);
ieee80211_beacon_loss(wl->vif);
+ mutex_lock(&wl->mutex);
}
return 0;
diff --git a/drivers/net/wireless/wl12xx/wl1271_event.h b/drivers/net/wireless/wl12xx/wl1271_event.h
index 3ab53d3..4e3f55e 100644
--- a/drivers/net/wireless/wl12xx/wl1271_event.h
+++ b/drivers/net/wireless/wl12xx/wl1271_event.h
@@ -63,6 +63,13 @@ enum {
EVENT_MBOX_ALL_EVENT_ID = 0x7fffffff,
};
+enum {
+ EVENT_ENTER_POWER_SAVE_FAIL = 0,
+ EVENT_ENTER_POWER_SAVE_SUCCESS,
+ EVENT_EXIT_POWER_SAVE_FAIL,
+ EVENT_EXIT_POWER_SAVE_SUCCESS,
+};
+
struct event_debug_report {
u8 debug_event_id;
u8 num_params;
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
index 0ae506a..d2149fc 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -222,7 +222,8 @@ static struct conf_drv_settings default_conf = {
.snr_pkt_avg_weight = 10
},
.bet_enable = CONF_BET_MODE_ENABLE,
- .bet_max_consecutive = 100
+ .bet_max_consecutive = 100,
+ .psm_entry_retries = 3
},
.init = {
.sr_err_tbl = {
@@ -973,6 +974,7 @@ static void wl1271_op_stop(struct ieee80211_hw *hw)
wl->rx_counter = 0;
wl->elp = false;
wl->psm = 0;
+ wl->psm_entry_retry = 0;
wl->tx_queue_stopped = false;
wl->power_level = WL1271_DEFAULT_POWER_LEVEL;
wl->tx_blocks_available = 0;
@@ -1822,6 +1824,7 @@ static int __devinit wl1271_probe(struct spi_device *spi)
wl->elp = false;
wl->psm = 0;
wl->psm_requested = false;
+ wl->psm_entry_retry = 0;
wl->tx_queue_stopped = false;
wl->power_level = WL1271_DEFAULT_POWER_LEVEL;
wl->basic_rate_set = WL1271_DEFAULT_BASIC_RATE_SET;
--
1.5.6.5
^ permalink raw reply related
* [PATCH 1/6] wl1271: Remove excess null-data template settings
From: Luciano Coelho @ 2009-11-02 18:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1257186133-18367-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
The null-data template (nullfunc) is dependent on the BSSID of the
current AP only, so it needs to be updated only when the BSSID changes.
Removed excess setting of the template.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_main.c | 14 +++++---------
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_main.c b/drivers/net/wireless/wl12xx/wl1271_main.c
index 86132bb..0ae506a 100644
--- a/drivers/net/wireless/wl12xx/wl1271_main.c
+++ b/drivers/net/wireless/wl12xx/wl1271_main.c
@@ -1067,11 +1067,11 @@ static int wl1271_op_config_interface(struct ieee80211_hw *hw,
ret = wl1271_cmd_join(wl);
if (ret < 0)
goto out_sleep;
- }
- ret = wl1271_cmd_build_null_data(wl);
- if (ret < 0)
- goto out_sleep;
+ ret = wl1271_cmd_build_null_data(wl);
+ if (ret < 0)
+ goto out_sleep;
+ }
wl->ssid_len = conf->ssid_len;
if (wl->ssid_len)
@@ -1137,10 +1137,6 @@ static int wl1271_op_config(struct ieee80211_hw *hw, u32 changed)
wl->channel = channel;
}
- ret = wl1271_cmd_build_null_data(wl);
- if (ret < 0)
- goto out_sleep;
-
if (conf->flags & IEEE80211_CONF_PS && !wl->psm_requested) {
wl1271_info("psm enabled");
@@ -1165,7 +1161,7 @@ static int wl1271_op_config(struct ieee80211_hw *hw, u32 changed)
if (conf->power_level != wl->power_level) {
ret = wl1271_acx_tx_power(wl, conf->power_level);
if (ret < 0)
- goto out;
+ goto out_sleep;
wl->power_level = conf->power_level;
}
--
1.5.6.5
^ permalink raw reply related
* [PATCH 3/6] wl1271: Check result code of commands
From: Luciano Coelho @ 2009-11-02 18:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1257186133-18367-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Check the result code of all commands, and return an error code if the
firmware reports an error in execution. Previously this error would go
ignored in most cases.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_cmd.c | 34 +++++++---------------------
drivers/net/wireless/wl12xx/wl1271_init.c | 7 ++++-
2 files changed, 14 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_cmd.c b/drivers/net/wireless/wl12xx/wl1271_cmd.c
index 0666328..46e5ea4 100644
--- a/drivers/net/wireless/wl12xx/wl1271_cmd.c
+++ b/drivers/net/wireless/wl12xx/wl1271_cmd.c
@@ -74,6 +74,15 @@ int wl1271_cmd_send(struct wl1271 *wl, u16 id, void *buf, size_t len)
intr = wl1271_spi_read32(wl, ACX_REG_INTERRUPT_NO_CLEAR);
}
+ /* read back the status code of the command */
+ wl1271_spi_read(wl, wl->cmd_box_addr, cmd,
+ sizeof(struct wl1271_cmd_header), false);
+
+ if (cmd->status != CMD_STATUS_SUCCESS) {
+ wl1271_error("command execute failure %d", cmd->status);
+ ret = -EIO;
+ }
+
wl1271_spi_write32(wl, ACX_REG_INTERRUPT_ACK,
WL1271_ACX_INTR_CMD_COMPLETE);
@@ -306,7 +315,6 @@ int wl1271_cmd_test(struct wl1271 *wl, void *buf, size_t buf_len, u8 answer)
if (answer) {
struct wl1271_command *cmd_answer;
- u16 status;
/*
* The test command got in, we can read the answer.
@@ -316,10 +324,6 @@ int wl1271_cmd_test(struct wl1271 *wl, void *buf, size_t buf_len, u8 answer)
wl1271_spi_read(wl, wl->cmd_box_addr, buf, buf_len, false);
cmd_answer = buf;
- status = le16_to_cpu(cmd_answer->header.status);
-
- if (status != CMD_STATUS_SUCCESS)
- wl1271_error("TEST command answer error: %d", status);
}
return 0;
@@ -354,11 +358,6 @@ int wl1271_cmd_interrogate(struct wl1271 *wl, u16 id, void *buf, size_t len)
/* the interrogate command got in, we can read the answer */
wl1271_spi_read(wl, wl->cmd_box_addr, buf, len, false);
- acx = buf;
- if (le16_to_cpu(acx->cmd.status) != CMD_STATUS_SUCCESS)
- wl1271_error("INTERROGATE command error: %d",
- le16_to_cpu(acx->cmd.status));
-
out:
return ret;
}
@@ -507,11 +506,6 @@ int wl1271_cmd_read_memory(struct wl1271 *wl, u32 addr, void *answer,
/* the read command got in, we can now read the answer */
wl1271_spi_read(wl, wl->cmd_box_addr, cmd, sizeof(*cmd), false);
-
- if (le16_to_cpu(cmd->header.status) != CMD_STATUS_SUCCESS)
- wl1271_error("error in read command result: %d",
- le16_to_cpu(cmd->header.status));
-
memcpy(answer, cmd->value, len);
out:
@@ -639,17 +633,7 @@ int wl1271_cmd_scan(struct wl1271 *wl, u8 *ssid, size_t len,
ret = wl1271_cmd_send(wl, CMD_SCAN, params, sizeof(*params));
if (ret < 0) {
wl1271_error("SCAN failed");
- goto out;
- }
-
- wl1271_spi_read(wl, wl->cmd_box_addr, params, sizeof(*params),
- false);
-
- if (le16_to_cpu(params->header.status) != CMD_STATUS_SUCCESS) {
- wl1271_error("Scan command error: %d",
- le16_to_cpu(params->header.status));
wl->scanning = false;
- ret = -EIO;
goto out;
}
diff --git a/drivers/net/wireless/wl12xx/wl1271_init.c b/drivers/net/wireless/wl12xx/wl1271_init.c
index 417b415..7c2017f 100644
--- a/drivers/net/wireless/wl12xx/wl1271_init.c
+++ b/drivers/net/wireless/wl12xx/wl1271_init.c
@@ -303,12 +303,15 @@ int wl1271_hw_init(struct wl1271 *wl)
{
int ret;
+ /* FIXME: the following parameter setting functions return error
+ * codes - the reason is so far unknown. The -EIO is therefore
+ * ignored for the time being. */
ret = wl1271_init_general_parms(wl);
- if (ret < 0)
+ if (ret < 0 && ret != -EIO)
return ret;
ret = wl1271_init_radio_parms(wl);
- if (ret < 0)
+ if (ret < 0 && ret != -EIO)
return ret;
/* Template settings */
--
1.5.6.5
^ permalink raw reply related
* [PATCH 2/6] wl1271: Increase TX power value
From: Luciano Coelho @ 2009-11-02 18:22 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Juuso Oikarinen
In-Reply-To: <1257186133-18367-1-git-send-email-luciano.coelho@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Currently, to avoid distortions, the TX power level has been hardcoded
to a low value. The value is slightly too low for good functionality, so
we increase it from 7dB to 12dB.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
Reviewed-by: Luciano Coelho <luciano.coelho@nokia.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_acx.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_acx.c b/drivers/net/wireless/wl12xx/wl1271_acx.c
index bf5a868..5cc89bb 100644
--- a/drivers/net/wireless/wl12xx/wl1271_acx.c
+++ b/drivers/net/wireless/wl12xx/wl1271_acx.c
@@ -141,7 +141,7 @@ int wl1271_acx_tx_power(struct wl1271 *wl, int power)
* calibration, to avoid distortions
*/
/* acx->current_tx_power = power * 10; */
- acx->current_tx_power = 70;
+ acx->current_tx_power = 120;
ret = wl1271_cmd_configure(wl, DOT11_CUR_TX_PWR, acx, sizeof(*acx));
if (ret < 0) {
--
1.5.6.5
^ permalink raw reply related
* Re: pull request: wireless-next-2.6 2009-10-28
From: John W. Linville @ 2009-11-02 18:29 UTC (permalink / raw)
To: Randy Dunlap
Cc: Luis Correia, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Bartlomiej Zolnierkiewicz, Pekka Enberg, David Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <4AEF1894.2010809@xenotime.net>
On Mon, Nov 02, 2009 at 09:36:20AM -0800, Randy Dunlap wrote:
> Luis Correia wrote:
> > [huge snip]
> >
> > This is going to be my last reply to this thread (even if I get to be insulted).
> >
> > I'm not a coder, I'm a tester and administrator for the rt2x00 project.
> > I'm not happy about the current state of the rt2x00 in-kernel drivers.
> > I tend to agree that more could be done.
> >
> > Even though I'm not a coder, I could be hipotetically responsable for
> > the current situation. It is my job function to motivate people to
> > work on the rt2x00 in-kernel drivers, but apparently I've failed here.
> > It's not an atitude problem, as some have suggested, it's just life.
> >
> > About Bartlomiej, there is only one more thing that I'll say:
> >
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> >
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> >
> > Which, while technically correct, adds nothing to the project.
>
> whatever. That patch still needs to be applied.
And, in fact, it has been...already in linux-2.6:
commit b5654f5e7fc414a6e69b3647db2b043257c9e62e
Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Mon Oct 26 16:49:50 2009 -0700
MAINTAINERS: rt2x00 list is moderated
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Hth...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Ivo van Doorn @ 2009-11-02 18:43 UTC (permalink / raw)
To: netdev
Cc: Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Bartlomiej Zolnierkiewicz,
Pekka Enberg, David Miller, linux-wireless, linux-kernel
In-Reply-To: <4AEF1894.2010809@xenotime.net>
Well and then another rt2x00 developer discovered this nice little
fight about rt2x00 on the mailinglists...
First for the record, because at the start people where talking about the
maintainership of rt2x00, one thing needs to be straight:
As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
drivers/net/wireless/rt2x00 folder.
At this time I am hold the position within the rt2x00 team which is making the
decisions about the rt2x00 code and design.
I am also the one that is (N)Acks the patches from others when they are send
to the rt2x00-users or linux-wireless mailinglist.
As for my behavior in discussions:
I am doing my best to listen to all complains regarding the rt2x00 code and design and
improve it if the complainer has a valid point. However, obviously I can disagree with
the complainer and in that case I will explain to that person _why_ I disagree. It is up
to the complainer to convince me that he is right, agree with my response, or whine.
Now as for more specific responses:
On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> rt2800 drivers have their maintainers and I would like to know what they
> are doing besides complaining about users and staging tree..
Working for Avanade, Zarafa and as freelancer for Linux Magazine.
But I guess you mean rt2x00 specific work?
Well that list consists of:
- Listening to people complain
- Responding to those people, because otherwise they complain that they are being ignored.
- Following bug reports, and request testing or additional information if required
- Bugfixing
- Reviewing patches from contributors
- Applying patches from contributors
- Discussing improvements over patches from contributors
Well nothing of this list should be new to you, but apparently you needed some confirmation.
On Thursday 29 October 2009, Johannes Berg wrote:
> On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
>
> > In case you're concerned, I actually agree with John and others
> > on this issue, and disagree with your position.
>
> In this particular case, I think it makes more sense to duplicate the
> code _especially_ because it's not working yet. That frees people
> hacking on it of having to worry about breaking other devices.
Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
in the previous discussion.
On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> I find it rather disappointing that all my review comments regarding
> rt2800pci support were just completely ignored and then the initial
> patch was merged just as it was..
Your code review comments were commented upon with my reasons
why this code duplication exists. I even admitted that when the time is
ready I will remove the code duplication.
On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
The review concerns regarding the duplicate code would only reduce the
amount of code. It would not magically fix bugs (at least the chance of that
would be quite small).
So far rt2800usb performs better then rt2800pci, and the difference gets
only bigger when I use the exact same register initialization from rt2800usb
in rt2800pci.
But Bartjmoiej knows that the register initialization can be exactly the same,
from his experience with the staging drivers.
So far hasn't been interested in sharing the knowledge in what must be
changed in rt2800pci/usb to make them both work with the same register
initialization.
On Monday 02 November 2009, Randy Dunlap wrote:
> Luis Correia wrote:
> > [huge snip]
> > I've searched on my GMail archives and the only patch Bart has
> > provided so far for the rt2x00 project is this:
> >
> > [PATCH] MAINTAINERS: rt2x00 list is moderated
> >
> > Which, while technically correct, adds nothing to the project.
>
> whatever. That patch still needs to be applied.
And I haven't seen anybody stating the opposite...
Ivo
^ permalink raw reply
* Re: [PATCH] mac80211: Fix IBSS merge
From: John W. Linville @ 2009-11-02 18:32 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Johannes Berg, Sujith, linux-wireless
In-Reply-To: <4AEF14E9.7060902@nbd.name>
On Mon, Nov 02, 2009 at 06:20:41PM +0100, Felix Fietkau wrote:
> John W. Linville wrote:
> > On Mon, Nov 02, 2009 at 09:44:46AM +0100, Johannes Berg wrote:
> >> On Mon, 2009-11-02 at 12:33 +0530, Sujith wrote:
> >> > Currently, in IBSS mode, a single creator would go into
> >> > a loop trying to merge/scan. This happens because the IBSS timer is
> >> > rearmed on finishing a scan and the subsequent
> >> > timer invocation requests another scan immediately.
> >> >
> >> > This patch fixes this issue by checking if we have just completed
> >> > a scan run trying to merge with other IBSS networks.
> >>
> >> Heh, how many people do we need to fix IBSS? :)
> >
> > Yeah, no kidding...I suspect that actual IBSS users are few, and a
> > substantial number of those are doing crazy things with it! :-)
> Yeah, we're doing crazy things like mesh networks of few hundred
> nodes... something that 11s isn't really suitable for. :-)
In fact, I had you in mind when I said that -- crazy doesn't mean
useless... :-)
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: linux-next: Tree for November 2 (wireless/wl1271)
From: John W. Linville @ 2009-11-02 18:44 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, linux-wireless
In-Reply-To: <4AEF1E7F.50306@oracle.com>
On Mon, Nov 02, 2009 at 10:01:35AM -0800, Randy Dunlap wrote:
> Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20091030:
>
>
> wl1271 build fails when CONFIG_INET=n.
> Should this driver depend on INET?
>
> Why does this driver, unlike all other wireless drivers,
> want to use register_inetaddr_notifier()?
>
> wl1271_main.c:(.text+0x271052): undefined reference to `unregister_inetaddr_notifier'
> wl1271_main.c:(.text+0x2714d7): undefined reference to `register_inetaddr_notifier'
Yeah, that driver is doing some filtering based on IPv4.
Luca, is that necessary? If so, then we need a patch like the one below...?
John
>From ba823accfad68151d80503ff5fb04c049c9eadc2 Mon Sep 17 00:00:00 2001
From: John W. Linville <linville@tuxdriver.com>
Date: Mon, 2 Nov 2009 13:43:32 -0500
Subject: [PATCH] wl1271: depend on INET
wl1271_main.c:(.text+0x271052): undefined reference to `unregister_inetaddr_notifier'
wl1271_main.c:(.text+0x2714d7): undefined reference to `register_inetaddr_notifier'
Driver is doing some filtering based on IP addresses...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/wl12xx/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/Kconfig b/drivers/net/wireless/wl12xx/Kconfig
index 33de7fa..785e024 100644
--- a/drivers/net/wireless/wl12xx/Kconfig
+++ b/drivers/net/wireless/wl12xx/Kconfig
@@ -42,6 +42,7 @@ config WL1251_SDIO
config WL1271
tristate "TI wl1271 support"
depends on WL12XX && SPI_MASTER && GENERIC_HARDIRQS
+ depends on INET
select FW_LOADER
select CRC7
---help---
--
1.6.2.5
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: linux-next: Tree for November 2 (wireless/wl1271)
From: John W. Linville @ 2009-11-02 18:48 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, linux-wireless,
Luciano Coelho
In-Reply-To: <20091102184449.GJ14046@tuxdriver.com>
Helps if I actually Cc: Luca...
On Mon, Nov 02, 2009 at 01:44:49PM -0500, John W. Linville wrote:
> On Mon, Nov 02, 2009 at 10:01:35AM -0800, Randy Dunlap wrote:
> > Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20091030:
> >
> >
> > wl1271 build fails when CONFIG_INET=n.
> > Should this driver depend on INET?
> >
> > Why does this driver, unlike all other wireless drivers,
> > want to use register_inetaddr_notifier()?
> >
> > wl1271_main.c:(.text+0x271052): undefined reference to `unregister_inetaddr_notifier'
> > wl1271_main.c:(.text+0x2714d7): undefined reference to `register_inetaddr_notifier'
>
> Yeah, that driver is doing some filtering based on IPv4.
>
> Luca, is that necessary? If so, then we need a patch like the one below...?
>
> John
>
> From ba823accfad68151d80503ff5fb04c049c9eadc2 Mon Sep 17 00:00:00 2001
> From: John W. Linville <linville@tuxdriver.com>
> Date: Mon, 2 Nov 2009 13:43:32 -0500
> Subject: [PATCH] wl1271: depend on INET
>
> wl1271_main.c:(.text+0x271052): undefined reference to `unregister_inetaddr_notifier'
> wl1271_main.c:(.text+0x2714d7): undefined reference to `register_inetaddr_notifier'
>
> Driver is doing some filtering based on IP addresses...
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/wl12xx/Kconfig | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/wl12xx/Kconfig b/drivers/net/wireless/wl12xx/Kconfig
> index 33de7fa..785e024 100644
> --- a/drivers/net/wireless/wl12xx/Kconfig
> +++ b/drivers/net/wireless/wl12xx/Kconfig
> @@ -42,6 +42,7 @@ config WL1251_SDIO
> config WL1271
> tristate "TI wl1271 support"
> depends on WL12XX && SPI_MASTER && GENERIC_HARDIRQS
> + depends on INET
> select FW_LOADER
> select CRC7
> ---help---
> --
> 1.6.2.5
>
> --
> John W. Linville Someday the world will need a hero, and you
> linville@tuxdriver.com might be all we have. Be ready.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: May I join ath9k_htc update 2009-10-28
From: Luis R. Rodriguez @ 2009-11-02 19:34 UTC (permalink / raw)
To: hong zhang; +Cc: Christian Lamparter, devel, linux-wireless, Stephen Chen
In-Reply-To: <44491.72003.qm@web57906.mail.re3.yahoo.com>
On Mon, Nov 2, 2009 at 11:26 AM, hong zhang <henryzhang62@yahoo.com> wrote:
> TL-WN721N is not 11n complied.
Huh? TL-WN721N should be ar9271 hardware. All ar9271 devices are
single stream devices which means the highest MCS rate is MCS 7. I
forget but I believe 11n wifi cert accepts single stream devices now.
> TL-WN821N complies with 11n.
As per Christian it seems this is an ar9170 device, which is dual
stream and using the older Atheros hardware. It certainly has capacity
to TX/RX more but remember that it is more expensive too. Single
stream devices bring 802.11n hardware price down to a competitive
level and kill 802.11g :)
Luis
^ permalink raw reply
* Re: Incorrect signal levels reported using wpa_supplicant's driver_nl80211
From: Dan Williams @ 2009-11-02 19:40 UTC (permalink / raw)
To: Maxim Levitsky
Cc: hostap@lists.shmoo.com, linux-wireless, networkmanager-list
In-Reply-To: <1256953837.9681.13.camel@maxim-laptop>
On Sat, 2009-10-31 at 03:50 +0200, Maxim Levitsky wrote:
> Sorry for cross-posting, but this issue really spans all three systems.
>
> I anylized why I get 100% quality on all access points except currently
> connected, when I used driver_nl80211 of wpa_supplcant.
>
> First, when NetworkManager plans to switch to this driver?
Soon. We've got some patches for this, but we'll also need tons of
testing. The WEXT stuff is pretty baked while nl80211 is still under
some flux. But of course the only way we bake nl80211 is by switching
to it...
> For me it gives me faster association speeds, especially when I toggle
> wireless with rfkill button.
>
>
> this is what happens on the kernel side:
> --> n80211 encodes only dBm data. It does so in, nl80211_send_bss.
> (or it can encode unspecified data, which has little use...)
>
> --> kernel also gives maximum ranges in, cfg80211_wext_giwrange, which is used by NM:
> range->max_qual.updated = IW_QUAL_NOISE_INVALID | IW_QUAL_DBM | IW_QUAL_QUAL_UPDATED | IW_QUAL_LEVEL_UPDATED ;
> range->max_qual.level = -110;
> range->max_qual.qual = 70;
> Thus it reports that it can't report noise.
>
>
> driver_nl80211 side:
>
> --> sends data as is, done in bss_info_handler:
> r->level = nla_get_u32(bss[NL80211_BSS_SIGNAL_MBM]);
> r->level /= 100; /* mBm to dBm */
> r->flags |= WPA_SCAN_LEVEL_DBM | WPA_SCAN_QUAL_INVALID;
>
> Again explicitly says that has no quality data, sends only dBm or unspecified data;
>
>
>
> NM side:
>
> --> three strategies used (in wireless_qual_to_percent)
> --> quality: (used with driver_wext), not reported by nl80211
>
> --> dbm: used only if:
> * valid and zero max_qual->level (but now set to -110....)
IIRC non-zero max_qual->level was the indication that the driver wanted
to use RSSI, not dBm. Since the real "max" dBm is around 0 (ie, that's
the highest signal strength you'll ever really see), max_qual->level
meant the driver was reporting signal strength in dBm. max_qual->level
== -110 is kinda wrong, because that's the _minimum_ level, not the max.
The noise floor is almost always around -100 dBm so setting
max_qual->level is pretty useless.
This is *exactly* why 'qual' is there: so that the driver itself can
figure out what the hell it's signal level is, and so that NM doesn't
have to go around assuming stuff.
For WEXT reporting, mac80211 should really be constructing a 'qual'
instead of leaving it 0. Then we don't have ambiguities with dBm, RSSI,
unspec, etc.
Dan
> * valid level (OK)
> * valid positive max_qual->noise OR valid positive current noise (noise set to invalid and not reported even by my driver...)
>
> --> RSSI: (device reports numbers from 0 to max_qual.level):
> * nonzero valid max_qual->level, and it is assumed to be positive too...
> * valid level
>
>
> currently RSSI path is taken and results in 100% quality.
>
>
> I think that dBm strategy should be revised, and in addtion to that.
>
> Of course whole NM currently depends on WEXT, for exmple it would get signal level for current AP via WEXT, and thus use quality level
> as reported by driver.
>
> Thus there are differences between NM dBm quality calculation and driver ones, and therefore NM will report different quality levels... sigh...
>
>
> Best regards,
> Maxim Levitsky
>
>
> PS: I want signal quality bars back in NM....
>
> --
> 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
^ permalink raw reply
* Re: ath5k AP issues
From: Bob Copeland @ 2009-11-02 19:43 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Michael Buesch, Johannes Berg, linux-wireless, Luis Rodriguez,
ath9k-devel
In-Reply-To: <40f31dec0911010541l650513fg31ffcadd12698f0@mail.gmail.com>
On Sun, Nov 01, 2009 at 03:41:49PM +0200, Nick Kossifidis wrote:
> So beacon-sent gated option doesn't work ?
> Did you try also AR5K_DCU_MISC_ARBLOCK_IGNORE ?
>
> Also according to docs Beacon frames should use queue 9 and CAB should
> use queue 8 (don't know why but docs say that these are the
> appropriate DCUs), beacon-gated triggering might only work if we use
> DCU 9 for beacons (now we are using queue 7 for beacons and queue 6
> for cab).
So the results of that testing aren't so good; I still couldn't get it
to work. See the following patch if you want to play with it. Eventually
TXDESC interrupt should fire and you would see:
cabq: enqueued xxxxx
cabq: processed xxxxx
But that only happens with DBA gating, with BCN_SENT_GT I never see
'processed.' Anything else to try?
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 1c90d6b..fb80b53 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -504,10 +504,10 @@ enum ath5k_tx_queue_id {
AR5K_TX_QUEUE_ID_DATA_MIN = 0, /*IEEE80211_TX_QUEUE_DATA0*/
AR5K_TX_QUEUE_ID_DATA_MAX = 4, /*IEEE80211_TX_QUEUE_DATA4*/
AR5K_TX_QUEUE_ID_DATA_SVP = 5, /*IEEE80211_TX_QUEUE_SVP - Spectralink Voice Protocol*/
- AR5K_TX_QUEUE_ID_CAB = 6, /*IEEE80211_TX_QUEUE_AFTER_BEACON*/
- AR5K_TX_QUEUE_ID_BEACON = 7, /*IEEE80211_TX_QUEUE_BEACON*/
- AR5K_TX_QUEUE_ID_UAPSD = 8,
- AR5K_TX_QUEUE_ID_XR_DATA = 9,
+ AR5K_TX_QUEUE_ID_UAPSD = 6,
+ AR5K_TX_QUEUE_ID_XR_DATA = 7,
+ AR5K_TX_QUEUE_ID_CAB = 8, /*IEEE80211_TX_QUEUE_AFTER_BEACON*/
+ AR5K_TX_QUEUE_ID_BEACON = 9, /*IEEE80211_TX_QUEUE_BEACON*/
};
/*
@@ -541,7 +541,7 @@ struct ath5k_txq_info {
u32 tqi_cbr_period; /* Constant bit rate period */
u32 tqi_cbr_overflow_limit;
u32 tqi_burst_time;
- u32 tqi_ready_time; /* Not used */
+ u32 tqi_ready_time; /* Time queue waits after an event */
};
/*
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 9c6ab53..1287ded 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1488,7 +1488,8 @@ ath5k_beaconq_config(struct ath5k_softc *sc)
ret = ath5k_hw_get_tx_queueprops(ah, sc->bhalq, &qi);
if (ret)
- return ret;
+ goto err;
+
if (sc->opmode == NL80211_IFTYPE_AP ||
sc->opmode == NL80211_IFTYPE_MESH_POINT) {
/*
@@ -1515,10 +1516,28 @@ ath5k_beaconq_config(struct ath5k_softc *sc)
if (ret) {
ATH5K_ERR(sc, "%s: unable to update parameters for beacon "
"hardware queue!\n", __func__);
- return ret;
+ goto err;
}
+ ret = ath5k_hw_reset_tx_queue(ah, sc->bhalq); /* push to h/w */
+ if (ret)
+ goto err;
- return ath5k_hw_reset_tx_queue(ah, sc->bhalq); /* push to h/w */;
+ /* reconfigure cabq with ready time to 80% of beacon_interval */
+ ret = ath5k_hw_get_tx_queueprops(ah, AR5K_TX_QUEUE_ID_CAB, &qi);
+ if (ret)
+ goto err;
+
+ qi.tqi_aifs = 0;
+ qi.tqi_cw_min = 0;
+ qi.tqi_cw_max = 0;
+ qi.tqi_ready_time = (sc->bintval * 80) / 100;
+ ret = ath5k_hw_set_tx_queueprops(ah, AR5K_TX_QUEUE_ID_CAB, &qi);
+ if (ret)
+ goto err;
+
+ ret = ath5k_hw_reset_tx_queue(ah, AR5K_TX_QUEUE_ID_CAB);
+err:
+ return ret;
}
static void
@@ -1939,6 +1958,10 @@ ath5k_tx_processq(struct ath5k_softc *sc, struct ath5k_txq *txq)
}
skb = bf->skb;
+
+ if (txq == sc->cabq)
+ printk(KERN_DEBUG "cabq processed %p\n", skb);
+
info = IEEE80211_SKB_CB(skb);
bf->skb = NULL;
@@ -2146,6 +2169,7 @@ ath5k_beacon_send(struct ath5k_softc *sc)
skb = ieee80211_get_buffered_bc(sc->hw, sc->vif);
while (skb) {
+ printk(KERN_DEBUG "cabq enqueued %p\n", skb);
ath5k_tx_queue(sc->hw, skb, sc->cabq);
skb = ieee80211_get_buffered_bc(sc->hw, sc->vif);
}
diff --git a/drivers/net/wireless/ath/ath5k/qcu.c b/drivers/net/wireless/ath/ath5k/qcu.c
index eeebb9a..592ee45 100644
--- a/drivers/net/wireless/ath/ath5k/qcu.c
+++ b/drivers/net/wireless/ath/ath5k/qcu.c
@@ -408,21 +408,29 @@ int ath5k_hw_reset_tx_queue(struct ath5k_hw *ah, unsigned int queue)
break;
case AR5K_TX_QUEUE_CAB:
+#if 1
AR5K_REG_ENABLE_BITS(ah, AR5K_QUEUE_MISC(queue),
AR5K_QCU_MISC_FRSHED_BCN_SENT_GT |
AR5K_QCU_MISC_CBREXP_DIS |
AR5K_QCU_MISC_CBREXP_BCN_DIS);
+#else
+ AR5K_REG_ENABLE_BITS(ah, AR5K_QUEUE_MISC(queue),
+ AR5K_QCU_MISC_FRSHED_DBA_GT |
+ AR5K_QCU_MISC_CBREXP_DIS |
+ AR5K_QCU_MISC_CBREXP_BCN_DIS);
- ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL -
+ ath5k_hw_reg_write(ah, ((tq->tqi_ready_time -
(AR5K_TUNE_SW_BEACON_RESP -
AR5K_TUNE_DMA_BEACON_RESP) -
AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF) * 1024) |
AR5K_QCU_RDYTIMECFG_ENABLE,
AR5K_QUEUE_RDYTIMECFG(queue));
+#endif
AR5K_REG_ENABLE_BITS(ah, AR5K_QUEUE_DFS_MISC(queue),
(AR5K_DCU_MISC_ARBLOCK_CTL_GLOBAL <<
- AR5K_DCU_MISC_ARBLOCK_CTL_S));
+ AR5K_DCU_MISC_ARBLOCK_CTL_S) |
+ AR5K_DCU_MISC_ARBLOCK_IGNORE);
break;
case AR5K_TX_QUEUE_UAPSD:
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply related
* Re: [PATCH] libertas: remove internal buffers from GSPI driver
From: Dan Williams @ 2009-11-02 19:54 UTC (permalink / raw)
To: Andrey Yurovsky; +Cc: linux-wireless, libertas-dev, sebatian, george.shore
In-Reply-To: <45e8e6c40910291048g2958c086oa6b7a39dbb68258f@mail.gmail.com>
On Thu, 2009-10-29 at 10:48 -0700, Andrey Yurovsky wrote:
> On Wed, Oct 28, 2009 at 10:13 AM, Dan Williams <dcbw@redhat.com> wrote:
> > Looks OK to me, but I don't have any of the SPI hardware so when you get
> > a Tested-by:, let me know and I'll ack.
>
> Thanks Dan, by the way the issue with WPA2 and IEEE PS is unrelated to
> this patch (that is, I can reproduce it without the patch applied) so
> we'll need to address that separately. So at this point we have:
>
> Tested-by: George Shore <george.shore@imgtec.com>
> Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Acked-by: Dan Williams <dcbw@redhat.com>
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Frank Schaefer @ 2009-11-02 20:07 UTC (permalink / raw)
To: Matthew Dharm, linux-wireless, linux-usb
In-Reply-To: <20091102004756.GC24436@one-eyed-alien.net>
Matthew Dharm schrieb:
> On Sun, Nov 01, 2009 at 09:24:28PM +0100, Frank Schaefer wrote:
>
>> Matthew Dharm schrieb:
>>
>>> On Sun, Nov 01, 2009 at 07:29:20PM +0100, Josua Dietze wrote:
>>>
>>>> Frank Schaefer schrieb:
>>>>> I really think the mode-switching should be done in the kernel and not
>>>>> in user-space for reasons of usability.
>>>>>
>>>> What is wrong with an udev rule entry? By the way, did the "eject"
>>>> command line tool work as well?
>>>>
>>> And I think it should be done in userspace for issues of maintainability
>>> and useability. It is much easier for users to upgrade their udev then
>>> their kernel.
>>>
>> Maintainability for whom ? The kernel-devs or the distro-people and the
>> users ? ;)
>>
>
> Both.
>
>> Please think about the users. They don't know that they have to create
>> udev-rules or have to install additional packages like usb_modeswitch
>> (which is nevertheless a great tool !).
>> And even if they know, they don't want to do that. So it's up to the
>> distros to do this automatically, which will in reality never come true
>> for all devices and distros.
>
> I am thinking about the users. Do you really think someone who has
> difficulty installing a new udev rule (probably a line or two of text
> copied from a google search) or installing a new version of usb_modeswitch
> (probably one or two commands to the distro package manager) will have an
> easier time doing a custom kernel-compile and update?
>
I think users should not need to do ANY of these things ! That's called
usability.
Which users do you think know how to create udev-rules and how to
compile a kernel ?
Of course you and me and likely all others on this mailing-list and
maybe you think Linux should be for them, only.
I think we should do as much as possible to improve Linux-usability for
"normal" and even "less experienced" users.
And in this case, it would be really easy.
> Updates in userspace are universally easier; on users, on kernel deves, and
> on distro devs.
>
> Matt
>
Why ? Of course, the benfit for kernel-developers is that the work is
done by others...
But for the distros it makes life much more difficult in many respects.
And users are in the somehow insane situation that they have to keep the
driver (kernel) AND the "key to be able to use it" up-to-date.
That's not only a problem because they both things from different
sources/directions !
Frank
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Frank Schaefer @ 2009-11-02 20:10 UTC (permalink / raw)
To: Matthew Dharm, linux-wireless, linux-usb
In-Reply-To: <20091102005144.GE24436@one-eyed-alien.net>
Matthew Dharm schrieb:
> On Sun, Nov 01, 2009 at 09:11:49PM +0100, Frank Schaefer wrote:
>
>> Josua Dietze schrieb:
>>
>>> Frank Schaefer schrieb:
>>>
>>>> I really think the mode-switching should be done in the kernel and not
>>>> in user-space for reasons of usability.
>>>>
>>> What is wrong with an udev rule entry? By the way, did the "eject"
>>> command line tool work as well?
>>>
>> It returns an error but the device is ejected.
>> But do you really want the users to open a terminal window and call
>> "eject" each time they plug their device in ;) ?
>>
>
> If 'eject' worked, then why not use a simple udev entry? That way nobody
> has to call anything by hand...
>
> Matt
>
And who will create this udev-entry ;) ? How can you make sure that this
is done on all systems ?
Frank
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Frank Schaefer @ 2009-11-02 20:16 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-usb, linux-wireless
In-Reply-To: <200911012149.57966.chunkeey@googlemail.com>
Christian Lamparter schrieb:
> On Sunday 01 November 2009 21:24:28 Frank Schaefer wrote:
>
>> Matthew Dharm schrieb:
>>
>>> On Sun, Nov 01, 2009 at 07:29:20PM +0100, Josua Dietze wrote:
>>>
>>>> Frank Schaefer schrieb:
>>>>
>>>>> I really think the mode-switching should be done in the kernel and not
>>>>> in user-space for reasons of usability.
>>>>>
>>>> What is wrong with an udev rule entry? By the way, did the "eject"
>>>> command line tool work as well?
>>>>
>>> And I think it should be done in userspace for issues of maintainability
>>> and useability. It is much easier for users to upgrade their udev then
>>> their kernel.
>>>
>> Maintainability for whom ? The kernel-devs or the distro-people and the
>> users ? ;)
>>
>> Please think about the users. They don't know that they have to create
>> udev-rules or have to install additional packages like usb_modeswitch
>> (which is nevertheless a great tool !).
>> And even if they know, they don't want to do that. So it's up to the
>> distros to do this automatically, which will in reality never come true
>> for all devices and distros.
>>
> yes, please think about the users!
>
> All not-so-trival-changes have to go through wireless-testing / wireless-next,
> net-next, linux-next until it hits finally the mainline... And then only users
> which are able to update their kernels will benefit, *everyone else* has
> to wait until their distros to pick up the new kernel... this could be easily more
> than a year before the device will work right out of the box for *everyone else*.
>
Which potential not-so-trivial-changes do you think of in this case ?
And userspace-software + packages have a quality-assurance-procedure,
too, right ? ;)
> Therefore udev should be the way to go...
Maybe it should be, but it's a solution which will never work
satisfyingly. At least as long as the needed udev-rules are not shipped
with the kernel...
> and as a bonus: a userspace/udev solution
> does work with older kernels right away!
>
> Regards,
> Chr
Frank
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Dan Williams @ 2009-11-02 20:18 UTC (permalink / raw)
To: Frank Schaefer; +Cc: Matthew Dharm, linux-wireless, linux-usb
In-Reply-To: <4AEF3CAD.10809@gmx.net>
On Mon, 2009-11-02 at 21:10 +0100, Frank Schaefer wrote:
> Matthew Dharm schrieb:
> > On Sun, Nov 01, 2009 at 09:11:49PM +0100, Frank Schaefer wrote:
> >
> >> Josua Dietze schrieb:
> >>
> >>> Frank Schaefer schrieb:
> >>>
> >>>> I really think the mode-switching should be done in the kernel and not
> >>>> in user-space for reasons of usability.
> >>>>
> >>> What is wrong with an udev rule entry? By the way, did the "eject"
> >>> command line tool work as well?
> >>>
> >> It returns an error but the device is ejected.
> >> But do you really want the users to open a terminal window and call
> >> "eject" each time they plug their device in ;) ?
> >>
> >
> > If 'eject' worked, then why not use a simple udev entry? That way nobody
> > has to call anything by hand...
> >
> > Matt
> >
> And who will create this udev-entry ;) ? How can you make sure that this
> is done on all systems ?
You can't. The distros have to make sure it works. Personally, I think
these should all be in the kernel, but the kernel doesn't contain
policy. And unfortunately, for some devices (3G modems specifically)
ejecting the driver CD thing *is* policy. Option for example protested
mightily when I sent a patch to auto-eject their driver CD, because they
apparently do use the driver CD thing to send Linux drivers and software
to a few clients. But by and large, the driver CD is completely
useless.
Devices with fake driver CDs and how they are handled currently:
Zydas WLAN - kernel
Huawei 3G - kernel (unusual_devs entry)
Sierra 3G - kernel (drivers/usb/serial/sierra.c)
Option 3G - udev rules, 'rezero', or usb_modeswitch
ZTE 3G - udev rules, simple 'eject'
Dan
^ permalink raw reply
* Re: [PATCH] mac80211: Fix IBSS merge
From: Felix Fietkau @ 2009-11-02 20:27 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: John W. Linville, Johannes Berg, Sujith, linux-wireless
In-Reply-To: <43e72e890911020947i3a9ea736ve95fa6b1fac724a4@mail.gmail.com>
Luis R. Rodriguez wrote:
> On Mon, Nov 2, 2009 at 9:20 AM, Felix Fietkau <nbd@nbd.name> wrote:
>> John W. Linville wrote:
>>> On Mon, Nov 02, 2009 at 09:44:46AM +0100, Johannes Berg wrote:
>>>> On Mon, 2009-11-02 at 12:33 +0530, Sujith wrote:
>>>> > Currently, in IBSS mode, a single creator would go into
>>>> > a loop trying to merge/scan. This happens because the IBSS timer is
>>>> > rearmed on finishing a scan and the subsequent
>>>> > timer invocation requests another scan immediately.
>>>> >
>>>> > This patch fixes this issue by checking if we have just completed
>>>> > a scan run trying to merge with other IBSS networks.
>>>>
>>>> Heh, how many people do we need to fix IBSS? :)
>>>
>>> Yeah, no kidding...I suspect that actual IBSS users are few, and a
>>> substantial number of those are doing crazy things with it! :-)
>> Yeah, we're doing crazy things like mesh networks of few hundred
>> nodes... something that 11s isn't really suitable for. :-)
>
> Anyone know if this applies for 32?
What exactly?
- Felix
^ permalink raw reply
* Re: [PATCH] mac80211: Fix IBSS merge
From: Luis R. Rodriguez @ 2009-11-02 20:36 UTC (permalink / raw)
To: Felix Fietkau; +Cc: John W. Linville, Johannes Berg, Sujith, linux-wireless
In-Reply-To: <4AEF40A0.2030408@openwrt.org>
On Mon, Nov 2, 2009 at 12:27 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> Luis R. Rodriguez wrote:
>> On Mon, Nov 2, 2009 at 9:20 AM, Felix Fietkau <nbd@nbd.name> wrote:
>>> John W. Linville wrote:
>>>> On Mon, Nov 02, 2009 at 09:44:46AM +0100, Johannes Berg wrote:
>>>>> On Mon, 2009-11-02 at 12:33 +0530, Sujith wrote:
>>>>> > Currently, in IBSS mode, a single creator would go into
>>>>> > a loop trying to merge/scan. This happens because the IBSS timer is
>>>>> > rearmed on finishing a scan and the subsequent
>>>>> > timer invocation requests another scan immediately.
>>>>> >
>>>>> > This patch fixes this issue by checking if we have just completed
>>>>> > a scan run trying to merge with other IBSS networks.
>>>>>
>>>>> Heh, how many people do we need to fix IBSS? :)
>>>>
>>>> Yeah, no kidding...I suspect that actual IBSS users are few, and a
>>>> substantial number of those are doing crazy things with it! :-)
>>> Yeah, we're doing crazy things like mesh networks of few hundred
>>> nodes... something that 11s isn't really suitable for. :-)
>>
>> Anyone know if this applies for 32?
> What exactly?
The patch.
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: Fix IBSS merge
From: John W. Linville @ 2009-11-02 20:43 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Felix Fietkau, Johannes Berg, Sujith, linux-wireless
In-Reply-To: <43e72e890911021236ra2a77baj6436abcc2d86cb3b@mail.gmail.com>
On Mon, Nov 02, 2009 at 12:36:31PM -0800, Luis R. Rodriguez wrote:
> On Mon, Nov 2, 2009 at 12:27 PM, Felix Fietkau <nbd@openwrt.org> wrote:
> > Luis R. Rodriguez wrote:
> >> On Mon, Nov 2, 2009 at 9:20 AM, Felix Fietkau <nbd@nbd.name> wrote:
> >>> John W. Linville wrote:
> >>>> On Mon, Nov 02, 2009 at 09:44:46AM +0100, Johannes Berg wrote:
> >>>>> On Mon, 2009-11-02 at 12:33 +0530, Sujith wrote:
> >>>>> > Currently, in IBSS mode, a single creator would go into
> >>>>> > a loop trying to merge/scan. This happens because the IBSS timer is
> >>>>> > rearmed on finishing a scan and the subsequent
> >>>>> > timer invocation requests another scan immediately.
> >>>>> >
> >>>>> > This patch fixes this issue by checking if we have just completed
> >>>>> > a scan run trying to merge with other IBSS networks.
> >>>>>
> >>>>> Heh, how many people do we need to fix IBSS? :)
> >>>>
> >>>> Yeah, no kidding...I suspect that actual IBSS users are few, and a
> >>>> substantial number of those are doing crazy things with it! :-)
> >>> Yeah, we're doing crazy things like mesh networks of few hundred
> >>> nodes... something that 11s isn't really suitable for. :-)
> >>
> >> Anyone know if this applies for 32?
> > What exactly?
>
> The patch.
The patch applies and seems sane. It seems like 2.6.32 would need it as well?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Alan Cox @ 2009-11-02 21:05 UTC (permalink / raw)
To: Dan Williams; +Cc: Frank Schaefer, Matthew Dharm, linux-wireless, linux-usb
In-Reply-To: <1257193115.1027.24.camel@localhost.localdomain>
> apparently do use the driver CD thing to send Linux drivers and software
> to a few clients. But by and large, the driver CD is completely
> useless.
And then every so often you need to rummage around the driver CD image to
extract the APN or other data you need to make your modem work. At which
point you end up having to recompile the kernel to get it. Very annoying
given it could be trivially done properly in user space.
HAL probably needs the database of these devices *not* the kernel.
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Matthew Dharm @ 2009-11-02 21:10 UTC (permalink / raw)
To: Frank Schaefer; +Cc: linux-wireless, linux-usb
In-Reply-To: <4AEF3BF8.1080701@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]
On Mon, Nov 02, 2009 at 09:07:20PM +0100, Frank Schaefer wrote:
> Matthew Dharm schrieb:
> > I am thinking about the users. Do you really think someone who has
> > difficulty installing a new udev rule (probably a line or two of text
> > copied from a google search) or installing a new version of usb_modeswitch
> > (probably one or two commands to the distro package manager) will have an
> > easier time doing a custom kernel-compile and update?
> >
> I think users should not need to do ANY of these things ! That's called
> usability.
So, new hardware should "magically" work? When you can write software to
support hardware that doesn't exist yet, let me know.
> Which users do you think know how to create udev-rules and how to
> compile a kernel ?
> Of course you and me and likely all others on this mailing-list and
> maybe you think Linux should be for them, only.
>
> I think we should do as much as possible to improve Linux-usability for
> "normal" and even "less experienced" users.
Okay, let's talk about "less experienced" users. Suppose you are one of
these users. You get a new device, and you want to use it. You do some
web searching, and discover either:
(a) you need to download and recompile your kernel
(b) you need to cut-and-paste some text from a web page into a file
Which do you think is easier?
And, the situation above pre-supposes that the requisite changes (kernel or
userspace) haven't already been picked up by a distro maintainer.
> And in this case, it would be really easy.
> > Updates in userspace are universally easier; on users, on kernel deves, and
> > on distro devs.
> >
> Why ? Of course, the benfit for kernel-developers is that the work is
> done by others...
> But for the distros it makes life much more difficult in many respects.
I highly doubt this. Distros must very carefully test all the kernel
changes they decide to pull in. Each and every change in a kernel-layer is
a high-risk change for them. Changing userspace packages is much
lower-risk, and thus consumes correspondingly fewer resources.
> And users are in the somehow insane situation that they have to keep the
> driver (kernel) AND the "key to be able to use it" up-to-date.
> That's not only a problem because they both things from different
> sources/directions !
I think you may have missed part of an earlier discussion, wherein we
discussed such devices which would NOT need ANY kernel changes. The idea
was that udev could "eject" the fake-USB device, then add the device IDs to
the serial/cdc_amc/whatever driver dynamically, at runtime. Thus, no need
to make any kernel updates at all.
And, that system works *today* with the existing kernel code.
Matt
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
Okay, this isn't funny anymore! Let me down! I'll tell Bill on you!!
-- Microsoft Salesman
User Friendly, 4/1/1998
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for November 2 (wireless/wl1271)
From: Luciano Coelho @ 2009-11-02 21:10 UTC (permalink / raw)
To: ext John W. Linville
Cc: Randy Dunlap, Stephen Rothwell, linux-next@vger.kernel.org, LKML,
linux-wireless@vger.kernel.org
In-Reply-To: <20091102184843.GK14046@tuxdriver.com>
ext John W. Linville wrote:
> Helps if I actually Cc: Luca...
Yes, it does. :) I would see this at some point but CCing me speed things up
quite a lot.
> On Mon, Nov 02, 2009 at 01:44:49PM -0500, John W. Linville wrote:
>> On Mon, Nov 02, 2009 at 10:01:35AM -0800, Randy Dunlap wrote:
>>> Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> Changes since 20091030:
>>>
>>> wl1271 build fails when CONFIG_INET=n.
>>> Should this driver depend on INET?
>>>
>>> Why does this driver, unlike all other wireless drivers,
>>> want to use register_inetaddr_notifier()?
>>>
>>> wl1271_main.c:(.text+0x271052): undefined reference to `unregister_inetaddr_notifier'
>>> wl1271_main.c:(.text+0x2714d7): undefined reference to `register_inetaddr_notifier'
>> Yeah, that driver is doing some filtering based on IPv4.
>>
>> Luca, is that necessary? If so, then we need a patch like the one below...?
Yes, this is necessary. We are doing ARP filtering according to the IP address
of the interface, as you have realized. Our implementation is rather ugly at
the moment, so the plan is to try to get rid of this dependency on INET, but we
need it for now.
Thanks Randy for finding this and thanks John for fixing it.
>> From ba823accfad68151d80503ff5fb04c049c9eadc2 Mon Sep 17 00:00:00 2001
>> From: John W. Linville <linville@tuxdriver.com>
>> Date: Mon, 2 Nov 2009 13:43:32 -0500
>> Subject: [PATCH] wl1271: depend on INET
>>
>> wl1271_main.c:(.text+0x271052): undefined reference to `unregister_inetaddr_notifier'
>> wl1271_main.c:(.text+0x2714d7): undefined reference to `register_inetaddr_notifier'
>>
>> Driver is doing some filtering based on IP addresses...
>>
>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>> ---
>> drivers/net/wireless/wl12xx/Kconfig | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/wireless/wl12xx/Kconfig b/drivers/net/wireless/wl12xx/Kconfig
>> index 33de7fa..785e024 100644
>> --- a/drivers/net/wireless/wl12xx/Kconfig
>> +++ b/drivers/net/wireless/wl12xx/Kconfig
>> @@ -42,6 +42,7 @@ config WL1251_SDIO
>> config WL1271
>> tristate "TI wl1271 support"
>> depends on WL12XX && SPI_MASTER && GENERIC_HARDIRQS
>> + depends on INET
>> select FW_LOADER
>> select CRC7
>> ---help---
>> --
>> 1.6.2.5
Acked-by: Luciano Coelho <luciano.coelho@nokia.com>
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Matthew Dharm @ 2009-11-02 21:11 UTC (permalink / raw)
To: Dan Williams; +Cc: Frank Schaefer, linux-wireless, linux-usb
In-Reply-To: <1257193115.1027.24.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 897 bytes --]
On Mon, Nov 02, 2009 at 12:18:35PM -0800, Dan Williams wrote:
> Devices with fake driver CDs and how they are handled currently:
>
> Zydas WLAN - kernel
> Huawei 3G - kernel (unusual_devs entry)
> Sierra 3G - kernel (drivers/usb/serial/sierra.c)
> Option 3G - udev rules, 'rezero', or usb_modeswitch
> ZTE 3G - udev rules, simple 'eject'
It's worth noting that for some of these which are handled in-kernel, it
had to be done that way because their storage-emulation was so poor that
the normal 'eject' WOULD NOT work properly.
Any device which can be handled in userspace SHOULD be handled there.
Matt
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
But where are the THEMES?! How do you expect me to use an OS without
themes?!
-- Stef
User Friendly, 10/9/1998
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Matthew Dharm @ 2009-11-02 21:15 UTC (permalink / raw)
To: Frank Schaefer, linux-wireless, linux-usb
In-Reply-To: <20091102211001.GH24436@one-eyed-alien.net>
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
On Mon, Nov 02, 2009 at 01:10:01PM -0800, Matthew Dharm wrote:
> I think you may have missed part of an earlier discussion, wherein we
> discussed such devices which would NOT need ANY kernel changes. The idea
> was that udev could "eject" the fake-USB device, then add the device IDs to
> the serial/cdc_amc/whatever driver dynamically, at runtime. Thus, no need
> to make any kernel updates at all.
>
> And, that system works *today* with the existing kernel code.
Search the archives for "Toshiba G450" if you want to find that discussion.
Matt
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
Sir, for the hundreth time, we do NOT carry 600-round boxes of belt-fed
suction darts!
-- Salesperson to Greg
User Friendly, 12/30/1997
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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