Re: [OpenWrt-Devel] Linux 4.x

2015-06-05 Thread Dirk Neukirchen 
On 05.06.2015 16:00, Baptiste Clenet wrote:
> Hi OpenWRT developers,
> 
> Is there any plan to port OPENWRT on Linux 4.x? (Or is it already done?)
> 
> 

There is a patch available for Kernel 4.1-rc1 [1]
it does not apply cleanly anymore, have a look at my refreshed version [2]
There might be some compile issues depending your target, see the other folders 
at [2]

4.x commits are a little bit on hold since CC which has 3.18 
is not branched yet and probably needs some more testing

Some testing results for 4.0/4.1:
- afaik omap was running but produces an oops in bootup
(afair Arch Linux produced an oops too during bootup)

- ar71xx: ar8216/ar8316/ar8xxx driver is broken
on 8337N and some unknown router (reported yesterday on IRC)
look at [3] if anybody is interested


References:
[1]: http://patchwork.ozlabs.org/patch/465774/
[2]: https://github.com/plntyk/openwrt-patches/tree/master/kernel_4_1
[3]: ar71xx with 4.1-rc1 switch driver error: paste.debian.net/205511

> 
> Wpan-tools works mainly on bluetooth-next kernel which is base on
> Linux 4.x so it doesn't currently work with OpenWRT.
> 
> Cheers,
> 
> Baptiste
> ___
> 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] ar71xx: fix 100/10mbps ethernet link issues on mynet range extender

2015-06-05 Thread Florian Fainelli 
Florian
On Jun 5, 2015 2:18 PM, "Dave Taht"  wrote:
>
> TX delay setting? What else can it do?

This is a delay between the transmit data lines and the transmit clock on a
RGMII interface. Based on PCB designs, this is something that may have to
be configured to align clock and data lines in a way that does not violate
timings and causes packet losses between the MAC and the PHY. These delays
are not valid when a RGMII interface operates at 10 or 100Mbits/sec since
the clock becomes slow enough the rise and fall times of the data lines are
negligable.

>
> My dream has been to find a way to set the tx completion interrupt
> to only return with a soft set rate. So if I had a gigE connection
> but my uplink was only 10Mbits, it would return the interrupt
> after 1.3ms had expired.

What you are referring to here is interrupt coalescing, which is different
and implemented at the Ethernet MAC and DMA engine levels and not all
controllers support that.

