Re: [OpenWrt-Devel] [PATCH] ar71xx: fix UAP-PRO images

2015-07-06 Thread Roman Yeryomin
On 6 July 2015 at 12:40, Matt . yamakasi@gmail.com wrote:
 Hi,

 I mean, not only ar71xx.

Looks like you don't understand what you are talking about - UAP-PRO
exists only under ar71xx target.

 Which version is going to be patched, as in BB, CC ?

This patch is for trunk, it's up to core devs if they want it to be
backported or not.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable

2015-07-06 Thread Martin Blumenstingl
On Mon, Jul 6, 2015 at 12:39 PM, Felix Fietkau n...@openwrt.org wrote:
 What's the newest firmware that still works on your card?
 Also, please report these issues to the ath10k firmware maintainer.
I think the latest working version was the newest -2 (10.1 branch). I
can look it up when I have access to the device again (probably this
weekend).
Reporting to the ath10k firmware maintainer is done by sending an
email to the ath10k mailing list, or what is the preferred way?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable

2015-07-06 Thread Felix Fietkau
On 2015-07-06 12:48, Martin Blumenstingl wrote:
 On Mon, Jul 6, 2015 at 12:39 PM, Felix Fietkau n...@openwrt.org wrote:
 What's the newest firmware that still works on your card?
 Also, please report these issues to the ath10k firmware maintainer.
 I think the latest working version was the newest -2 (10.1 branch). I
 can look it up when I have access to the device again (probably this
 weekend).
 Reporting to the ath10k firmware maintainer is done by sending an
 email to the ath10k mailing list, or what is the preferred way?
Yes, and Cc kv...@qca.qualcomm.com (Kalle Valo)

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable

2015-07-06 Thread Felix Fietkau
On 2015-07-06 12:36, Martin Blumenstingl wrote:
 Hi Felix,
 
 On Mon, Jul 6, 2015 at 12:26 PM, Felix Fietkau n...@openwrt.org wrote:
 Instead of adding more options that most people don't know what to do
 with, please test the current v5 firmware in trunk and provide details
 about any issues that you find.
 I am not sure which issue Günther is trying to solve, but there ath10k
 firmware crashes for some users: [0]
 For me the crashes are reproducible even with the latest v5 firmware
 on a QCA9880-BR4A.
 However, older and newer ath10k firmware versions are working fine on
 a QCA9880-2R4E - so it seems that this crash is chip-specific.
What's the newest firmware that still works on your card?
Also, please report these issues to the ath10k firmware maintainer.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v2 6/8] generic: replace request_irq by request_threaded_irq to fix non working ledtrig-gpio

2015-07-06 Thread Felix Fietkau
On 2015-07-02 13:47, Günther Kelleter wrote:
 Signed-off-by: Günther Kelleter guenther.kelle...@devolo.de
What issue does this fix?

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable

2015-07-06 Thread Guenther Kelleter
Hi Felix 

 -Original Message-
 From: Felix Fietkau [mailto:n...@openwrt.org]
 Sent: Monday, July 06, 2015 12:27 PM
 To: Guenther Kelleter; openwrt-devel@lists.openwrt.org
 Subject: Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k
 firmwares selectable
 
 On 2015-07-02 13:47, Günther Kelleter wrote:
  The ath10k firmware version is now a choice in the config menu.
  Added options for older firmware versions (10.1 and 10.2). It seems
  that recent firmware versions don't always run properly and this
  provides the option to select an older (more stable) version instead.
 
  Signed-off-by: Günther Kelleter guenther.kelle...@devolo.de
 Instead of adding more options that most people don't know what to do with,
 please test the current v5 firmware in trunk and provide details about any
 issues that you find.
 
 - Felix

The V2 firmware was the only one that didn't crash. We didn't try V5 so far 
because it was released after we made that patch. I'm going to check V5.

Günther
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ar71xx: fix UAP-PRO images

2015-07-06 Thread Matt .
Ow I'm sorry, I'm replying to the wrong thread it seems! :)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable

2015-07-06 Thread Felix Fietkau
On 2015-07-02 13:47, Günther Kelleter wrote:
 The ath10k firmware version is now a choice in the config menu.
 Added options for older firmware versions (10.1 and 10.2). It seems that
 recent firmware versions don't always run properly and this provides the
 option to select an older (more stable) version instead.
 
 Signed-off-by: Günther Kelleter guenther.kelle...@devolo.de
Instead of adding more options that most people don't know what to do
with, please test the current v5 firmware in trunk and provide details
about any issues that you find.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable

2015-07-06 Thread Martin Blumenstingl
Hi Felix,

On Mon, Jul 6, 2015 at 12:26 PM, Felix Fietkau n...@openwrt.org wrote:
 Instead of adding more options that most people don't know what to do
 with, please test the current v5 firmware in trunk and provide details
 about any issues that you find.
I am not sure which issue Günther is trying to solve, but there ath10k
firmware crashes for some users: [0]
For me the crashes are reproducible even with the latest v5 firmware
on a QCA9880-BR4A.
However, older and newer ath10k firmware versions are working fine on
a QCA9880-2R4E - so it seems that this crash is chip-specific.

Regards,
Martin


[0] https://dev.openwrt.org/ticket/19167
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] ramips: adding support for OY-0001 Wireless Router

2015-07-06 Thread LiWeijian
From: Tom Deng 2579131...@qq.com

Adding support for OY-0001 Wireless Router.
OY-0001 is a wireless router made by oyewifi.com. Below is the details:
MT7620A, 128MB DDR2, 16MB FLASH, SD Slot, USB 2.0, 4 x LAN + 1 x WAN.
Signed-off-by: Tom Deng 2579131...@qq.com
---
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 74b8867..35a64dd 100755
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -186,6 +186,9 @@ get_status_led() {
f7c027)
status_led=belkin:orange:status
;;
+   oy-0001)
+   status_led=oy:green:wifi
+   ;;
na930)
status_led=na930:blue:power
;;
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/01_leds 
b/target/linux/ramips/base-files/etc/uci-defaults/01_leds
index 5d6ed2b..265525a 100755
--- a/target/linux/ramips/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ramips/base-files/etc/uci-defaults/01_leds
@@ -199,6 +199,10 @@ case $board in
set_wifi_led zbtlink:blue:air
set_usb_led zbtlink:blue:usb
;;
+   oy-0001)
+   ucidef_set_led_default power power oy:green:power 1
+   set_wifi_led oy:green:wifi
+   ;;
wr8305rt)
ucidef_set_led_default power power wr8305rt:sys 1
set_usb_led wr8305rt:usb
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/02_network 
b/target/linux/ramips/base-files/etc/uci-defaults/02_network
index c3ea489..b847a1b 100755
--- a/target/linux/ramips/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ramips/base-files/etc/uci-defaults/02_network
@@ -104,6 +104,7 @@ ramips_setup_interfaces()
dir-615-h1 | \
hlk-rm04 | \
mzk-w300nh2 | \
+   oy-0001 | \
mzk-750dhp)
ucidef_set_interfaces_lan_wan eth0.1 eth0.2
ucidef_add_switch switch0 1 1
@@ -221,6 +222,11 @@ ramips_setup_macs()
wan_mac=$(mtd_get_mac_binary devdata 7)
;;
 
