Re: [OpenWrt-Devel] Toolchain issue: Significant decrease in performance of binaries produced by Barrier Breaker relative to Attitude Adjustment

2014-08-31 Thread Hannu Nyman 

> 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

2014-08-31 Thread Felix Fietkau 
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

2014-08-31 Thread Nikos Mavrogiannopoulos 
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

2014-08-31 Thread Felix Fietkau 
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]

2014-08-31 Thread Felix Fietkau 
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

2014-08-31 Thread Felix Fietkau 
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

2014-08-31 Thread serge 

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

2014-08-31 Thread Сергей Василюгин 
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

2014-08-31 Thread Jiri Pirko 
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

2014-08-31 Thread Jiri Pirko 
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

2014-08-31 Thread Fernando Frediani 

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

2014-08-31 Thread Jiri Pirko 
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";

2014-08-31 Thread Luis Soltero 

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

2014-08-31 Thread Matthias Schiffer 
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

2014-08-31 Thread Matthias Schiffer 
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

2014-08-31 Thread Daniel Golle 
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

2014-08-31 Thread Hiroaki KAWAI 
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";

2014-08-31 Thread John Crispin 
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

2014-08-31 Thread Jiri Pirko 
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