>
> this would let me get away entirely from using software rate limiting
> with htb, just program a register once with the uplink rate, and
> let bql and fq_codel handle the rest.
>
> On Wed, Jun 03, 2015 at 05:20:22PM +0200, Christian Lamparter wrote:
> > The mynet range extender hardware is suffering from ethernet
> > link loss when booting with a recent openwrt image. This only
> > happens on 100mbps links, with 1Gbps speed the link was fine.
> >
> > The cause of the problem is that the AR8035 PHY (aka F1E)
> > requires turning on and off the special TX delay setting
> > depending on the speed of the link.
> >
> > The 10mbps mode only needed the proper pll value, which was
> > extracted from the vendor code.
> >
> > Reported-by: Pascal Paradis
> > Signed-off-by: Christian Lamparter 
> > ---
> >  .../ar71xx/files/arch/mips/ath79/mach-mynet-rext.c | 20 
> >  ...t-phy-at803x-allow-to-configure-via-pdata.patch | 53
--
> >  2 files changed, 69 insertions(+), 4 deletions(-)
> >
> > diff --git
a/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
> > index 02d168e..3d48ca8 100644
> > --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
> > +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >
> > @@ -124,6 +125,21 @@ static struct gpio_keys_button
mynet_rext_gpio_keys[] __initdata = {
> >   },
> >  };
> >
> > +static struct at803x_platform_data mynet_rext_at803x_data = {
> > + .disable_smarteee = 0,
> > + .enable_rgmii_rx_delay = 1,
> > + .enable_rgmii_tx_delay = 0,
> > + .fixup_rgmii_tx_delay = 1,
> > +};
> > +
> > +static struct mdio_board_info mynet_rext_mdio0_info[] = {
> > +{
> > +.bus_id = "ag71xx-mdio.0",
> > +.phy_addr = 4,
> > +.platform_data = &mynet_rext_at803x_data,
> > +},
> > +};
> > +
> >  static void mynet_rext_get_mac(const char *name, char *mac)
> >  {
> >   u8 *nvram = (u8 *) KSEG1ADDR(MYNET_REXT_NVRAM_ADDR);
> > @@ -169,12 +185,16 @@ static void __init mynet_rext_setup(void)
> >
> >   ath79_register_mdio(0, 0x0);
> >
> > + mdiobus_register_board_info(mynet_rext_mdio0_info,
> > + ARRAY_SIZE(mynet_rext_mdio0_info));
> > +
> >   /* LAN */
> >   mynet_rext_get_mac("et0macaddr=", ath79_eth0_data.mac_addr);
> >
> >   /* GMAC0 is connected to an external PHY on Port 4 */
> >   ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
> >   ath79_eth0_data.phy_mask = BIT(4);
> > + ath79_eth0_pll_data.pll_10   = 0x1313; /* athrs_mac.c */
> >   ath79_eth0_pll_data.pll_1000 = 0x0e00; /* athrs_mac.c */
> >   ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
> >   ath79_register_eth(0);
> > diff --git
a/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
b/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
> > index babc695..d046ede 100644
> > ---
a/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
> > +++
b/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
> > @@ -32,6 +32,14 @@
> >   #define AT803X_DEBUG_SYSTEM_MODE_CTRL   0x05
> >   #define AT803X_DEBUG_RGMII_TX_CLK_DLY   BIT(8)
> >
> > +@@ -50,6 +60,7 @@ MODULE_LICENSE("GPL");
> > + struct at803x_priv {
> > + bool phy_reset:1;
> > + struct gpio_desc *gpiod_reset;
> > ++int prev_speed;
> > + };
> > +
> > + struct at803x_context {
> >  @@ -61,6 +71,43 @@ struct at803x_context {
> >   u16 led_control;
> >   };
> > @@ -120,16 +128,53 @@
> >   return 0;
> >   }
> >
> > +@@ -258,6 +334,8 @@ static int at803x_config_intr(struct phy
> > + static void at803x_link_change_notify(struct phy_device *phydev)
> > + {
> > + struct at80

[OpenWrt-Devel] [PATCH] ramips: Add support for the D-Link DCS-930 B1

2015-06-05 Thread L. D. Pinney 
http://wiki.openwrt.org/toh/d-link/dcs-930l

Signed-off-by: L. D. Pinney 
---
 target/linux/ramips/base-files/etc/board.d/01_leds |  4 
 target/linux/ramips/base-files/etc/board.d/02_network  |  1 +
 target/linux/ramips/base-files/etc/diag.sh |  3 +++
 target/linux/ramips/base-files/lib/ramips.sh   |  3 +++
 target/linux/ramips/base-files/lib/upgrade/platform.sh |  1 +
 target/linux/ramips/image/Makefile |  2 ++
 target/linux/ramips/rt305x/profiles/dlink.mk   | 13 +
 7 files changed, 27 insertions(+)

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index ad0062a..64c2c2f 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -85,6 +85,10 @@ case $board in
ucidef_set_led_default "power" "POWER" "d105:red:power" "1"
set_usb_led "d105:green:usb"
;;
+   dcs-930l-b1)
+   ucidef_set_led_default "power" "POWER" "d-link:red:power" "1"
+   ucidef_set_led_netdev "wifi" "WiFi" "d-link:blue:wps"
+   ;;
dir-300-b1|\
dir-600-b1|\
dir-600-b2|\
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index 4982566..55af58f 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -53,6 +53,7 @@ ramips_setup_interfaces()
all5003 | \
broadway | \
dcs-930| \
+   dcs-930l-b1| \
ht-tm02| \
ncs601w | \
wnce2001)
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index c5b2921..f62005e 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -48,6 +48,9 @@ get_status_led() {
dcs-930 | dir-300-b1 | dir-600-b1 | dir-600-b2 | dir-610-a1 | 
dir-615-h1 | dir-615-d | dir-620-a1| dir-620-d1| dir-300-b7| dir-320-b1)
status_led="d-link:green:status"
;;
+   dcs-930l-b1)
+   status_led="d-link:red:power"
+   ;;
dir-645)
status_led="d-link:green:wps"
;;
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 0cb02c7..912512b 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -106,6 +106,9 @@ ramips_board_detect() {
*"DCS-930")
name="dcs-930"
;;
+   *"DCS-930L B1")
+   name="dcs-930l-b1"
+   ;;
*"DIR-300 B1")
name="dir-300-b1"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 99cabbd..41e8ef0 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -37,6 +37,7 @@ platform_check_image() {
d105 | \
dap-1350 | \
dcs-930 | \
+   dcs-930l-b1 | \
dir-300-b1 | \
dir-300-b7 | \
dir-320-b1 | \
diff --git a/target/linux/ramips/dts/DCS-930L-B1.dts 
b/target/linux/ramips/dts/DCS-930L-B1.dts
new file mode 100644
index 000..f73a997
--- /dev/null
+++ b/target/linux/ramips/dts/DCS-930L-B1.dts
@@ -0,0 +1,103 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+   compatible =  "DCS-930L-B1", "ralink,rt5350-soc";
+   model = "D-Link DCS-930L B1";
+
+   palmbus@1000 {
+   spi@b00 {
+   status = "okay";
+   m25p80@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "mx25l3205d";
+   reg = <0 0>;
+   linux,modalias = "m25p80", "s25fl064k";
+   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 {
+   label = "factory";
+   reg = <0x4 0x1>;
+   read-only;
+   };
+
+

Re: [OpenWrt-Devel] [PATCH] ar71xx: fix 100/10mbps ethernet link issues on mynet range extender

2015-06-05 Thread Dave Taht 
TX delay setting? What else can it do?

My dream has been to find a way to set the tx completion interrupt
to only return with a soft set rate. So if I had a gigE connection
but my uplink was only 10Mbits, it would return the interrupt
after 1.3ms had expired.

this would let me get away entirely from using software rate limiting
with htb, just program a register once with the uplink rate, and
let bql and fq_codel handle the rest.

On Wed, Jun 03, 2015 at 05:20:22PM +0200, Christian Lamparter wrote:
> The mynet range extender hardware is suffering from ethernet
> link loss when booting with a recent openwrt image. This only
> happens on 100mbps links, with 1Gbps speed the link was fine.
> 
> The cause of the problem is that the AR8035 PHY (aka F1E)
> requires turning on and off the special TX delay setting
> depending on the speed of the link.
> 
> The 10mbps mode only needed the proper pll value, which was
> extracted from the vendor code.
> 
> Reported-by: Pascal Paradis
> Signed-off-by: Christian Lamparter 
> ---
>  .../ar71xx/files/arch/mips/ath79/mach-mynet-rext.c | 20 
>  ...t-phy-at803x-allow-to-configure-via-pdata.patch | 53 
> --
>  2 files changed, 69 insertions(+), 4 deletions(-)
> 
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c 
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
> index 02d168e..3d48ca8 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-mynet-rext.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -124,6 +125,21 @@ static struct gpio_keys_button mynet_rext_gpio_keys[] 
> __initdata = {
>   },
>  };
>  
> +static struct at803x_platform_data mynet_rext_at803x_data = {
> + .disable_smarteee = 0,
> + .enable_rgmii_rx_delay = 1,
> + .enable_rgmii_tx_delay = 0,
> + .fixup_rgmii_tx_delay = 1,
> +};
> +
> +static struct mdio_board_info mynet_rext_mdio0_info[] = {
> +{
> +.bus_id = "ag71xx-mdio.0",
> +.phy_addr = 4,
> +.platform_data = &mynet_rext_at803x_data,
> +},
> +};
> +
>  static void mynet_rext_get_mac(const char *name, char *mac)
>  {
>   u8 *nvram = (u8 *) KSEG1ADDR(MYNET_REXT_NVRAM_ADDR);
> @@ -169,12 +185,16 @@ static void __init mynet_rext_setup(void)
>  
>   ath79_register_mdio(0, 0x0);
>  
> + mdiobus_register_board_info(mynet_rext_mdio0_info,
> + ARRAY_SIZE(mynet_rext_mdio0_info));
> +
>   /* LAN */
>   mynet_rext_get_mac("et0macaddr=", ath79_eth0_data.mac_addr);
>  
>   /* GMAC0 is connected to an external PHY on Port 4 */
>   ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
>   ath79_eth0_data.phy_mask = BIT(4);
> + ath79_eth0_pll_data.pll_10   = 0x1313; /* athrs_mac.c */
>   ath79_eth0_pll_data.pll_1000 = 0x0e00; /* athrs_mac.c */
>   ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
>   ath79_register_eth(0);
> diff --git 
> a/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
>  
> b/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
> index babc695..d046ede 100644
> --- 
> a/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
> +++ 
> b/target/linux/ar71xx/patches-3.18/425-net-phy-at803x-allow-to-configure-via-pdata.patch
> @@ -32,6 +32,14 @@
>   #define AT803X_DEBUG_SYSTEM_MODE_CTRL   0x05
>   #define AT803X_DEBUG_RGMII_TX_CLK_DLY   BIT(8)
>   
> +@@ -50,6 +60,7 @@ MODULE_LICENSE("GPL");
> + struct at803x_priv {
> + bool phy_reset:1;
> + struct gpio_desc *gpiod_reset;
> ++int prev_speed;
> + };
> + 
> + struct at803x_context {
>  @@ -61,6 +71,43 @@ struct at803x_context {
>   u16 led_control;
>   };
> @@ -120,16 +128,53 @@
>   return 0;
>   }
>   
> +@@ -258,6 +334,8 @@ static int at803x_config_intr(struct phy
> + static void at803x_link_change_notify(struct phy_device *phydev)
> + {
> + struct at803x_priv *priv = phydev->priv;
> ++struct at803x_platform_data *pdata;
> ++pdata = dev_get_platdata(&phydev->dev);
> + 
> + /*
> +  * Conduct a hardware reset for AT8030 every time a link loss is
> +@@ -287,6 +365,26 @@ static void at803x_link_change_notify(st
> + } else {
> + priv->phy_reset = false;
> + }
> ++}
> ++if (pdata->fixup_rgmii_tx_delay &&
> ++phydev->speed != priv->prev_speed) {
> ++switch (phydev->speed) {
> ++case SPEED_10:
> ++case SPEED_100:
> ++at803x_dbg_reg_set(phydev,
> ++AT803X_DEBUG_SYSTEM_MODE_CTRL,
> ++AT803X_DEBUG_RGMII_TX_CLK_DLY);
> ++break;
> ++case SPEED_1000:
> ++at803x_dbg_reg_cl

[OpenWrt-Devel] [PATCH 2/2] ar71xx: add support for TRENDnet TEW-823DRU

2015-06-05 Thread Cezary Jackiewicz 
This is new router from TRENDnet:
- cpu: QCA9558 @720MHz
- flash: 16MB
- ram: 256MB
- 4+1 RJ45 100/1000Mbps
- wifi:  QCA9558 (bgn) and  QCA9880-BR4A (ac)
- 1x USB 2.0

Signed-off-by: Cezary Jackiewicz 
---

diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh
index 0553251..fe3997d 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -206,7 +206,8 @@ get_status_led() {
status_led="trendnet:blue:wps"
;;
tew-712br|\
-   tew-732br)
+   tew-732br|\
+   tew-823dru)
status_led="trendnet:green:power"
;;
tl-mr3020)
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 41b..8466a28 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -283,6 +283,10 @@ tew-732br)
ucidef_set_led_netdev "wan" "WAN" "trendnet:green:wan" "eth1"
;;
 
+tew-823dru)
+   ucidef_set_led_netdev "wan" "WAN" "trendnet:green:planet" "eth0"
+   ;;
+
 tl-mr11u | \
 tl-mr3020 | \
 tl-mr3040 | \
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 f5c6865..907e6aa 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -46,6 +46,7 @@ ap136-010)
 
 ap136-020 |\
 ap135-020 |\
+tew-823dru |\
 tl-wr1043nd-v2 |\
 wzr-450hp2)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index b13be1e..21c599a 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -658,6 +658,9 @@ ar71xx_board_detect() {
*TEW-732BR)
name="tew-732br"
;;
+   *TEW-823DRU)
+   name="tew-823dru"
+   ;;
*"TL-WR1041N v2")
name="tl-wr1041n-v2"
;;
diff --git a/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k 
b/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k
index 88ca1e9..cda76dd 100644
--- a/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k
+++ b/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k
@@ -23,7 +23,7 @@ do_patch_ath10k_firmware() {
 
# some boards have bogus mac in otp, patch the default mac in the 
firmware
case $(ar71xx_board_name) in
-   dgl-5500-a1)
+   dgl-5500-a1 | tew-823dru)
local mac
mac=$(mtd_get_mac_ascii nvram wlan1_mac)
 
@@ -42,7 +42,7 @@ do_patch_ath10k_firmware() {
 
 check_patch_ath10k_firmware() {
case $(ar71xx_board_name) in
-   dgl-5500-a1)
+   dgl-5500-a1 | tew-823dru)
do_patch_ath10k_firmware
;;
esac
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 3dbd91c..3916fe1 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -219,6 +219,7 @@ platform_check_image() {
tew-632brp | \
tew-712br | \
tew-732br | \
+   tew-823dru | \
wrt400n | \
airgateway | \
airrouter | \
diff --git a/target/linux/ar71xx/config-3.18 b/target/linux/ar71xx/config-3.18
index 543b77e..9bd53b5 100644
--- a/target/linux/ar71xx/config-3.18
+++ b/target/linux/ar71xx/config-3.18
@@ -99,6 +99,7 @@ CONFIG_ATH79_MACH_TEW_632BRP=y
 CONFIG_ATH79_MACH_TEW_673GRU=y
 CONFIG_ATH79_MACH_TEW_712BR=y
 CONFIG_ATH79_MACH_TEW_732BR=y
+CONFIG_ATH79_MACH_TEW_823DRU=y
 CONFIG_ATH79_MACH_TL_MR11U=y
 CONFIG_ATH79_MACH_TL_MR13U=y
 CONFIG_ATH79_MACH_TL_MR3020=y
diff --git a/target/linux/ar71xx/generic/profiles/trendnet.mk 
b/target/linux/ar71xx/generic/profiles/trendnet.mk
index 42d05b6..6102e04 100644
--- a/target/linux/ar71xx/generic/profiles/trendnet.mk
+++ b/target/linux/ar71xx/generic/profiles/trendnet.mk
@@ -60,3 +60,15 @@ define Profile/TEW732BR/Description
 endef
 
 $(eval $(call Profile,TEW732BR))
+
+
+define Profile/TEW823DRU
+   NAME:=TRENDNet TEW-823DRU
+   PACKAGES:=kmod-usb-core kmod-usb2 kmod-ath10k
+endef
+
+define Profile/TEW823DRU/Description
+   Package set optimized for the TRENDNet TEW-823DRU.
+endef
+
+$(eval $(call Profile,TEW823DRU))
diff --git a/target/linux/ar71xx/image/Makefile 
b/target/linux/ar71xx/image/Makefile
index 580a640..10f30ec 100644
--- a/target/linux/ar71xx/image/Makefile
+++ b/target/linux/ar71xx/image/Makefile
@@ -937,6 +937,7 @@ 
wnr2200_mtdlayout=mtdparts=spi0.0:256k(u-boot)ro,64k(u-boot-env)ro,7808k(firmwar
 
wnr2000v3_mtdlayout=mtdparts=s

[OpenWrt-Devel] [PATCH 1/2] ar71xx: fix mac offset in firmware file

2015-06-05 Thread Cezary Jackiewicz 
In new firmware-4.bin (for ath10k) mac offset is 0x114 (276), not 0x118 (280).
This also closes #19751, bug introduced in #45624

Signed-off-by: Cezary Jackiewicz 
---

diff --git a/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k 
b/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k
index 88ca1e9..4511162 100644
--- a/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k
+++ b/target/linux/ar71xx/base-files/lib/preinit/82_patch_ath10k
@@ -29,7 +29,7 @@ do_patch_ath10k_firmware() {
 
cp $firmware_file /tmp/ath10k-firmware.bin
macaddr_2bin $mac | dd of=/tmp/ath10k-firmware.bin \
-   conv=notrunc bs=1 seek=280 count=6
+   conv=notrunc bs=1 seek=276 count=6
 
;;
esac


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

Re: [OpenWrt-Devel] [PATCH 2/5] utils: refine calloc_a a bit.

2015-06-05 Thread Felix Fietkau 
On 2015-06-05 17:03, Yousong Zhou wrote:
> 
> On Jun 5, 2015 3:14 PM, "Felix Fietkau"  > wrote:
>>
>> On 2015-06-04 15:41, Yousong Zhou wrote:
>> >  - Return early on calloc() failure.
>> >  - Correct comment text for __calloc_a().
>> >
>> > Signed-off-by: Yousong Zhou  >
>> > ---
>> >  utils.c |4 
>> >  utils.h |6 +++---
>> >  2 files changed, 7 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/utils.c b/utils.c
>> > index 8fd19f4..627b0f6 100644
>> > --- a/utils.c
>> > +++ b/utils.c
>> > @@ -43,6 +43,10 @@ void *__calloc_a(size_t len, ...)
>> >   va_end(ap1);
>> >
>> >   ptr = calloc(1, alloc_len);
>> > + if (!ptr) {
>> > + va_end(ap);
>> > + return NULL;
>> > + }
>> What's the point? The return value without this check will be NULL
>> anyway, and optimizing a rare error case does not seem useful to me.
>>
> 
> rare case indeed, also a trivial change.  null check is for
> correctness.  it also seems to me assigning invalid pointer values to
> output arguments is not right.  well, my 2 cents :)
Well, the way you implemented it, the output argument values will be
undefined, which is not significantly better :)

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

Re: [OpenWrt-Devel] [PATCH 2/5] utils: refine calloc_a a bit.

2015-06-05 Thread Yousong Zhou 
On Jun 5, 2015 3:14 PM, "Felix Fietkau"  wrote:
>
> On 2015-06-04 15:41, Yousong Zhou wrote:
> >  - Return early on calloc() failure.
> >  - Correct comment text for __calloc_a().
> >
> > Signed-off-by: Yousong Zhou 
> > ---
> >  utils.c |4 
> >  utils.h |6 +++---
> >  2 files changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/utils.c b/utils.c
> > index 8fd19f4..627b0f6 100644
> > --- a/utils.c
> > +++ b/utils.c
> > @@ -43,6 +43,10 @@ void *__calloc_a(size_t len, ...)
> >   va_end(ap1);
> >
> >   ptr = calloc(1, alloc_len);
> > + if (!ptr) {
> > + va_end(ap);
> > + return NULL;
> > + }
> What's the point? The return value without this check will be NULL
> anyway, and optimizing a rare error case does not seem useful to me.
>

rare case indeed, also a trivial change.  null check is for correctness.
it also seems to me assigning invalid pointer values to output arguments is
not right.  well, my 2 cents :)

yousong

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

Re: [OpenWrt-Devel] Linux 4.x

2015-06-05 Thread Sedat Dilek 
On Fri, Jun 5, 2015 at 4:00 PM, Baptiste Clenet  wrote:
> Hi OpenWRT developers,
>
> Is there any plan to port OPENWRT on Linux 4.x? (Or is it already done?)
>

Linux v4.0.4 is supported, see...

http://git.openwrt.org/?p=openwrt.git;a=blob;f=include/kernel-version.mk

> Wpan-tools works mainly on bluetooth-next kernel which is base on
> Linux 4.x so it doesn't currently work with OpenWRT.
>

What do you mean by "bluetooth-next"?
Linux v4.1 is at -rc6.
So you mean bluetooth stuff for Linux v4.2?

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

[OpenWrt-Devel] Linux 4.x

2015-06-05 Thread Baptiste Clenet 
Hi OpenWRT developers,

Is there any plan to port OPENWRT on Linux 4.x? (Or is it already done?)



Wpan-tools works mainly on bluetooth-next kernel which is base on
Linux 4.x so it doesn't currently work with OpenWRT.

Cheers,

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

Re: [OpenWrt-Devel] [PATCH] [ 4/5] ramips: add xmit_more support

2015-06-05 Thread Mingyu Li 
this feature i reference tg3.c driver at function tg3_start_xmit.
it says therer is a small possibility that start_xmit will miss it
and cause the queue to be stopped forever.

below is the tg3 drivers code
=== function tg3_tx ===
tnapi->tx_cons = sw_idx;

/* Need to make the tx_cons update visible to tg3_start_xmit()
 * before checking for netif_queue_stopped().  Without the
 * memory barrier, there is a small possibility that
tg3_start_xmit()
 * will miss it and cause the queue to be stopped forever.
 */
smp_mb();

if (unlikely(netif_tx_queue_stopped(txq) &&
 (tg3_tx_avail(tnapi) > TG3_TX_WAKEUP_THRESH(tnapi {
__netif_tx_lock(txq, smp_processor_id());
if (netif_tx_queue_stopped(txq) &&
(tg3_tx_avail(tnapi) > TG3_TX_WAKEUP_THRESH(tnapi)))
netif_tx_wake_queue(txq);
__netif_tx_unlock(txq);
}

=== tg3_start_xmit ===
budget = tg3_tx_avail(tnapi);

/* We are running in BH disabled context with netif_tx_lock
 * and TX reclaim runs via tp->napi.poll inside of a software
 * interrupt.  Furthermore, IRQ processing runs lockless so we have
 * no IRQ context deadlocks to worry about either.  Rejoice!
 */
if (unlikely(budget <= (skb_shinfo(skb)->nr_frags + 1))) {
if (!netif_tx_queue_stopped(txq)) {
netif_tx_stop_queue(txq);

/* This is a hard error, log it. */
netdev_err(dev,
   "BUG! Tx Ring full when queue awake!\n");
}
return NETDEV_TX_BUSY;
}


2015-06-05 16:40 GMT+08:00 Felix Fietkau :

> On 2015-06-02 15:06, michael lee wrote:
> > use pktgen to verify on rt3662. can improve transmit rate.
> > pkt_size 1500
> > burst 1 : 807Mb/sec
> > burst 8 : 984Mb/sec
> >
> > pkt_size 60
> > burst 1 : 57Mb/sec
> > burst 8 : 236Mb/sec
> >
> > Signed-off-by: michael lee 
> > ---
> >  .../drivers/net/ethernet/ralink/ralink_soc_eth.c   | 51
> +-
> >  .../drivers/net/ethernet/ralink/ralink_soc_eth.h   |  2 +
> >  2 files changed, 33 insertions(+), 20 deletions(-)
> >
> > diff --git
> a/target/linux/ramips/files/drivers/net/ethernet/ralink/ralink_soc_eth.c
> b/target/linux/ramips/files/drivers/net/ethernet/ralink/ralink_soc_eth.c
> > index b2304bb..4b39825 100644
> > ---
> a/target/linux/ramips/files/drivers/net/ethernet/ralink/ralink_soc_eth.c
> > +++
> b/target/linux/ramips/files/drivers/net/ethernet/ralink/ralink_soc_eth.c
> > @@ -337,6 +337,8 @@ static int fe_alloc_tx(struct fe_priv *priv)
> >   struct fe_tx_ring *ring = &priv->tx_ring;
> >
> >   ring->tx_free_idx = 0;
> > + ring->tx_next_idx = 0;
> > + ring->tx_thresh = max((unsigned long)ring->tx_ring_size >> 2,
> MAX_SKB_FRAGS);
> >
> >   ring->tx_buf = kcalloc(ring->tx_ring_size, sizeof(*ring->tx_buf),
> >   GFP_KERNEL);
> > @@ -525,8 +527,16 @@ static int fe_vlan_rx_kill_vid(struct net_device
> *dev,
> >   return 0;
> >  }
> >
> > +static inline u32 fe_empty_txd(struct fe_tx_ring *ring)
> > +{
> > + barrier();
> What is this barrier for?
>
> > + return (u32)(ring->tx_ring_size -
> > + ((ring->tx_next_idx - ring->tx_free_idx) &
> > +  (ring->tx_ring_size - 1)));
> > +}
> > +
> >  static int fe_tx_map_dma(struct sk_buff *skb, struct net_device *dev,
> > - int idx, int tx_num, struct fe_tx_ring *ring)
> > + int tx_num, struct fe_tx_ring *ring)
> >  {
> >   struct fe_priv *priv = netdev_priv(dev);
> >   struct skb_frag_struct *frag;
> > @@ -649,14 +659,22 @@ static int fe_tx_map_dma(struct sk_buff *skb,
> struct net_device *dev,
> >   netdev_sent_queue(dev, skb->len);
> >   skb_tx_timestamp(skb);
> >
> > - j = NEXT_TX_DESP_IDX(j);
> > + ring->tx_next_idx = NEXT_TX_DESP_IDX(j);
> >   wmb();
> > - fe_reg_w32(j, FE_REG_TX_CTX_IDX0);
> > + if (unlikely(fe_empty_txd(ring) <= ring->tx_thresh)) {
> > + netif_stop_queue(dev);
> > + smp_mb();
> > + if (unlikely(fe_empty_txd(ring) > ring->tx_thresh))
> > + netif_wake_queue(dev);
> Why do that queue wake check here, when it's already being done during
> tx cleanup.
>
> > + }
> > +
> > + if (netif_xmit_stopped(netdev_get_tx_queue(dev, 0)) ||
> !skb->xmit_more)
> > + fe_reg_w32(ring->tx_next_idx, FE_REG_TX_CTX_IDX0);
> >
> >   return 0;
> >
> >  err_dma:
> > - j = idx;
> > + j = ring->tx_next_idx;
> >   for (i = 0; i < tx_num; i++) {
> >   ptxd = &ring->tx_dma[j];
> >   tx_buf = &ring->tx_buf[j];
>
> - Felix
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/list

Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info

2015-06-05 Thread Martin Blumenstingl 
On Fri, Jun 5, 2015 at 4:56 AM, Aleksander Wałęski  wrote:
> Try playing with /etc/init.d/dsl_control when you'll have a moment to
> spare to see if all parameters it passes to control application are
> necessary. Selecting between ADSL and VDSL may be necessary but
> firmware for ADSL seems to be annex-specific and I think that each
> step we can make towards simplifying configuration will be welcomed.
I'm hoping to have time for this on Saturday, because starting on
Monday my connection will be upgraded to VDSL.

For your own tests: please make sure you restart the device every time
you change /etc/init.d/dsl_control. At least the old driver (4.11.4) didn't
allow changing some values (after vdsl_cpe_control passed the values
to the kernel driver, it silently ignored any change to those values).


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

Re: [OpenWrt-Devel] [PATCH] [ 4/5] ramips: add xmit_more support

2015-06-05 Thread Felix Fietkau 
On 2015-06-02 15:06, michael lee wrote:
> use pktgen to verify on rt3662. can improve transmit rate.
> pkt_size 1500
> burst 1 : 807Mb/sec
> burst 8 : 984Mb/sec
> 
> pkt_size 60
> burst 1 : 57Mb/sec
> burst 8 : 236Mb/sec
> 
> Signed-off-by: michael lee 
> ---
>  .../drivers/net/ethernet/ralink/ralink_soc_eth.c   | 51 
> +-
>  .../drivers/net/ethernet/ralink/ralink_soc_eth.h   |  2 +
>  2 files changed, 33 insertions(+), 20 deletions(-)
> 
> diff --git 
> a/target/linux/ramips/files/drivers/net/ethernet/ralink/ralink_soc_eth.c 
> b/target/linux/ramips/files/drivers/net/ethernet/ralink/ralink_soc_eth.c
> index b2304bb..4b39825 100644
> --- a/target/linux/ramips/files/drivers/net/ethernet/ralink/ralink_soc_eth.c
> +++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/ralink_soc_eth.c
> @@ -337,6 +337,8 @@ static int fe_alloc_tx(struct fe_priv *priv)
>   struct fe_tx_ring *ring = &priv->tx_ring;
>  
>   ring->tx_free_idx = 0;
> + ring->tx_next_idx = 0;
> + ring->tx_thresh = max((unsigned long)ring->tx_ring_size >> 2, 
> MAX_SKB_FRAGS);
>  
>   ring->tx_buf = kcalloc(ring->tx_ring_size, sizeof(*ring->tx_buf),
>   GFP_KERNEL);
> @@ -525,8 +527,16 @@ static int fe_vlan_rx_kill_vid(struct net_device *dev,
>   return 0;
>  }
>  
> +static inline u32 fe_empty_txd(struct fe_tx_ring *ring)
> +{
> + barrier();
What is this barrier for?

> + return (u32)(ring->tx_ring_size -
> + ((ring->tx_next_idx - ring->tx_free_idx) &
> +  (ring->tx_ring_size - 1)));
> +}
> +
>  static int fe_tx_map_dma(struct sk_buff *skb, struct net_device *dev,
> - int idx, int tx_num, struct fe_tx_ring *ring)
> + int tx_num, struct fe_tx_ring *ring)
>  {
>   struct fe_priv *priv = netdev_priv(dev);
>   struct skb_frag_struct *frag;
> @@ -649,14 +659,22 @@ static int fe_tx_map_dma(struct sk_buff *skb, struct 
> net_device *dev,
>   netdev_sent_queue(dev, skb->len);
>   skb_tx_timestamp(skb);
>  
> - j = NEXT_TX_DESP_IDX(j);
> + ring->tx_next_idx = NEXT_TX_DESP_IDX(j);
>   wmb();
> - fe_reg_w32(j, FE_REG_TX_CTX_IDX0);
> + if (unlikely(fe_empty_txd(ring) <= ring->tx_thresh)) {
> + netif_stop_queue(dev);
> + smp_mb();
> + if (unlikely(fe_empty_txd(ring) > ring->tx_thresh))
> + netif_wake_queue(dev);
Why do that queue wake check here, when it's already being done during
tx cleanup.

> + }
> +
> + if (netif_xmit_stopped(netdev_get_tx_queue(dev, 0)) || !skb->xmit_more)
> + fe_reg_w32(ring->tx_next_idx, FE_REG_TX_CTX_IDX0);
>  
>   return 0;
>  
>  err_dma:
> - j = idx;
> + j = ring->tx_next_idx;
>   for (i = 0; i < tx_num; i++) {
>   ptxd = &ring->tx_dma[j];
>   tx_buf = &ring->tx_buf[j];

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

Re: [OpenWrt-Devel] [PATCH 4/4] ralink: firewrt support memory detect

2015-06-05 Thread Felix Fietkau 
On 2015-06-05 09:54, w...@t-chip.com.cn wrote:
> Dear sir:
> 
> i got it.
> please ignore the 2 patches i have send this morning .
> i will try again and give you more detail.
I now implemented the highmem offset change that I mentioned in my last
email and added your memory map fix. It is working well in my test.

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

[OpenWrt-Devel] [PATCH] [RFC] b53: widen stp state mask to 3 bits (instead of 2)

2015-06-05 Thread Alexandru Ardelean 
At least on my b53 chip, the mask is 3 bits wide, and because
of this some STP states are not set properly and discarded when read.

Maybe for some other chips it makes sense to have just 2 bits width,
but I don't have other versions around to test/validate.

If that's the case then maybe we could add another STP state mask.

Signed-off-by: Alexandru Ardelean 
---
 target/linux/generic/files/drivers/net/phy/b53/b53_regs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h 
b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h
index eef5c81..144e1c8 100644
--- a/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h
+++ b/target/linux/generic/files/drivers/net/phy/b53/b53_regs.h
@@ -65,7 +65,7 @@
 #define   PORT_CTRL_RX_MCST_EN BIT(3) /* Multicast RX (P8 only) */
 #define   PORT_CTRL_RX_UCST_EN BIT(4) /* Unicast RX (P8 only) */
 #define  PORT_CTRL_STP_STATE_S 5
-#define   PORT_CTRL_STP_STATE_MASK (0x3 << PORT_CTRL_STP_STATE_S)
+#define   PORT_CTRL_STP_STATE_MASK (0x7 << PORT_CTRL_STP_STATE_S)
 
 /* SMP Control Register (8 bit) */
 #define B53_SMP_CTRL   0x0a
-- 
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 4/4] ralink: firewrt support memory detect

2015-06-05 Thread Felix Fietkau 
On 2015-06-05 09:30, w...@t-chip.com.cn wrote:
> Dear sir:
> I believe that it will work well on other 256mb memory board .
> 
> But FireWRT has 512mb memory .
> I am confuse that enable HIGHMEM is not for using 512mb memory ? 
I'm running my code on the FireWRT board with 512M.
I ran memtester with 465M (biggest mmap it could do without causing OOM).

> Why enable HIGHMEM without using long jump .
kmalloc will only return allocations from low-memory space. As long as
the first 256M are low-mem and the second 256M are high-mem, no
long-jump is needed.

I have another idea for adjusting the code to the memory map you
provided without using long-jump. I'm going to change the highmem start
offset from 0x2000 to 0x1000, that way module allocations will
always fit in the 256M boundary.

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

Re: [OpenWrt-Devel] [PATCH 2/5] utils: refine calloc_a a bit.

2015-06-05 Thread Felix Fietkau 
On 2015-06-04 15:41, Yousong Zhou wrote:
>  - Return early on calloc() failure.
>  - Correct comment text for __calloc_a().
> 
> Signed-off-by: Yousong Zhou 
> ---
>  utils.c |4 
>  utils.h |6 +++---
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/utils.c b/utils.c
> index 8fd19f4..627b0f6 100644
> --- a/utils.c
> +++ b/utils.c
> @@ -43,6 +43,10 @@ void *__calloc_a(size_t len, ...)
>   va_end(ap1);
>  
>   ptr = calloc(1, alloc_len);
> + if (!ptr) {
> + va_end(ap);
> + return NULL;
> + }
What's the point? The return value without this check will be NULL
anyway, and optimizing a rare error case does not seem useful to me.

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

Re: [OpenWrt-Devel] [PATCH 4/4] ralink: firewrt support memory detect

2015-06-05 Thread Felix Fietkau 
On 2015-06-05 08:16, w...@t-chip.com.cn wrote:
> Dear sir:
> it not working on my board .
Please provide details.

> The memory map is not correct. and you forget to using long jump.
In my tests, I found that the window at 0x2000 is bigger than
documented in the datasheet. I'm not entirely sure about how it is
routed in the hardware, maybe I need to add a 64M offset to account for
the re-map, but I did run memtester for a while with the biggest memory
size I could use, and it did not print any errors.

Since I use only 256M low-mem, the long-jump is not necessary.

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