Re: [OpenWrt-Devel] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
> This could be a problem caused by mips16. We use that in BB to create smaller binaries. but Jonas saw a performance problem in some applications, mostly stuff doing crypto (big integer calculations). Have developers evaluated the pros and cons of using mips16 as the default? It was made the default along the switch to gcc4.8, but I do not remember seeing any extensive discussion about that change. Yes, it produces smaller binaries, but apparently with a visible performance hit. The performance problems can materialize in strange ways, e.g. ssh login time to dropbear doubled (increased by several seconds), https://dev.openwrt.org/ticket/15209 . So, it is not just about gradual performance hit, but it can apparently cause visible annoyances. Now that the performance issues have been noticed, is there any plan for developers to systematically go through the core apps to check the impact and turn mips16 off for problematic apps? I guess that based by evedence so far, it might be turned off for all math-intensive apps like crypto libraries, but there may be also others (maybe voice & image encoding/decoding?) To have small binaries is nice, but I guess that a growing amount of Openwrt users are power users with modern routers with more flash space and having interest for VPNs etc. And for them mips16 may have brought more trouble than benefits. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
On 2014-08-31 11:53, Hannu Nyman wrote: > > This could be a problem caused by mips16. We use that in BB to create > smaller binaries. but Jonas saw a performance problem in some > applications, mostly stuff doing crypto (big integer calculations). > > Have developers evaluated the pros and cons of using mips16 as the default? Yes > It was made the default along the switch to gcc4.8, but I do not remember > seeing any extensive discussion about that change. Yes, it produces smaller > binaries, but apparently with a visible performance hit. Most binaries are not performance sensitive > The performance problems can materialize in strange ways, e.g. ssh login time > to dropbear doubled (increased by several seconds), > https://dev.openwrt.org/ticket/15209 . So, it is not just about gradual > performance hit, but it can apparently cause visible annoyances. Right. We should simply identify binaries where mips16 is causing problems and disable it for those. > Now that the performance issues have been noticed, is there any plan for > developers to systematically go through the core apps to check the impact and > turn mips16 off for problematic apps? I guess that based by evedence so far, > it might be turned off for all math-intensive apps like crypto libraries, but > there may be also others (maybe voice & image encoding/decoding?) > > To have small binaries is nice, but I guess that a growing amount of Openwrt > users are power users with modern routers with more flash space and having > interest for VPNs etc. And for them mips16 may have brought more trouble than > benefits. I think only a small portion of our packages seem to have problems with mips16, and turning it off selectively is very easy - so I don't consider this a big deal. I think it makes sense to simply wait for bug reports to show up and deal with those on a case by case basis. If we delay using mips16 until core devs have gone through every single package, it will never get done... - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
On Sun, 2014-08-31 at 12:14 +0200, Felix Fietkau wrote: > > To have small binaries is nice, but I guess that a growing amount of > > Openwrt > > users are power users with modern routers with more flash space and having > > interest for VPNs etc. And for them mips16 may have brought more trouble > > than > > benefits. > I think only a small portion of our packages seem to have problems with > mips16, and turning it off selectively is very easy - so I don't > consider this a big deal. I think it makes sense to simply wait for bug > reports to show up and deal with those on a case by case basis. I don't know if bug reports would help on that case. I had noticed that 2048-bit key generation with nettle+minigmp would take an enormous amount of time, but I just blamed the router's cpu. You'll only get bug reports from people who can compare with different toolchains and that's not a common case (not my case at least). > If we delay using mips16 until core devs have gone through every single > package, it will never get done... Well, space is much less of an issue in new embedded systems, but nevertheless the fix of having each package add a MIPS16 flag doesn't scale very well. The maintainer would have to do quite some testing (supposing that he has the specific hardware) and make benchmarks on with different toolchains to see whether that flag should be set or not. This of course will not happen and in the end, every package that depends on performance will just enable that flag. Wouldn't it make sense to introduce a performance critical flag instead that can also cover more cpus than mips, and would ease the maintainers job, as it would be more clear on which packages to enable the flag? regards, Nikos ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment
On 2014-08-31 12:56, Nikos Mavrogiannopoulos wrote: > On Sun, 2014-08-31 at 12:14 +0200, Felix Fietkau wrote: > >> > To have small binaries is nice, but I guess that a growing amount of >> > Openwrt >> > users are power users with modern routers with more flash space and having >> > interest for VPNs etc. And for them mips16 may have brought more trouble >> > than >> > benefits. >> I think only a small portion of our packages seem to have problems with >> mips16, and turning it off selectively is very easy - so I don't >> consider this a big deal. I think it makes sense to simply wait for bug >> reports to show up and deal with those on a case by case basis. > > I don't know if bug reports would help on that case. I had noticed that > 2048-bit key generation with nettle+minigmp would take an enormous > amount of time, but I just blamed the router's cpu. You'll only get bug > reports from people who can compare with different toolchains and that's > not a common case (not my case at least). Still, it's usually only going to affect some corner cases. >> If we delay using mips16 until core devs have gone through every single >> package, it will never get done... > > Well, space is much less of an issue in new embedded systems, but > nevertheless the fix of having each package add a MIPS16 flag doesn't > scale very well. The maintainer would have to do quite some testing > (supposing that he has the specific hardware) and make benchmarks on > with different toolchains to see whether that flag should be set or not. > This of course will not happen and in the end, every package that > depends on performance will just enable that flag. Wouldn't it make > sense to introduce a performance critical flag instead that can also > cover more cpus than mips, and would ease the maintainers job, as it > would be more clear on which packages to enable the flag? I don't think "performance criticial" is a good fit for a flag. In some cases, performance critical code could actually work better with mips16 if cache footprint is the driving factor. So far the only code I've seen where performance was significantly affected was crypto related code... - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] nettle mips16 patch [was: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment]
On 2014-08-30 22:13, Nikos Mavrogiannopoulos wrote: > From a75b56c15bd28e41daec6867fe652a3c61a65edc Mon Sep 17 00:00:00 2001 > From: Nikos Mavrogiannopoulos > Date: Sat, 30 Aug 2014 22:09:27 +0200 > Subject: [PATCH] nettle: set PKG_USE_MIPS16 to zer > > Signed-off-by: Nikos Mavrogiannopoulos Committed in r42341, r42342 - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RESEND] libubus: fix msgbuf reduction logic during receive
On 2014-08-07 07:32, Alexandru Ardelean wrote: > Signed-off-by: Alexandru Ardelean Applied (with modifications) Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mac80211:add wireless modules building for mt7620a and mt7620n
Just resend. Signed-off-by: Serge Vasilugin Index: package/kernel/mac80211/Makefile === --- package/kernel/mac80211/Makefile(revision 42167) +++ package/kernel/mac80211/Makefile(working copy) @@ -328,7 +328,7 @@ define KernelPackage/rt2800-soc $(call KernelPackage/rt2x00/Default) - DEPENDS += @(TARGET_ramips_rt288x||TARGET_ramips_rt305x||TARGET_ramips_rt3883) +kmod-rt2800-mmio +kmod-rt2800-lib + DEPENDS += @(TARGET_ramips_rt288x||TARGET_ramips_rt305x||TARGET_ramips_rt3883||TARGET_ramips_mt7620a||TARGET_ramips_mt7620n) +kmod-rt2800-mmio +kmod-rt2800-lib TITLE += (RT28xx/RT3xxx SoC) FILES := \ $(PKG_BUILD_DIR)/drivers/net/wireless/rt2x00/rt2x00soc.ko \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][RFC]mac80211: rt2x00 correctly set ht20/ht40 filter
Simple patch to correct ht20/ht40 switching. Tested with rt3290/rt3352/rt5350 Signed-off-by: Serge Vasilugin diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h index a394a9a..e145e0f 100644 --- a/drivers/net/wireless/rt2x00/rt2800.h +++ b/drivers/net/wireless/rt2x00/rt2800.h @@ -2284,6 +2284,8 @@ struct mac_iveiv_entry { #define RFCSR30_RX_H20M FIELD8(0x04) #define RFCSR30_RX_VCM FIELD8(0x18) #define RFCSR30_RF_CALIBRATION FIELD8(0x80) +#define RF3322_RFCSR30_TX_H20M FIELD8(0x01) +#define RF3322_RFCSR30_RX_H20M FIELD8(0x02) /* * RFCSR 31: diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c index 893c9d5..4e4daa0 100644 --- a/drivers/net/wireless/rt2x00/rt2800lib.c +++ b/drivers/net/wireless/rt2x00/rt2800lib.c @@ -3208,8 +3208,13 @@ static void rt2800_config_channel(struct rt2x00_dev *rt2x00dev, rt2x00_rf(rt2x00dev, RF5390) || rt2x00_rf(rt2x00dev, RF5392)) { rt2800_rfcsr_read(rt2x00dev, 30, &rfcsr); - rt2x00_set_field8(&rfcsr, RFCSR30_TX_H20M, 0); - rt2x00_set_field8(&rfcsr, RFCSR30_RX_H20M, 0); + if(rt2x00_rf(rt2x00dev, RF3322)) { + rt2x00_set_field8(&rfcsr, RF3320_RFCSR30_TX_H20M, conf_is_ht40(conf)); + rt2x00_set_field8(&rfcsr, RF3322_RFCSR30_RX_H20M, conf_is_ht40(conf)); + else { + rt2x00_set_field8(&rfcsr, RFCSR30_TX_H20M, conf_is_ht40(conf)); + rt2x00_set_field8(&rfcsr, RFCSR30_RX_H20M, conf_is_ht40(conf)); + } rt2800_rfcsr_write(rt2x00dev, 30, rfcsr); rt2800_rfcsr_read(rt2x00dev, 3, &rfcsr); ---serge ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] Fix VLAN on Atheros AR8327N
Sat, Jul 19, 2014 at 09:49:38PM CEST, nolt...@gmail.com wrote: >Commit 40842 reverted the fix for tagged+untagged VLANs on AR8327: >https://dev.openwrt.org/changeset/40777 >https://dev.openwrt.org/changeset/40842 > >According to jow, some people experienced some "issues" on older devices. Can >anyone tell me what were those issues? > >Anyway, that patch modified some parts of the ar8216/ar8236, so I suppose any >device with those switches were affected. >However, I've modified the patch keeping the ar8216/ar8236 as much untouched >as possible. >Could anyone test it on those devices? > >BTW, this works for me on a TP-Link WDR4300 (ar8327). I tested the patch on TL-WR1043ND v2 with Atheros AR8327 rev. 4. Vlans are working as expected. Please include this into BB (might need repost) Thanks! Tested-by: Jiri Pirko > >Signed-off-by: Saverio Proto >Signed-off-by: Álvaro Fernández >--- >diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c >b/target/linux/generic/files/drivers/net/phy/ar8216.c >index 3846159..9eae624 100644 >--- a/target/linux/generic/files/drivers/net/phy/ar8216.c >+++ b/target/linux/generic/files/drivers/net/phy/ar8216.c >@@ -78,7 +78,7 @@ struct ar8xxx_chip { > u32 (*read_port_status)(struct ar8xxx_priv *priv, int port); > int (*atu_flush)(struct ar8xxx_priv *priv); > void (*vtu_flush)(struct ar8xxx_priv *priv); >- void (*vtu_load_vlan)(struct ar8xxx_priv *priv, u32 vid, u32 port_mask); >+ void (*vtu_load_vlan)(struct ar8xxx_priv *priv, u32 vlan); > > const struct ar8xxx_mib_desc *mib_decs; > unsigned num_mibs; >@@ -112,7 +112,12 @@ struct ar8327_led { > enum ar8327_led_pattern pattern; > }; > >+struct ar8216_data { >+ u8 vlan_tagged; >+}; >+ > struct ar8327_data { >+ u8 vlan_tagged[AR8X16_MAX_VLANS]; > u32 port0_status; > u32 port6_status; > >@@ -138,6 +143,7 @@ struct ar8xxx_priv { > u8 chip_rev; > const struct ar8xxx_chip *chip; > union { >+ struct ar8216_data ar8216; > struct ar8327_data ar8327; > } chip_data; > bool initialized; >@@ -159,7 +165,6 @@ struct ar8xxx_priv { > bool vlan; > u16 vlan_id[AR8X16_MAX_VLANS]; > u8 vlan_table[AR8X16_MAX_VLANS]; >- u8 vlan_tagged; > u16 pvid[AR8X16_MAX_PORTS]; > > /* mirroring */ >@@ -641,7 +646,7 @@ ar8216_mangle_rx(struct net_device *dev, struct sk_buff >*skb) > port = buf[0] & 0xf; > > /* no need to fix up packets coming from a tagged source */ >- if (priv->vlan_tagged & (1 << port)) >+ if (priv->chip_data.ar8216.vlan_tagged & BIT(port)) > return; > > /* lookup port vid from local table, the switch passes an invalid vlan > id */ >@@ -695,10 +700,13 @@ ar8216_vtu_flush(struct ar8xxx_priv *priv) > } > > static void >-ar8216_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vid, u32 port_mask) >+ar8216_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vlan) > { > u32 op; > >+ u32 vid = priv->vlan_id[vlan]; >+ u32 port_mask = priv->vlan_table[vlan]; >+ > op = AR8216_VTU_OP_LOAD | (vid << AR8216_VTU_VID_S); > ar8216_vtu_op(priv, op, port_mask); > } >@@ -1705,12 +1713,16 @@ ar8327_vtu_flush(struct ar8xxx_priv *priv) > } > > static void >-ar8327_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vid, u32 port_mask) >+ar8327_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vlan) > { > u32 op; > u32 val; > int i; > >+ u32 vid = priv->vlan_id[vlan]; >+ u32 port_mask = priv->vlan_table[vlan]; >+ u32 tagged = priv->chip_data.ar8327.vlan_tagged[vlan]; >+ > op = AR8327_VTU_FUNC1_OP_LOAD | (vid << AR8327_VTU_FUNC1_VID_S); > val = AR8327_VTU_FUNC0_VALID | AR8327_VTU_FUNC0_IVL; > for (i = 0; i < AR8327_NUM_PORTS; i++) { >@@ -1720,7 +1732,7 @@ ar8327_vtu_load_vlan(struct ar8xxx_priv *priv, u32 vid, >u32 port_mask) > mode = AR8327_VTU_FUNC0_EG_MODE_NOT; > else if (priv->vlan == 0) > mode = AR8327_VTU_FUNC0_EG_MODE_KEEP; >- else if (priv->vlan_tagged & BIT(i)) >+ else if (tagged & BIT(i)) > mode = AR8327_VTU_FUNC0_EG_MODE_TAG; > else > mode = AR8327_VTU_FUNC0_EG_MODE_UNTAG; >@@ -1734,26 +1746,22 @@ static void > ar8327_setup_port(struct ar8xxx_priv *priv, int port, u32 egress, u32 ingress, > u32 members, u32 pvid) > { >- u32 t; >- u32 mode; >+ u32 mode, t; >+ >+ if (priv->vlan) { >+ pvid = priv->vlan_id[priv->pvid[port]]; >+ mode = AR8327_PORT_VLAN1_OUT_MODE_UNMOD; >+ ingress = AR8216_IN_SECURE; >+ } else { >+ pvid = port; >+ mode = AR8327_PORT_VLAN1_OUT_MODE_UNTOUCH; >+ ingress = AR8216_IN_PORT_ONLY; >+ } > > t = pvid << AR8327_PORT_VLAN0_DEF_SVID_S; > t |= pvid << AR8327_PORT_VLAN0_DEF_CVID_S; > pri
[OpenWrt-Devel] VXLAN support
Hi all. I did not find any movement in support of VXLAN. Are there any plans to support it? Or is anyone working on that? I can try to add VXLAN support to netifd. Any comments, ideas, hints appreciated. Thanks. Jiri ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] VXLAN support
Hi, This would be a really useful and nice feature to add. May be use for example for connecting an office to DC based infra-structure that makes use of VXLAN. Open vSwitch (which runs on OpenWRT), as far as I know supports VXLAN but it doesn't seem to achieve very good performance on most OpenWRT devices. Regards, Fernando On 31/08/2014 19:51, Jiri Pirko wrote: Hi all. I did not find any movement in support of VXLAN. Are there any plans to support it? Or is anyone working on that? I can try to add VXLAN support to netifd. Any comments, ideas, hints appreciated. Thanks. Jiri ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] VXLAN support
Sun, Aug 31, 2014 at 09:40:50PM CEST, fhfredi...@gmail.com wrote: >Hi, >This would be a really useful and nice feature to add. May be use for example >for connecting an office to DC based infra-structure that makes use of VXLAN. >Open vSwitch (which runs on OpenWRT), as far as I know supports VXLAN but it >doesn't seem to achieve very good performance on most OpenWRT devices. openvswitch supports vxlan directly in its kernel datapath. I would like to add support for sole vxlan interfaces, without ovs being involved. > >Regards, >Fernando > >On 31/08/2014 19:51, Jiri Pirko wrote: >>Hi all. >> >>I did not find any movement in support of VXLAN. Are there any plans to >>support it? Or is anyone working on that? >> >>I can try to add VXLAN support to netifd. Any comments, ideas, hints >>appreciated. >> >>Thanks. >> >>Jiri >>___ >>openwrt-devel mailing list >>openwrt-devel@lists.openwrt.org >>https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >___ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] compatible = "ralink,mt7620a-spi", "ralink,rt2880-spi";
Hello All, the mt7620a.dtsi makes reference to mt7620a-spi but this node does not exist in spi.c. The following patch address this. here is the entry in the dts file... spi@b00 { compatible = "ralink,mt7620a-spi", "ralink,rt2880-spi"; reg = <0xb00 0x100>; resets = <&rstctrl 18>; reset-names = "spi"; #address-cells = <1>; #size-cells = <1>; status = "disabled"; pinctrl-names = "default"; pinctrl-0 = <&spi_pins>; }; the following mus be added to the DTS file to use it. spi@b00 { status = "okay"; num-cs = <2>; m25p80@0 { snip here is the patch. --luis -- Luis Soltero, Ph.D., MCS Director of Software Development, CTO Global Marine Networks, LLC StarPilot, LLC Tel: +1.865.379.8723 Fax: +1.865.681.5017 E-Mail: lsolt...@globalmarinenet.net Web: http://www.globalmarinenet.net Web: http://www.redportglobal.com Web: http://www.starpilotllc.com >From 9d18142f0d91e50f0e2249ee4b42ad9da19f186a Mon Sep 17 00:00:00 2001 From: Luis Soltero Date: Sun, 31 Aug 2014 13:50:32 -0700 Subject: [PATCH] the mt7620a.dtsi makes reference to mt7620a-spi but this node does not exist in spi.c. The following patch address this. here is the entry in the dts file... spi@b00 { compatible = "ralink,mt7620a-spi", "ralink,rt2880-spi"; reg = <0xb00 0x100>; resets = <&rstctrl 18>; reset-names = "spi"; #address-cells = <1>; #size-cells = <1>; status = "disabled"; pinctrl-names = "default"; pinctrl-0 = <&spi_pins>; }; the following mus be added to the DTS file to use it. spi@b00 { status = "okay"; num-cs = <2>; m25p80@0 { snip --- .../0403-SPI-ralink-add-mt7620a-support.patch |9 + 1 file changed, 9 insertions(+) create mode 100644 target/
[OpenWrt-Devel] uClibc bug: epoll_pwait broken on OpenWrt x86
Hi, I'm posting this on both the OpenWrt and the uClibc lists to hopefully find someone who has an idea how the code in question might ever have worked (if it ever has...). The issue probably affects not only epoll_pwait, but also other syscall6 on i386. It can be seen on all OpenWrt versions ranging from Attitude Adjustment to Barrier Breaker (and probably also the current trunk). I noticed that epoll_pwait always returns EINVAL when I supply a signal set; analzing it with gdb I found out that %ebp contains a stack address instead of the length of the signal set (which should be 8). Looking at the generated code reveals this: b360 <__libc_epoll_pwait>: b360: 55 push %ebp b361: 57 push %edi b362: 56 push %esi b363: 53 push %ebx b364: 51 push %ecx b365: e8 eb ef ff ff call a355 <__x86.get_pc_thunk.bx> b36a: 81 c3 8a 4c 04 00 add$0x44c8a,%ebx b370: 8b 74 24 24 mov0x24(%esp),%esi b374: 8b 7c 24 28 mov0x28(%esp),%edi b378: c7 04 24 08 00 00 00movl $0x8,(%esp) #1 b37f: 65 a1 0c 00 00 00 mov%gs:0xc,%eax b385: 85 c0 test %eax,%eax b387: 75 33 jneb3bc <__libc_epoll_pwait+0x5c> b389: 8b 44 24 18 mov0x18(%esp),%eax b38d: 8b 4c 24 1c mov0x1c(%esp),%ecx b391: 8b 54 24 20 mov0x20(%esp),%edx b395: 53 push %ebx #2 b396: 89 c3 mov%eax,%ebx b398: 55 push %ebp #3 b399: 8b 2c 24mov(%esp),%ebp #4 b39c: b8 3f 01 00 00 mov$0x13f,%eax b3a1: cd 80 int$0x80 ... As can be seen, the value 8 is moved onto the stack at #1 and is supposed to be moved to %ebp at #4. Unfortunately, #2 and #3 move the stack pointer... signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Build logs of Barrier Breaker RCs
Hi, I've noticed that the package "fastd" (which I maintain) is missing from some targets in all Barrier Breaker RCs, for example on x86. It does exist though on ar71xx, and everything is fine in the current trunk snapshots. I can't find any issues when building BB myself either. Are the build logs available somewhere so I can find out what is wrong? signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][RFC]mac80211: rt2x00 correctly set ht20/ht40 filter
Hi Serge! Please do not send HTML emails. Your submissions are not useful for anyone if the mail body is HTML formatted and your mail application corrupted the white-space formatting. That's sad because your work will not be appreciated due to formalities which are easy to fulfil. Please read https://dev.openwrt.org/wiki/SubmittingPatches and have a look at the archive to get an impression why this is needed: https://lists.openwrt.org/pipermail/openwrt-devel/2014-August/027718.html also note that your patch was dropped by patchwork.openwrt.org for the same reasons and thus cannot be easily applied and merged. I suggest you should consider using git send-email to avoid these difficulties in future. It required quite some manual work to even read your patch. First of all, your patch applies to rt2x00, so please send it to the rt2x00 users mailing list. http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com To add it to patches applied to mac80211 in OpenWrt, you'd have to create a patch adding a patch-file to package/kernel/mac80211/patches/ Please read http://wiki.openwrt.org/doc/devel/patches Anyway, I'm still glad you figured out why rt2x00 performs bad in HT40 mode on these chips. Thank you for that! I manually applied your patch and am about to test it on DIR-615-H1 ;) Cheers Daniel On Sun, Aug 31, 2014 at 08:18:27PM +0700, Сергей Василюгин wrote: > style="font-family:-moz-fixed;font-size:12px;">Simple patch to correct > ht20/ht40 switching. Tested with rt3290/rt3352/rt5350 />Signed-off-by: Serge Vasilugin href="mailto:vasilu...@yanedx.ru";>/>diff --git a/drivers/net/wireless/rt2x00/rt2800.h > b/drivers/net/wireless/rt2x00/rt2800.h index a394a9a..e145e0f 100644 > --- a/drivers/net/wireless/rt2x00/rt2800.h +++ > b/drivers/net/wireless/rt2x00/rt2800.h @@ -2284,6 +2284,8 @@ struct > mac_iveiv_entry { #define RFCSR30_RX_H20M FIELD8(0x04) /> #define RFCSR30_RX_VCM FIELD8(0x18) #define > RFCSR30_RF_CALIBRATION FIELD8(0x80) +#define > RF3322_RFCSR30_TX_H20M FIELD8(0x01) +#define > RF3322_RFCSR30_RX_H20M FIELD8(0x02) /* * RFCSR > 31: diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c > b/drivers/net/wireless/rt2x00/rt2800lib.c index 893c9d5..4e4daa0 100644 > --- a/drivers/net/wireless/rt2x00/rt2800lib.c +++ > b/drivers/net/wireless/rt2x00/rt2800lib.c @@ -3208,8 +3208,13 @@ static > void rt2800_config_channel(struct rt2x00_dev *rt2x00dev, > rt2x00_rf(rt2x00dev, RF5390) || rt2x00_rf(rt2x00dev, RF5392)) > { rt2800_rfcsr_read(rt2x00dev, 30, &rfcsr); - > rt2x00_set_field8(&rfcsr, RFCSR30_TX_H20M, 0); - > rt2x00_set_field8(&rfcsr, RFCSR30_RX_H20M, 0); + > if(rt2x00_rf(rt2x00dev, RF3322)) { + > rt2x00_set_field8(&rfcsr, RF3320_RFCSR30_TX_H20M, conf_is_ht40(conf)); > + rt2x00_set_field8(&rfcsr, RF3322_RFCSR30_RX_H20M, > conf_is_ht40(conf)); + else { + > rt2x00_set_field8(&rfcsr, RFCSR30_TX_H20M, conf_is_ht40(conf)); + > rt2x00_set_field8(&rfcsr, RFCSR30_RX_H20M, conf_is_ht40(conf)); > + } rt2800_rfcsr_write(rt2x00dev, 30, rfcsr); /> rt2800_rfcsr_read(rt2x00dev, 3, &rfcsr); > ---serge > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] VXLAN support
Hi, There's a vxlan kernel module in Linux source tree, and `ip` command can create vxlan netdev. Are you talking about netifd support for it? (2014/09/01 3:51), Jiri Pirko wrote: > Hi all. > > I did not find any movement in support of VXLAN. Are there any plans to > support it? Or is anyone working on that? > > I can try to add VXLAN support to netifd. Any comments, ideas, hints > appreciated. > > Thanks. > > Jiri > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] compatible = "ralink,mt7620a-spi", "ralink,rt2880-spi";
Hi, that patch subject is utterly wrong. the real desc would be "add support for the 2nd CS line on mt7620a and add a special device_id for this." however, as you only register the CS with the spi driver and are missing the actuall /cs1 mux init, this patch is wrong/incomplete as it relies on the bootloader to have setup the cs line already and has a misleading desription. John On 31/08/2014 22:55, Luis Soltero wrote: > > Hello All, > > the mt7620a.dtsi makes reference to mt7620a-spi but this node does > not exist in spi.c. The following patch address this. > > here is the entry in the dts file... spi@b00 { > > > compatible = "ralink,mt7620a-spi", "ralink,rt2880-spi"; > > > reg = <0xb00 0x100>; > > > > > resets = <&rstctrl 18>; > > > reset-names = "spi"; > > > > > #address-cells = <1>; > > > #size-cells = <1>; > > > > > status = "disabled"; > > > > > pinctrl-names = "default"; > > > pinctrl-0 = <&spi_pins>; > > > }; > > > the following mus be added to the DTS file to use it. > > spi@b00 { > > > status = "okay"; > > > num-cs = <2>; > > > m25p80@0 { snip > > here is the patch. > > --luis > > > > > > > ___ openwrt-devel > mailing list openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] VXLAN support
Mon, Sep 01, 2014 at 03:57:19AM CEST, ka...@stratosphere.co.jp wrote: >Hi, > >There's a vxlan kernel module in Linux source tree, >and `ip` command can create vxlan netdev. >Are you talking about netifd support for it? Yes, I am. See below... > > >(2014/09/01 3:51), Jiri Pirko wrote: >> Hi all. >> >> I did not find any movement in support of VXLAN. Are there any plans to >> support it? Or is anyone working on that? >> >> I can try to add VXLAN support to netifd. Any comments, ideas, hints >>> ^^^ >> appreciated. >> >> Thanks. >> >> Jiri >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> >___ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel