[OpenWrt-Devel] [PATCH 1/2] Add W1 DS2423 build config option
Add option to select DS2423 kernel module via openwrt's build config. Signed-off-by: Mika Laitio lam...@pilppa.org --- package/kernel/modules/w1.mk | 14 ++ 1 file changed, 14 insertions(+) diff --git a/package/kernel/modules/w1.mk b/package/kernel/modules/w1.mk index e0e9e57..d8b1ceb 100644 --- a/package/kernel/modules/w1.mk +++ b/package/kernel/modules/w1.mk @@ -112,6 +112,20 @@ endef $(eval $(call KernelPackage,w1-slave-smem)) +define KernelPackage/w1-slave-ds2423 + TITLE:=1-Wire Counter chip support (DS2423) + KCONFIG:= CONFIG_W1_SLAVE_DS2423 + FILES:=$(W1_SLAVES_DIR)/w1_ds2423.ko + AUTOLOAD:=$(call AutoLoad,70,w1_ds2423) + $(call AddDepends/w1) +endef + +define KernelPackage/w1-slave-ds2423/description + Kernel module for 1-wire counter(ds2423) +endef + +$(eval $(call KernelPackage,w1-slave-ds2423)) + define KernelPackage/w1-slave-ds2431 TITLE:=DS2431 1kb EEPROM driver KCONFIG:= CONFIG_W1_SLAVE_DS2431 -- 1.7.10 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] brcm63xx: add support for NB6 boards based on BCM6362 CPU.
On Sun, 2012-07-22 at 12:59 +0200, Jonas Gorski wrote: Hello Miguel, Hello On 6 July 2012 14:19, Miguel GAIO miguel.g...@efixo.com wrote: This is a second release for NB6 boards support. The first patch add support for 6362 CPU. It's based on 6328 works. It also includes RGMII clock enable. The second patch include support for NB6 boards. The NB6 has a RTL8367R switch connected to internal enetsw using rgmii bus. The third patch change rgmii setup on RTL8366R. I confirm that the realtek switch works with these patches. I did some changes though. 1) I substituted your BCM6362 patches with my own (yours seem to be based on an older broadcom SDK), since these are the ones I plan to submit eventually to upstream. Greats 2) I made the realtek patch a platform patch, because I do not know the impact on other devices using this switch (which didn't need it). 3) I added a network config for it 4) I commented out the nb6 image build, since even with network working you can't do much with it Hopefully, once your patches are submitted, I can help to get more working (namely wireless) I am more or less ready to commit this, but I am missing your signed-off-by. Can you please either reply with it or resend the board patch with it added? I created a branch on github with what I plan to submit, so you can use that to check that I did not miss anything ( https://github.com/KanjiMonster/openwrt/tree/neufbox6 ). I have some additional questions though: How is one supposed to flash the NB6 without serial access? At least I did not find anything in the web interface that allowed me to flash an image, and the CFE does not provide a web interface either. Without serial access, users have to use bootp method via SFR button. What's the tftpboot? I noticed that if I have the SFR button pressed when powering the device up, CFE prints ** tftpboot requested, but then shortly after that CFE crashes. To use SFR button you have to: - setup DHCP server to provide board IP address - The DHCP answer needs tftp serveur and bootp image - Depending on nature of provided image, the cfe can boot vmlinux or burns new tagged image You can found a wiki at neufbox4.org (in french) which contains HOWTOs http://www.neufbox4.org/wiki/index.php?title=Flasher_une_NB6 Lastly, you added an image build for NB6-SER-r0, shouldn't you also add one for NB6-FXC-r0? Or do they not care about the board id? Board id is not care. Miguel Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel From 9bf7925c23e4bc5982b0af74f980cf1ceb8be841 Mon Sep 17 00:00:00 2001 From: Miguel GAIO miguel.g...@efixo.com Date: Fri, 6 Jul 2012 14:10:52 +0200 Subject: [PATCH 05/22] * [brcm63xx] Add nb6 support (BCM6362 SoC base boards) Signed-off-by: Miguel GAIO miguel.g...@efixo.com --- target/linux/brcm63xx/config-3.3 |2 + target/linux/brcm63xx/image/Makefile |2 + .../linux/brcm63xx/patches-3.3/301-led_count.patch | 15 +- .../linux/brcm63xx/patches-3.3/554-board_nb6.patch | 146 .../801-ssb_export_fallback_sprom.patch|4 +- 5 files changed, 163 insertions(+), 6 deletions(-) create mode 100644 target/linux/brcm63xx/patches-3.3/554-board_nb6.patch diff --git a/target/linux/brcm63xx/config-3.3 b/target/linux/brcm63xx/config-3.3 index fed43ff..f8cf486 100644 --- a/target/linux/brcm63xx/config-3.3 +++ b/target/linux/brcm63xx/config-3.3 @@ -120,6 +120,8 @@ CONFIG_PCIEPORTBUS=y CONFIG_PCI_DOMAINS=y CONFIG_PERF_USE_VMALLOC=y CONFIG_PHYLIB=y +CONFIG_RTL8366_SMI=y +CONFIG_RTL8367_PHY=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y # CONFIG_PREEMPT_RCU is not set diff --git a/target/linux/brcm63xx/image/Makefile b/target/linux/brcm63xx/image/Makefile index 8066430..06c5d64 100644 --- a/target/linux/brcm63xx/image/Makefile +++ b/target/linux/brcm63xx/image/Makefile @@ -191,6 +191,8 @@ define Image/Build $(call Image/Build/CFEFIXUP,$(1),96348GW,GW6200,6348,GW6200,$(shell printf '\x99')) # Neufbox4 $(call Image/Build/CFE,$(1),96358VW,6358,NEUFBOX4,OpenWRT-$(REVISION)) + # Neufbox6 + $(call Image/Build/CFE,$(1),NB6-SER-r0,6362,NEUFBOX6,OpenWRT-$(REVISION)) # Comtrend 536, 5621 $(call Image/Build/CFEFIXUP,$(1),96348GW-11,CT536_CT5621,6348,CT536_CT5621) # Davolink DV201AMR diff --git a/target/linux/brcm63xx/patches-3.3/301-led_count.patch b/target/linux/brcm63xx/patches-3.3/301-led_count.patch index 84d57a0..b6c1196 100644 --- a/target/linux/brcm63xx/patches-3.3/301-led_count.patch +++ b/target/linux/brcm63xx/patches-3.3/301-led_count.patch @@ -8,19 +8,26 @@ if (board.has_uart0) bcm63xx_uart_register(0); -@@ -900,7 +901,11 @@ int __init board_register_devices(void) +@@ -900,10 +901,16 @@ int __init board_register_devices(void) bcm63xx_flash_register(); -
Re: [OpenWrt-Devel] [PATCH 1/2] Add W1 DS2423 build config option
On 31/07/12 08:38, Mika Laitio wrote: Add option to select DS2423 kernel module via openwrt's build config. Signed-off-by: Mika Laitio lam...@pilppa.org --- package/kernel/modules/w1.mk | 14 ++ 1 file changed, 14 insertions(+) is there a 2/2 for this patch ? or is the subject simply an error ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] uci vlan configuration
I'm just looking through hotplug/10-net and network/config.sh and I see that the following uci settings produce a vlan interface. network.v100=interface network.v100.proto=dhcp network.v100.ifname=eth0.100 network.v100.device=eth0.100 Is this a side-effect or a valid config? There seems to be no mention of it in any docs on the wiki? Thanks, Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] Add W1 DS2423 build config option
On 07/31/2012 10:49 AM, John Crispin wrote: On 31/07/12 08:38, Mika Laitio wrote: Add option to select DS2423 kernel module via openwrt's build config. Signed-off-by: Mika Laitio lam...@pilppa.org --- package/kernel/modules/w1.mk | 14 ++ 1 file changed, 14 insertions(+) is there a 2/2 for this patch ? or is the subject simply an error ? Sorry, subject was simply error, so no need for 2/2 patch and you can safely apply just this patch. (2423 kernel module has been in the kernel since 2.6.37...) Mika ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] brcm63xx: add support for NB6 boards based on BCM6362 CPU.
Hi Miguel, thanks, and committed. On 31 July 2012 09:31, Miguel GAIO miguel.g...@efixo.com wrote: 2) I made the realtek patch a platform patch, because I do not know the impact on other devices using this switch (which didn't need it). 3) I added a network config for it 4) I commented out the nb6 image build, since even with network working you can't do much with it Hopefully, once your patches are submitted, I can help to get more working (namely wireless) Getting wireless to work is one of the last things I expected, so I'm quite curious about how you will do it :-) I am more or less ready to commit this, but I am missing your signed-off-by. Can you please either reply with it or resend the board patch with it added? I created a branch on github with what I plan to submit, so you can use that to check that I did not miss anything ( https://github.com/KanjiMonster/openwrt/tree/neufbox6 ). I have some additional questions though: How is one supposed to flash the NB6 without serial access? At least I did not find anything in the web interface that allowed me to flash an image, and the CFE does not provide a web interface either. Without serial access, users have to use bootp method via SFR button. What's the tftpboot? I noticed that if I have the SFR button pressed when powering the device up, CFE prints ** tftpboot requested, but then shortly after that CFE crashes. To use SFR button you have to: - setup DHCP server to provide board IP address - The DHCP answer needs tftp serveur and bootp image - Depending on nature of provided image, the cfe can boot vmlinux or burns new tagged image You can found a wiki at neufbox4.org (in french) which contains HOWTOs http://www.neufbox4.org/wiki/index.php?title=Flasher_une_NB6 That's neat, thanks for the explanation. Maybe somebody should add this to the OpenWrt wiki *cough* *lazy*. Lastly, you added an image build for NB6-SER-r0, shouldn't you also add one for NB6-FXC-r0? Or do they not care about the board id? Board id is not care. Great. I decided to enable building the images, since it allows people to play with it, but unless we manage to get bcm63xx migrated to swconfig before the AA, I don't know if it makes sense to have it built for the release. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] mac80211 MAC address generation
Hello!
With changeset 28298 for
trunk/package/mac80211/files/lib/wifi/mac80211.sh (09/25/11 by jow) you
introduced a change to the MAC address generation for virtual interfaces
which I think is not optimal:
[package] mac80211: rework mac address generation for virtual
interfaces; set locally administered bit on generated macs and
change the last two bytes isntead of the first one
Now, If you have two wirless LAN cards which have sequentially numbered
MAC addresses (e.g. AA:BB:CC:DD:EE:01 and AA:BB:CC:DD:EE:02, either on
the same board or two devices close to each other) and you want to use
virtual interfaces on both this easily leads to clashes: 2 VAP using the
same MAC address.
I believe the old method was more robust and thus propose the following
change (patch below).
Best greetings,
Bruno
---
commit 297256680b3870b498a737498ef2d2fdd424f783
Author: Bruno Randolf b...@thinktube.com
Date: Thu Jul 26 20:21:22 2012 +0100
mac80211: generate MAC adresses in the upper byte
This way it's easier to avoid duplicate MAC adresses.
diff --git a/package/mac80211/files/lib/wifi/mac80211.sh
b/package/mac80211/files/lib/wifi/mac
index 1a4d7c1..cc7c9bb 100644
--- a/package/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/mac80211/files/lib/wifi/mac80211.sh
@@ -273,17 +273,17 @@ get_freq() {
}
mac80211_generate_mac() {
- local off=$1
- local mac=$2
- local oIFS=$IFS; IFS=:; set -- $mac; IFS=$oIFS
+ local macidx=$1
+ local mac_1=${2%%:*}
+ local mac_2=${2#*:}
- local b2mask=0x00
- [ $off -gt 0 ] b2mask=0x02
+ if [ $macidx -gt 0 ]; then
+ offset=$(( 2 + $macidx * 4 ))
+ else
+ offset=0
+ fi
- printf %02x:%s:%s:%s:%02x:%02x \
- $(( 0x$1 | $b2mask )) $2 $3 $4 \
- $(( (0x$5 + ($off / 0x100)) % 0x100 )) \
- $(( (0x$6 + $off) % 0x100 ))
+printf %02x:$mac_2 $((0x$mac_1 + $offset))
}
enable_mac80211() {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1]: eglibc: add librt dependencies to various packages
On 7/30/12 7:36 AM, Florian Fainelli wrote: Hello, On Saturday 23 June 2012 17:22:35 Philip Prindeville wrote: Building eglibc on x86 requires various packages explicitly call out librt. Add these dependencies. Signed-off-by: Philip Prindeville phil...@redfish-solutions.com The proper way to do this is rather: +USE_EGLIBC:librt instead of a plain +librt. -- Florian I originally had that, but then I looked at other places where librt was used and none of them explicitly called out a libc dependency. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3] libtransmission eglibc build fix
If eglibc (2.1.5) is selected in openwrt instead of uclibc, transmission package will fail to build because the function definition exported by the libtransmission/fdlimit.c is lightly different than the function definition in fcntl.h that is installed by eglibc. To get transmission build to work both with uclibc and eglibc, fdlimit.c needs to export function only if the build toolchain uses uclibc. This fixes also a openwrt bug https://dev.openwrt.org/ticket/8820 openwrt_trunk.git/staging_dir/ toolchain-mipsel_gcc-4.6-linaro_eglibc-2.15/lib/ gcc/mipsel-openwrt-linux-gnu/4.6.3/../../../../ mipsel-openwrt-linux-gnu/sys-include/bits/fcntl.h:316:12: error: conflicting types for 'fallocate64' fdlimit.c:30:14: note: previous declaration of 'fallocate64' was here Signed-off-by: Mika Laitio mika.lai...@nokia.com --- .../patches/010_libtransmission_fallocate64_eglibc.patch | 13 + 1 file changed, 13 insertions(+) create mode 100644 net/transmission/patches/010_libtransmission_fallocate64_eglibc.patch diff --git a/net/transmission/patches/010_libtransmission_fallocate64_eglibc.patch b/net/transmission/patches/010_libtransmission_fallocate64_eglibc.patch new file mode 100644 index 000..15ae518 --- /dev/null +++ b/net/transmission/patches/010_libtransmission_fallocate64_eglibc.patch @@ -0,0 +1,13 @@ +diff -Naur transmission-2.61/libtransmission/fdlimit.c transmission-2.61-new/libtransmission/fdlimit.c +--- transmission-2.61/libtransmission/fdlimit.c2012-07-24 04:59:03.429474697 +0300 transmission-2.61-new/libtransmission/fdlimit.c2012-07-31 14:40:23.999860054 +0300 +@@ -25,7 +25,8 @@ + #include fcntl.h + #endif + +-#ifdef HAVE_FALLOCATE64 ++/* no need to define fallocate64 in glibc/eglibc case */ ++#if defined(__UCLIBC__) (HAVE_FALLOCATE64) + /* FIXME can't find the right #include voodoo to pick up the declaration.. */ + extern int fallocate64( int fd, int mode, uint64_t offset, uint64_t len ); + #endif -- 1.7.10 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3] libevent2 eglibc toolchain build fix
When openwrt toolchain uses eglibc (2.15) instead of uclibc, libevent2 build fails to following error: Package libevent2 is missing dependencies for the following libraries: librt.so.1 Fix is to define DEPENDS:=+USE_EGLIBC:librt which adds the librt dependency only if the eglibc is used by toolchain. Patch has been tested by building the libevent2 both with the the eglibc and uclibc openwrt toolchains. Signed-off-by: Mika Laitio mika.lai...@nokia.com --- libs/libevent2/Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/libs/libevent2/Makefile b/libs/libevent2/Makefile index 6271f23..ce39e1a 100644 --- a/libs/libevent2/Makefile +++ b/libs/libevent2/Makefile @@ -45,6 +45,7 @@ endef define Package/libevent2 $(call Package/libevent2/Default) TITLE+= library (version 2.0) + DEPENDS:=+USE_EGLIBC:librt endef define Package/libevent2/description -- 1.7.10 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/3] build fixes with eglibc toolchain
This set of patches include fixes for 3 build errors I noticed when building some of the luci modules with openwrt trunk where I had selected eglibc instead of uclibc. Mika Laitio (3): libtransmission eglibc build fix samba36 eglibc toolchain build fix libevent2 eglibc toolchain build fix libs/libevent2/Makefile |1 + net/samba36/Makefile |1 + .../patches/010_libtransmission_fallocate64_eglibc.patch | 13 + 3 files changed, 15 insertions(+) create mode 100644 net/transmission/patches/010_libtransmission_fallocate64_eglibc.patch -- 1.7.10 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] samba36 eglibc toolchain build fix
When openwrt toolchain uses eglibc (2.15) instead of uclibc, samba36-server build causes following error: Package samba36-server is missing dependencies for the following libraries: librt.so.1 Fix is to define DEPENDS:=+USE_EGLIBC:librt which adds the librt dependency only if the eglibc is used by toolchain. Patch tested by building the samba36 both with the the eglibc and uclibc openwrt toolchains. Signed-off-by: Mika Laitio mika.lai...@nokia.com --- net/samba36/Makefile |1 + 1 file changed, 1 insertion(+) diff --git a/net/samba36/Makefile b/net/samba36/Makefile index 2ebfcbe..2a6b6b6 100644 --- a/net/samba36/Makefile +++ b/net/samba36/Makefile @@ -28,6 +28,7 @@ define Package/samba36-server CATEGORY:=Network TITLE:=Samba 3.6 SMB/CIFS server URL:=http://www.samba.org/ + DEPENDS:=+USE_EGLIBC:librt endef define Package/samba36-client -- 1.7.10 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Codel: avoid a nul rec_inv_sqrt
One condition before codel_Newton_step() was not good if
we never left the dropping state for a flow. As a result
rec_inv_sqrt was 0, instead of the ~0 initial value.
codel control law was then set to a very aggressive mode, dropping
many packets before reaching 'target' and recovering from this problem.
Brought over from 3.5-stable
---
...one-condition-to-avoid-a-nul-rec_inv_sqrt.patch | 68
1 file changed, 68 insertions(+)
create mode 100644
target/linux/generic/patches-3.3/049-codel-refine-one-condition-to-avoid-a-nul-rec_inv_sqrt.patch
diff --git
a/target/linux/generic/patches-3.3/049-codel-refine-one-condition-to-avoid-a-nul-rec_inv_sqrt.patch
b/target/linux/generic/patches-3.3/049-codel-refine-one-condition-to-avoid-a-nul-rec_inv_sqrt.patch
new file mode 100644
index 000..210a58c
--- /dev/null
+++
b/target/linux/generic/patches-3.3/049-codel-refine-one-condition-to-avoid-a-nul-rec_inv_sqrt.patch
@@ -0,0 +1,68 @@
+From patchwork Mon Jul 30 06:52:21 2012
+Content-Type: text/plain; charset=utf-8
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Subject: codel: refine one condition to avoid a nul rec_inv_sqrt
+Date: Sun, 29 Jul 2012 20:52:21 -
+From: Eric Dumazet eric.duma...@gmail.com
+X-Patchwork-Id: 173968
+Message-Id: 1343631141.2626.13293.camel@edumazet-glaptop
+To: David Miller da...@davemloft.net
+Cc: netdev net...@vger.kernel.org, Anton Mich lp2...@gmail.com
+
+From: Eric Dumazet eduma...@google.com
+
+One condition before codel_Newton_step() was not good if
+we never left the dropping state for a flow. As a result
+rec_inv_sqrt was 0, instead of the ~0 initial value.
+
+codel control law was then set to a very aggressive mode, dropping
+many packets before reaching 'target' and recovering from this problem.
+
+To keep codel_vars_init() as efficient as possible, refine
+the condition to make sure rec_inv_sqrt initial value is correct
+
+Many thanks to Anton Mich for discovering the issue and suggesting
+a fix.
+
+Reported-by: Anton Mich lp2...@gmail.com
+Signed-off-by: Eric Dumazet eduma...@google.com
+
+---
+include/net/codel.h |8 ++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+
+
+--
+To unsubscribe from this list: send the line unsubscribe netdev in
+the body of a message to majord...@vger.kernel.org
+More majordomo info at http://vger.kernel.org/majordomo-info.html
+
+diff --git a/include/net/codel.h b/include/net/codel.h
+index 550debf..389cf62 100644
+--- a/include/net/codel.h
b/include/net/codel.h
+@@ -305,6 +305,8 @@ static struct sk_buff *codel_dequeue(struct Qdisc *sch,
+ }
+ }
+ } else if (drop) {
++ u32 delta;
++
+ if (params-ecn INET_ECN_set_ce(skb)) {
+ stats-ecn_mark++;
+ } else {
+@@ -320,9 +322,11 @@ static struct sk_buff *codel_dequeue(struct Qdisc *sch,
+* assume that the drop rate that controlled the queue on the
+* last cycle is a good starting point to control it now.
+*/
+- if (codel_time_before(now - vars-drop_next,
++ delta = vars-count - vars-lastcount;
++ if (delta 1
++ codel_time_before(now - vars-drop_next,
+ 16 * params-interval)) {
+- vars-count = (vars-count - vars-lastcount) | 1;
++ vars-count = delta;
+ /* we dont care if rec_inv_sqrt approximation
+* is not very precise :
+* Next Newton steps will correct it quadratically.
--
1.7.9.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WZR-HP-AG300H led support
On 07/30/2012 09:51 PM, LEO Airwarosu Yoichi Shinoda wrote: Peter and folks, I believe Peter meant WZR-HP-AG300H. Last night, I did some research on behaviors of leds on WZR-HP-AG300H, and located controls for all remaining leds on wmacs. Awesome, seems to work fine. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WZR-HP-AG300H led support
On 2012/08/01, at 6:28, Peter Naulls wrote: On 07/30/2012 09:51 PM, LEO Airwarosu Yoichi Shinoda wrote: Peter and folks, I believe Peter meant WZR-HP-AG300H. Last night, I did some research on behaviors of leds on WZR-HP-AG300H, and located controls for all remaining leds on wmacs. Awesome, seems to work fine. Thanks. What about the initialization (priming?) problem I mentioned? I.e., I added a code for the wmac_leds, and they work, EXCEPT that wmacs must be enabled ONCE (by means of wifi command execution) before they actually start to work. After the first enable, leds can be controlled independent from phy states. --- shinoda ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
