* [PATCH] mac80211: fix reason code output endianness
From: Johannes Berg @ 2009-10-29 9:09 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
When HT debugging is enabled and we receive a DelBA
frame we print out the reason code in the wrong byte
order. Fix that so we don't get weird values printed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/ht.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- wireless-testing.orig/net/mac80211/ht.c 2009-10-29 10:07:41.000000000 +0100
+++ wireless-testing/net/mac80211/ht.c 2009-10-29 10:07:49.000000000 +0100
@@ -153,7 +153,7 @@ void ieee80211_process_delba(struct ieee
if (net_ratelimit())
printk(KERN_DEBUG "delba from %pM (%s) tid %d reason code %d\n",
mgmt->sa, initiator ? "initiator" : "recipient", tid,
- mgmt->u.action.u.delba.reason_code);
+ le16_to_cpu(mgmt->u.action.u.delba.reason_code));
#endif /* CONFIG_MAC80211_HT_DEBUG */
if (initiator == WLAN_BACK_INITIATOR)
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 11:12 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel, John W. Linville
In-Reply-To: <200910282256.00407.bzolnier@gmail.com>
On Wednesday 28 October 2009 22:56:00 Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 28 October 2009 22:10:32 John W. Linville wrote:
> > Dave,
> >
> > I let my patches pile-up! Yikes!!
> >
> > This request includes the usual ton of stuff for -next -- driver
> > updates, fixes for some earlier -next stuff, a few cfg80211 changes to
> > accomodate the libertas driver, etc. Of note is the rt2800pci support
> > added to the rt2x00 family.
>
> Unfortunately rt2800pci support is non-functioning at the moment... :(
>
> > Pleaset let me know if there are problems!
>
> 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..
>
> The way rt2800usb and rt2800pci drivers are designed really results
> in making the task of adding working support for RT28x0 and RT30x0
> chipsets to rt2x00 infrastructure more difficult and time consuming
> than it should be... :(
What is even more disappointing (especially after all that "working with"
preaching) is that the patch is now in net-next-2.6..
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* [PATCH] mac80211: unconditionally set IEEE80211_TX_CTL_SEND_AFTER_DTIM
From: Johannes Berg @ 2009-10-29 11:19 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
When mac80211 is asked to buffer multicast frames
in AP mode, it will not set the flag indicating
that the frames should be sent after the DTIM
beacon for those frames buffered in software. Fix
this little inconsistency by always setting that
flag in the buffering code path.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
Drivers still need to know since they usually have to put such frames
onto a separate queue...
net/mac80211/tx.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- wireless-testing.orig/net/mac80211/tx.c 2009-10-29 12:15:05.000000000 +0100
+++ wireless-testing/net/mac80211/tx.c 2009-10-29 12:18:04.000000000 +0100
@@ -317,12 +317,11 @@ ieee80211_tx_h_multicast_ps_buf(struct i
if (!atomic_read(&tx->sdata->bss->num_sta_ps))
return TX_CONTINUE;
- /* buffered in hardware */
- if (!(tx->local->hw.flags & IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING)) {
- info->flags |= IEEE80211_TX_CTL_SEND_AFTER_DTIM;
+ info->flags |= IEEE80211_TX_CTL_SEND_AFTER_DTIM;
+ /* device releases frame after DTIM beacon */
+ if (!(tx->local->hw.flags & IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING))
return TX_CONTINUE;
- }
/* buffered in mac80211 */
if (tx->local->total_ps_buffered >= TOTAL_MAX_TX_BUFFER)
^ permalink raw reply
* [PATCH] wl1271: fix init loop timeout
From: Luciano Coelho @ 2009-10-29 11:20 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, juha_motorsportcom
The check after the loop which checks whether the initialization timed-out
was wrong. If the initialization would succeed exactly in the 20000th time
(the value set for INIT_LOOP), the driver would bail out and claim that
initialization failed.
Reported-by: Juha Leppanen <juha_motorsportcom@luukku.com>
Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
Reviewed-by: Janne Ylalehto <janne.ylalehto@nokia.com>
---
drivers/net/wireless/wl12xx/wl1271_boot.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/wl1271_boot.c b/drivers/net/wireless/wl12xx/wl1271_boot.c
index ba4a2b4..8678bea 100644
--- a/drivers/net/wireless/wl12xx/wl1271_boot.c
+++ b/drivers/net/wireless/wl12xx/wl1271_boot.c
@@ -380,7 +380,7 @@ static int wl1271_boot_run_firmware(struct wl1271 *wl)
}
}
- if (loop >= INIT_LOOP) {
+ if (loop > INIT_LOOP) {
wl1271_error("timeout waiting for the hardware to "
"complete initialization");
return -EIO;
--
1.5.6.5
^ permalink raw reply related
* [PATCH] firmware_class: make request_firmware_nowait more useful
From: Johannes Berg @ 2009-10-29 11:36 UTC (permalink / raw)
To: Greg KH
Cc: linux-wireless, linux-kernel, Ming Lei, Catalin Marinas,
David Woodhouse, Pavel Roskin, Abhay Salunke
Unfortunately, one cannot hold on to the struct firmware
that request_firmware_nowait() hands off, which is needed
in some cases. Allow this by requiring the callback to
free it (via release_firmware).
Additionally, give it a gfp_t parameter -- all the current
users call it from a GFP_KERNEL context so the GFP_ATOMIC
isn't necessary. This also marks an API break which is
useful in a sense, although that is obviously not the
primary purpose of this change.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/base/firmware_class.c | 14 ++++++--------
drivers/firmware/dell_rbu.c | 9 +++++++--
drivers/serial/ucc_uart.c | 8 +++++---
drivers/staging/comedi/drivers/usbdux.c | 5 ++++-
drivers/staging/comedi/drivers/usbduxfast.c | 5 ++++-
drivers/usb/atm/ueagle-atm.c | 7 ++++---
include/linux/firmware.h | 5 +++--
7 files changed, 33 insertions(+), 20 deletions(-)
--- wireless-testing.orig/drivers/base/firmware_class.c 2009-10-26 16:45:18.000000000 +0100
+++ wireless-testing/drivers/base/firmware_class.c 2009-10-26 17:08:10.000000000 +0100
@@ -601,12 +601,9 @@ request_firmware_work_func(void *arg)
}
ret = _request_firmware(&fw, fw_work->name, fw_work->device,
fw_work->uevent);
- if (ret < 0)
- fw_work->cont(NULL, fw_work->context);
- else {
- fw_work->cont(fw, fw_work->context);
- release_firmware(fw);
- }
+
+ fw_work->cont(fw, fw_work->context);
+
module_put(fw_work->module);
kfree(fw_work);
return ret;
@@ -619,6 +616,7 @@ request_firmware_work_func(void *arg)
* is non-zero else the firmware copy must be done manually.
* @name: name of firmware file
* @device: device for which firmware is being loaded
+ * @gfp: allocation flags
* @context: will be passed over to @cont, and
* @fw may be %NULL if firmware request fails.
* @cont: function will be called asynchronously when the firmware
@@ -631,12 +629,12 @@ request_firmware_work_func(void *arg)
int
request_firmware_nowait(
struct module *module, int uevent,
- const char *name, struct device *device, void *context,
+ const char *name, struct device *device, gfp_t gfp, void *context,
void (*cont)(const struct firmware *fw, void *context))
{
struct task_struct *task;
struct firmware_work *fw_work = kmalloc(sizeof (struct firmware_work),
- GFP_ATOMIC);
+ gfp);
if (!fw_work)
return -ENOMEM;
--- wireless-testing.orig/include/linux/firmware.h 2009-10-26 16:45:53.000000000 +0100
+++ wireless-testing/include/linux/firmware.h 2009-10-26 17:03:56.000000000 +0100
@@ -4,6 +4,7 @@
#include <linux/module.h>
#include <linux/types.h>
#include <linux/compiler.h>
+#include <linux/gfp.h>
#define FW_ACTION_NOHOTPLUG 0
#define FW_ACTION_HOTPLUG 1
@@ -38,7 +39,7 @@ int request_firmware(const struct firmwa
struct device *device);
int request_firmware_nowait(
struct module *module, int uevent,
- const char *name, struct device *device, void *context,
+ const char *name, struct device *device, gfp_t gfp, void *context,
void (*cont)(const struct firmware *fw, void *context));
void release_firmware(const struct firmware *fw);
@@ -51,7 +52,7 @@ static inline int request_firmware(const
}
static inline int request_firmware_nowait(
struct module *module, int uevent,
- const char *name, struct device *device, void *context,
+ const char *name, struct device *device, gfp_t gfp, void *context,
void (*cont)(const struct firmware *fw, void *context))
{
return -EINVAL;
--- wireless-testing.orig/drivers/firmware/dell_rbu.c 2009-10-26 16:49:06.000000000 +0100
+++ wireless-testing/drivers/firmware/dell_rbu.c 2009-10-26 16:49:52.000000000 +0100
@@ -544,9 +544,12 @@ static void callbackfn_rbu(const struct
{
rbu_data.entry_created = 0;
- if (!fw || !fw->size)
+ if (!fw)
return;
+ if (!fw->size)
+ goto out;
+
spin_lock(&rbu_data.lock);
if (!strcmp(image_type, "mono")) {
if (!img_update_realloc(fw->size))
@@ -568,6 +571,8 @@ static void callbackfn_rbu(const struct
} else
pr_debug("invalid image type specified.\n");
spin_unlock(&rbu_data.lock);
+ out:
+ release_firmware(fw);
}
static ssize_t read_rbu_image_type(struct kobject *kobj,
@@ -615,7 +620,7 @@ static ssize_t write_rbu_image_type(stru
spin_unlock(&rbu_data.lock);
req_firm_rc = request_firmware_nowait(THIS_MODULE,
FW_ACTION_NOHOTPLUG, "dell_rbu",
- &rbu_device->dev, &context,
+ &rbu_device->dev, GFP_KERNEL, &context,
callbackfn_rbu);
if (req_firm_rc) {
printk(KERN_ERR
--- wireless-testing.orig/drivers/serial/ucc_uart.c 2009-10-26 16:50:04.000000000 +0100
+++ wireless-testing/drivers/serial/ucc_uart.c 2009-10-26 16:51:10.000000000 +0100
@@ -1179,16 +1179,18 @@ static void uart_firmware_cont(const str
if (firmware->header.length != fw->size) {
dev_err(dev, "invalid firmware\n");
- return;
+ goto out;
}
ret = qe_upload_firmware(firmware);
if (ret) {
dev_err(dev, "could not load firmware\n");
- return;
+ goto out;
}
firmware_loaded = 1;
+ out:
+ release_firmware(fw);
}
static int ucc_uart_probe(struct of_device *ofdev,
@@ -1247,7 +1249,7 @@ static int ucc_uart_probe(struct of_devi
*/
ret = request_firmware_nowait(THIS_MODULE,
FW_ACTION_HOTPLUG, filename, &ofdev->dev,
- &ofdev->dev, uart_firmware_cont);
+ GFP_KERNEL, &ofdev->dev, uart_firmware_cont);
if (ret) {
dev_err(&ofdev->dev,
"could not load firmware %s\n",
--- wireless-testing.orig/drivers/staging/comedi/drivers/usbdux.c 2009-10-26 16:51:16.000000000 +0100
+++ wireless-testing/drivers/staging/comedi/drivers/usbdux.c 2009-10-26 16:51:52.000000000 +0100
@@ -2327,9 +2327,11 @@ static void usbdux_firmware_request_comp
if (ret) {
dev_err(&usbdev->dev,
"Could not upload firmware (err=%d)\n", ret);
- return;
+ goto out;
}
comedi_usb_auto_config(usbdev, BOARDNAME);
+ out:
+ release_firmware(fw);
}
/* allocate memory for the urbs and initialise them */
@@ -2580,6 +2582,7 @@ static int usbduxsub_probe(struct usb_in
FW_ACTION_HOTPLUG,
"usbdux_firmware.bin",
&udev->dev,
+ GFP_KERNEL,
usbduxsub + index,
usbdux_firmware_request_complete_handler);
--- wireless-testing.orig/drivers/staging/comedi/drivers/usbduxfast.c 2009-10-26 17:01:20.000000000 +0100
+++ wireless-testing/drivers/staging/comedi/drivers/usbduxfast.c 2009-10-26 17:01:47.000000000 +0100
@@ -1451,10 +1451,12 @@ static void usbduxfast_firmware_request_
if (ret) {
dev_err(&usbdev->dev,
"Could not upload firmware (err=%d)\n", ret);
- return;
+ goto out;
}
comedi_usb_auto_config(usbdev, BOARDNAME);
+ out:
+ release_firmware(fw);
}
/*
@@ -1569,6 +1571,7 @@ static int usbduxfastsub_probe(struct us
FW_ACTION_HOTPLUG,
"usbduxfast_firmware.bin",
&udev->dev,
+ GFP_KERNEL,
usbduxfastsub + index,
usbduxfast_firmware_request_complete_handler);
--- wireless-testing.orig/drivers/usb/atm/ueagle-atm.c 2009-10-26 17:01:48.000000000 +0100
+++ wireless-testing/drivers/usb/atm/ueagle-atm.c 2009-10-26 17:03:29.000000000 +0100
@@ -667,12 +667,12 @@ static void uea_upload_pre_firmware(cons
else
uea_info(usb, "firmware uploaded\n");
- uea_leaves(usb);
- return;
+ goto err;
err_fw_corrupted:
uea_err(usb, "firmware is corrupted\n");
err:
+ release_firmware(fw_entry);
uea_leaves(usb);
}
@@ -705,7 +705,8 @@ static int uea_load_firmware(struct usb_
break;
}
- ret = request_firmware_nowait(THIS_MODULE, 1, fw_name, &usb->dev, usb, uea_upload_pre_firmware);
+ ret = request_firmware_nowait(THIS_MODULE, 1, fw_name, &usb->dev,
+ GFP_KERNEL, usb, uea_upload_pre_firmware);
if (ret)
uea_err(usb, "firmware %s is not available\n", fw_name);
else
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: David Miller @ 2009-10-29 12:15 UTC (permalink / raw)
To: bzolnier; +Cc: linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291212.41656.bzolnier@gmail.com>
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 29 Oct 2009 12:12:41 +0100
> What is even more disappointing (especially after all that "working with"
> preaching) is that the patch is now in net-next-2.6..
John is the wireless maintainer, I take his tree in since the changes
in there have his blessing.
If you have a problem with some change in there, work it out with him
and he'll send the fixed up changes to me thereafterwards.
I don't really see what the big deal is, any change can be reverted.
^ permalink raw reply
* ath5k AP issues
From: Michael Buesch @ 2009-10-29 12:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luis Rodriguez
[-- Attachment #1: Type: text/plain, Size: 709 bytes --]
Attached is a wireshark log. Let me explain what you see in there:
I have an ath5k AP and the powersaving n810 device as STA.
What I try to do is ping the n810. You can see that at the start of the log.
Packet #31 is a ping to the n810. #42, too. and so on...
You see that the n810 does not reply. (not even with an 802.11 ack)
I guess the n810 is in PS at that time.
Also note that the TIM sent by the AP is empty.
What I did at #135 is _simultaneously_ ping from the n810 to the ath5k.
At that point suddenly both pings running on both ends start to succeed.
This is with a vanilla 2.6.31.5 kernel, but I can also reproduce this with
compat-wireless and compat-wireless-stable.
--
Greetings, Michael.
[-- Attachment #2: capture --]
[-- Type: application/octet-stream, Size: 41364 bytes --]
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 12:45 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.051509.119751790.davem@davemloft.net>
On Thursday 29 October 2009 13:15:09 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 12:12:41 +0100
>
> > What is even more disappointing (especially after all that "working with"
> > preaching) is that the patch is now in net-next-2.6..
>
> John is the wireless maintainer, I take his tree in since the changes
> in there have his blessing.
>
> If you have a problem with some change in there, work it out with him
> and he'll send the fixed up changes to me thereafterwards.
What do you mean by that?
That *I* should be fixing the patch in question instead of the submitter?
Do some different rules apply in the networking than in other parts of
the kernel that I'm not aware of?
There were valid concerns raised on the initial rt2800pci patch submission,
yet two days later patch is in John's tree, after few more days it is in yours
tree and happily on his way into 2.6.33.
Until issues mentioned in:
http://lkml.org/lkml/2009/10/17/81
are addressed rt2800pci shouldn't be queued for Linus' tree.
[ Please note that this driver doesn't work at all currently so the standard
argument of having hardware support early upstream cannot be applied here. ]
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: David Miller @ 2009-10-29 12:59 UTC (permalink / raw)
To: bzolnier; +Cc: linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291345.05888.bzolnier@gmail.com>
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 29 Oct 2009 13:45:05 +0100
> That *I* should be fixing the patch in question instead of the
> submitter?
I'm saying that you should work with John to have him send a revert or
whatever to me.
^ permalink raw reply
* Re: ath5k AP issues
From: Michael Buesch @ 2009-10-29 13:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luis Rodriguez
In-Reply-To: <200910291330.26172.mb@bu3sch.de>
On Thursday 29 October 2009 13:30:24 Michael Buesch wrote:
> Attached is a wireshark log. Let me explain what you see in there:
>
> I have an ath5k AP and the powersaving n810 device as STA.
> What I try to do is ping the n810. You can see that at the start of the log.
>
> Packet #31 is a ping to the n810. #42, too. and so on...
> You see that the n810 does not reply. (not even with an 802.11 ack)
> I guess the n810 is in PS at that time.
> Also note that the TIM sent by the AP is empty.
>
> What I did at #135 is _simultaneously_ ping from the n810 to the ath5k.
> At that point suddenly both pings running on both ends start to succeed.
>
> This is with a vanilla 2.6.31.5 kernel, but I can also reproduce this with
> compat-wireless and compat-wireless-stable.
>
This is dmesg log with verbose PS debugging enabled.
[265617.902457] phy0: Allocated STA 00:1d:6e:9b:c5:a6
[265617.903187] phy0: Inserted STA 00:1d:6e:9b:c5:a6
[265620.539771] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
Here I start pinging the n810. No dmesg messages appear and pinging does not work.
When I start pinging _from_ the n810, the following messages appear:
[265660.078055] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 exits power save mode
[265660.078066] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 sending 0 filtered/0 PS frames since STA not sleeping anymore
[265660.289206] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
[265660.938988] STA 00:1d:6e:9b:c5:a6 aid 1: PS buffer (entries before 0)
[265660.985997] STA 00:1d:6e:9b:c5:a6 aid 1: PS Poll (entries after 0)
[265660.986016] wlan0: STA 00:1d:6e:9b:c5:a6 in PS mode, but pspoll set -> send frame
[265661.008310] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 exits power save mode
[265661.008321] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 sending 0 filtered/0 PS frames since STA not sleeping anymore
[265661.226915] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
--
Greetings, Michael.
^ permalink raw reply
* Re: ath5k AP issues
From: Johannes Berg @ 2009-10-29 13:29 UTC (permalink / raw)
To: Michael Buesch; +Cc: linux-wireless, Luis Rodriguez, Bob Copeland
In-Reply-To: <200910291330.26172.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
On Thu, 2009-10-29 at 13:30 +0100, Michael Buesch wrote:
> Attached is a wireshark log. Let me explain what you see in there:
>
> I have an ath5k AP and the powersaving n810 device as STA.
> What I try to do is ping the n810. You can see that at the start of the log.
>
> Packet #31 is a ping to the n810. #42, too. and so on...
It's not a ping, it's an ARP. The problem is that the TIM IE never
indicates multicast traffic although multicast traffic is being sent.
But in later packets you can see that it's not buffered correctly at all
-- soemtimes it's sent after DTIM count 1 beacons.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: ath5k AP issues
From: Michael Buesch @ 2009-10-29 13:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luis Rodriguez, Bob Copeland
In-Reply-To: <200910291406.03422.mb@bu3sch.de>
On Thursday 29 October 2009 14:06:01 Michael Buesch wrote:
> On Thursday 29 October 2009 13:30:24 Michael Buesch wrote:
> > Attached is a wireshark log. Let me explain what you see in there:
> >
> > I have an ath5k AP and the powersaving n810 device as STA.
> > What I try to do is ping the n810. You can see that at the start of the log.
> >
> > Packet #31 is a ping to the n810. #42, too. and so on...
> > You see that the n810 does not reply. (not even with an 802.11 ack)
> > I guess the n810 is in PS at that time.
> > Also note that the TIM sent by the AP is empty.
> >
> > What I did at #135 is _simultaneously_ ping from the n810 to the ath5k.
> > At that point suddenly both pings running on both ends start to succeed.
> >
> > This is with a vanilla 2.6.31.5 kernel, but I can also reproduce this with
> > compat-wireless and compat-wireless-stable.
> >
>
> This is dmesg log with verbose PS debugging enabled.
>
> [265617.902457] phy0: Allocated STA 00:1d:6e:9b:c5:a6
> [265617.903187] phy0: Inserted STA 00:1d:6e:9b:c5:a6
> [265620.539771] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
>
> Here I start pinging the n810. No dmesg messages appear and pinging does not work.
>
> When I start pinging _from_ the n810, the following messages appear:
>
> [265660.078055] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 exits power save mode
> [265660.078066] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 sending 0 filtered/0 PS frames since STA not sleeping anymore
> [265660.289206] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
> [265660.938988] STA 00:1d:6e:9b:c5:a6 aid 1: PS buffer (entries before 0)
> [265660.985997] STA 00:1d:6e:9b:c5:a6 aid 1: PS Poll (entries after 0)
> [265660.986016] wlan0: STA 00:1d:6e:9b:c5:a6 in PS mode, but pspoll set -> send frame
> [265661.008310] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 exits power save mode
> [265661.008321] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 sending 0 filtered/0 PS frames since STA not sleeping anymore
> [265661.226915] wlan0: STA 00:1d:6e:9b:c5:a6 aid 1 enters power save mode
>
>
Ok, to sum up some discussion from IRC:
The initial packets that fail are not pings, but ARPs. Which are broadcast frames.
The access point simply fails to notify the station via DTIM for the pending
multicast frames, so it stays in PS. Unicast and the corresponding TIM bitmap works properly,
which also explains why it works once we got a successful ARP (and it didn't expire, yet).
So there is a DTIM problem with multicast frames in ath5k.
--
Greetings, Michael.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 13:35 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.055901.24976117.davem@davemloft.net>
On Thursday 29 October 2009 13:59:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 13:45:05 +0100
>
> > That *I* should be fixing the patch in question instead of the
> > submitter?
>
> I'm saying that you should work with John to have him send a revert or
> whatever to me.
This is your responsibility to deal with your downstream maintainers,
not mine and since you have accepted John's patch I'm asking you to
revert rt2800pci patch from your tree.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Pekka Enberg @ 2009-10-29 13:52 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: David Miller, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291435.54203.bzolnier@gmail.com>
Hi Bart,
On Thu, Oct 29, 2009 at 3:35 PM, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>> I'm saying that you should work with John to have him send a revert or
>> whatever to me.
>
> This is your responsibility to deal with your downstream maintainers,
> not mine and since you have accepted John's patch I'm asking you to
> revert rt2800pci patch from your tree.
So why don't you just send a patch to fix it up? I see you're doing
lots of cleanups to the staging drivers, why not direct some of that
energy to the drivers/net/wireless ones?
Pekka
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: David Miller @ 2009-10-29 13:53 UTC (permalink / raw)
To: bzolnier; +Cc: linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291435.54203.bzolnier@gmail.com>
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 29 Oct 2009 14:35:54 +0100
> This is your responsibility to deal with your downstream maintainers,
> not mine and since you have accepted John's patch I'm asking you to
> revert rt2800pci patch from your tree.
That's not how it works Bart. You should not be asking 'me' to do
anything on wireless bits, there is absolutely no reason to bypass
John in the workflow.
^ permalink raw reply
* mesh support for rt73
From: Dan Rosenqvist @ 2009-10-29 13:19 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hi,
I'm currently trying to set up a small 802.11s mesh network. As I've come to understand there's no support for mesh networking at the moment for rt 73 based cards (using DWL-G122 C1).
Is it possible to implement the changes mentioned in http://linuxwireless.org/en/developers/Documentation/mac80211/API to support mesh networks for rt 73 as well?
Is there someone out there currently working on this? Otherwise, how could I contribute to make this work?
Regards,
Dan
^ permalink raw reply
* Re: [PATCH] firmware_class: make request_firmware_nowait more useful
From: Marcel Holtmann @ 2009-10-29 13:58 UTC (permalink / raw)
To: Johannes Berg
Cc: Greg KH, linux-wireless, linux-kernel, Ming Lei, Catalin Marinas,
David Woodhouse, Pavel Roskin, Abhay Salunke
In-Reply-To: <1256816162.3865.110.camel@johannes.local>
Hi Johannes,
> Unfortunately, one cannot hold on to the struct firmware
> that request_firmware_nowait() hands off, which is needed
> in some cases. Allow this by requiring the callback to
> free it (via release_firmware).
>
> Additionally, give it a gfp_t parameter -- all the current
> users call it from a GFP_KERNEL context so the GFP_ATOMIC
> isn't necessary. This also marks an API break which is
> useful in a sense, although that is obviously not the
> primary purpose of this change.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
I had a look at this one and looks good to me and makes perfect sense.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 14:13 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.065336.119302168.davem@davemloft.net>
On Thursday 29 October 2009 14:53:36 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 14:35:54 +0100
>
> > This is your responsibility to deal with your downstream maintainers,
> > not mine and since you have accepted John's patch I'm asking you to
> > revert rt2800pci patch from your tree.
>
> That's not how it works Bart. You should not be asking 'me' to do
> anything on wireless bits, there is absolutely no reason to bypass
> John in the workflow.
John has chosen to ignore my concerns and you are sending me back to him?
I like ping-pong but as a sport.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 14:14 UTC (permalink / raw)
To: Pekka Enberg; +Cc: David Miller, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <84144f020910290652n2e75827dk698b238b6bd1cbed@mail.gmail.com>
Hi,
On Thursday 29 October 2009 14:52:50 Pekka Enberg wrote:
> Hi Bart,
>
> On Thu, Oct 29, 2009 at 3:35 PM, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> >> I'm saying that you should work with John to have him send a revert or
> >> whatever to me.
> >
> > This is your responsibility to deal with your downstream maintainers,
> > not mine and since you have accepted John's patch I'm asking you to
> > revert rt2800pci patch from your tree.
>
> So why don't you just send a patch to fix it up? I see you're doing
"git revert a9b3a9f"
done.
Dave, if you have problems with executing the command locally I'll be
happy to supply you with the patch.
> lots of cleanups to the staging drivers, why not direct some of that
> energy to the drivers/net/wireless ones?
When did we start to apply "fix it yourself" rule instead of "submitter
should fix it" one to the _new_ code..
rt2800 drivers have their maintainers and I would like to know what they
are doing besides complaining about users and staging tree..
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: David Miller @ 2009-10-29 14:20 UTC (permalink / raw)
To: bzolnier; +Cc: linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291513.54326.bzolnier@gmail.com>
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 29 Oct 2009 15:13:54 +0100
> John has chosen to ignore my concerns and you are sending me back to him?
That's exactly why I won't overreach his maintainership role,
because you're inability to interact with and work with the
wireless maintainer isn't my problem.
In case you're concerned, I actually agree with John and others
on this issue, and disagree with your position.
So even if I felt it legitimate to overreach John, I still wouldn't
make the change you are requesting in this case.
Does it really eat you so hard when someone disagrees with you?
That's not going to work in the long term Bart, if John disagrees with
you he's the maintainer of wireless and that's it. You're going to
have to learn to work with people, and not just automatically go to a
"higher power" as soon as someone disagrees with you.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: David Miller @ 2009-10-29 14:21 UTC (permalink / raw)
To: bzolnier; +Cc: penberg, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291514.40318.bzolnier@gmail.com>
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 29 Oct 2009 15:14:40 +0100
> Dave, if you have problems with executing the command locally I'll be
> happy to supply you with the patch.
This is not the issue.
The issue is that John disagrees with you can you can't handle
that.
So instead of continuing to discuss things with him and the
other wireless folks, you want me to just overreach everybody
and revert someone else's work.
I'm not going to do that sorry, learn how to work with the
wireless people instead.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Johannes Berg @ 2009-10-29 14:24 UTC (permalink / raw)
To: David Miller; +Cc: bzolnier, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.072001.153801635.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
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.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 14:34 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.072001.153801635.davem@davemloft.net>
On Thursday 29 October 2009 15:20:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 15:13:54 +0100
>
> > John has chosen to ignore my concerns and you are sending me back to him?
>
> That's exactly why I won't overreach his maintainership role,
> because you're inability to interact with and work with the
> wireless maintainer isn't my problem.
>
> In case you're concerned, I actually agree with John and others
> on this issue, and disagree with your position.
>
> So even if I felt it legitimate to overreach John, I still wouldn't
> make the change you are requesting in this case.
Sorry but you are also wrong then and you are just in the way of progress.
> Does it really eat you so hard when someone disagrees with you?
>
> That's not going to work in the long term Bart, if John disagrees with
> you he's the maintainer of wireless and that's it. You're going to
> have to learn to work with people, and not just automatically go to a
> "higher power" as soon as someone disagrees with you.
I'm not going to waste my time on stupid or hopeless things just because you
or John like to call themselves "maintainers".
If Red Hat or some other company wants to hire me and pay me for spinning
inside networking bureaucracy than please contact me in private but as
long as it is my own time I'll just do what I think makes sense on technical
merits and not on who is the "maintainer" of this or that..
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Michael Buesch @ 2009-10-29 14:39 UTC (permalink / raw)
To: David Miller
Cc: bzolnier, penberg, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.072101.109209962.davem@davemloft.net>
On Thursday 29 October 2009 15:21:01 David Miller wrote:
> The issue is that John disagrees with you can you can't handle
> that.
>
> So instead of continuing to discuss things with him and the
> other wireless folks, you want me to just overreach everybody
> and revert someone else's work.
In the end this results in the driver maintainer being forced to maintain
code and handle bugreports for code that he disagrees with in the first place.
This is unacceptable and has to be resolved in some way.
If it's not possible to get it reverted through John (for whatever reason),
you're in charge to help the actual code maintainer out.
> I'm not going to do that sorry, learn how to work with the
> wireless people instead.
This is not the problem.
The problem is that stuff is merged without ack from the maintainer
and it's virtually impossible to get the stuff reverted. The only real
way for the maintainer to resolve this is 1) live with it or 2) fix it.
And that's bad, because it completely invalidates his priority queue.
Just like you must not bypass John, the driver maintainers must not be bypassed, too.
The quality control does _only_ work if nobody in the chain is bypassed.
But in this situation the quality control did already fail and it should be
tried hard to resolve (=revert) the situation instead of pointing at John.
--
Greetings, Michael.
^ permalink raw reply
* RE: [PATCH] libertas: remove internal buffers from GSPI driver
From: George Shore @ 2009-10-29 14:27 UTC (permalink / raw)
To: Andrey Yurovsky, linux-wireless; +Cc: libertas-dev, sebatian, dcbw
In-Reply-To: <1256687501-8636-1-git-send-email-andrey@cozybit.com>
> -----Original Message-----
> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> owner@vger.kernel.org] On Behalf Of Andrey Yurovsky
> Sent: 27 October 2009 23:52
> To: linux-wireless@vger.kernel.org
> Cc: libertas-dev@lists.infradead.org; sebatian@breakpoint.cc;
> dcbw@redhat.com; Andrey Yurovsky
> Subject: [PATCH] libertas: remove internal buffers from GSPI driver
>
> This patch removes the internal command and data buffers that the GSPI
> driver
> maintained and instead relies on the Libertas core to synchronize
access
> to the command and data ports as with the other interface drivers.
This
> cleanup reduces the GSPI driver's memory footprint and should improve
> performance by removing the need to copy to these internal buffers.
> This also simplifies the bottom half of the interrupt handler.
>
> This is an incremental cleanup: after removing the redundant buffers,
we
> can further improve the driver to use a threaded IRQ handler instead
of
> maintaining its own thread. However I would like a few folks to test
> the buffer removal first and make sure that I'm not introducing
> regressions.
>
> Tested on Blackfin BF527 with DMA disabled due to an issue with the
SPI
> host controller driver in the current bleeding-edge Blackfin kernel.
I
> would appreciate it if someone with working DMA could test this patch
> and provide feedback.
>
I've tested this on our in-house dev board with our in-house CPU, on the
8686 in GSPI mode. Everything works as expected :)
Tested-by: George Shore <george.shore@imgtec.com>
> Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
> ---
> drivers/net/wireless/libertas/if_spi.c | 136
++-------------------------
> -----
> 1 files changed, 6 insertions(+), 130 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/if_spi.c
> b/drivers/net/wireless/libertas/if_spi.c
> index 06df2e1..9e0096d 100644
> --- a/drivers/net/wireless/libertas/if_spi.c
> +++ b/drivers/net/wireless/libertas/if_spi.c
> @@ -32,12 +32,6 @@
> #include "dev.h"
> #include "if_spi.h"
>
> -struct if_spi_packet {
> - struct list_head list;
> - u16 blen;
> - u8 buffer[0]
__attribute__((aligned(4)));
> -};
> -
> struct if_spi_card {
> struct spi_device *spi;
> struct lbs_private *priv;
> @@ -66,33 +60,10 @@ struct if_spi_card {
> struct semaphore spi_thread_terminated;
>
> u8 cmd_buffer[IF_SPI_CMD_BUF_SIZE];
> -
> - /* A buffer of incoming packets from libertas core.
> - * Since we can't sleep in hw_host_to_card, we have to buffer
> - * them. */
> - struct list_head cmd_packet_list;
> - struct list_head data_packet_list;
> -
> - /* Protects cmd_packet_list and data_packet_list */
> - spinlock_t buffer_lock;
> };
>
> static void free_if_spi_card(struct if_spi_card *card)
> {
> - struct list_head *cursor, *next;
> - struct if_spi_packet *packet;
> -
> - BUG_ON(card->run_thread);
> - list_for_each_safe(cursor, next, &card->cmd_packet_list) {
> - packet = container_of(cursor, struct if_spi_packet,
list);
> - list_del(&packet->list);
> - kfree(packet);
> - }
> - list_for_each_safe(cursor, next, &card->data_packet_list) {
> - packet = container_of(cursor, struct if_spi_packet,
list);
> - list_del(&packet->list);
> - kfree(packet);
> - }
> spi_set_drvdata(card->spi, NULL);
> kfree(card);
> }
> @@ -774,40 +745,6 @@ out:
> return err;
> }
>
> -/* Move data or a command from the host to the card. */
> -static void if_spi_h2c(struct if_spi_card *card,
> - struct if_spi_packet *packet, int type)
> -{
> - int err = 0;
> - u16 int_type, port_reg;
> -
> - switch (type) {
> - case MVMS_DAT:
> - int_type = IF_SPI_CIC_TX_DOWNLOAD_OVER;
> - port_reg = IF_SPI_DATA_RDWRPORT_REG;
> - break;
> - case MVMS_CMD:
> - int_type = IF_SPI_CIC_CMD_DOWNLOAD_OVER;
> - port_reg = IF_SPI_CMD_RDWRPORT_REG;
> - break;
> - default:
> - lbs_pr_err("can't transfer buffer of type %d\n", type);
> - err = -EINVAL;
> - goto out;
> - }
> -
> - /* Write the data to the card */
> - err = spu_write(card, port_reg, packet->buffer, packet->blen);
> - if (err)
> - goto out;
> -
> -out:
> - kfree(packet);
> -
> - if (err)
> - lbs_pr_err("%s: error %d\n", __func__, err);
> -}
> -
> /* Inform the host about a card event */
> static void if_spi_e2h(struct if_spi_card *card)
> {
> @@ -837,8 +774,6 @@ static int lbs_spi_thread(void *data)
> int err;
> struct if_spi_card *card = data;
> u16 hiStatus;
> - unsigned long flags;
> - struct if_spi_packet *packet;
>
> while (1) {
> /* Wait to be woken up by one of two things. First, our
ISR
> @@ -877,43 +812,9 @@ static int lbs_spi_thread(void *data)
> if (hiStatus & IF_SPI_HIST_CMD_DOWNLOAD_RDY ||
> (card->priv->psstate != PS_STATE_FULL_POWER &&
> (hiStatus & IF_SPI_HIST_TX_DOWNLOAD_RDY))) {
> - /* This means two things. First of all,
> - * if there was a previous command sent, the
card has
> - * successfully received it.
> - * Secondly, it is now ready to download another
> - * command.
> - */
> lbs_host_to_card_done(card->priv);
> -
> - /* Do we have any command packets from the host
to
> - * send? */
> - packet = NULL;
> - spin_lock_irqsave(&card->buffer_lock, flags);
> - if (!list_empty(&card->cmd_packet_list)) {
> - packet = (struct if_spi_packet *)(card->
> - cmd_packet_list.next);
> - list_del(&packet->list);
> - }
> - spin_unlock_irqrestore(&card->buffer_lock,
flags);
> -
> - if (packet)
> - if_spi_h2c(card, packet, MVMS_CMD);
> }
> - if (hiStatus & IF_SPI_HIST_TX_DOWNLOAD_RDY) {
> - /* Do we have any data packets from the host to
> - * send? */
> - packet = NULL;
> - spin_lock_irqsave(&card->buffer_lock, flags);
> - if (!list_empty(&card->data_packet_list)) {
> - packet = (struct if_spi_packet *)(card->
> - data_packet_list.next);
> - list_del(&packet->list);
> - }
> - spin_unlock_irqrestore(&card->buffer_lock,
flags);
>
> - if (packet)
> - if_spi_h2c(card, packet, MVMS_DAT);
> - }
> if (hiStatus & IF_SPI_HIST_CARD_EVENT)
> if_spi_e2h(card);
>
> @@ -942,40 +843,18 @@ static int if_spi_host_to_card(struct
lbs_private
> *priv,
> u8 type, u8 *buf, u16 nb)
> {
> int err = 0;
> - unsigned long flags;
> struct if_spi_card *card = priv->card;
> - struct if_spi_packet *packet;
> - u16 blen;
>
> lbs_deb_enter_args(LBS_DEB_SPI, "type %d, bytes %d", type, nb);
>
> - if (nb == 0) {
> - lbs_pr_err("%s: invalid size requested: %d\n", __func__,
nb);
> - err = -EINVAL;
> - goto out;
> - }
> - blen = ALIGN(nb, 4);
> - packet = kzalloc(sizeof(struct if_spi_packet) + blen,
GFP_ATOMIC);
> - if (!packet) {
> - err = -ENOMEM;
> - goto out;
> - }
> - packet->blen = blen;
> - memcpy(packet->buffer, buf, nb);
> - memset(packet->buffer + nb, 0, blen - nb);
> + nb = ALIGN(nb, 4);
>
> switch (type) {
> case MVMS_CMD:
> - priv->dnld_sent = DNLD_CMD_SENT;
> - spin_lock_irqsave(&card->buffer_lock, flags);
> - list_add_tail(&packet->list, &card->cmd_packet_list);
> - spin_unlock_irqrestore(&card->buffer_lock, flags);
> + err = spu_write(card, IF_SPI_CMD_RDWRPORT_REG, buf, nb);
> break;
> case MVMS_DAT:
> - priv->dnld_sent = DNLD_DATA_SENT;
> - spin_lock_irqsave(&card->buffer_lock, flags);
> - list_add_tail(&packet->list, &card->data_packet_list);
> - spin_unlock_irqrestore(&card->buffer_lock, flags);
> + err = spu_write(card, IF_SPI_DATA_RDWRPORT_REG, buf,
nb);
> break;
> default:
> lbs_pr_err("can't transfer buffer of type %d", type);
> @@ -983,9 +862,6 @@ static int if_spi_host_to_card(struct lbs_private
> *priv,
> break;
> }
>
> - /* Wake up the spi thread */
> - up(&card->spi_ready);
> -out:
> lbs_deb_leave_args(LBS_DEB_SPI, "err=%d", err);
> return err;
> }
> @@ -1062,9 +938,6 @@ static int __devinit if_spi_probe(struct
spi_device
> *spi)
>
> sema_init(&card->spi_ready, 0);
> sema_init(&card->spi_thread_terminated, 0);
> - INIT_LIST_HEAD(&card->cmd_packet_list);
> - INIT_LIST_HEAD(&card->data_packet_list);
> - spin_lock_init(&card->buffer_lock);
>
> /* Initialize the SPI Interface Unit */
> err = spu_init(card, pdata->use_dummy_writes);
> @@ -1141,6 +1014,9 @@ static int __devinit if_spi_probe(struct
spi_device
> *spi)
> goto terminate_thread;
> }
>
> + /* poke the IRQ handler so that we don't miss the first
interrupt */
> + up(&card->spi_ready);
> +
> /* Start the card.
> * This will call register_netdev, and we'll start
> * getting interrupts... */
> --
> 1.5.6.3
>
> --
> 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
-
This message is subject to Imagination Technologies' e-mail terms: http://www.imgtec.com/e-mail.htm
Imagination Technologies Ltd is a limited company registered in England No: 1306335
Registered Office: Imagination House, Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ.
Email to and from the company may be monitored for compliance and other administrative purposes.
-
^ 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