[OpenWrt-Devel] [PATCH] add led defintion for the WR2543 5GHz WLAN LED
Signed-off-by: Andy Leiserson a...@leiserson.org
---
Looks like my timing was pretty bad with the Rygel patches, hopefully
this is more useful for the attitude adjustment release.
I don't see a simple way to make the LEDs actually indicate activity on
the corresponding bands.
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr2543n.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr2543n.c
@@ -24,6 +24,10 @@
#define TL_WR2543N_GPIO_LED_WPS0
#define TL_WR2543N_GPIO_LED_USB8
+// The WLAN LEDs use GPIOs on the discrete AR9380 wmac
+#define TL_WR2543N_GPIO_WMAC_LED_WLAN2G 0
+#define TL_WR2543N_GPIO_WMAC_LED_WLAN5G 1
+
#define TL_WR2543N_GPIO_BTN_RESET 11
#define TL_WR2543N_GPIO_BTN_WPS12
@@ -54,6 +58,14 @@
}
};
+static struct gpio_led tl_wr2543n_wmac_leds_gpio[] = {
+ {
+ .name = tp-link:green:wlan5g,
+ .gpio = TL_WR2543N_GPIO_WMAC_LED_WLAN5G,
+ .active_low = 1,
+ },
+};
+
static struct gpio_keys_button tl_wr2543n_gpio_keys[] __initdata = {
{
.desc = reset,
@@ -113,7 +125,14 @@
tl_wr2543n_gpio_keys);
ath79_register_usb();
- ap9x_pci_setup_wmac_led_pin(0, 0);
+ // The ath9k driver uses this pin for its default led device, which is
+ // named ath9k-phy0, and reflects activity on either the 2 GHz or 5 GHz
+ // bands. This pin is connected to the WR2543's 2GHz WLAN LED.
+ ap9x_pci_setup_wmac_led_pin(0, TL_WR2543N_GPIO_WMAC_LED_WLAN2G);
+ // We also have the driver set up an led device for the WR2543's
+ // separate 5 GHz WLAN LED in case the user wants it.
+ ap9x_pci_setup_wmac_leds(0, tl_wr2543n_wmac_leds_gpio,
+ARRAY_SIZE(tl_wr2543n_wmac_leds_gpio));
ap91_pci_init(eeprom, mac);
ath79_init_mac(ath79_eth0_data.mac_addr, mac, -1);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Time Division Multiple Access (TDMA)
On 13 July 2012 06:24, Jonathan Bither jonbit...@gmail.com wrote: Nico, I too have been interested in experimenting with TDMA. When I looked a while ago the most helpful information that I saw was that TDMA support is apparently included in freebsd. You may want to take a look at how it is implemented over there. http://fxr.watson.org/fxr/source/net80211/ieee80211_tdma.c I'm about to start working out the kinks. It broke some time after FreeBSD-7.x. Luckily I have all of the pre-11n atheros hardware here so I can setup a working environment and then figure out which commits/changes broke things. I'll post updates to FreeBSD-wireless once I figure it out. Thanks, Adrian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Keep /etc/nginx on sysupgrade
Jo-Philipp Wich wrote: Hi. You do not need to ship a keep file, it is enough to add /etc/nginx to the conffiles define. It looks like conffiles can only save files, not entire directories. /etc/nginx is a directory. Should conffiles be fixed to work with directories too? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Keep /etc/nginx on sysupgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It looks like conffiles can only save files, not entire directories. /etc/nginx is a directory. Should conffiles be fixed to work with directories too? It works fine with directories, see include/package-ipkg.mk, the code below ifneq ($$(KEEP_$(1)),) ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA1JzsACgkQdputYINPTPM+NwCfWqTOrkFsXlHBbVD+QHgHKw7P NPcAn0U3ISESdEKUdX7qHMCRCe1iNEjq =zkqZ -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
2012/8/22 Hauke Mehrtens ha...@hauke-m.de: On 07/18/2012 01:56 PM, Bastian Bittorf wrote: hi devs! yesterday we had a breaktrough debugging b43 in our hackspace maschinenraum/m18[1,2] at weimar.freifunk.net[3,4] - since a long time our darling wrt54g suffers from a hanging wifi and bad performance[5], but the workaround is easy: now it's up to you to fix the rootcause. our testsetup, where we could _reproduce_ reliably a stopping TX is like this: laptop ---lan--- A-wrt54g/adhoc ~~~ air ~~~ B-anyrouter/adhoc now make a testdownload with the laptop from B. wireless will stop working after ~10 seconds. wifi up will reanimate and our freifunk-cron.minutely-check will do this automagically. (read further, this is not the solution) we tried to limit the rateset to e.g. lower rates, but this does NOT change the behaviour. what works is: define a rateset on BOTH router which makes it impossible to change the band, e.g.: iw dev $WIFIDEV set bitrates legacy-2.4 1 2 5.5 11 OR iw dev $WIFIDEV set bitrates legacy-2.4 6 9 12 18 24 36 48 54 now we had a great performance, 10 Gigabytes of wireless transfer, no stopping TX anymore and an empty box of beer. three things to do now: 1) why does a band change (can be seen through minstrel) is a problem? 2) we have to make in config-option to force a band, or a rateset: e.g. uci set wireless.radio0.hwmode=11g e.g. uci set wireless.radio0.bitrates='6 9 12 18 24 36 48 54' 3) spread to word: there is a great frustration in the community about b43, but the old drivers _have_ to die, it's about time - really. thanks for your work, bye storchi, andi, bastian + m18 crew [1] http://blog.maschinenraum.tk/ [2] http://blog.maschinenraum.tk/2012/07/15/bitcoin-vending-machine-exchange-euro-coins-for-bitcoin-wallets/ [3] http://wireless.subsignal.org [4] http://wireless.subsignal.org/index.php?title=Main_Page_en [5] https://dev.openwrt.org/ticket/7552 I tried this on some of my devices (BCM4318 G-PHY and BCM4322 N-PHY) and it is easily reproducible on all tested devices when restricting the rates to 11 and 12 MBit/s. I have the Broadcom device working as an Access point (on a MIPS SoC) and a Laptop with an Intel Wifi device is connected to it. I generated the traffic with iperf. If the Access Points sends the traffic the problem occurs, if it is just receiving there is not problem. After the problem occurred b43_generate_txhdr is called rarely ( every ~10 seconds) and I am not able to stay connected or connect to the network any more. I am not familiar with the internal flow in b43 or mac80211 could someone give me a hint where to look. I can not see any special changes between CCK and OFDM rates before it goes down there are many changes without a problem before it goes down. Currently I do not have a Broadcom wifi card running in a x86 device just mips devices could someone try to reproduce the problem on a x86 device. I added the b43 mailing list and Rafał. Does your kernel include commit bad6919469662b7c92bc6353642777b36bac Author: francesco.gring...@ing.unibs.it francesco.gring...@ing.unibs.it Date: Fri Dec 16 18:34:56 2011 +0100 b43: avoid packet losses in the dma worker code. ? I have a lot of things on my TODO list, including that. Right now I just want to focus on BCM4706 support, which slowly moves into mainline. -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
On 08/22/2012 07:49 PM, Rafał Miłecki wrote: 2012/8/22 Hauke Mehrtens ha...@hauke-m.de: On 07/18/2012 01:56 PM, Bastian Bittorf wrote: hi devs! yesterday we had a breaktrough debugging b43 in our hackspace maschinenraum/m18[1,2] at weimar.freifunk.net[3,4] - since a long time our darling wrt54g suffers from a hanging wifi and bad performance[5], but the workaround is easy: now it's up to you to fix the rootcause. our testsetup, where we could _reproduce_ reliably a stopping TX is like this: laptop ---lan--- A-wrt54g/adhoc ~~~ air ~~~ B-anyrouter/adhoc now make a testdownload with the laptop from B. wireless will stop working after ~10 seconds. wifi up will reanimate and our freifunk-cron.minutely-check will do this automagically. (read further, this is not the solution) we tried to limit the rateset to e.g. lower rates, but this does NOT change the behaviour. what works is: define a rateset on BOTH router which makes it impossible to change the band, e.g.: iw dev $WIFIDEV set bitrates legacy-2.4 1 2 5.5 11 OR iw dev $WIFIDEV set bitrates legacy-2.4 6 9 12 18 24 36 48 54 now we had a great performance, 10 Gigabytes of wireless transfer, no stopping TX anymore and an empty box of beer. three things to do now: 1) why does a band change (can be seen through minstrel) is a problem? 2) we have to make in config-option to force a band, or a rateset: e.g. uci set wireless.radio0.hwmode=11g e.g. uci set wireless.radio0.bitrates='6 9 12 18 24 36 48 54' 3) spread to word: there is a great frustration in the community about b43, but the old drivers _have_ to die, it's about time - really. thanks for your work, bye storchi, andi, bastian + m18 crew [1] http://blog.maschinenraum.tk/ [2] http://blog.maschinenraum.tk/2012/07/15/bitcoin-vending-machine-exchange-euro-coins-for-bitcoin-wallets/ [3] http://wireless.subsignal.org [4] http://wireless.subsignal.org/index.php?title=Main_Page_en [5] https://dev.openwrt.org/ticket/7552 I tried this on some of my devices (BCM4318 G-PHY and BCM4322 N-PHY) and it is easily reproducible on all tested devices when restricting the rates to 11 and 12 MBit/s. I have the Broadcom device working as an Access point (on a MIPS SoC) and a Laptop with an Intel Wifi device is connected to it. I generated the traffic with iperf. If the Access Points sends the traffic the problem occurs, if it is just receiving there is not problem. After the problem occurred b43_generate_txhdr is called rarely ( every ~10 seconds) and I am not able to stay connected or connect to the network any more. I am not familiar with the internal flow in b43 or mac80211 could someone give me a hint where to look. I can not see any special changes between CCK and OFDM rates before it goes down there are many changes without a problem before it goes down. Currently I do not have a Broadcom wifi card running in a x86 device just mips devices could someone try to reproduce the problem on a x86 device. I added the b43 mailing list and Rafał. Does your kernel include commit bad6919469662b7c92bc6353642777b36bac Author: francesco.gring...@ing.unibs.it francesco.gring...@ing.unibs.it Date: Fri Dec 16 18:34:56 2011 +0100 b43: avoid packet losses in the dma worker code. ? I have a lot of things on my TODO list, including that. Right now I just want to focus on BCM4706 support, which slowly moves into mainline. This patch is included. I used compat-wireless-2012-07-16 plus some more backport patches for b43. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WRT54g / b43 / mac802.11 BREAKTHROUGH
On 08/22/2012 08:45 PM, Larry Finger wrote: On 08/22/2012 11:21 AM, Hauke Mehrtens wrote: On 07/18/2012 01:56 PM, Bastian Bittorf wrote: hi devs! yesterday we had a breaktrough debugging b43 in our hackspace maschinenraum/m18[1,2] at weimar.freifunk.net[3,4] - since a long time our darling wrt54g suffers from a hanging wifi and bad performance[5], but the workaround is easy: now it's up to you to fix the rootcause. our testsetup, where we could _reproduce_ reliably a stopping TX is like this: laptop ---lan--- A-wrt54g/adhoc ~~~ air ~~~ B-anyrouter/adhoc now make a testdownload with the laptop from B. wireless will stop working after ~10 seconds. wifi up will reanimate and our freifunk-cron.minutely-check will do this automagically. (read further, this is not the solution) we tried to limit the rateset to e.g. lower rates, but this does NOT change the behaviour. what works is: define a rateset on BOTH router which makes it impossible to change the band, e.g.: iw dev $WIFIDEV set bitrates legacy-2.4 1 2 5.5 11 OR iw dev $WIFIDEV set bitrates legacy-2.4 6 9 12 18 24 36 48 54 now we had a great performance, 10 Gigabytes of wireless transfer, no stopping TX anymore and an empty box of beer. three things to do now: 1) why does a band change (can be seen through minstrel) is a problem? 2) we have to make in config-option to force a band, or a rateset: e.g. uci set wireless.radio0.hwmode=11g e.g. uci set wireless.radio0.bitrates='6 9 12 18 24 36 48 54' 3) spread to word: there is a great frustration in the community about b43, but the old drivers _have_ to die, it's about time - really. thanks for your work, bye storchi, andi, bastian + m18 crew [1] http://blog.maschinenraum.tk/ [2] http://blog.maschinenraum.tk/2012/07/15/bitcoin-vending-machine-exchange-euro-coins-for-bitcoin-wallets/ [3] http://wireless.subsignal.org [4] http://wireless.subsignal.org/index.php?title=Main_Page_en [5] https://dev.openwrt.org/ticket/7552 I tried this on some of my devices (BCM4318 G-PHY and BCM4322 N-PHY) and it is easily reproducible on all tested devices when restricting the rates to 11 and 12 MBit/s. I have the Broadcom device working as an Access point (on a MIPS SoC) and a Laptop with an Intel Wifi device is connected to it. I generated the traffic with iperf. If the Access Points sends the traffic the problem occurs, if it is just receiving there is not problem. After the problem occurred b43_generate_txhdr is called rarely ( every ~10 seconds) and I am not able to stay connected or connect to the network any more. I am not familiar with the internal flow in b43 or mac80211 could someone give me a hint where to look. I can not see any special changes between CCK and OFDM rates before it goes down there are many changes without a problem before it goes down. Currently I do not have a Broadcom wifi card running in a x86 device just mips devices could someone try to reproduce the problem on a x86 device. I added the b43 mailing list and Rafał. Hauke or Bastian, Do you have any info whether the failure occurs with the change from OFDM to CCK, or vice versa? I am wondering if the radio needs a dummy transmission when the switch happens. I will try to put together a patch to test that hypothesis. Larry It is strange. The stop does not occur directly after changing from OFDM to CCK or vice versa. TX seams to still work, but the device does not receive anything any more. Here are some logs from my device: http://hauke-m.de/files/b43/wifi-stop/2012-08-22/b43-ap-block.txt Patch used: http://hauke-m.de/files/b43/wifi-stop/2012-08-22/b43-ap-block.patch iw dev wlan0 set bitrates legacy-2.4 11 12 was issued at ~120.00. How do I monitor this particular channel with an other wifi card to get most of the packages, with aircrack I am unable to set the channel? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] avahi: remove inappropriate dependency on dbus in Changeset 32330
This patch fixes an issue reported by Damiano Albani. Changeset 32330, while fixing one bug, unfortunately introduces another one -- it makes avahi-daemon always dependent on the dbus package, causing dbus to be loaded even when it's not needed. This patch makes avahi-daemon dependent on dbus only is avahi dbus support has been selected. Signed-off-by Mike Brady mikebr...@eircom.net Index: libs/avahi/Makefile === --- libs/avahi/Makefile (revision 33223) +++ libs/avahi/Makefile (working copy) @@ -16,7 +16,7 @@ PKG_NAME:=avahi PKG_VERSION:=0.6.31 -PKG_RELEASE:=2 +PKG_RELEASE:=3 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz @@ -94,7 +94,11 @@ define Package/avahi-daemon $(call Package/avahi/Default) SUBMENU:=IP Addresses and Names + ifeq ($(BUILD_VARIANT),dbus) DEPENDS:=+libavahi +libexpat +librt +libdbus + else + DEPENDS:=+libavahi +libexpat +librt + endif TITLE+= (daemon) endef ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