+   oy-0001)
+   lan_mac=$(mtd_get_mac_binary factory 40)
+   wan_mac=$(mtd_get_mac_binary factory 46)
+   ;;
+
w306r-v20)
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(macaddr_add $lan_mac 5)
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index fd03423..f95adc5 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -325,6 +325,9 @@ ramips_board_detect() {
*Zbtlink ZBT-WA05)
name=zbt-wa05
;;
+   *OY-0001)
+   name=oy-0001
+   ;;
*ZBT WR8305RT)
name=wr8305rt
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index ba69a89..ad35f9d 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -96,6 +96,7 @@ platform_check_image() {
wmr300 |\
wr8305rt |\
wrtnode |\
+   oy-0001 |\
x5 |\
x8 |\
zbt-wa05 |\
diff --git a/target/linux/ramips/dts/OY-0001.dts 
b/target/linux/ramips/dts/OY-0001.dts
new file mode 100644
index 000..48b7099
--- /dev/null
+++ b/target/linux/ramips/dts/OY-0001.dts
@@ -0,0 +1,123 @@
+/dts-v1/;
+
+/include/ mt7620a.dtsi
+
+/ {
+   compatible = ralink,mt7620a-soc;
+   model = OY-0001;
+
+chosen {
+bootargs = console=ttyS0,115200;
+};
+
+   palmbus@1000 {
+   gpio2: gpio@660 {
+   status = okay;
+   };
+
+   gpio3: gpio@688 {
+   status = okay;
+   };
+
+   spi@b00 {
+   status = okay;
+
+   m25p80@0 {
+   #address-cells = 1;
+   #size-cells = 1;
+   compatible = w25q128;
+   reg = 0 0;
+   linux,modalias = m25p80, w25q128;
+   spi-max-frequency = 1000;
+
+   partition@0 {
+   label = u-boot;
+   reg = 0x0 0x3;
+   read-only;
+   };
+
+   partition@3 {
+   label = u-boot-env;
+   reg = 0x3 0x1;
+   read-only;
+   };
+
+   factory: partition@4 {
+  

[OpenWrt-Devel] VoCore as wireless bridge

2015-07-06 Thread Yaroslav Syrytsia
Hi,

I am trying to use VoCore (RT5350 board) as wireless bridge with the following 
wpa_supplicant config:

ctrl_interface=/var/run/wpa.sock
update_config=1
fast_reauth=1
ap_scan=1
network={
ssid=home_wifi
psk=915644af001df2afbcf02df60f3fc27f9f7d7b09f1ac3667bb84e0776ec25e08
}

I do:
# iw dev wlan0 interface add client0 type station
# wpa_supplicant -i client0 -c ./wpa.conf -dd -t

And got log:
1436168056.380440: Successfully initialized wpa_supplicant
1436168057.769320: client0: SME: Trying to authenticate with 00:21:91:8b:61:c4 
(SSID='home_wifi' freq=2462 MHz)
1436168057.827220: client0: Trying to associate with 00:21:91:8b:61:c4 
(SSID='home_wifi' freq=2462 MHz)
1436168057.874320: client0: Associated with 00:21:91:8b:61:c4
1436168057.989180: client0: WPA: Key negotiation completed with 
00:21:91:8b:61:c4 [PTK=CCMP GTK=CCMP]
1436168057.990540: client0: CTRL-EVENT-CONNECTED - Connection to 
00:21:91:8b:61:c4 completed [id=0 id_str=]

Kernel side:
Mon Jul 6 07:36:11 2015 kern.info kernel: [130154.44] client0: authenticate 
with 00:21:91:8b:61:c4
Mon Jul 6 07:36:11 2015 kern.info kernel: [130154.48] client0: send auth to 
00:21:91:8b:61:c4 (try 1/3)
Mon Jul 6 07:36:11 2015 kern.info kernel: [130154.49] client0: authenticated
Mon Jul 6 07:36:11 2015 kern.info kernel: [130154.51] client0: associate 
with 00:21:91:8b:61:c4 (try 1/3)
Mon Jul 6 07:36:11 2015 kern.info kernel: [130154.52] client0: RX AssocResp 
from 00:21:91:8b:61:c4 (capab=0x411 status=0 aid=1)
Mon Jul 6 07:36:11 2015 kern.info kernel: [130154.54] client0: associated

Looks like everything is fine:
# iwinfo
client0   ESSID: home_wifi
  Access Point: 00:21:91:8B:61:C4
  Mode: Client  Channel: 11 (2.462 GHz)
  Tx-Power: 20 dBm  Link Quality: 42/70
  Signal: -68 dBm  Noise: unknown
  Bit Rate: 65.0 MBit/s
  Encryption: unknown
  Type: nl80211  HW Mode(s): 802.11bgn
  Hardware: unknown [Generic MAC80211]
  TX power offset: unknown
  Frequency offset: unknown
  Supports VAPs: yes  PHY name: phy0

wlan0 ESSID: OpenWrt
  Access Point: 00:0C:43:30:50:F8
  Mode: Master  Channel: 11 (2.462 GHz)
  Tx-Power: 20 dBm  Link Quality: unknown/70
  Signal: unknown  Noise: unknown
  Bit Rate: unknown
  Encryption: none
  Type: nl80211  HW Mode(s): 802.11bgn
  Hardware: unknown [Generic MAC80211]
  TX power offset: unknown
  Frequency offset: unknown
  Supports VAPs: yes  PHY name: phy0

As next step, i run: ifconfig client0 172.16.0.31 netmask 255.255.240.0 up

# ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: seq=0 ttl=64 time=2.160 ms
64 bytes from 172.16.0.1: seq=1 ttl=64 time=2.740 ms
^C
--- 172.16.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 2.160/2.450/2.740 ms

# route add default gw 172.16.0.1 dev client0
# echo 'nameserver 8.8.8.8'  /etc/resolv.conf
# opkg update  opkg install iperf

HW:
  GW) bcm63168 based router
  PC) connected to gw as 172.16.0.111 on gigabit ethernet port
  VoCore) connected to gw via WiFi (2.4 Ghz)

And run test on VoCore:
# iperf -c 172.16.0.111 -i 5 -t 999

Client connecting to 172.16.0.111, TCP port 5001
TCP window size: 43.8 KByte (default)

[  3] local 172.16.0.31 port 32956 connected with 172.16.0.111 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0- 5.0 sec  12.0 MBytes  20.1 Mbits/sec
[  3]  5.0-10.0 sec  11.6 MBytes  19.5 Mbits/sec
[  3] 10.0-15.0 sec  11.5 MBytes  19.3 Mbits/sec
[  3] 15.0-20.0 sec  11.4 MBytes  19.1 Mbits/sec
[  3] 20.0-25.0 sec  11.5 MBytes  19.3 Mbits/sec
[  3] 25.0-30.0 sec  11.6 MBytes  19.5 Mbits/sec
[  3] 30.0-35.0 sec  11.5 MBytes  19.3 Mbits/sec

But sometimes i got this without *ANY* logs or warnings on 
kernel/wpa_supplicant,
And in this moment ping also fails:

[  3] 205.0-210.0 sec  3.12 MBytes  5.24 Mbits/sec
[  3] 210.0-215.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 215.0-220.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 220.0-225.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 225.0-230.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 230.0-235.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 235.0-240.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 240.0-245.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 245.0-250.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 250.0-255.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 255.0-260.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 260.0-265.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 265.0-270.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 270.0-275.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 275.0-280.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 280.0-285.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 285.0-290.0 sec  0.00 Bytes  0.00 bits/sec
[  3] 290.0-295.0 sec  7.00 MBytes  11.7 Mbits/sec
[  3] 

Re: [OpenWrt-Devel] [PATCH] ar71xx: fix UAP-PRO images

2015-07-06 Thread Roman Yeryomin
On 5 July 2015 at 23:31, Matt . yamakasi@gmail.com wrote:
 Hi,

 This needs to be patched on ALL versions! After this, we need to point
 the main devs of this package to it.

 Sounds like a plan ?


What do you mean ALL versions?
This patch is easily backportable into CC if you mean that...

Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ar71xx: fix UAP-PRO images

2015-07-06 Thread Matt .
Hi,

I mean, not only ar71xx.


Which version is going to be patched, as in BB, CC ?

2015-07-06 10:30 GMT+02:00 Roman Yeryomin leroi.li...@gmail.com:
 On 5 July 2015 at 23:31, Matt . yamakasi@gmail.com wrote:
 Hi,

 This needs to be patched on ALL versions! After this, we need to point
 the main devs of this package to it.

 Sounds like a plan ?


 What do you mean ALL versions?
 This patch is easily backportable into CC if you mean that...

 Regards,
 Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v2 6/8] generic: replace request_irq by request_threaded_irq to fix non working ledtrig-gpio

2015-07-06 Thread Guenther Kelleter

 -Original Message-
 From: Felix Fietkau [mailto:n...@openwrt.org]
 Sent: Monday, July 06, 2015 12:43 PM
 To: Guenther Kelleter; openwrt-devel@lists.openwrt.org
 Subject: Re: [OpenWrt-Devel] [PATCH v2 6/8] generic: replace request_irq by
 request_threaded_irq to fix non working ledtrig-gpio
 
 On 2015-07-02 13:47, Günther Kelleter wrote:
  Signed-off-by: Günther Kelleter guenther.kelle...@devolo.de
 What issue does this fix?
 
 - Felix

Without this change, gpio_trig_gpio_store() throws this error:
[   88.54] leds devolo:status:dlan: request_irq failed with error -22
[   88.55] leds devolo:error:dlan: request_irq failed with error -22


Günther
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ar71xx: fix kernel Oops in at803x_link_change_notify

2015-07-06 Thread Christian Lamparter
On Friday, July 03, 2015 12:29:32 PM Sven Eckelmann wrote:
  Sven, I've seen you did quite a bit of work on the OM5P-AN
  with the same F1E-PHY. I went through the code from Atheros'
  original driver SDK v17 (which was part of the GPL source
  for the mynet). Apart from tx delay handling, everything
  else matches perfectly, so the tx/rx delay code should be
  enabled by default for this chip on all platforms without
  needing any platform data overwrites.
 
 Interesting, I don't have the SDK and I am only using OpenWrt. So I cannot say
 anything about the Atheros driver. But sounds like you are right. At least all
 recent devices I had in my hand required this change.
Oh, I figured you have access to some of Qualcomm Atheros' SDKs
and most importantly: some documentations from Qualcomm Atheros? 
I hoped you could confirm or disconfirm based on the documents.
 
 I also saw your fixup_rgmii_tx_delay delay change. I would ack when you submit
 a change like this. Just don't forget that the pll_1000 has also to be changed
 (especially when you move the default values to at803x.c):
 
 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-om5p.c
 +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-om5p.c
 @@ -154,7 +154,8 @@ static struct i2c_board_info om5pan_i2c_devs[] __initdata 
 = {
  static struct at803x_platform_data om5p_an_at803x_data = {
   .disable_smarteee = 1,
   .enable_rgmii_rx_delay = 1,
 - .enable_rgmii_tx_delay = 1,
 + .enable_rgmii_tx_delay = 0,
 + .fixup_rgmii_tx_delay = 1,
  };
  
  static struct mdio_board_info om5p_an_mdio0_info[] = {
 @@ -201,7 +202,7 @@ static void __init om5p_an_setup(void)
   ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
   ath79_eth0_data.mii_bus_dev = ath79_mdio0_device.dev;
   ath79_eth0_data.phy_mask = BIT(7);
 - ath79_eth0_pll_data.pll_1000 = 0x0200;
 + ath79_eth0_pll_data.pll_1000 = 0x0e00;
   ath79_eth0_pll_data.pll_100 = 0x0101;
   ath79_eth0_pll_data.pll_10 = 0x1313;
   ath79_register_eth(0);
 
 
 I don't have the equipment to check the actual signals (as you said in an
 earlier mail) - only some people which complained very loud when their long
 cable setup didn't work. :)
Long cable... That's a good point, I think I never tested the AT8035 with
anything beyond a 5m / 16 feet cable.  

 Maybe there are some non atheros SoC's out there which would have problems
 when you would change the default behavior of the AT8035.
I've been looking around for devices with an AT8035. And I found a few gems.

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-September/200978.html
https://forum.openwrt.org/viewtopic.php?id=42896https://dev.openwrt.org/ticket/13203
...
(The AT8035 is also used in some of the new HomePlug AV2 equipment) 

As far as I can tell, the defaults only seem to work for the 100mbps.
This makes sense, since the F1E has different PLLs and rx/tx delay
settings. Fixing this globally might actually be a good thing. At
least I'll give it a try.
  I'm interested to hear from any other devices which have 
  a AT803x. Also, please let me know where to get the GPL
  tars for the devices.
 
 I have forwarded your mail to the person which is handling the actual
 firmware builds of the OM5P-AN. He will contact you later and provide
 the sources.
Oh, that might be helpful yes. I can also post the sources from Western
Digital's S17_SSDK [The Ethernet driver SDK is part of their GPL.tar.gz].

Thanks,
  Christian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v2 6/8] generic: replace request_irq by request_threaded_irq to fix non working ledtrig-gpio

2015-07-06 Thread Felix Fietkau
On 2015-07-06 14:14, Guenther Kelleter wrote:
 
 -Original Message-
 From: Felix Fietkau [mailto:n...@openwrt.org]
 Sent: Monday, July 06, 2015 12:43 PM
 To: Guenther Kelleter; openwrt-devel@lists.openwrt.org
 Subject: Re: [OpenWrt-Devel] [PATCH v2 6/8] generic: replace request_irq by
 request_threaded_irq to fix non working ledtrig-gpio
 
 On 2015-07-02 13:47, Günther Kelleter wrote:
  Signed-off-by: Günther Kelleter guenther.kelle...@devolo.de
 What issue does this fix?
 
 - Felix
 
 Without this change, gpio_trig_gpio_store() throws this error:
 [   88.54] leds devolo:status:dlan: request_irq failed with error -22
 [   88.55] leds devolo:error:dlan: request_irq failed with error -22
If you rework the GPIO IRQ handler code to not require threading, you
probably won't have to change this generic code.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: rework patch for qca953x/956x

2015-07-06 Thread Matthias Schiffer
On 07/04/2015 10:32 PM, Christian Mehlis wrote:
 Am 02.07.2015 um 23:10 schrieb Matthias Schiffer:
  I've fixed it
 up using the following snippet, the Compex WPJ531 will probably need the
 same fix (it uses pretty much the same initialization code).
 
 Thanks Matthias,
 
 When submitting the fix for the WR841Nv9 please also include the fix for
 the wpj531.
 
 I'll test and verify!
 
 Best
 Christian

Hi,
could you send me the output of `swconfig dev eth1 show` (or eth0?) on
OpenWrt? The current initialization code looks a bit weird as it's the
same one would use for a device with 4 LAN ports, even though the WPJ531
has only one.

Matthias



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 v2 5/8] mac80211: make more ath10k firmwares selectable

2015-07-06 Thread Guenther Kelleter
 -Original Message-
 From: Martin Blumenstingl [mailto:martin.blumensti...@googlemail.com]
 Sent: Monday, July 06, 2015 12:36 PM
 To: Felix Fietkau
 Cc: Guenther Kelleter; openwrt-devel@lists.openwrt.org
 Subject: Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k
 firmwares selectable
 
 Hi Felix,
 
 On Mon, Jul 6, 2015 at 12:26 PM, Felix Fietkau n...@openwrt.org wrote:
  Instead of adding more options that most people don't know what to do
  with, please test the current v5 firmware in trunk and provide details
  about any issues that you find.
 I am not sure which issue Günther is trying to solve, but there ath10k
 firmware crashes for some users: [0] For me the crashes are reproducible even
 with the latest v5 firmware on a QCA9880-BR4A.
 However, older and newer ath10k firmware versions are working fine on a
 QCA9880-2R4E - so it seems that this crash is chip-specific.
 
 Regards,
 Martin
 
 
 [0] https://dev.openwrt.org/ticket/19167


I've tried v5 firmware patch from mailing list. This is the result.

4 fw crashes during boot time:

[   13.18] cfg80211: Calling CRDA to update world regulatory domain
[   13.21] cfg80211: World regulatory domain updated:
[   13.21] cfg80211:  DFS Master region: unset
[   13.22] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[   13.23] cfg80211:   (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[   13.23] cfg80211:   (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[   13.24] cfg80211:   (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 
mBm), (N/A)
[   13.25] cfg80211:   (517 KHz - 525 KHz @ 8 KHz), (N/A, 2000 
mBm), (N/A)
[   13.26] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (0 s)
[   13.27] cfg80211:   (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 
mBm), (0 s)
[   13.28] cfg80211:   (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 
mBm), (N/A)
[   13.28] cfg80211:   (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 
mBm), (N/A)
[   13.39] PCI: Enabling device :00:00.0 ( - 0002)
[   13.40] ath10k_pci :00:00.0: pci irq legacy interrupts 0 irq_mode 0 
reset_mode 0
[   13.62] ath10k_pci :00:00.0: Direct firmware load for 
ath10k/cal-pci-:00:00.0.bin failed with error -2
[   13.63] ath10k_pci :00:00.0: Falling back to user helper
[   15.43] ath10k_pci :00:00.0: qca988x hw2.0 (0x4100016c, 0x043222ff) 
fw 10.2.4.70-2 api 5 htt 2.1 wmi 5 cal file max_sta 128
[   15.44] ath10k_pci :00:00.0: debug 0 debugfs 1 tracing 0 dfs 1 
testmode 1
[   15.56] cfg80211: Calling CRDA for country: AW
[   15.56] cfg80211: Regulatory domain changed to country: AW
[   15.57] cfg80211:  DFS Master region: ETSI
[   15.57] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[   15.58] cfg80211:   (2402000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[   15.59] cfg80211:   (517 KHz - 525 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (N/A)
[   15.60] cfg80211:   (525 KHz - 533 KHz @ 8 KHz, 16 KHz 
AUTO), (N/A, 2000 mBm), (0 s)
[   15.61] cfg80211:   (549 KHz - 571 KHz @ 16 KHz), (N/A, 2700 
mBm), (0 s)
[   15.69] Ebtables v2.0 registered
[   15.70] ip_tables: (C) 2000-2006 Netfilter Core Team
[   15.73] nf_conntrack version 0.5.0 (1971 buckets, 7884 max)
[   15.87] xt_time: kernel timezone is -
[   15.92] PPP generic driver version 2.4.2
[   15.94] NET: Registered protocol family 24
[   15.99] ieee80211 phy1: Atheros AR9340 Rev:3 mem=0xb810, irq=47
[   29.33] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
[   29.36] jffs2_build_filesystem(): unlocking the mtd device... done.
[   29.36] jffs2_build_filesystem(): erasing all blocks after the end 
marker... 
[   35.14] device eth0 entered promiscuous mode
[   35.18] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
[   37.29] eth0: link up (1000Mbps/Full duplex)
[   37.36] br-lan: port 1(eth0) entered forwarding state
[   37.36] br-lan: port 1(eth0) entered forwarding state
[   37.37] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
[   37.46] cfg80211: Calling CRDA for country: DE
[   37.47] cfg80211: Regulatory domain changed to country: DE
[   37.47] cfg80211:  DFS Master region: ETSI
[   37.48] cfg80211:   (start_freq - end_freq @ bandwidth), 
(max_antenna_gain, max_eirp), (dfs_cac_time)
[   37.49] cfg80211:   (240 KHz - 2483000 KHz @ 4 KHz), (N/A, 2000 
mBm), (N/A)
[   37.49] cfg80211:   (515 KHz - 525 KHz @ 8 KHz, 20 KHz 
AUTO), (N/A, 2000 mBm), (N/A)
[   37.50] cfg80211:   (525 KHz - 535 KHz @ 8 KHz, 20 KHz 
AUTO), (N/A, 2000 mBm), (0 s)
[   37.51] cfg80211:   (547 KHz - 

[OpenWrt-Devel] [PATCH] mac80211: update regulatory database to master-2015-06-05

2015-07-06 Thread Petko Bordjukov
Signed-off-by: Petko Bordjukov bordju...@gmail.com
---
 package/kernel/mac80211/files/regdb.txt | 126 
 1 file changed, 81 insertions(+), 45 deletions(-)

diff --git a/package/kernel/mac80211/files/regdb.txt 
b/package/kernel/mac80211/files/regdb.txt
index ba95fc6..84413fd 100644
--- a/package/kernel/mac80211/files/regdb.txt
+++ b/package/kernel/mac80211/files/regdb.txt
@@ -6,7 +6,7 @@ country 00:
# Channel 14. Only JP enables this and for 802.11b only
(2474 - 2494 @ 20), (20), NO-IR, NO-OFDM
# Channel 36 - 48
-   (5170 - 5250 @ 80), (20)
+   (5170 - 5250 @ 80), (20), AUTO-BW
# Channel 52 - 64
(5250 - 5330 @ 80), (20), NO-IR, DFS, AUTO-BW
# Channel 100 - 144
@@ -54,8 +54,8 @@ country AL: DFS-ETSI
 
 country AM: DFS-ETSI
(2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (18)
-   (5250 - 5330 @ 80), (18), DFS
+   (5170 - 5250 @ 20), (18)
+   (5250 - 5330 @ 20), (18), DFS
 
 country AN: DFS-ETSI
(2402 - 2482 @ 40), (20)
@@ -85,7 +85,7 @@ country AT: DFS-ETSI
# 60 gHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
 
-country AU:
+country AU: DFS-ETSI
(2402 - 2482 @ 40), (20)
(5170 - 5250 @ 80), (17), AUTO-BW
(5250 - 5330 @ 80), (24), DFS, AUTO-BW
@@ -141,14 +141,20 @@ country BG: DFS-ETSI
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
+   # 5 gHz Short Range Devices, ref:
+   # Etsi EN 300 440-1
+   # Etsi EN 300 440-2
+   # http://crc.bg/files/_bg/Spisak_2015.pdf
+   # http://crc.bg/files/_bg/Pravila_2015_resh24.pdf
+   (5725 - 5875 @ 80), (14)
# 60 gHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
 
 country BH: DFS-JP
(2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (20)
-   (5250 - 5330 @ 80), (20), DFS
-   (5735 - 5835 @ 80), (20)
+   (5170 - 5250 @ 20), (20)
+   (5250 - 5330 @ 20), (20), DFS
+   (5735 - 5835 @ 20), (20)
 
 country BL: DFS-ETSI
(2402 - 2482 @ 40), (20)
@@ -263,10 +269,10 @@ country CO: DFS-FCC
 
 country CR: DFS-FCC
(2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (17)
-   (5250 - 5330 @ 80), (24), DFS
-   (5490 - 5730 @ 80), (24), DFS
-   (5735 - 5835 @ 80), (30)
+   (5170 - 5250 @ 20), (17)
+   (5250 - 5330 @ 20), (24), DFS
+   (5490 - 5730 @ 20), (24), DFS
+   (5735 - 5835 @ 20), (30)
 
 country CX: DFS-FCC
(2402 - 2482 @ 40), (20)
@@ -349,10 +355,10 @@ country DZ: DFS-JP
 
 country EC: DFS-FCC
(2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (17)
-   (5250 - 5330 @ 80), (24), DFS
-   (5490 - 5730 @ 80), (24), DFS
-   (5735 - 5835 @ 80), (30)
+   (5170 - 5250 @ 20), (17)
+   (5250 - 5330 @ 20), (24), DFS
+   (5490 - 5730 @ 20), (24), DFS
+   (5735 - 5835 @ 20), (30)
 
 country EE: DFS-ETSI
(2402 - 2482 @ 40), (20)
@@ -364,8 +370,8 @@ country EE: DFS-ETSI
 
 country EG: DFS-ETSI
(2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (20)
-   (5250 - 5330 @ 80), (20), DFS
+   (5170 - 5250 @ 40), (20)
+   (5250 - 5330 @ 40), (20), DFS
 
 # Orden IET/787/2013, de 25 de abril, por la que se aprueba
 # el cuadro nacional de atribución de frecuencias.
@@ -474,10 +480,10 @@ country GT: DFS-FCC
 
 country GU: DFS-FCC
(2402 - 2472 @ 40), (30)
-   (5170 - 5250 @ 80), (17)
-   (5250 - 5330 @ 80), (24), DFS
-   (5490 - 5730 @ 80), (24), DFS
-   (5735 - 5835 @ 80), (30)
+   (5170 - 5250 @ 20), (17)
+   (5250 - 5330 @ 20), (24), DFS
+   (5490 - 5730 @ 20), (24), DFS
+   (5735 - 5835 @ 20), (30)
 
 country GY:
(2402 - 2482 @ 40), (30)
@@ -522,8 +528,8 @@ country HU: DFS-ETSI
 
 country ID: DFS-JP
# ref: 
http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf
-   (2402 - 2482 @ 40), (20)
-   (5735 - 5815 @ 80), (23)
+   (2402 - 2482 @ 20), (20)
+   (5735 - 5815 @ 20), (23)
 
 country IE: DFS-ETSI
(2402 - 2482 @ 40), (20)
@@ -584,6 +590,9 @@ country JP: DFS-JP
(5170 - 5250 @ 80), (20), AUTO-BW
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (23), DFS
+   # 60 GHz band channels 2-4 at 10mW,
+   # ref: http://www.arib.or.jp/english/html/overview/doc/1-STD-T74v1_1.pdf
+   (59000 - 66000 @ 2160), (10 mW)
 
 country KE: DFS-JP
(2402 - 2482 @ 40), (20)
@@ -607,11 +616,11 @@ country KN: DFS-ETSI
(5735 - 5815 @ 80), (30)
 
 country KP: DFS-JP
-   (2402 - 2482 @ 40), (20)
-   (5170 - 5250 @ 80), (20), AUTO-BW
-   (5250 - 5330 @ 80), (20), DFS, AUTO-BW
-   (5490 - 5630 @ 80), (30), DFS
-   (5735 - 5815 @ 80), (30)
+   (2402 - 2482 @ 20), (20)
+   (5170 - 5250 @ 20), (20)
+   (5250 - 5330 @ 20), (20), DFS
+   (5490 - 5630 @ 20), (30), 

[OpenWrt-Devel] [PATCH] ramips mt7620: ArcherC20i USB support and more

2015-07-06 Thread Gunnar Thorburn

Hi,

Trunk and CC image for ArcherC20i do not support USB/leds/buttons.
This patch is for an updated/improved .dts-file.
See also: https://forum.openwrt.org/viewtopic.php?pid=281794#p281794

Signed-off-by: Gunnar Thorburn gun...@thorburn.se

$ diff -up target/linux/ramips/dts/ArcherC20i.dts{.orig,}
--- target/linux/ramips/dts/ArcherC20i.dts.orig	2015-07-05 
15:27:04.763421748 +0200
+++ target/linux/ramips/dts/ArcherC20i.dts	2015-07-05 15:53:24.738509389 
+0200

@@ -3,109 +3,139 @@
 /include/ mt7620a.dtsi

 / {
-   compatible = ralink,mt7620a-soc;
-   model = TP-Link Archer C20i;
+compatible = ralink,mt7620a-soc;
+model = TP-Link Archer C20i;

-   chosen {
-   bootargs = console=ttyS0,115200;
-   };
-
-   palmbus@1000 {
-   gpio2: gpio@660 {
-   status = okay;
-   };
-
-   spi@b00 {
-   status = okay;
-
-   m25p80@0 {
-   #address-cells = 1;
-   #size-cells = 1;
-   compatible = en25q64;
-   reg = 0 0;
-   linux,modalias = m25p80, mx25l6405d;
-   spi-max-frequency = 1000;
-
-   partition@0 {
-   label = u-boot;
-   reg = 0x0 0x2;
-   read-only;
-   };
-
-   partition@2 {
-   label = firmware;
-   reg = 0x2 0x7a;
-   };
-
-   partition@7c {
-   label = config;
-   reg = 0x7c 0x1;
-   };
-
-   rom: partition@7d {
-   label = rom;
-   reg = 0x7d 0x1;
-   };
-
-   partition@7e {
-   label = romfile;
-   reg = 0x7e 0x1;
-   };
-
-   radio: partition@7f {
-   label = radio;
-   reg = 0x7f 0x1;
-   };
-   };
-   };
-   };
-
-   pinctrl {
-   state_default: pinctrl0 {
-   gpio {
-   ralink,group = i2c, uartf, rgmii1, rgmii2, 
wled, nd_sd;
-   ralink,function = gpio;
-   };
-   };
-   };
-
-   ethernet@1010 {
-   pinctrl-names = default;
-   pinctrl-0 = ephy_pins;
-
-   mtd-mac-address = rom 0xf100;
-   ralink,port-map = w;
-   };
-
-   gsw@1011 {
-   ralink,port4 = ephy;
-   };
-
-   wmac@1018 {
-   ralink,mtd-eeprom = radio 0;
-   };
-
-   pcie@1014 {
-   status = okay;
-
-   pcie-bridge {
-   mt76@0,0 {
-   reg = 0x 0 0 0 0;
-   device_type = pci;
-   mediatek,mtd-eeprom = radio 32768;
-   mediatek,2ghz = 0;
-   };
-   };
-   };
-
-   gpio-leds {
-   compatible = gpio-leds;
-   };
-
-   gpio-keys-polled {
-   compatible = gpio-keys-polled;
-   #address-cells = 1;
-   #size-cells = 0;
-   poll-interval = 20;
-   };
+chosen {
+bootargs = console=ttyS0,115200;
+};
+
+palmbus@1000 {
+gpio2: gpio@660 {
+status = okay;
+};
+
+gpio3: gpio@688 {
+status = okay;
+};
+
+spi@b00 {
+status = okay;
+
+m25p80@0 {
+#address-cells = 1;
+#size-cells = 1;
+compatible = en25q64;
+reg = 0 0;
+linux,modalias = m25p80, mx25l6405d;
+spi-max-frequency = 1000;
+
+partition@0 {
+label = u-boot;
+reg = 0x0 0x2;
+read-only;
+};
+
+partition@2 {
+label = firmware;
+reg = 0x2 0x7a;
+};
+
+partition@7c {
+label = config;
+reg = 0x7c 0x1;
+};
+
+ 

Re: [OpenWrt-Devel] [PATCH] ramips mt7620: ArcherC20i USB support and more

2015-07-06 Thread Jonas Gorski
Hi,

On Mon, Jul 6, 2015 at 10:36 PM, Gunnar Thorburn gun...@thorburn.se wrote:
 Hi,

 Trunk and CC image for ArcherC20i do not support USB/leds/buttons.
 This patch is for an updated/improved .dts-file.

Please describe what you changed (added/removed/changed nodes/properties).

 See also: https://forum.openwrt.org/viewtopic.php?pid=281794#p281794

 Signed-off-by: Gunnar Thorburn gun...@thorburn.se

 $ diff -up target/linux/ramips/dts/ArcherC20i.dts{.orig,}
 --- target/linux/ramips/dts/ArcherC20i.dts.orig 2015-07-05
 15:27:04.763421748 +0200
 +++ target/linux/ramips/dts/ArcherC20i.dts  2015-07-05
 15:53:24.738509389 +0200
 @@ -3,109 +3,139 @@
  /include/ mt7620a.dtsi

  / {
 -   compatible = ralink,mt7620a-soc;
 -   model = TP-Link Archer C20i;
 +compatible = ralink,mt7620a-soc;
 +model = TP-Link Archer C20i;

Why did you replace all tabs with spaces? This makes the patch hard to
review. Please fix and resend.


Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] Deal with allocation errors in a few missing places.

2015-07-06 Thread Felix Fietkau
On 2015-06-26 00:20, Juliusz Chroboczek wrote:
 Since libubox is used by procd, it should deal gracefully with allocation
 failures.
 ---
  blobmsg_json.c |  2 ++
  json_script.c  |  3 +++
  kvlist.c   |  4 
  ustream.c  | 16 +---
  utils.c|  3 +++
  5 files changed, 25 insertions(+), 3 deletions(-)
 
 diff --git a/blobmsg_json.c b/blobmsg_json.c
 index ffde23d..1f2b4bc 100644
 --- a/blobmsg_json.c
 +++ b/blobmsg_json.c
 @@ -297,6 +297,8 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, 
 bool list, blobmsg_jso
  
   s.len = blob_len(attr);
   s.buf = malloc(s.len);
 +if (!s.buf)
 +return NULL;
Please use tab instead of spaces for indenting.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable

2015-07-06 Thread Felix Fietkau
On 2015-07-06 16:05, Guenther Kelleter wrote:
 Instead of the original patch, would you accept an option to only
 choose between STA mode, AP mode w/ latest API fw (default) and AP mode
 with fallback API2 fw (new) for those people who experience crashes with
 latest fw? At least until these issues are finally fixed?
I already removed the STA fw because it has been obsolete for a long
time. I will accept a patch that adds v2 firmware as a fallback until
the current one is fixed. Maybe it would also be worth testing the Ben
Greear's firmware (the candelatech one) to see if that's a suitable
replacement for the old v2 stuff.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] watchping

2015-07-06 Thread Saverio Proto
Hello Bruno,

yet another tool used in Ninux.org:

https://github.com/ninuxorg/misc_tools/tree/master/adsl_check

What you want to implement is a generic tool... that checks a network
condition and if this condition happens triggers an event.

Yes it would be a nice tool. However routing protocols implementations
have to provide some kind of API to make possible for the tool to make
some actions once a condition is met.

Saverio



2015-07-06 20:54 GMT+02:00 Bruno Randolf b...@thinktube.com:
 Hi Juliusz and all,

 Exporting a route to a routing protocol was just one example of what
 could be done based on the fact that internet connectivity is available
 on an interface. There are other uses one could imagine:
  - Activate a backup interface, say a 3G connection
  - Announce a default GW or not (routing proto or DHCP).
  - Check for firmware upgrades on a public server
  - Start or reconfigure a service

 Second, a default route is not enough: what counts is wether inernet
 connectivity is available thru that route. Sometimes a router announces
 a default route but is not connected itself, or problems exist
 upstream. In that sense it's probably like your babel-pinger but
 more generic.

 The mwan3 package seems do do a similar thing in a script. Do you think
 it could profit from a C-based ubus service? Would it make sense?

 bruno



 On 07/03/2015 09:19 PM, Juliusz Chroboczek wrote:
 Hi Bruno,

 Sometimes it's necessary to re-configure an OpenWRT system based on the
 fact wether Internet connectivity is available on a certain interface.
 [...]
 One example where this is useful is: When Internet is available, we
 configure BATMAN to act as a gateway 'server', if not as a gateway
 'client'.

 I think that a solution that relies on distribution scripts is inherently
 brittle.  The routing daemon should be able to detect the current
 configuration, in a distribution-independent manner, and automatically
 adapt to the current situation.  This is what happens with babeld -- it is
 able to automatically redistribute a kernel route (typically the default
 route, but not necessarily) into the routing protocol.

 I know of three ways of automatically obtaining a default route, in
 descending order of preference:

   - if the other end of the Internet connection speaks RIP, RIPng or OSPF,
 we run Quagga on the gateway and redistribute into Babel;

   - if DHCPv4 is reliable (it usually is), then we simply redistribute the
 DHCP-provided route into the routing protocol;

   - if DHCPv4 is unreliable, we use the babel-pinger utility which
 pings a remote host and installs a route depending on its availability.

 Additionally, there is some very promising but still experimental work to
 provide a fully general and highly integrated solution in the hnetd-full
 package.

 -- Juliusz
 ___
 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


Re: [OpenWrt-Devel] [PATCH 1/2] Provide meaningful error messages when fork fails.

2015-07-06 Thread Felix Fietkau
On 2015-06-26 00:23, Juliusz Chroboczek wrote:
 ---
  inittab.c | 6 +++---
  rcS.c | 4 +++-
  2 files changed, 6 insertions(+), 4 deletions(-)
 
 diff --git a/inittab.c b/inittab.c
 index eb402f8..2767e17 100644
 --- a/inittab.c
 +++ b/inittab.c
 @@ -116,13 +116,13 @@ static void fork_worker(struct init_action *a)
   execvp(a-argv[0], a-argv);
   ERROR(Failed to execute %s\n, a-argv[0]);
   exit(-1);
 - }
 -
 - if (a-proc.pid  0) {
 + } if (a-proc.pid  0) {
Why change the indentation here?

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] Deal gracefully with allocation failures in a few omitted places.

2015-07-06 Thread Felix Fietkau
On 2015-06-26 00:21, Juliusz Chroboczek wrote:
 ---
  libubus.c   | 3 +++
  ubusd_acl.c | 2 ++
  2 files changed, 5 insertions(+)
 
 diff --git a/libubus.c b/libubus.c
 index ccaa069..9aae613 100644
 --- a/libubus.c
 +++ b/libubus.c
 @@ -77,6 +77,9 @@ ubus_queue_msg(struct ubus_context *ctx, struct 
 ubus_msghdr_buf *buf)
   void *data;
  
   pending = calloc_a(sizeof(*pending), data, blob_raw_len(buf-data));
 +if (!pending)
 + /* XXX */
 + return;
Please use tab instead of space for indenting. Also, why XXX here?

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH 2/2] dnsmasq: Add sequential_ip UCI parameter

2015-07-06 Thread Hans Dedecker
When enabled the dnsmasq DHCP server allocates the IP addresses sequentially
starting from the lowest available IP address.

Signed-off-by: Hans Dedecker dedec...@gmail.com
---
 package/network/services/dnsmasq/files/dnsmasq.init | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index bbe2b56..5844aaf 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -135,6 +135,7 @@ dnsmasq() {
append_bool $cfg proxydnssec --proxy-dnssec
append_bool $cfg localservice --local-service
append_bool $cfg quietdhcp --quiet-dhcp
+   append_bool $cfg sequential_ip --dhcp-sequential-ip
 
append_parm $cfg dhcpscript --dhcp-script
append_parm $cfg cachesize --cache-size
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH 1/2] dnsmasq: enable extra tracing by default when UCI parameter logqueries is set

2015-07-06 Thread Hans Dedecker
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
 package/network/services/dnsmasq/files/dnsmasq.init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/network/services/dnsmasq/files/dnsmasq.init 
b/package/network/services/dnsmasq/files/dnsmasq.init
index b0a5fbc..bbe2b56 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -121,7 +121,7 @@ dnsmasq() {
append_bool $cfg nohosts --no-hosts
append_bool $cfg nonegcache --no-negcache
append_bool $cfg strictorder --strict-order
-   append_bool $cfg logqueries --log-queries
+   append_bool $cfg logqueries --log-queries=extra
append_bool $cfg noresolv --no-resolv
append_bool $cfg localise_queries --localise-queries
append_bool $cfg readethers --read-ethers
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ramips mt7620: ArcherC20i USB support and more

2015-07-06 Thread Gunnar Thorburn

Hi,

The patch (actually the entire file) was contributed on the OpenWrt 
forum:

https://forum.openwrt.org/viewtopic.php?pid=281794#p281794
My contribution is that I have tested it and that I am trying to submit 
it here.


I can confirm that:
 1) My ArcherC20i works fine with the patch applied
 2) USB works (which it does not do in CC without the patch)

If the changes not related to USB (ehci/ohci) are questionable, I would 
be happy to resubmit a patch for just USB. I am sorry about the spaces 
and tabs. The clean patch below looks much nicer.


  Gunnar T.


$ diff -up target/linux/ramips/dts/ArcherC20i.dts{.orig,}
--- target/linux/ramips/dts/ArcherC20i.dts.orig	2015-07-05 
15:27:04.763421748 +0200
+++ target/linux/ramips/dts/ArcherC20i.dts	2015-07-06 23:11:04.533094775 
+0200

@@ -15,6 +15,10 @@
status = okay;
};

+   gpio3: gpio@688 {
+   status = okay;
+   };
+
spi@b00 {
status = okay;

@@ -77,8 +81,12 @@
ralink,port-map = w;
};

-   gsw@1011 {
-   ralink,port4 = ephy;
+   ehci@101c {
+   status = okay;
+   };
+
+   ohci@101c1000 {
+   status = okay;
};

wmac@1018 {
@@ -100,6 +108,18 @@

gpio-leds {
compatible = gpio-leds;
+   lan {
+   label = tp-link:blue:lan;
+   gpios = gpio0 1 1;
+   };
+   usb {
+   label = tp-link:blue:usb;
+   gpios = gpio0 11 1;
+   };
+   wlan {
+   label = tp-link:blue:wlan;
+   gpios = gpio3 0 1;
+   };
};

gpio-keys-polled {
@@ -107,5 +127,15 @@
#address-cells = 1;
#size-cells = 0;
poll-interval = 20;
+   reset_wps {
+   label = reset_wps;
+   gpios = gpio0 13 1;
+   linux,code = 0x198;
+   };
+   rfkill {
+   label = rfkill;
+   gpios = gpio0 2 1;
+   linux,code = 0xf7;
+   };
};
 };




06.07.2015 22:54 skrev Jonas Gorski:

Hi,


Why did you replace all tabs with spaces? This makes the patch hard to
review. Please fix and resend.


Jonas

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH 2/2] mvebu: undo LA bit on WRT1900ACv1 WAN MAC address

2015-07-06 Thread Claudio Leite
This had been set in r44508 as a workaround for switch
problems.

Now that the switch driver can handle two devices with
the same MAC address in separate VLANs we can go back
to using the same address on both interfaces.

This is the Linksys firmware's default behavior.

Signed-off-by: Claudio Leite lei...@staticky.com
---
 target/linux/mvebu/base-files/lib/preinit/06_set_iface_mac | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/target/linux/mvebu/base-files/lib/preinit/06_set_iface_mac 
b/target/linux/mvebu/base-files/lib/preinit/06_set_iface_mac
index 7217e93..9fc8d9a 100644
--- a/target/linux/mvebu/base-files/lib/preinit/06_set_iface_mac
+++ b/target/linux/mvebu/base-files/lib/preinit/06_set_iface_mac
@@ -11,9 +11,8 @@ preinit_set_mac_address() {
case $(mvebu_board_name) in
armada-xp-linksys-mamba)
mac=$(mtd_get_mac_ascii devinfo hw_mac_addr)
-   mac_wan=$(macaddr_setbit_la $mac)
ifconfig eth0 hw ether $mac 2/dev/null
-   ifconfig eth1 hw ether $mac_wan 2/dev/null
+   ifconfig eth1 hw ether $mac 2/dev/null
;;
armada-385-linksys-caiman|armada-385-linksys-cobra)
mac=$(mtd_get_mac_ascii devinfo hw_mac_addr)
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH V3] service: if logging start app with LD_PRELOAD lib for line buffering

2015-07-06 Thread Rafał Miłecki
Using pipe automatically switches service to block buffering which kind
of breaks our logging. We won't get anything from stdout FD until the
buffer gets filled fully or the service exits. This makes log messages
appear with an unwanted delay.
This change adds a tiny libsetlbf.so switching stdout to line buffering
and uses this lib for every logging-enabled service started by procd.
We don't need any extra change for stderr as it's unbuffered by default.

Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
V2: Use strncat for safety
Use line buffering instead of no buffering
V3: Use asprintf  putenv as suggested byu cyrus
---
 CMakeLists.txt |  7 +++
 service/instance.c | 19 ++-
 service/setlbf.c   |  6 ++
 3 files changed, 31 insertions(+), 1 deletion(-)
 create mode 100644 service/setlbf.c

diff --git a/CMakeLists.txt b/CMakeLists.txt
index dfa9413..6af17a3 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -10,6 +10,13 @@ IF(APPLE)
   LINK_DIRECTORIES(/opt/local/lib)
 ENDIF()
 
+
+ADD_LIBRARY(setlbf SHARED service/setlbf.c)
+INSTALL(TARGETS setlbf
+   LIBRARY DESTINATION lib
+)
+
+
 SET(SOURCES procd.c signal.c watchdog.c state.cinittab.c rcS.c ubus.c 
system.c
service/service.c service/instance.c service/validate.c 
service/trigger.c service/watch.c
plug/coldplug.c plug/hotplug.c utils/utils.c)
diff --git a/service/instance.c b/service/instance.c
index 35b2def..0bd0bed 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -12,6 +12,7 @@
  * GNU General Public License for more details.
  */
 
+#define _GNU_SOURCE
 #include sys/resource.h
 #include sys/types.h
 #include sys/socket.h
@@ -19,6 +20,7 @@
 #include net/if.h
 #include unistd.h
 #include stdint.h
+#include stdio.h
 #include fcntl.h
 #include pwd.h
 #include libgen.h
@@ -224,6 +226,9 @@ instance_run(struct service_instance *in, int _stdout, int 
_stderr)
struct blobmsg_list_node *var;
struct blob_attr *cur;
char **argv;
+   char *ld_preload;
+   bool ld_preload_seccomp = false;
+   bool ld_preload_setlbf = false;
int argc = 1; /* NULL terminated */
int rem, _stdin;
 
@@ -238,7 +243,19 @@ instance_run(struct service_instance *in, int _stdout, int 
_stderr)
 
if (!in-trace  !in-has_jail  in-seccomp) {
setenv(SECCOMP_FILE, in-seccomp, 1);
-   setenv(LD_PRELOAD, /lib/libpreload-seccomp.so, 1);
+   ld_preload_seccomp = true;
+   }
+   if (_stdout = 0) {
+   ld_preload_setlbf = true;
+   }
+
+   if (ld_preload_seccomp || ld_preload_setlbf) {
+   int bytes = asprintf(ld_preload, LD_PRELOAD=%s%s%s,
+ld_preload_seccomp ? 
/lib/libpreload-seccomp.so : ,
+ld_preload_seccomp  ld_preload_setlbf ? 
: : ,
+ld_preload_setlbf ? /lib/libsetlbf.so : 
);
+   if (bytes)
+   putenv(ld_preload);
}
 
blobmsg_list_for_each(in-limits, var)
diff --git a/service/setlbf.c b/service/setlbf.c
new file mode 100644
index 000..df00366
--- /dev/null
+++ b/service/setlbf.c
@@ -0,0 +1,6 @@
+#include stdio.h
+
+static void __attribute__((constructor)) setlbf(void)
+{
+   setlinebuf(stdout);
+}
-- 
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH v2 0/3] QCA953x fixes, AP143 support

2015-07-06 Thread Matthias Schiffer
This patchset was originally submitted by Miaoqing Pan.   
  
* 1/3 fixes the initialization on TP-Link TL-WR841N/ND v9 and Compex WPJ531
  (TL-WR841N/ND v9 is working, Compex WPJ531 compile-tested only, please
  test!) 
* 2/3 is 1/2 from the original submission rebased to apply to the current  
  trunk   
* 3/3 is 2/2 from the original submission without changes 

Matthias Schiffer (1):
  ar71xx: fix ethernet initialization on QCA953x-based boards (TP-Link
TL-WR841N/ND v9, Compex WPJ531)

Miaoqing Pan (2):
  ar71xx: rework patch for qca953x/956x
  ar71xx: add support for ap143

 .../ar71xx/base-files/etc/uci-defaults/02_network  |   1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
 target/linux/ar71xx/config-3.18|   1 +
 .../linux/ar71xx/files/arch/mips/ath79/dev-eth.c   |  18 +-
 .../ar71xx/files/arch/mips/ath79/mach-ap143.c  | 142 +
 .../files/arch/mips/ath79/mach-tl-wr841n-v9.c  |   6 +
 .../ar71xx/files/arch/mips/ath79/mach-wpj531.c |   7 +
 target/linux/ar71xx/generic/profiles/atheros.mk|  12 +
 target/linux/ar71xx/image/Makefile |   5 +
 ...07-MIPS-ath79-add-support-for-QCA953x-SoC.patch | 326 +++--
 ...35-MIPS-ath79-add-support-for-QCA956x-SoC.patch | 171 ---
 .../736-MIPS-ath79-fix-chained-irq-disable.patch   |  21 +-
 .../810-MIPS-ath79-wmac-enable-set-led-pin.patch   |  24 ++
 .../811-MIPS-ath79-gpio-enable-set-direction.patch |  43 +++
 .../812-MIPS-ath79-add-ap143-support.patch |  43 +++
 15 files changed, 666 insertions(+), 157 deletions(-)
 create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-ap143.c
 create mode 100644 
target/linux/ar71xx/patches-3.18/810-MIPS-ath79-wmac-enable-set-led-pin.patch
 create mode 100644 
target/linux/ar71xx/patches-3.18/811-MIPS-ath79-gpio-enable-set-direction.patch
 create mode 100644 
target/linux/ar71xx/patches-3.18/812-MIPS-ath79-add-ap143-support.patch

-- 
2.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH v2 2/3] ar71xx: rework patch for qca953x/956x

2015-07-06 Thread Matthias Schiffer
From: Miaoqing Pan miaoq...@codeaurora.org

Patch cherry-picked from the following location:
https://www.codeaurora.org/cgit/quic/qsdk/oss/system/openwrt/commit/?h=release/coconut_ioe4531_2.0id=5c357bf6c763e4140dddcc9a3bc5f005525a9c0e

Changelist,
- add more register defines
- add EHCI support
- fix GPIO pin count to 18
- fix chained irq disabled
- fix GMAC0/GMAC1 initial
- fix WMAC irq number to 47
- merge the changes of dev-eth.c from the patch to file.

Signed-off-by: Miaoqing Pan miaoq...@codeaurora.org
Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
---
 .../linux/ar71xx/files/arch/mips/ath79/dev-eth.c   |  18 +-
 ...07-MIPS-ath79-add-support-for-QCA953x-SoC.patch | 326 +++--
 ...35-MIPS-ath79-add-support-for-QCA956x-SoC.patch | 171 ---
 .../736-MIPS-ath79-fix-chained-irq-disable.patch   |  21 +-
 4 files changed, 379 insertions(+), 157 deletions(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c 
b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
index ae3db4c..ff94e2e 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
@@ -198,6 +198,8 @@ void __init ath79_register_mdio(unsigned int id, u32 
phy_mask)
case ATH79_SOC_AR9330:
case ATH79_SOC_AR9331:
case ATH79_SOC_QCA9533:
+   case ATH79_SOC_QCA9561:
+   case ATH79_SOC_TP9343:
mdio_dev = ath79_mdio1_device;
mdio_data = ath79_mdio1_data;
break;
@@ -256,6 +258,8 @@ void __init ath79_register_mdio(unsigned int id, u32 
phy_mask)
break;
 
case ATH79_SOC_QCA9533:
+   case ATH79_SOC_QCA9561:
+   case ATH79_SOC_TP9343:
mdio_data-builtin_switch = 1;
break;
 
@@ -571,6 +575,8 @@ static void __init ath79_init_eth_pll_data(unsigned int id)
case ATH79_SOC_QCA9533:
case ATH79_SOC_QCA9556:
case ATH79_SOC_QCA9558:
+   case ATH79_SOC_QCA9561:
+   case ATH79_SOC_TP9343:
pll_10 = AR934X_PLL_VAL_10;
pll_100 = AR934X_PLL_VAL_100;
pll_1000 = AR934X_PLL_VAL_1000;
@@ -627,6 +633,8 @@ static int __init ath79_setup_phy_if_mode(unsigned int id,
case ATH79_SOC_AR9330:
case ATH79_SOC_AR9331:
case ATH79_SOC_QCA9533:
+   case ATH79_SOC_QCA9561:
+   case ATH79_SOC_TP9343:
pdata-phy_if_mode = PHY_INTERFACE_MODE_MII;
break;
 
@@ -687,7 +695,8 @@ static int __init ath79_setup_phy_if_mode(unsigned int id,
case ATH79_SOC_AR7241:
case ATH79_SOC_AR9330:
case ATH79_SOC_AR9331:
-   case ATH79_SOC_QCA9533:
+   case ATH79_SOC_QCA9561:
+   case ATH79_SOC_TP9343:
pdata-phy_if_mode = PHY_INTERFACE_MODE_GMII;
break;
 
@@ -697,6 +706,7 @@ static int __init ath79_setup_phy_if_mode(unsigned int id,
case ATH79_SOC_AR9341:
case ATH79_SOC_AR9342:
case ATH79_SOC_AR9344:
+   case ATH79_SOC_QCA9533:
switch (pdata-phy_if_mode) {
case PHY_INTERFACE_MODE_MII:
case PHY_INTERFACE_MODE_GMII:
@@ -986,6 +996,7 @@ void __init ath79_register_eth(unsigned int id)
case ATH79_SOC_AR9341:
case ATH79_SOC_AR9342:
case ATH79_SOC_AR9344:
+   case ATH79_SOC_QCA9533:
if (id == 0) {
pdata-reset_bit = AR934X_RESET_GE0_MAC |
   AR934X_RESET_GE0_MDIO;
@@ -1017,7 +1028,8 @@ void __init ath79_register_eth(unsigned int id)
pdata-fifo_cfg3 = 0x01f00140;
break;
 
-   case ATH79_SOC_QCA9533:
+   case ATH79_SOC_QCA9561:
+   case ATH79_SOC_TP9343:
if (id == 0) {
pdata-reset_bit = AR933X_RESET_GE0_MAC |
   AR933X_RESET_GE0_MDIO;
@@ -1123,6 +1135,8 @@ void __init ath79_register_eth(unsigned int id)
case ATH79_SOC_AR9330:
case ATH79_SOC_AR9331:
case ATH79_SOC_QCA9533:
+   case ATH79_SOC_QCA9561:
+   case ATH79_SOC_TP9343:
pdata-mii_bus_dev = ath79_mdio1_device.dev;
break;
 
diff --git 
a/target/linux/ar71xx/patches-3.18/707-MIPS-ath79-add-support-for-QCA953x-SoC.patch
 
b/target/linux/ar71xx/patches-3.18/707-MIPS-ath79-add-support-for-QCA953x-SoC.patch
index 4f5d203..be4f547 100644
--- 
a/target/linux/ar71xx/patches-3.18/707-MIPS-ath79-add-support-for-QCA953x-SoC.patch
+++ 
b/target/linux/ar71xx/patches-3.18/707-MIPS-ath79-add-support-for-QCA953x-SoC.patch
@@ -44,7 +44,7 @@ meaning of the bits CPUCLK_FROM_CPUPLL and 

[OpenWrt-Devel] [PATCH v2 3/3] ar71xx: add support for ap143

2015-07-06 Thread Matthias Schiffer
From: Miaoqing Pan miaoq...@codeaurora.org

Signed-off-by: Miaoqing Pan miaoq...@codeaurora.org
---
 .../ar71xx/base-files/etc/uci-defaults/02_network  |   1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh   |   3 +
 target/linux/ar71xx/config-3.18|   1 +
 .../ar71xx/files/arch/mips/ath79/mach-ap143.c  | 142 +
 target/linux/ar71xx/generic/profiles/atheros.mk|  12 ++
 target/linux/ar71xx/image/Makefile |   5 +
 .../810-MIPS-ath79-wmac-enable-set-led-pin.patch   |  24 
 .../811-MIPS-ath79-gpio-enable-set-direction.patch |  43 +++
 .../812-MIPS-ath79-add-ap143-support.patch |  43 +++
 9 files changed, 274 insertions(+)
 create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-ap143.c
 create mode 100644 
target/linux/ar71xx/patches-3.18/810-MIPS-ath79-wmac-enable-set-led-pin.patch
 create mode 100644 
target/linux/ar71xx/patches-3.18/811-MIPS-ath79-gpio-enable-set-direction.patch
 create mode 100644 
target/linux/ar71xx/patches-3.18/812-MIPS-ath79-add-ap143-support.patch

diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index 2fab4c2..6d76af8 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -383,6 +383,7 @@ wpj558)
 
 ap121 |\
 ap121-mini |\
+ap143 |\
 ap96 |\
 airrouter |\
 dir-600-a1 |\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 00e39ae..4fee82c 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -359,6 +359,9 @@ ar71xx_board_detect() {
*AP135-020 reference board)
name=ap135-020
;;
+   *AP143 reference board)
+   name=ap143
+   ;;
*AP81)
name=ap81
;;
diff --git a/target/linux/ar71xx/config-3.18 b/target/linux/ar71xx/config-3.18
index 17f33bd..0af087d 100644
--- a/target/linux/ar71xx/config-3.18
+++ b/target/linux/ar71xx/config-3.18
@@ -35,6 +35,7 @@ CONFIG_ATH79_MACH_AP113=y
 CONFIG_ATH79_MACH_AP121=y
 CONFIG_ATH79_MACH_AP132=y
 CONFIG_ATH79_MACH_AP136=y
+CONFIG_ATH79_MACH_AP143=y
 CONFIG_ATH79_MACH_AP81=y
 CONFIG_ATH79_MACH_AP83=y
 CONFIG_ATH79_MACH_AP96=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-ap143.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-ap143.c
new file mode 100644
index 000..098420b
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-ap143.c
@@ -0,0 +1,142 @@
+/*
+ * Atheros AP143 reference board support
+ *
+ * Copyright (c) 2013-2015 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2012 Gabor Juhos juh...@openwrt.org
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ */
+
+#include linux/platform_device.h
+#include linux/ath9k_platform.h
+#include linux/ar8216_platform.h
+
+#include asm/mach-ath79/ar71xx_regs.h
+
+#include common.h
+#include dev-eth.h
+#include dev-gpio-buttons.h
+#include dev-leds-gpio.h
+#include dev-m25p80.h
+#include dev-spi.h
+#include dev-usb.h
+#include dev-wmac.h
+#include machtypes.h
+
+#define AP143_GPIO_LED_WLAN12
+#define AP143_GPIO_LED_WPS 13
+#define AP143_GPIO_LED_STATUS  13
+
+#define AP143_GPIO_LED_WAN 4
+#define AP143_GPIO_LED_LAN116
+#define AP143_GPIO_LED_LAN215
+#define AP143_GPIO_LED_LAN314
+#define AP143_GPIO_LED_LAN411
+
+#define AP143_GPIO_BTN_WPS 17
+
+#define AP143_KEYS_POLL_INTERVAL   20  /* msecs */
+#define AP143_KEYS_DEBOUNCE_INTERVAL   (3 * AP143_KEYS_POLL_INTERVAL)
+
+#define AP143_MAC0_OFFSET  0
+#define AP143_MAC1_OFFSET  6
+#define AP143_WMAC_CALDATA_OFFSET  0x1000
+
+static struct gpio_led ap143_leds_gpio[] __initdata = {
+   {
+   .name   = ap143:green:status,
+   .gpio   = AP143_GPIO_LED_STATUS,
+   .active_low = 1,
+   },
+   {
+   .name   = ap143:green:wlan,
+   .gpio   = AP143_GPIO_LED_WLAN,
+   .active_low = 1,
+   }
+};
+
+static 

[OpenWrt-Devel] TEXTREL in x86 with musl

2015-07-06 Thread Luiz Angelo Daros de Luca
Hello,

SInce x86 started to compile with musl, elfutils package becomes broken.
http://buildbot.openwrt.org:8010/broken_packages/x86/elfutils/compile.txt

During linking, elfutils checks if there is TEXTREL in its .so files, and
it fatally fails if so. I guess this is the only package that does this
kind of test.

I'm new to PIE binary but google says that the presence of TEXTREL in an
readelf -d indicates that one of more files linked were not compiled with
-fPIC.  Following https://wiki.gentoo.org/wiki/Hardened/Textrels_Guide, I
tried to locale the offending file with scanelf and got this:

$ trunk/build_dir/target-i386_i486_musl-1.1.10/elfutils-0.163 $ scanelf -qT
*.so libelf/*.so
  libelf.so: __func__.3897 [0xE1F1] in (optimized out: previous
__stack_chk_fail_local) [0xE1F0]
  libelf/libelf.so

I checked all .so files generated with musl and most of them (or all) got
the same output. I still have the uclibc binaries and none have TEXTREL.

What is the best way to deal with this? Turn TEXTREL into non-fatal for
elfutils?

Regards,
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH] ar71xx: add LED defaults for the EnGenius EPG5000

2015-07-06 Thread Christian Beier
Am Mon, 22 Jun 2015 13:28:14 +0200
schrieb Christian Beier c...@shoutrlabs.com:

 NB that wlan5g is phy0tpt and wlan2g phy1tpt.

Hey,

just wanted to know whether I need to change anything or this just takes time
to get applied?

Cheers,

   Christian 

 
 Signed-off-by: Christian Beier c...@shoutrlabs.com
 ---
  target/linux/ar71xx/base-files/etc/uci-defaults/01_leds | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
 b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index
 19814f4..7c10f42 100644 ---
 a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++
 b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -165,6 +165,11
 @@ esr1750) ucidef_set_led_wlan wlan5g WLAN 5 GHz esr1750:blue:wlan-5g
 phy1tpt ;;
  
 +epg5000)
 + ucidef_set_led_wlan wlan2g WLAN 2.4 GHz epg5000:blue:wlan-2g
 phy1tpt
 + ucidef_set_led_wlan wlan5g WLAN 5 GHz epg5000:blue:wlan-5g
 phy0tpt
 + ;;
 +
  hiwifi-hc6361)
   ucidef_set_led_netdev inet INET hiwifi:blue:internet eth1
   ucidef_set_led_wlan wlan WLAN hiwifi:blue:wlan-2p4 phy0tpt
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: rework patch for qca953x/956x

2015-07-06 Thread Christian Mehlis

Am 06.07.2015 um 15:59 schrieb Matthias Schiffer:

could you send me the output of `swconfig dev eth1 show` (or eth0?) on
OpenWrt? The current initialization code looks a bit weird as it's the
same one would use for a device with 4 LAN ports, even though the WPJ531
has only one.


root@OpenWrt:/# swconfig dev eth0 show
Failed to connect to the switch. Use the list command to see which 
switches are available.

root@OpenWrt:/# swconfig dev eth1 show
Global attributes:
enable_vlan: 0
Port 0:
pvid: 0
link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
Port 1:
pvid: 0
link: port:1 link:down
Port 2:
pvid: 0
link: port:2 link:down
Port 3:
pvid: 0
link: port:3 link:up speed:100baseT full-duplex auto
Port 4:
pvid: 0
link: port:4 link:down
VLAN 0:
vid: 0
ports: 0 1 2 3 4

root@OpenWrt:/# ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes:   10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Link partner advertised link modes:  10baseT/Half 10baseT/Full
 100baseT/Half 100baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 4
Transceiver: external
Auto-negotiation: on
Current message level: 0x00ff (255)
   drv probe link timer ifdown ifup rx_err 
tx_err

Link detected: no
root@OpenWrt:/# ethtool eth1
Settings for eth1:
Cannot get device settings: No such device
Current message level: 0x00ff (255)
   drv probe link timer ifdown ifup rx_err 
tx_err

Link detected: yes

###

Both ports are working, but I just took the vendor source code...

In case you have any suggestion to make the initialization more 
correct drop me a mail, I will test your it!


Best
Christian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel