* [RFC/RFT] rtl8187: Implement rfkill support
From: Herton Ronaldo Krzesinski @ 2009-08-22 3:38 UTC (permalink / raw)
To: linux-wireless; +Cc: Larry Finger, Hin-Tak Leung
This change implements rfkill support for RTL8187B and RTL8187L devices,
using new cfg80211 rfkill API.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
---
drivers/net/wireless/rtl818x/Makefile | 2 +-
drivers/net/wireless/rtl818x/rtl8187.h | 1 +
drivers/net/wireless/rtl818x/rtl8187_dev.c | 28 ++++++-----
drivers/net/wireless/rtl818x/rtl8187_leds.c | 4 +-
drivers/net/wireless/rtl818x/rtl8187_rfkill.c | 63 +++++++++++++++++++++++++
drivers/net/wireless/rtl818x/rtl8187_rfkill.h | 8 +++
drivers/net/wireless/rtl818x/rtl818x.h | 5 +-
7 files changed, 94 insertions(+), 17 deletions(-)
create mode 100644 drivers/net/wireless/rtl818x/rtl8187_rfkill.c
create mode 100644 drivers/net/wireless/rtl818x/rtl8187_rfkill.h
diff --git a/drivers/net/wireless/rtl818x/Makefile b/drivers/net/wireless/rtl818x/Makefile
index 37e3d4d..93cbfbe 100644
--- a/drivers/net/wireless/rtl818x/Makefile
+++ b/drivers/net/wireless/rtl818x/Makefile
@@ -1,5 +1,5 @@
rtl8180-objs := rtl8180_dev.o rtl8180_rtl8225.o rtl8180_sa2400.o rtl8180_max2820.o rtl8180_grf5101.o
-rtl8187-objs := rtl8187_dev.o rtl8187_rtl8225.o rtl8187_leds.o
+rtl8187-objs := rtl8187_dev.o rtl8187_rtl8225.o rtl8187_leds.o rtl8187_rfkill.o
obj-$(CONFIG_RTL8180) += rtl8180.o
obj-$(CONFIG_RTL8187) += rtl8187.o
diff --git a/drivers/net/wireless/rtl818x/rtl8187.h b/drivers/net/wireless/rtl818x/rtl8187.h
index c09bfef..bf9175a 100644
--- a/drivers/net/wireless/rtl818x/rtl8187.h
+++ b/drivers/net/wireless/rtl818x/rtl8187.h
@@ -133,6 +133,7 @@ struct rtl8187_priv {
__le16 bits16;
__le32 bits32;
} *io_dmabuf;
+ bool rfkill_off;
};
void rtl8187_write_phy(struct ieee80211_hw *dev, u8 addr, u32 data);
diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index 5830f6c..b6e9fbd 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -32,6 +32,7 @@
#ifdef CONFIG_RTL8187_LEDS
#include "rtl8187_leds.h"
#endif
+#include "rtl8187_rfkill.h"
MODULE_AUTHOR("Michael Wu <flamingice@sourmilk.net>");
MODULE_AUTHOR("Andrea Merello <andreamrl@tiscali.it>");
@@ -648,10 +649,10 @@ static int rtl8187_init_hw(struct ieee80211_hw *dev)
/* setup card */
rtl818x_iowrite16(priv, &priv->map->RFPinsSelect, 0);
- rtl818x_iowrite8(priv, &priv->map->GPIO, 0);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, 0);
rtl818x_iowrite16(priv, &priv->map->RFPinsSelect, (4 << 8));
- rtl818x_iowrite8(priv, &priv->map->GPIO, 1);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, 1);
rtl818x_iowrite8(priv, &priv->map->GP_ENABLE, 0);
rtl818x_iowrite8(priv, &priv->map->EEPROM_CMD, RTL818X_EEPROM_CMD_CONFIG);
@@ -674,11 +675,11 @@ static int rtl8187_init_hw(struct ieee80211_hw *dev)
/* host_usb_init */
rtl818x_iowrite16(priv, &priv->map->RFPinsSelect, 0);
- rtl818x_iowrite8(priv, &priv->map->GPIO, 0);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, 0);
reg = rtl818x_ioread8(priv, (u8 *)0xFE53);
rtl818x_iowrite8(priv, (u8 *)0xFE53, reg | (1 << 7));
rtl818x_iowrite16(priv, &priv->map->RFPinsSelect, (4 << 8));
- rtl818x_iowrite8(priv, &priv->map->GPIO, 0x20);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, 0x20);
rtl818x_iowrite8(priv, &priv->map->GP_ENABLE, 0);
rtl818x_iowrite16(priv, &priv->map->RFPinsOutput, 0x80);
rtl818x_iowrite16(priv, &priv->map->RFPinsSelect, 0x80);
@@ -910,12 +911,12 @@ static int rtl8187_start(struct ieee80211_hw *dev)
u32 reg;
int ret;
+ mutex_lock(&priv->conf_mutex);
+
ret = (!priv->is_rtl8187b) ? rtl8187_init_hw(dev) :
rtl8187b_init_hw(dev);
if (ret)
- return ret;
-
- mutex_lock(&priv->conf_mutex);
+ goto rtl8187_start_exit;
init_usb_anchor(&priv->anchored);
priv->dev = dev;
@@ -942,8 +943,7 @@ static int rtl8187_start(struct ieee80211_hw *dev)
(7 << 21 /* MAX TX DMA */));
rtl8187_init_urbs(dev);
rtl8187b_init_status_urb(dev);
- mutex_unlock(&priv->conf_mutex);
- return 0;
+ goto rtl8187_start_exit;
}
rtl818x_iowrite16(priv, &priv->map->INT_MASK, 0xFFFF);
@@ -987,9 +987,10 @@ static int rtl8187_start(struct ieee80211_hw *dev)
reg |= RTL818X_CMD_RX_ENABLE;
rtl818x_iowrite8(priv, &priv->map->CMD, reg);
INIT_DELAYED_WORK(&priv->work, rtl8187_work);
- mutex_unlock(&priv->conf_mutex);
- return 0;
+rtl8187_start_exit:
+ mutex_unlock(&priv->conf_mutex);
+ return ret;
}
static void rtl8187_stop(struct ieee80211_hw *dev)
@@ -1282,7 +1283,8 @@ static const struct ieee80211_ops rtl8187_ops = {
.bss_info_changed = rtl8187_bss_info_changed,
.prepare_multicast = rtl8187_prepare_multicast,
.configure_filter = rtl8187_configure_filter,
- .conf_tx = rtl8187_conf_tx
+ .conf_tx = rtl8187_conf_tx,
+ .rfkill_poll = rtl8187_rfkill_poll
};
static void rtl8187_eeprom_register_read(struct eeprom_93cx6 *eeprom)
@@ -1522,6 +1524,7 @@ static int __devinit rtl8187_probe(struct usb_interface *intf,
reg &= 0xFF;
rtl8187_leds_init(dev, reg);
#endif
+ rtl8187_rfkill_init(dev);
return 0;
@@ -1545,6 +1548,7 @@ static void __devexit rtl8187_disconnect(struct usb_interface *intf)
#ifdef CONFIG_RTL8187_LEDS
rtl8187_leds_exit(dev);
#endif
+ rtl8187_rfkill_exit(dev);
ieee80211_unregister_hw(dev);
priv = dev->priv;
diff --git a/drivers/net/wireless/rtl818x/rtl8187_leds.c b/drivers/net/wireless/rtl818x/rtl8187_leds.c
index a6cfb7e..a1c670f 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_leds.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_leds.c
@@ -42,7 +42,7 @@ static void led_turn_on(struct work_struct *work)
mutex_lock(&priv->conf_mutex);
switch (led->ledpin) {
case LED_PIN_GPIO0:
- rtl818x_iowrite8(priv, &priv->map->GPIO, 0x01);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, 0x01);
rtl818x_iowrite8(priv, &priv->map->GP_ENABLE, 0x00);
break;
case LED_PIN_LED0:
@@ -80,7 +80,7 @@ static void led_turn_off(struct work_struct *work)
mutex_lock(&priv->conf_mutex);
switch (led->ledpin) {
case LED_PIN_GPIO0:
- rtl818x_iowrite8(priv, &priv->map->GPIO, 0x01);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, 0x01);
rtl818x_iowrite8(priv, &priv->map->GP_ENABLE, 0x01);
break;
case LED_PIN_LED0:
diff --git a/drivers/net/wireless/rtl818x/rtl8187_rfkill.c b/drivers/net/wireless/rtl818x/rtl8187_rfkill.c
new file mode 100644
index 0000000..1e17236
--- /dev/null
+++ b/drivers/net/wireless/rtl818x/rtl8187_rfkill.c
@@ -0,0 +1,63 @@
+/*
+ * Linux RFKILL support for RTL8187B
+ *
+ * Copyright (c) 2009 Herton Ronaldo Krzesinski <herton@mandriva.com.br>
+ *
+ * Based on the RFKILL handling in the r8187 driver, which is:
+ * Copyright (c) Realtek Semiconductor Corp. All rights reserved.
+ *
+ * Thanks to Realtek for their support!
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/types.h>
+#include <linux/usb.h>
+#include <net/mac80211.h>
+
+#include "rtl8187.h"
+
+static bool rtl8187_is_radio_enabled(struct rtl8187_priv *priv)
+{
+ u8 gpio;
+
+ gpio = rtl818x_ioread8(priv, &priv->map->GPIO0);
+ rtl818x_iowrite8(priv, &priv->map->GPIO0, gpio & ~0x02);
+ gpio = rtl818x_ioread8(priv, &priv->map->GPIO1);
+
+ return gpio & 0x02;
+}
+
+void rtl8187_rfkill_init(struct ieee80211_hw *hw)
+{
+ struct rtl8187_priv *priv = hw->priv;
+
+ priv->rfkill_off = rtl8187_is_radio_enabled(priv);
+ printk(KERN_INFO "rtl8187: wireless switch is %s\n",
+ priv->rfkill_off ? "on" : "off");
+ wiphy_rfkill_set_hw_state(hw->wiphy, !priv->rfkill_off);
+ wiphy_rfkill_start_polling(hw->wiphy);
+}
+
+void rtl8187_rfkill_poll(struct ieee80211_hw *hw)
+{
+ bool enabled;
+ struct rtl8187_priv *priv = hw->priv;
+
+ mutex_lock(&priv->conf_mutex);
+ enabled = rtl8187_is_radio_enabled(priv);
+ if (unlikely(enabled != priv->rfkill_off)) {
+ priv->rfkill_off = enabled;
+ printk(KERN_INFO "rtl8187: wireless radio switch turned %s\n",
+ enabled ? "on" : "off");
+ wiphy_rfkill_set_hw_state(hw->wiphy, !enabled);
+ }
+ mutex_unlock(&priv->conf_mutex);
+}
+
+void rtl8187_rfkill_exit(struct ieee80211_hw *hw)
+{
+ wiphy_rfkill_stop_polling(hw->wiphy);
+}
diff --git a/drivers/net/wireless/rtl818x/rtl8187_rfkill.h b/drivers/net/wireless/rtl818x/rtl8187_rfkill.h
new file mode 100644
index 0000000..e12575e
--- /dev/null
+++ b/drivers/net/wireless/rtl818x/rtl8187_rfkill.h
@@ -0,0 +1,8 @@
+#ifndef RTL8187_RFKILL_H
+#define RTL8187_RFKILL_H
+
+void rtl8187_rfkill_init(struct ieee80211_hw *hw);
+void rtl8187_rfkill_poll(struct ieee80211_hw *hw);
+void rtl8187_rfkill_exit(struct ieee80211_hw *hw);
+
+#endif /* RTL8187_RFKILL_H */
diff --git a/drivers/net/wireless/rtl818x/rtl818x.h b/drivers/net/wireless/rtl818x/rtl818x.h
index 562222e..8522490 100644
--- a/drivers/net/wireless/rtl818x/rtl818x.h
+++ b/drivers/net/wireless/rtl818x/rtl818x.h
@@ -138,8 +138,9 @@ struct rtl818x_csr {
__le32 RF_PARA;
__le32 RF_TIMING;
u8 GP_ENABLE;
- u8 GPIO;
- u8 reserved_12[2];
+ u8 GPIO0;
+ u8 GPIO1;
+ u8 reserved_12;
__le32 HSSI_PARA;
u8 reserved_13[4];
u8 TX_AGC_CTL;
--
1.6.4
^ permalink raw reply related
* Re: Plans for an online meeting regarding Radiotap
From: Dave Young @ 2009-08-22 4:38 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Johannes Berg, Richard Farina, Mike Kershaw, Sam Leffler,
Rafael Laufer, Damien Bergamini, Sepherosa Ziehau,
Thomas d'Otreppe, radiotap, linux-wireless, freebsd-mobile,
misc-openbsd, tech-openbsd, netbsd-net, wireshark-dev
In-Reply-To: <69e28c910908211455u5dcd70f0u94eab510ab91a69a@mail.gmail.com>
2009/8/22 Gábor Stefanik <netrolller.3d@gmail.com>:
> 2009/8/21 Johannes Berg <johannes@sipsolutions.net>:
>> On Fri, 2009-08-21 at 17:04 +0200, Gábor Stefanik wrote:
>>
>>> I've reworked RTS/CTS since then, just haven't got to sending a new
>>> proposal yet. The current plan is as follows:
>>>
>>> TX_FLAGS & 0x0002: Use CTS
>>> TX_FLAGS & 0x0004: Use RTS
>>> TX_FLAGS & 0x0020: Disable RTS/CTS usage
>>
>> Seems a bit strange, wouldn't setting neither RTS nor CTS have the
>> effect? Seems like 0x20 should rather be "use automatic and ignore the
>> other bits". Anyway, not appropriate here, you should just bring a new
>> proposal.
>
> The point is that if all bits are 0, auto-setup is used. The problem
> with my original proposal (using two bits) was that an all-zero value
> had different effect than not including the TX flags field (and simply
> swapping "none" and "auto" would result in an illogicality where what
> would logically be "use both" would become "use neither" - just the
> opposite of its logical meaning). Making 0x20 mean "Auto-select
> RTS/CTS", interpreting all-zeros as "Use neither", would have the same
> problem as my proposal - all-zeros is different from a missing field.
> (An empty, zeroed field 15 should have no effect on the process,
> behaving as if field 15 was not present in the header.)
>
>>
>>> If I remember correctly, I made an implementation for the Linux kernel
>>> (a generator-side implementation) and one for Wireshark (a parser-side
>>> implementation). Or should I make two generator-side implementations
>>> according to the requirement (e.g. one for Linux, another for
>>> OpenBSD)?
>>
>> No, that was ok, I just meant that therefore by definition it can't be a
>> problem of lack of implementations.
>>
>> johannes
>>
>
>
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>
Here also, please fix your cc-list, I'm not the david what you want to send to
--
Regards
dave
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: feng tian @ 2009-08-22 5:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: Larry Finger, linux-wireless
In-Reply-To: <1250858409.5137.2.camel@johannes.local>
Instead of waiting for the codes, we decide to do someting on
supporting the BCM 4325 running in linux via SDIO.
The linux wireless dirver supports another chip (marvel 8686) with
SDIO interface, the sources codes locate in
drivers/net/wireless/libertas.
We are wondering to develop the BCM4325 driver in the reference to the
marvel 8686 SDIO driver.
Please give comments on this, thanks.
BR
Feng
2009/8/21 Johannes Berg <johannes@sipsolutions.net>:
> On Fri, 2009-08-21 at 07:13 -0500, Larry Finger wrote:
>
>> > We are working on a project which supports the BCM4325 linux wireless
>> > driver. The interface between the BCM chip and SOC(pxa310) is SDIO.
>> > I did some searches online and found that there is no available driver
>> > for this chip. Do I have to implement this myself? Is there anyone can
>> > provide us some related materials? Thanks very much.
>>
>> The code for the LP PHY, which I believe is present in the 4325, is
>> just being written. At the moment, the chip is able to receive on some
>> channels, and may be able to transmit. These results are reported on
>> this mailing list, and the code is being applied to the wireless
>> testing git tree.
>
> Also, somebody is working on SDIO support with Michael.
>
> johannes
>
^ permalink raw reply
* Re: [PATCH] mac80211 : fix a race with update_tkip_key
From: Johannes Berg @ 2009-08-22 7:45 UTC (permalink / raw)
To: gregor kowski; +Cc: linux-wireless
In-Reply-To: <83a869cd0908211513k2e14ba40k251aa8a1e7393a77@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
On Sat, 2009-08-22 at 00:13 +0200, gregor kowski wrote:
> The mac80211 tkip code won't call update_tkip_key, if some rx packets
s/,// s/rx //
> get received without KEY_FLAG_UPLOADED_TO_HARDWARE. This can happen on
s/get/are/
> first packet because the hardware key stuff is called asynchronously with
> todo workqueue.
>
> This patch workaround that by tracking if we send the key to hardware.
s/send/sent/, s/hardware/the driver/
> +enum ieee80211_internal_tkip_initialized {
> + TKIP_INITIALIZED_NONE,
> + TKIP_INITIALIZED_PHASE1,
> + TKIP_INITIALIZED_UPDATE_KEY,
> +};
Those constants and the enum itself really need better names. This way,
there's no way to understand what it means without reading all the code.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Johannes Berg @ 2009-08-22 7:48 UTC (permalink / raw)
To: Rafael Laufer; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <4A8EE182.6040709@cs.ucla.edu>
[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]
On Fri, 2009-08-21 at 11:03 -0700, Rafael Laufer wrote:
> + * @IEEE80211_TX_CTL_RATE_RADIOTAP: completely internal to mac80211,
> + * used to indicate that the rate was defined in the received radiotap
> + * header and therefore the rate control algorithm should not change it.
This should be an internal flag, the driver doesn't care.
> + /* In monitor mode, if the IEEE80211_RADIOTAP_RATE option is set in
> + * the received radiotap header, do not call the rate control algorithm.
> + */
coding style
> + /* Get the rate parameter from the radiotap header,
> + * allowing rate selection on a per-packet basis
> + */
coding style
> + case IEEE80211_RADIOTAP_RATE:
> + bitrate = (*iterator.this_arg) * 5;
> + for (i = 0; i < sband->n_bitrates; i++) {
> + if (sband->bitrates[i].bitrate == bitrate)
> + break;
> + }
> + if (i != sband->n_bitrates) {
> + info->control.rates[0].idx = i;
> + info->flags |= IEEE80211_TX_CTL_RATE_RADIOTAP;
> + }
You never set the counter, or any other fields.
> /*
> * Please update the file
> * Documentation/networking/mac80211-injection.txt
And you even quote the instructions.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Johannes Berg @ 2009-08-22 7:50 UTC (permalink / raw)
To: Rafael Laufer; +Cc: Gábor Stefanik, linux-wireless
In-Reply-To: <4A8F01B8.40708@cs.ucla.edu>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Fri, 2009-08-21 at 13:21 -0700, Rafael Laufer wrote:
> It is strange that a function called "get_rate" would also change other
> fields which are at first sight do not look related to rate. Why not
> call other functions for that? What is the reasoning behind this?
> Different rates have different retry counts or RTS/CTS usage?
I can't tell if you're kidding or not. This also doesn't get a single
rate, but the entire rate control setup.
> As far as I could tell from a quick look in the code,
> rate_control_get_rate only sets the fields of info->control.rates,
> except for this driver-specific function.
Right. And now look again what's in control.rates[].
> If this function really does other stuff, then a simple solution is to
> check if the IEEE80211_TX_CTL_RATE_RADIOTAP flag is set and, in that
> case, store the value of info->control.rates[0].idx before calling
> rate_control_get_rate, and restoring it afterwards. Make sense?
Ick, no.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFT] ar9170: use eeprom's frequency calibration values
From: Johannes Berg @ 2009-08-22 7:52 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, John Linville
In-Reply-To: <200908212252.41053.chunkeey@web.de>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On Fri, 2009-08-21 at 22:52 +0200, Christian Lamparter wrote:
> Johannes, in phy.c (now at line) line 429
>
> int ar9170_init_phy(struct ar9170 *ar, enum ieee80211_band band)
> {
> [...]
> /* XXX: use EEPROM data here! */
>
> err = ar9170_init_power_cal(ar);
> if (err)
> [...]
> }
>
> do you still know what EEPROM data is missing here?
Sorry, no, I don't remember, and can't seem to find it either in otus
right now.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] compal-laptop: Replace sysfs support with rfkill support
From: Alan Jenkins @ 2009-08-22 11:20 UTC (permalink / raw)
To: Mario Limonciello
Cc: cezary.jackiewicz, linux-wireless, linux-acpi, linux-kernel
In-Reply-To: <1250890778-28959-1-git-send-email-Mario_Limonciello@Dell.com>
On 8/21/09, Mario Limonciello <Mario_Limonciello@dell.com> wrote:
> This drops the support for manually groking the files in sysfs
> to turn on and off the WLAN and BT for Compal laptops in favor
> of platform rfkill support.
>
> It has been combined into a single patch to not introduce regressions
> in the process of simply adding rfkill support.
>
> Signed-off-by: Mario Limonciello <Mario_Limonciello@Dell.com>
> @@ -390,23 +314,19 @@ static int __init compal_init(void)
>
> ret = platform_device_add(compal_device);
> if (ret)
> - goto fail_platform_device1;
> + goto fail_platform_device;
>
> - ret = sysfs_create_group(&compal_device->dev.kobj,
> - &compal_attribute_group);
> + ret = setup_rfkill();
> if (ret)
> - goto fail_platform_device2;
> + goto fail_rfkill;
>
> printk(KERN_INFO "compal-laptop: driver "COMPAL_DRIVER_VERSION
> " successfully loaded.\n");
>
> return 0;
>
> -fail_platform_device2:
> -
> - platform_device_del(compal_device);
> -
> -fail_platform_device1:
> +fail_rfkill:
> +fail_platform_device:
>
> platform_device_put(compal_device);
>
I guess our mails crossed. As in the previous patch I think
platform_device_del() should still be called, in the fail_rfkill case.
Previously platform_device_del() was required after
platform_device_add(), if we bailed out because of a failure in
sysfs_create_group(). I don't think that requirement is removed by
replacing sysfs_create_group() with setup_rfkill().
Regards
Alan
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Bob Copeland @ 2009-08-22 12:47 UTC (permalink / raw)
To: Fabio Comolli; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <b6c5339f0908210719o2323d590w4a9f6a01d5ecb2d6@mail.gmail.com>
On Fri, Aug 21, 2009 at 10:19:33AM -0400, Bob Copeland wrote:
> Okay, I think I see what is going on here.
Well I can't quite convince myself of what exactly is requeing
sta work; we do cancel everything already as far as I can tell, but
something is rearming, I just can't tell which.
Fabio, can you please apply this patch against wireless-testing (not
compat-wireless) and report all the warnings produced when doing a
suspend/resume? This should tell us the code paths that are queuing
work too late.
>From 6eb7d5c3ae8f2f42b164491acd02631858515876 Mon Sep 17 00:00:00 2001
From: Bob Copeland <me@bobcopeland.com>
Date: Sat, 22 Aug 2009 08:40:53 -0400
Subject: [PATCH] mac80211: set suspended before final flush_workqueue
Just a temporary debugging aid.
---
net/mac80211/pm.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
index a5d2f1f..231c8be 100644
--- a/net/mac80211/pm.c
+++ b/net/mac80211/pm.c
@@ -117,13 +117,13 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
* shouldn't be doing (or cancel everything in the
* stop callback) that but better safe than sorry.
*/
- flush_workqueue(local->workqueue);
-
local->suspended = true;
/* need suspended to be visible before quiescing is false */
barrier();
local->quiescing = false;
+ flush_workqueue(local->workqueue);
+
return 0;
}
--
1.6.2.5
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply related
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Fabio Comolli @ 2009-08-22 13:02 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <20090822124709.GA6762@hash.localnet>
Hi Bob.
On Sat, Aug 22, 2009 at 2:47 PM, Bob Copeland<me@bobcopeland.com> wrote:
> On Fri, Aug 21, 2009 at 10:19:33AM -0400, Bob Copeland wrote:
>> Okay, I think I see what is going on here.
>
> Well I can't quite convince myself of what exactly is requeing
> sta work; we do cancel everything already as far as I can tell, but
> something is rearming, I just can't tell which.
>
> Fabio, can you please apply this patch against wireless-testing (not
> compat-wireless) and report all the warnings produced when doing a
> suspend/resume? This should tell us the code paths that are queuing
> work too late.
I'm not a git user. How can I user wireless-testing without git? Is
there a patch or seomething?
>
> From 6eb7d5c3ae8f2f42b164491acd02631858515876 Mon Sep 17 00:00:00 2001
> From: Bob Copeland <me@bobcopeland.com>
> Date: Sat, 22 Aug 2009 08:40:53 -0400
> Subject: [PATCH] mac80211: set suspended before final flush_workqueue
>
> Just a temporary debugging aid.
> ---
> net/mac80211/pm.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
> index a5d2f1f..231c8be 100644
> --- a/net/mac80211/pm.c
> +++ b/net/mac80211/pm.c
> @@ -117,13 +117,13 @@ int __ieee80211_suspend(struct ieee80211_hw *hw)
> * shouldn't be doing (or cancel everything in the
> * stop callback) that but better safe than sorry.
> */
> - flush_workqueue(local->workqueue);
> -
> local->suspended = true;
> /* need suspended to be visible before quiescing is false */
> barrier();
> local->quiescing = false;
>
> + flush_workqueue(local->workqueue);
> +
> return 0;
> }
>
> --
> 1.6.2.5
>
>
> --
> Bob Copeland %% www.bobcopeland.com
>
>
Regards,
Fabio
^ permalink raw reply
* Re: ath5k: ath5k_pci_probe(): weirdo code
From: Bob Copeland @ 2009-08-22 13:35 UTC (permalink / raw)
To: Andreas Mohr; +Cc: ath5k-devel, linux-wireless, Johannes Stezenbach
In-Reply-To: <20090821094732.GA970@rhlx01.hs-esslingen.de>
On Fri, Aug 21, 2009 at 11:47:32AM +0200, Andreas Mohr wrote:
> Hello all,
>
> that 2GHz/5GHz radio information code in ath5k_pci_probe() in 2.6.31-rc6
> source seems VERY weird.
The code looks horribly confusing, it should be moved into attach.c
and reworked a lot probably. It looks correct though - it is fixing up
settings for (really old) multiple radio chip devices, where we can't
tell by the radio revision alone if it is multiband or not.
ah_radio_{2,5}ghz_revision is what is in the appropriate registers in
the card, but e.g. the revision in the 5ghz radio register may actually
refer to the 2ghz radio on some 802.11B-only devices, depending on what
is in the eeprom.
> Then also at this place, why is there no
> else
> {
> WARN_ONCE(...); // Huh. Unknown/unhandled/impossible revision combo
Should be caught already in attach.c, but yeah, another warning wouldn't
hurt.
> if (!sc->ah->ah_single_chip) {
> /* Single chip radio (!RF5111) */
>
> part seemed weird logic, too, but I then thought that this code section
> is perhaps _intended_ to be skipped in this case, to simply not log anything
> for single-chip radios
The comment belongs to the subsequent if() test, where it should probably
live to be clearer. All recent devices (including yours) are now single
chip so this code wouldn't run on your device.
> BTW, I'm currently on 2.6.31-rc6 on Aspire One, with even more ath5k problems
> than before, connection is dying every couple minutes, extended to every
> couple dozen minutes if I force rate 1M
Can you supply /debug/ieee80211/phy0/stations/<...>/rc_stats?
> (but it looks like "[Bug #13948] ath5k broken after suspend-to-ram"
> http://lkml.org/lkml/2009/8/19/468 is hopefully covering these issues already).
Can you verify that the patch mentioned in the bug report works?
We need to queue that for 2.6.31.
> And I do have CONFIG..._PS (powersave) enabled by default...
> And I do make liberal use of suspend-to-ram, as should everyone.
As do I. I don't have a 2425 though, and there are quite some variations
between each HW revision.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Bob Copeland @ 2009-08-22 13:40 UTC (permalink / raw)
To: Fabio Comolli; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <b637ec0b0908220602v3b9c2a35ob1e44d70f131890c@mail.gmail.com>
On Sat, Aug 22, 2009 at 03:02:26PM +0200, Fabio Comolli wrote:
> Hi Bob.
>
> I'm not a git user. How can I user wireless-testing without git? Is
> there a patch or seomething?
No, I'm unaware of a way to get it without git. Well, okay, try
compat-wireless, but be sure to use the 'bleeding edge' compat-wireless,
and post the contents of its 'git-describe' file with the warnings so
I can be sure we're on the same page.
http://wireless.kernel.org/en/users/Download
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* 2.6.31 patch for regression #13948
From: Bob Copeland @ 2009-08-22 13:47 UTC (permalink / raw)
To: linville; +Cc: mickflemm, linux-wireless
Hi John,
Can you queue this patch for 2.6.31? It's on the regression list
but isn't upstream. I cherry-picked it here and it applied and
built cleanly.
http://bugzilla.kernel.org/show_bug.cgi?id=13948
commit 399b1ffc45081a0f087fe3824b263fd27909cb7a
Author: Nick Kossifidis <mick@madwifi-project.org>
Date: Mon Aug 10 03:29:02 2009 +0300
ath5k: Wakeup fixes
* Don't put chip to full sleep because there are problems during
wakeup. Instead hold MAC/Baseband on warm reset state via a new
function ath5k_hw_on_hold.
* Minor cleanups
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Tested-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Larry Finger @ 2009-08-22 14:27 UTC (permalink / raw)
To: feng tian; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <f42a38140908212242h1ce0339fw1243dbacf54000ab@mail.gmail.com>
feng tian wrote:
> Instead of waiting for the codes, we decide to do someting on
> supporting the BCM 4325 running in linux via SDIO.
> The linux wireless dirver supports another chip (marvel 8686) with
> SDIO interface, the sources codes locate in
> drivers/net/wireless/libertas.
> We are wondering to develop the BCM4325 driver in the reference to the
> marvel 8686 SDIO driver.
> Please give comments on this, thanks.
The SDIO routines might be transferable; however, the radio and PHY
code will be completely different.
^ permalink raw reply
* Re: ath5k: ath5k_pci_probe(): weirdo code
From: Andreas Mohr @ 2009-08-22 15:10 UTC (permalink / raw)
To: Bob Copeland
Cc: Andreas Mohr, ath5k-devel, linux-wireless, Johannes Stezenbach
In-Reply-To: <20090822133557.GB6762@hash.localnet>
Hi,
On Sat, Aug 22, 2009 at 09:35:57AM -0400, Bob Copeland wrote:
> On Fri, Aug 21, 2009 at 11:47:32AM +0200, Andreas Mohr wrote:
> > Hello all,
> >
> > that 2GHz/5GHz radio information code in ath5k_pci_probe() in 2.6.31-rc6
> > source seems VERY weird.
> ah_radio_{2,5}ghz_revision is what is in the appropriate registers in
> the card, but e.g. the revision in the 5ghz radio register may actually
> refer to the 2ghz radio on some 802.11B-only devices, depending on what
> is in the eeprom.
Ah, that explains why the logic was rather counter-intuitive.
Still, in OSS it is very common to have _other_ people modify code,
and with that kind of clarity things can thus go haywire easily
(unless a core maintainer happens to catch it after submission).
> Can you verify that the patch mentioned in the bug report works?
YES, I can verify that replacing those 2 §"§$%>: Hermei capacitors
with good Rubycon ones in one of my three WRT54G(S) worked. :-P
(global series failure, "Defective By Design _without_ even needing
to make use of DRM"). aka "Planned failure one year post warranty" ;)
It seems MUCH more reliable now, after some short testing...
> Can you supply /debug/ieee80211/phy0/stations/<...>/rc_stats?
[NOTE: not sure whether these ath5k module stats are (partially) still pre-repair]
root@andinet:/sys/kernel/debug/ieee80211/phy19/stations/00:0f:66:4c:c4:44# cat rc_stats
^^^^^ *wink* ;-)
rate throughput ewma prob this prob this succ/attempt success attempts
1 0.9 97.6 100.0 0( 0) 20 20
2 0.4 25.0 100.0 0( 0) 1 1
5.5 0.0 0.0 0.0 0( 0) 0 0
11 9.1 95.5 100.0 0( 0) 78 82
6 0.0 0.0 0.0 0( 0) 0 0
9 0.0 0.0 0.0 0( 0) 0 0
12 2.7 25.0 100.0 0( 0) 1 1
18 4.0 25.0 100.0 0( 0) 1 1
24 5.3 25.0 100.0 0( 0) 1 1
36 7.6 25.0 100.0 0( 0) 1 1
t 48 7.0 77.6 50.0 0( 0) 1543 1685
T P 54 20.0 99.9 100.0 1( 1) 357588 398612
Total packet count:: ideal 8186 lookaround 909
> We need to queue that for 2.6.31.
Cannot test the patch right now since I cannot do a kernel build at this place.
> As do I. I don't have a 2425 though, and there are quite some variations
> between each HW revision.
Which is quite the norm with todays hardware :-P
(I even once bought an ACX100 hardware with the wrong revision
- read: COMPLETELY different hardware - where I then found that the seller
had _both_ revision variants in the _SAME_ shelf box at the same time
and they were friggin' out themselves when I enlightened them about this fact...)
Not to mention the even much more HORRIBLE CRIME of assigning the SAME PCI ID even,
to DIFFERENT hardware, that some vendors dare to commit.
Andreas Mohr
^ permalink raw reply
* Re: [RFC/RFT] rtl8187: Implement rfkill support
From: Larry Finger @ 2009-08-22 17:12 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski; +Cc: linux-wireless, Hin-Tak Leung
In-Reply-To: <200908220038.35564.herton@mandriva.com.br>
Herton Ronaldo Krzesinski wrote:
> This change implements rfkill support for RTL8187B and RTL8187L devices,
> using new cfg80211 rfkill API.
>
> Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
> ---
I don't have an RFKILL switch on my rtl8187 devices and cannot test
that part; however, everything looks OK and the devices still work.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Larry
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Johannes Berg @ 2009-08-22 18:13 UTC (permalink / raw)
To: Larry Finger; +Cc: feng tian, linux-wireless
In-Reply-To: <4A90005B.3030101@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 874 bytes --]
On Sat, 2009-08-22 at 09:27 -0500, Larry Finger wrote:
> feng tian wrote:
> > Instead of waiting for the codes, we decide to do someting on
> > supporting the BCM 4325 running in linux via SDIO.
> > The linux wireless dirver supports another chip (marvel 8686) with
> > SDIO interface, the sources codes locate in
> > drivers/net/wireless/libertas.
> > We are wondering to develop the BCM4325 driver in the reference to the
> > marvel 8686 SDIO driver.
> > Please give comments on this, thanks.
>
> The SDIO routines might be transferable; however, the radio and PHY
> code will be completely different.
Very few of them will be, afaict the SDIO bus access is vastly
different. Learning how to write an SDIO driver might be possible, but I
suspect transferring code won't make much sense.
Either way, isobel has some b43 sdio code already.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Broadcom BCM43XG Master mode?
From: Nathan Kennedy @ 2009-08-22 18:41 UTC (permalink / raw)
To: linux-wireless
I recently purchased a Linksys WMP300N that has teh BCM43XG chipset.
The only driver that I've gotten to work well with it is the wl driver
from Broadcom, however when I try to set the wireless mode to master I
get an error that the operation is not permitted. Is there a different
way to get this card into master mode?
Thanks in advance
^ permalink raw reply
* Re: Broadcom BCM43XG Master mode?
From: Johannes Berg @ 2009-08-22 18:56 UTC (permalink / raw)
To: Nathan Kennedy; +Cc: linux-wireless
In-Reply-To: <4A903BEB.4030606@flidais.net>
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
On Sat, 2009-08-22 at 11:41 -0700, Nathan Kennedy wrote:
> I recently purchased a Linksys WMP300N that has teh BCM43XG chipset.
> The only driver that I've gotten to work well with it is the wl driver
> from Broadcom, however when I try to set the wireless mode to master I
> get an error that the operation is not permitted. Is there a different
> way to get this card into master mode?
If you're using wl, then we don't know, and you have to ask Broadcom.
If you're using b43, you start hostapd.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Broadcom BCM43XG Master mode?
From: Nathan Kennedy @ 2009-08-22 18:59 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1250967366.23605.23.camel@johannes.local>
Johannes Berg wrote:
> On Sat, 2009-08-22 at 11:41 -0700, Nathan Kennedy wrote:
>
>> I recently purchased a Linksys WMP300N that has teh BCM43XG chipset.
>> The only driver that I've gotten to work well with it is the wl driver
>> from Broadcom, however when I try to set the wireless mode to master I
>> get an error that the operation is not permitted. Is there a different
>> way to get this card into master mode?
>>
>
> If you're using wl, then we don't know, and you have to ask Broadcom.
>
> If you're using b43, you start hostapd.
>
> johannes
>
Unfortunately the b43 driver will not load at all because there hasn't
been an update to support this chipset. Any devs want a guinea pig to
test driver ideas?
^ permalink raw reply
* Re: Broadcom BCM43XG Master mode?
From: Gábor Stefanik @ 2009-08-22 18:59 UTC (permalink / raw)
To: Nathan Kennedy, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1250967366.23605.23.camel@johannes.local>
On Sat, Aug 22, 2009 at 8:56 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Sat, 2009-08-22 at 11:41 -0700, Nathan Kennedy wrote:
>> I recently purchased a Linksys WMP300N that has teh BCM43XG chipset.
>> The only driver that I've gotten to work well with it is the wl driver
>> from Broadcom, however when I try to set the wireless mode to master I
>> get an error that the operation is not permitted. Is there a different
>> way to get this card into master mode?
>
> If you're using wl, then we don't know, and you have to ask Broadcom.
>
> If you're using b43, you start hostapd.
>
> johannes
>
WMP300N is an N-PHY, not supported by b43 (LP-PHY is being done right
now, N-PHY is probably the next). AFAIK wl (the hybrid driver) only
supports STA mode, there is no AP-ready x86 driver (Broadcom only
makes AP drivers for the MIPS platform).
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH] nl80211: jump to out_err upon unsupported iftype
From: Roel Kluin @ 2009-08-22 19:15 UTC (permalink / raw)
To: John W. Linville, linux-wireless, Andrew Morton
Jump to out_err when the iftype is not supported.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 634496b..c6fc083 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1998,7 +1998,7 @@ static int nl80211_dump_mpath(struct sk_buff *skb,
if (netdev->ieee80211_ptr->iftype != NL80211_IFTYPE_MESH_POINT) {
err = -EOPNOTSUPP;
- goto out;
+ goto out_err;
}
while (1) {
^ permalink raw reply related
* Re: WARNING: at net/mac80211/mlme.c:2292
From: Fabio Comolli @ 2009-08-22 19:29 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <20090822134044.GC6762@hash.localnet>
Hi Bob.
Unfortunately the patch doesn't apply at all with compat-wireless,
there's no "flush_workqueue" before "local->suspended" there....
Please advice.
Regards,
Fabio
On Sat, Aug 22, 2009 at 3:40 PM, Bob Copeland<me@bobcopeland.com> wrote:
> On Sat, Aug 22, 2009 at 03:02:26PM +0200, Fabio Comolli wrote:
>> Hi Bob.
>>
>> I'm not a git user. How can I user wireless-testing without git? Is
>> there a patch or seomething?
>
> No, I'm unaware of a way to get it without git. Well, okay, try
> compat-wireless, but be sure to use the 'bleeding edge' compat-wireless,
> and post the contents of its 'git-describe' file with the warnings so
> I can be sure we're on the same page.
>
> http://wireless.kernel.org/en/users/Download
>
> --
> Bob Copeland %% www.bobcopeland.com
>
>
^ permalink raw reply
* Re: [RFT] ar9170: use eeprom's frequency calibration values
From: Joerg Albert @ 2009-08-22 21:03 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, John Linville, Johannes Berg
In-Reply-To: <200908220151.19792.chunkeey@web.de>
On 08/22/2009 01:51 AM, Christian Lamparter wrote:
> On Saturday 22 August 2009 01:36:17 Joerg Albert wrote:
>> On 08/21/2009 10:52 PM, Christian Lamparter wrote:
>>> This patch adds some more bits from the vendor driver, which
>>> are supposed to help users with the one-stage/openfw firmwares.
>> The otus driver sets phy registers 672-703 only for the one-stage firmware -
>> hal/hpmain.c, line 3445:
>>
>> #ifndef ZM_OTUS_LINUX_PHASE_2
>> reg_write(regAddr + i, val); /* CR672 */
>> #endif
>>
>> Are you sure it doesn't hurt with the two-stage firmware?
> no idea, that's why I ask requested input, instead of posting a patch +
> sob right away.
>
> so far, I haven't heard of or experienced any regressions or anomalies.
> Do you already have comments or complains? :)
Your patch works fine here with a WNDA3100, using the two-stage firmware, against
a 802.11g AP. After "iwconfig wlan1 rate 54M" I get approx. 22 MBit/s throughput
with iperf, same as without the patch.
> Unfortunately, my device (WNDA3100) still doesn't work properly
> with either version at phy-rates beyond the magic 18MBit barrier.
Strange, same device here (or another hw version? FCC ID: PY307300073)
and I see packets @ 54M from the dev in the sniffer. But it also has the
invalid regdomain 0x8000 in the eeprom ...
With the one-stage firmware and without your patch my device doesn't associate with the AP,
seems like no packets are sent. So I can't test your patch with the one-stage fw.
Same result with a AVM Fritz stick.
I'll look into bisecting.
Regards,
Joerg.
^ permalink raw reply
* Re: [RFT] ar9170: use eeprom's frequency calibration values
From: Christian Lamparter @ 2009-08-22 21:43 UTC (permalink / raw)
To: Joerg Albert; +Cc: linux-wireless, John Linville, Johannes Berg
In-Reply-To: <4A905D2B.9090405@gmx.de>
On Saturday 22 August 2009 23:03:39 Joerg Albert wrote:
> On 08/22/2009 01:51 AM, Christian Lamparter wrote:
> > On Saturday 22 August 2009 01:36:17 Joerg Albert wrote:
> >> On 08/21/2009 10:52 PM, Christian Lamparter wrote:
> >>> This patch adds some more bits from the vendor driver, which
> >>> are supposed to help users with the one-stage/openfw firmwares.
> >> The otus driver sets phy registers 672-703 only for the one-stage firmware -
> >> hal/hpmain.c, line 3445:
> >>
> >> #ifndef ZM_OTUS_LINUX_PHASE_2
> >> reg_write(regAddr + i, val); /* CR672 */
> >> #endif
> >>
> >> Are you sure it doesn't hurt with the two-stage firmware?
> > no idea, that's why I ask requested input, instead of posting a patch +
> > sob right away.
> >
> > so far, I haven't heard of or experienced any regressions or anomalies.
> > Do you already have comments or complains? :)
>
> Your patch works fine here with a WNDA3100, using the two-stage firmware, against
> a 802.11g AP. After "iwconfig wlan1 rate 54M" I get approx. 22 MBit/s throughput
> with iperf, same as without the patch.
same here... and not really surprising.
According to my sources, the two-stage firmware is
capable of doing calibration without extra help from
the host.
> > Unfortunately, my device (WNDA3100) still doesn't work properly
> > with either version at phy-rates beyond the magic 18MBit barrier.
>
> Strange, same device here (or another hw version? FCC ID: PY307300073)
> and I see packets @ 54M from the dev in the sniffer. But it also has the
> invalid regdomain 0x8000 in the eeprom ...
that comment about "18mbit barrier" is only true for the one-stage fw.
I've no problem getting up and slightly above 80mbits with the original
two-stage fw.
Regards,
Chr
^ 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