Re: [LEDE-DEV] [PATCH] This patch adds support for the Netgear WN3000RPv3 N300 repeater.

2017-01-18 Thread Mathias Kresin 

Hey Thibaut,

see my comment inline.

Mathias

17.01.2017 23:12, ha...@slashdirt.org:

From: Thibaut VARENE 

It uses the same trick as for the EX2700 to pass the Second Part
Magic Check from the bootloader (as described here
https://forum.openwrt.org/viewtopic.php?pid=312577#p312577 )

Specifications:
- SoC: MediaTek MT7620A (580MHz, ramips)
- RAM: 32MB
- Storage: 8MB NOR SPI flash
- Wireless: builtin MT7620A
- Ethernet: 1x100M

Stock firmware is based on OpenWRT Kamikaze snapshot. To install
LEDE, use the factory.bin image. Once LEDE is installed, subsequent
updates can use the sysupgrade.bin image.

Signed-off-by: Thibaut VARENE 
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   3 +-
 .../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 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/WN3000RPV3.dts | 148 +
 target/linux/ramips/image/mt7620.mk|  11 ++
 7 files changed, 168 insertions(+), 2 deletions(-)
 create mode 100644 target/linux/ramips/dts/WN3000RPV3.dts

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 3d3aa0a..545d6a4 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -155,7 +155,8 @@ vr500)
 dir-860l-b1)
ucidef_set_led_netdev "wan" "wan" "$board:green:net" "eth0.2"
;;
-ex2700)
+ex2700|\
+wn3000rpv3)
ucidef_set_led_default "power_r" "POWER (red)" "$board:red:power" "0"
set_wifi_led "$board:green:router"
;;
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 baf619f..4c94fba 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -58,6 +58,7 @@ ramips_setup_interfaces()
timecloud|\
w150m|\
widora-neo|\
+   wn3000rpv3|\
wnce2001|\
zbt-cpe102|\
zte-q7)
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 5367e65..9499833 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -53,7 +53,8 @@ get_status_led() {
jhr-n825r|\
mpr-a1|\
mpr-a2|\
-   mzk-ex750np)
+   mzk-ex750np|\
+   wn3000rpv3)
status_led="$board:red:power"


Any specific reason why you are using the red led here? I mean, you are 
switching on the green led already in the dts and red is at least for me 
some kind of warning signal, which I would not expect to see if 
everything is fine.


If you decide to use the green led, you can remove the red power off led 
from /etc/board.d/01_leds.




;;
ac1200pro|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 6afe709..8292da1 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -553,6 +553,9 @@ ramips_board_detect() {
*"WMR-300")
name="wmr-300"
;;
+   *"WN3000RPv3")
+   name="wn3000rpv3"
+   ;;
*"WNCE2001")
name="wnce2001"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 0f2510c..c6ad8ca 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -157,6 +157,7 @@ platform_check_image() {
wli-tx4-ag300n|\
wlr-6000|\
wmr-300|\
+   wn3000rpv3|\
wnce2001|\
wndr3700v5|\
wr512-3gn|\
diff --git a/target/linux/ramips/dts/WN3000RPV3.dts 
b/target/linux/ramips/dts/WN3000RPV3.dts
new file mode 100644
index 000..8dc4249
--- /dev/null
+++ b/target/linux/ramips/dts/WN3000RPV3.dts
@@ -0,0 +1,148 @@
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+


Please include  here as well.

Use the GPIO_ACTIVE_LOW and GPIO_ACTIVE_HIGH macros afterwards in stead 
of 1 and 0 in the gpio parameters.


Check the recent ramips board additions for examples.


+#include 
+
+/ {
+   compatible = "ralink,mt7620a-soc";
+   model = "Netgear WN3000RPv3";
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   power_g {
+   label = "wn3000rpv3:green:power";
+   gpios = <&gpio0 9 1>;
+   default-state = "on";
+   };
+
+   power_r {
+   label = "wn3000rpv3:red:power";
+   gpios = <&gpio0 11 1

[LEDE-DEV] [PATCH V2] ar71xx: mark soft_config mtd part as writeable for RB-941-2nD

2017-01-18 Thread hacks 
From: Thibaut VARENE 

The soft_config partition must be writeable for rbcfg to be able to
enact changes to the routerboot configuration.
The read-only flag was a mistake in the initial patch. Removing it
brings mach-rb941.c in line with all other RB platforms.

Signed-off-by: Thibaut VARENE 
---
 target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c
index 5a8c7c0..5da950b 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-rb941.c
@@ -99,7 +99,6 @@ static struct mtd_partition rb941_spi_partitions[] = {
 .name = "soft_config",
 .offset = RB_SOFT_CFG_OFFSET,
 .size = RB_SOFT_CFG_SIZE,
-.mask_flags = MTD_WRITEABLE,
 }, {
 .name = "rootfs",
 .offset = RB_ROOTFS_OFFSET,
-- 
2.1.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] This patch adds support for the Netgear WN3000RPv3 N300 repeater.

2017-01-18 Thread Thibaut 
Hi,

> Le 18 janv. 2017 à 09:05, Mathias Kresin  a écrit :
> 
> Hey Thibaut,
> 
> see my comment inline.
> 
> Mathias
> 
> 17.01.2017 23:12, ha...@slashdirt.org:

>> --- a/target/linux/ramips/base-files/etc/diag.sh
>> +++ b/target/linux/ramips/base-files/etc/diag.sh
>> @@ -53,7 +53,8 @@ get_status_led() {
>>  jhr-n825r|\
>>  mpr-a1|\
>>  mpr-a2|\
>> -mzk-ex750np)
>> +mzk-ex750np|\
>> +wn3000rpv3)
>>  status_led="$board:red:power"
> 
> Any specific reason why you are using the red led here? I mean, you are 
> switching on the green led already in the dts and red is at least for me some 
> kind of warning signal, which I would not expect to see if everything is fine.

Yes, this is to match stock firmware’s behavior:

This is a dual-color led. At power on, the boot loader brings both LEDs on, 
giving an orange status color. During boot up, LEDE will signal the boot / 
failsafe by blinking the red led, giving an orange-green blink. After boot is 
completed, the red LED is turned off to give a solid green.

> If you decide to use the green led, you can remove the red power off led from 
> /etc/board.d/01_leds.

I think it’s fine the way it is. It also matches the EX2700 setup which is a 
very similar device.

>> --- /dev/null
>> +++ b/target/linux/ramips/dts/WN3000RPV3.dts
>> @@ -0,0 +1,148 @@
>> +/dts-v1/;
>> +
>> +#include "mt7620a.dtsi"
>> +
> 
> Please include  here as well.
> 
> Use the GPIO_ACTIVE_LOW and GPIO_ACTIVE_HIGH macros afterwards in stead of 1 
> and 0 in the gpio parameters.
> 
> Check the recent ramips board additions for examples.

Done.

>> +
>> +l_arrow {
>> +label = "wn3000rpv3:blue:l_arrow";
> 
> I guess it would be more clear to use leftarrow and rightarrow here instead 
> of abbreviations.

Done.

>> +gpios = <&gpio0 7 1>;
>> +};
>> +
>> +r_arrow {
>> +label = "wn3000rpv3:blue:r_arrow";
>> +gpios = <&gpio0 8 1>;
>> +};
>> +};
>> +
>> +gpio-keys-polled {
>> +compatible = "gpio-keys-polled";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +poll-interval = <20>;
>> +
>> +reset {
>> +label = "reset";
>> +gpios = <&gpio0 1 1>;
>> +linux,code = ;
>> +};
>> +
>> +wps {
>> +label = "wps";
>> +gpios = <&gpio0 2 1>;
>> +linux,code = ;
>> +};
>> +};
>> +};
>> +
>> +&gpio0 {
>> +status = "okay";
>> +};
> 
> It should be safe to drop the gpio0 node. It should be already enabled in the 
> mt7620a.dtsi.

Done.

>> +
>> +&gpio1 {
>> +status = "okay";
>> +};
>> +
>> +&spi0 {
>> +status = "okay";
>> +
>> +m25p80@0 {
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +compatible = "jedec,spi-nor";
>> +reg = <0>;
>> +linux,modalias = "m25p80", "mx25l6405d";
> 
> Drop the linux,modalias line. It was only required for kernel < 4.4.

Done.

>> +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;
>> +};
>> +
>> +partition@4 {
>> +label = "firmware";
>> +reg = <0x4 0x7b>;
>> +};
>> +
>> +art: partition@7f {
>> +label = "art";
>> +reg = <0x7f 0x1>;
>> +read-only;
>> +};
>> +};
>> +};
>> +
>> +ðernet {
>> +mtd-mac-address = <&art 0x0>;
>> +};
>> +
>> +&wmac {
>> +mtd-mac-address = <&art 0x6>;
>> +ralink,mtd-eeprom = <&art 0x1000>;
>> +};
>> +
>> +&pinctrl {
>> +state_default: pinctrl0 {
>> +default {
>> +//  spi refclk: pins 37, 38, 39
>> +//   uartf: pins 8, 9, 10, 11, 12, 13, 14
>> +// i2c: pins 1, 2
> 
> Remove the comments. If they are important, add the information to the commit 
> message.

Done.

Thanks.

Thibaut
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH V2] ramips: add support for Netgear WN3000RPv3

2017-01-18 Thread hacks 
From: Thibaut VARENE 

This patch adds support for the Netgear WN3000RPv3
http://www.netgear.com/support/product/wn3000rpv3.aspx

Specifications:
- SoC: MediaTek MT7620A (580MHz, ramips)
- RAM: 32MB DDR
- Storage: 8MB NOR SPI flash
- Wireless: builtin MT7620A, 2x2:2 with u.FL connectors
- Ethernet: 1x100M
- Serial: JP1 header, 57600-8N1
- Stock firmware based on OpenWRT Kamikaze

Like the EX2700, the bootloader expects a secondary image signature,
see https://forum.openwrt.org/viewtopic.php?pid=312577#p312577
This is why the same fakeroot image is used for the WN3000

Signed-off-by: Thibaut VARENE 
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   3 +-
 .../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 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/WN3000RPV3.dts | 143 +
 target/linux/ramips/image/mt7620.mk|  11 ++
 7 files changed, 163 insertions(+), 2 deletions(-)
 create mode 100644 target/linux/ramips/dts/WN3000RPV3.dts

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 3d3aa0a..545d6a4 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -155,7 +155,8 @@ vr500)
 dir-860l-b1)
ucidef_set_led_netdev "wan" "wan" "$board:green:net" "eth0.2"
;;
-ex2700)
+ex2700|\
+wn3000rpv3)
ucidef_set_led_default "power_r" "POWER (red)" "$board:red:power" "0"
set_wifi_led "$board:green:router"
;;
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 baf619f..4c94fba 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -58,6 +58,7 @@ ramips_setup_interfaces()
timecloud|\
w150m|\
widora-neo|\
+   wn3000rpv3|\
wnce2001|\
zbt-cpe102|\
zte-q7)
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 5367e65..9499833 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -53,7 +53,8 @@ get_status_led() {
jhr-n825r|\
mpr-a1|\
mpr-a2|\
-   mzk-ex750np)
+   mzk-ex750np|\
+   wn3000rpv3)
status_led="$board:red:power"
;;
ac1200pro|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 6afe709..8292da1 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -553,6 +553,9 @@ ramips_board_detect() {
*"WMR-300")
name="wmr-300"
;;
+   *"WN3000RPv3")
+   name="wn3000rpv3"
+   ;;
*"WNCE2001")
name="wnce2001"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 0f2510c..c6ad8ca 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -157,6 +157,7 @@ platform_check_image() {
wli-tx4-ag300n|\
wlr-6000|\
wmr-300|\
+   wn3000rpv3|\
wnce2001|\
wndr3700v5|\
wr512-3gn|\
diff --git a/target/linux/ramips/dts/WN3000RPV3.dts 
b/target/linux/ramips/dts/WN3000RPV3.dts
new file mode 100644
index 000..deebfd0
--- /dev/null
+++ b/target/linux/ramips/dts/WN3000RPV3.dts
@@ -0,0 +1,143 @@
+/* This file is released into the public domain */
+
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "ralink,mt7620a-soc";
+   model = "Netgear WN3000RPv3";
+
+   chosen {
+   bootargs = "console=ttyS0,57600";
+   };
+
+   gpio-leds {
+   compatible = "gpio-leds";
+
+   power_g {
+   label = "wn3000rpv3:green:power";
+   gpios = <&gpio0 9 GPIO_ACTIVE_LOW>;
+   default-state = "on";
+   };
+
+   power_r {
+   label = "wn3000rpv3:red:power";
+   gpios = <&gpio0 11 GPIO_ACTIVE_LOW>;
+   };
+
+   client_g {
+   label = "wn3000rpv3:green:client";
+   gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
+   };
+
+   client_r {
+   label = "wn3000rpv3:red:client";
+   gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
+   };
+
+   router_g {
+   label = "wn3000rpv3:green:router";
+   gpios = <&gpio0

[LEDE-DEV] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

2017-01-18 Thread Daniel Golle 
Hi!

In preparation to be submitted upstream I started to clean up a huge
pile of patches for rt2x00 we have been carrying along for quite a
while (some for more than half a decade!).
Some of them are fixes, most importantly Serge Vasilugin fixed setting
the HT20/HT40 filter which got us much closer to the expected
performance when using HT40 modes.

And also a lot of new added hardware support:
Gabor Juhos wrote code for Rt3883 WiSoC.
Daniel Golle implemented support for Rt3352 by designs with external PA
as well as for boards using a 20MHz crystal instead of the usual 40MHz.
Serge Vasilugin contributed support for the Rt5350 WiSoC.
Michel Stempin, Felix Fietkau and John Crispin have been helping with
cleaning up things and putting away legal doubts.

Please review and comment, so we can get those patches merged!


Cheers


Daniel


The following changes since commit cc75c577806a53893122829d91cb122b51643a2d:

  mwifiex: get rid of global save_adapter and sdio_work (2017-01-12 16:49:18 
+0200)

are available in the git repository at:

  https://github.com/dangowrt/linux.git rt2x00-from-openwrt

for you to fetch changes up to fb8832d1896475059c964c75ab4baaf94199143c:

  rt2x00: fix WARN_ON_ONCE() caused by inbalanced set/clear of beacon enable 
bit (2017-01-13 04:17:57 +0100)


Claudio Mignanti (1):
  rt2x00: rt2x00pci: set PCI MWI only if supported

Daniel Golle (2):
  rt2x00: support for for RT3352 with external PA
  rt2x00: add support for RT3352 with 20MHz crystal

Felix Fietkau (1):
  rt2x00: fix rf id for RT3352

Gabor Juhos (34):
  rt2x00: rt2800lib: move rt2800_drv_data declaration into rt2800lib.h
  rt2x00: rt2800lib: introduce RT2800_HAS_HIGH_SHARED_MEM flag
  rt2x00: rt2800: serialize shared memory access
  rt2x00: rt2800lib: fix beacon generation on RT3593
  rt2x00: rt2800lib: add hw_beacon_count field to struct rt2800_drv_data
  rt2x00: rt2800lib: init additional beacon offset registers
  rt2x00: rt2800lib: fix max supported beacon count for RT3593
  rt2x00: allow to build rt2800soc module for RT3883
  rt2x00: rt2800lib: enable support for RT3883
  rt2x00: rt2800lib: add rf_vals for RF3853
  rt2x00: rt2800lib: enable VCO calibration for RF3853
  rt2x00: rt2800lib: add channel configuration function for RF3853
  rt2x00: rt2800lib: enable RF3853 support
  rt2x00: rt2800lib: add MAC register initialization for RT3883
  rt2x00: rt2800soc: fix rt2800soc_disable_radio for RT3883
  rt2x00: rt2800lib: add BBP register initialization for RT3883
  rt2x00: rt2800lib: add RFCSR initialization for RT3883
  rt2x00: rt2800lib: use the extended EEPROM map for RT3883
  rt2x00: rt2800lib: force rf type to RF3853 on RT3883
  rt2x00: rt2800lib: add channel configuration code for RT3883
  rt2x00: rt2800lib: fix txpower_to_dev function for RT3883
  rt2x00: rt2800lib: use correct txpower calculation function for RT3883
  rt2x00: rt2800lib: hardcode txmixer gain values to zero for RT3883
  rt2x00: rt2800lib: use correct [RT]XWI size for RT3883
  rt2x00: rt2800lib: use correct beacon base for RT3883
  rt2x00: rt2800lib: use correct beacon count for RT3883
  rt2x00: rt2800lib: fix antenna configuration for RT3883
  rt2x00: rt2800lib: fix LNA gain configuration for RT3883
  rt2x00: rt2800lib: fix VGC setup for RT3883
  rt2x00: rt2800lib: fix EEPROM LNA validation for RT3883
  rt2x00: rt2800lib: fix txpower compensation for RT3883
  rt2x00: rt2800lib: enable RT2800_HAS_HIGH_SHARED_MEM for RT3883
  rt2x00: rt2800lib: use high memory for beacons on RT3883
  rt2x00: rt2800mmio: add a workaround for spurious TX_FIFO_STATUS 
interrupts

Michel Stempin (1):
  rt2x00: add support for RT5350 WiSoC

Serge Vasilugin (1):
  rt2x00 correctly set ht20/ht40 filter

evaxige (1):
  rt2x00: fix WARN_ON_ONCE() caused by inbalanced set/clear of beacon 
enable bit

 drivers/net/wireless/ralink/rt2x00/Kconfig  |2 +-
 drivers/net/wireless/ralink/rt2x00/rt2800.h |   79 +-
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c  | 1006 ++-
 drivers/net/wireless/ralink/rt2x00/rt2800lib.h  |   63 ++
 drivers/net/wireless/ralink/rt2x00/rt2800mmio.c |   98 ++-
 drivers/net/wireless/ralink/rt2x00/rt2800mmio.h |4 +
 drivers/net/wireless/ralink/rt2x00/rt2800pci.c  |   14 +
 drivers/net/wireless/ralink/rt2x00/rt2800soc.c  |   12 +-
 drivers/net/wireless/ralink/rt2x00/rt2800usb.c  |   31 +
 drivers/net/wireless/ralink/rt2x00/rt2x00.h |   10 +
 drivers/net/wireless/ralink/rt2x00/rt2x00dev.c  |7 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00mac.c  |8 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00pci.c  |2 +
 13 files changed, 1254 insertions(+), 82 deletions(-)

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailm

Re: [LEDE-DEV] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

2017-01-18 Thread Kalle Valo 
Daniel Golle  writes:

> In preparation to be submitted upstream I started to clean up a huge
> pile of patches for rt2x00 we have been carrying along for quite a
> while (some for more than half a decade!).
> Some of them are fixes, most importantly Serge Vasilugin fixed setting
> the HT20/HT40 filter which got us much closer to the expected
> performance when using HT40 modes.
>
> And also a lot of new added hardware support:
> Gabor Juhos wrote code for Rt3883 WiSoC.
> Daniel Golle implemented support for Rt3352 by designs with external PA
> as well as for boards using a 20MHz crystal instead of the usual 40MHz.
> Serge Vasilugin contributed support for the Rt5350 WiSoC.
> Michel Stempin, Felix Fietkau and John Crispin have been helping with
> cleaning up things and putting away legal doubts.
>
> Please review and comment, so we can get those patches merged!

No pull requests, please. Instead send these as patches, easier to
review and actually also easier for me to merge.

-- 
Kalle Valo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

2017-01-18 Thread Johannes Berg 

> The advantage of pull requests is that author information can be
> preserved more easily. Running git format-patch results in most
> patches
> having wrong SMTP sender information due to the assumption that the
> patch author is the same person also submitting the patch.
> So in practise, this would either require changing the From: (and
> thus
> Author) to myself or having most mails eaten by anti-spam measures
> due
> to non-matching SPF which prohibits my SMTP to send mail on behalf of
> the original authors of the patches.
> 

This is completely untrue. If the first line of the *body* of the email
is "From: ..." then this is preserved as the author information by git
am, and doing so is also the default in git format-patch/send-email
when the author doesn't match the email configuration.

johannes

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

2017-01-18 Thread Stanislaw Gruszka 
Hi

On Fri, Jan 13, 2017 at 04:50:32AM +0100, Daniel Golle wrote:
> Please review and comment, so we can get those patches merged!

As already pointed by Kalle posting patches to mailing list is better
way for review. Posing patches is easy with git-format-patch and
git-send-email. Ideally patch series should not be long, let say no more
than 30 patches - I suggest to split this into two series: second one
for RT3853 support and first one for other patches.

> evaxige (1):
>   rt2x00: fix WARN_ON_ONCE() caused by inbalanced set/clear of beacon 
> enable bit

I think I would prefer to remove:

WARN_ON_ONCE(bcn_num != rt2x00dev->intf_beaconing);

line instead of this patch. Other patches looks ok after quick glance.
I think you can post them as normal PATCH in the topic (not as RFC).

Thanks
Stanislaw

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

2017-01-18 Thread Daniel Golle 
Hi Kalle,

On Fri, Jan 13, 2017 at 12:46:56PM +0200, Kalle Valo wrote:
> Daniel Golle  writes:
> > ...
> > Please review and comment, so we can get those patches merged!
> 
> No pull requests, please. Instead send these as patches, easier to
> review and actually also easier for me to merge.

The advantage of pull requests is that author information can be
preserved more easily. Running git format-patch results in most patches
having wrong SMTP sender information due to the assumption that the
patch author is the same person also submitting the patch.
So in practise, this would either require changing the From: (and thus
Author) to myself or having most mails eaten by anti-spam measures due
to non-matching SPF which prohibits my SMTP to send mail on behalf of
the original authors of the patches.

How do you suggest to handle this situation?


Cheers


Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

2017-01-18 Thread Daniel Golle 
On Fri, Jan 13, 2017 at 04:59:59PM +0100, Johannes Berg wrote:
> 
> > The advantage of pull requests is that author information can be
> > preserved more easily. Running git format-patch results in most
> > patches
> > having wrong SMTP sender information due to the assumption that the
> > patch author is the same person also submitting the patch.
> > So in practise, this would either require changing the From: (and
> > thus
> > Author) to myself or having most mails eaten by anti-spam measures
> > due
> > to non-matching SPF which prohibits my SMTP to send mail on behalf of
> > the original authors of the patches.
> > 
> 
> This is completely untrue. If the first line of the *body* of the email
> is "From: ..." then this is preserved as the author information by git
> am, and doing so is also the default in git format-patch/send-email
> when the author doesn't match the email configuration.

Thanks for the clarification, I'll then submit the patches via
git format-patch.

Cheers

Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

2017-01-18 Thread Christian Lamparter via Lede-dev 
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
On Friday, January 13, 2017 4:46:30 PM CET Daniel Golle wrote:
> On Fri, Jan 13, 2017 at 12:46:56PM +0200, Kalle Valo wrote:
> > Daniel Golle  writes:
> > > ...
> > > Please review and comment, so we can get those patches merged!
> > 
> > No pull requests, please. Instead send these as patches, easier to
> > review and actually also easier for me to merge.
> 
> The advantage of pull requests is that author information can be
> preserved more easily. Running git format-patch results in most patches
> having wrong SMTP sender information due to the assumption that the
> patch author is the same person also submitting the patch.
> So in practise, this would either require changing the From: (and thus
> Author) to myself or having most mails eaten by anti-spam measures due
> to non-matching SPF which prohibits my SMTP to send mail on behalf of
> the original authors of the patches.
> 
> How do you suggest to handle this situation?
> 
>From what I know, git format-patch and send-email [0] will add a second
FROM: in the email's body with the author of the commit automatically
(if author isn't you). This is what it did, when I posted the apm821xx
patches on lede-dev [1] (Look at the additional "FROM: Chris Blake ..."
line in these patches. Whereas the mail came from my address).

The MTA (MDA, ...) will use the first FROM: (your address) whereas git will
use the FROM in the mail body (so the patch will be correctly attributed to
the original patch author). If you don't want to bother the original
authors, you can look at the --suppress-cc=author option and enable --dry-run
on git send-email.

I would say, just give it a "dry".
(Sadly, I didn't find any documentation for this feature.
But I know it worked back then and it should be fine with SPF.)

Regards,
Christian

[0] 
[1] 

--- End Message ---
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

2017-01-18 Thread Kalle Valo 
Stanislaw Gruszka  writes:

> Hi
>
> On Fri, Jan 13, 2017 at 04:50:32AM +0100, Daniel Golle wrote:
>> Please review and comment, so we can get those patches merged!
>
> As already pointed by Kalle posting patches to mailing list is better
> way for review. Posing patches is easy with git-format-patch and
> git-send-email. Ideally patch series should not be long, let say no more
> than 30 patches - I suggest to split this into two series: second one
> for RT3853 support and first one for other patches.

Even 30 patches in a set is quite a lot. I think the pain point is
somewhere about 10-12 patches, anything longer than that and most people
lost interest looking at the patches in detail.

-- 
Kalle Valo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

2017-01-18 Thread Daniel Golle 
On Fri, Jan 13, 2017 at 05:17:23PM +0100, Daniel Golle wrote:
> On Fri, Jan 13, 2017 at 04:59:59PM +0100, Johannes Berg wrote:
> > 
> > > The advantage of pull requests is that author information can be
> > > preserved more easily. Running git format-patch results in most
> > > patches
> > > having wrong SMTP sender information due to the assumption that the
> > > patch author is the same person also submitting the patch.
> > > So in practise, this would either require changing the From: (and
> > > thus
> > > Author) to myself or having most mails eaten by anti-spam measures
> > > due
> > > to non-matching SPF which prohibits my SMTP to send mail on behalf of
> > > the original authors of the patches.
> > > 
> > 
> > This is completely untrue. If the first line of the *body* of the email
> > is "From: ..." then this is preserved as the author information by git
> > am, and doing so is also the default in git format-patch/send-email
> > when the author doesn't match the email configuration.
> 
> Thanks for the clarification, I'll then submit the patches via
> git format-patch.

I posted all patches on the mailing list and bundled them up on
patchwork.
https://patchwork.kernel.org/bundle/dangole/rt2x00-from-openwrt/

Cheers


Daniel

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Syslog-ng Makefile typo

2017-01-18 Thread Philip Prindeville 
I was going to submit a fix myself but while you’re making changes...

One thing I did notice is that MUSL does openlog() as a DGRAM socket, but 
syslog-ng currently opens a STREAM socket (in files/syslog-ng.conf).  Can you 
please change the unix-stream() to unix-gram() instead?

Thanks.



> On Jan 18, 2017, at 12:35 AM, Milan Kočvara  wrote:
> 
> Hello,
> 
> Sorry for miss and late. Changes bellow. I do not found any other 
> "depracated" function. One question about klogd and syslog-ng kernel 
> messagess. On Linux, the klogd daemon can be used in addition to syslog-ng to 
> read kernel messages and forward them to syslog-ng. klogd used to preprocess 
> kernel messages to resolve symbols and so on, but as this is deprecated by 
> ksymoops there is really no point in running both klogd and syslog-ng in 
> parallel. Also note that running two processes reading /proc/kmsg at the same 
> time might result in dead-locks. < Taken from manpage of syslog-ng. In 
> LEDE/OpenWRT is klogd part of busybox in default.
> 
> Thanks
> 
> 
> --- syslog-ng.conf-orig 2017-01-18 07:36:35.941285583 +0100
> +++ syslog-ng.conf  2017-01-18 08:30:30.416247478 +0100
> @@ -1,4 +1,4 @@
> -@version:3.8
> +@version:3.9
> 
> options {
>chain_hostnames(no);
> 
> Dne 17.1.2017 v 19:40 Philip Prindeville napsal(a):
>> Actually, I take that back.
>> 
>> Milan, can you please update the top line of files/syslog-ng.conf also?  It 
>> needs to read “3.9” instead (assuming there aren’t any syntactic constructs 
>> in that file that are now deprecated from 3.8 to 3.9… if there were, the 
>> file would need to be updated as well… like when the log_prefix() filter 
>> criteria got replaced by program()).
>> 
>> Thanks
>> 
>> 
>>> On Jan 16, 2017, at 1:45 PM, Philip Prindeville 
>>>  wrote:
>>> 
>>> Looks good to me.
>>> 
>>> 
 On Jan 16, 2017, at 4:24 AM, Milan Kočvara  wrote:
 
 Hello.
 I found typo in syslog-ng makefile.
 
 I've upgraded to the newest version and I've made correction of the typo. 
 Patch bellow.
 
 Sorry for bad format of everything. I did it never :)
 
 --- Makefile-orig   2017-01-16 12:06:44.367684776 +0100
 +++ Makefile~   2017-01-16 12:22:47.198478933 +0100
 @@ -1,14 +1,14 @@
 include  $(TOPDIR)/rules.mk
 
 PKG_NAME:=syslog-ng
 -PKG_VERSION:=3.8.1
 -PKG_RELEASE:=3
 +PKG_VERSION:=3.9.1
 +PKG_RELEASE:=1
 
 PKG_MAINTAINER:=W. Michael Petullo 
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=https://github.com/balabit/syslog-ng/releases/download/$(PKG_NAME)-$(PKG_VERSION)/
 -PKG_MD5SUM:=acf14563cf5ce435db8db35486ce66af
 +PKG_MD5SUM:=1b48da9ef620cf06e55e481b5abb677a
 
 PKG_INSTALL:=1
 
 @@ -41,7 +41,7 @@
 CONFIGURE_ARGS += \
  $(call autoconf_bool,CONFIG_IPV6,ipv6) \
 --disable-dependency-tracking \
 - --disable-ampq \
 + --disable-amqp \
 --disable-tcp-wrapper \
 --disable-glibtest \
 --disable-mongodb \
>>> 
>>> ___
>>> Lede-dev mailing list
>>> Lede-dev@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE 17.01 branched/Release Notes improving

2017-01-18 Thread Rich Brown 

> On Jan 16, 2017, at 1:37 PM, Jo-Philipp Wich  wrote:
> 
> this is just a heads-up to inform you that LEDE master has been branched
> into a new branch "lede-17.01" now.

Thanks to everyone who has contributed to the Release Notes. Here's the current 
state: If you think something's missing, please go to the site and update this 
page: https://lede-project.org/playground/draft-release-notes 

Thanks!

Rich
---

LEDE 17.xx First Stable Release - MMM 2017

 _
//\  ____ ___  ___
   /  LE/  \| |  | __|   \| __|
  /DE  /\   | |__| _|| |) | _|
 //  LE  \  ||___|___/|___|  lede-project.org
 \\   DE /
  \LE  \/  ---
   \  DE\  /Reboot (HEAD, rx)
\\/---

THIS IS A DRAFT. PLEASE MAKE IT BETTER.
The LEDE Project (“Linux Embedded Development Environment”) is a Linux 
operating system based on OpenWrt. It is a complete replacement for the 
vendor-supplied firmware of a wide range of wireless routers and non-network 
devices. See the Table of Hardware for supported devices. For more information 
about LEDE Project organization, see the About LEDE pages.

Get LEDE Firmware at: http://downloads.lede-project.org/

Highlights In LEDE 17.xx

The LEDE Community is proud to announce the first stable release of LEDE 17.xx. 
It incorporates thousands of commits over the last nine months of effort. With 
this release, the LEDE development team closes out an intense effort to 
modernize many parts of OpenWrt and incorporate many new modules, packages, and 
technologies. These are some of the highlights compared to OpenWrt Chaos Calmer:

Would it be possible to include a “More…” link for some/most of these features? 
People love to read more about the work that has been done. See the SQM item 
(below) for an example.

• Linux kernel updated to version 4.4.42
• Improved Security Features
• Memory Corruption Mitigation Methods
• gcc -Wformat -Wformat-security
• User space Stack-Smashing Protection (Regular)
• Kernel space Stack-Smashing Protection (Regular)
• buffer-overflows detection (FORTIFY_SOURCE) 
(Conservative)
• RELRO protection (Full)
• …
• Improved Networking Support
• Smart Queue Management (SQM) minimizes bufferbloat by using 
the cake and fq_codel qdisc's. More...
• Improvements to the WiFi stack eliminating bufferbloat on 
ath9k (and some ath10k) chipsets
• …
• Improved Performance
• …
• Updated toolchain
• musl 1.1.15
• gcc 5.4.0
• binutils 2.25.1
• Platform and Driver Support
• Lantiq
• Added redistributable DSL firmware
• Updated DSL phy drivers
• Added new targets:
• apm821xx (AppliedMicro APM821xx)
• arc770 (Synopsys DesignWare ARC 770D)
• archs38 (Synopsys DesignWare ARC HS38)
• armvirt (QEMU ARM Virtual Machine)
• ipq806x (Qualcomm Atheros IPQ806X)
• layerscape (NXP Layerscape)
• zynq (Xilinx Zynq 7000 SoCs)
• …
• New build system supports easier branches and ???
• Building different root file systems for different devices at 
once
• Added support for a many new routers and boards
• And lots and lots of other advancements…
As always, a big thank you goes to all our active package maintainers, testers, 
documenters, and supporters.

Have fun!

The LEDE Community
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Syslog-ng Makefile typo

2017-01-18 Thread Philip Prindeville 
You can also add:

Reviewed-by: Philip Prindeville 

regarding the unix-stream() vs. unix-dgram(), here’s a bug from Debian (which 
also uses syslog-ng):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=384802


> On Jan 18, 2017, at 12:39 AM, John Crispin  wrote:
> 
> Hi,
> 
> although the content of the patch looks good the format is incorrect.
> you really want to generate the patch using git and then use git
> format-patch/send-email to export and mail it. we cannot merge it in
> this format i am afraid. please also make sure to add a Signed-off-by line
> 
>   John
> 
> On 16/01/2017 12:24, Milan Kočvara wrote:
>> Hello.
>> I found typo in syslog-ng makefile.
>> 
>> I've upgraded to the newest version and I've made correction of the
>> typo. Patch bellow.
>> 
>> Sorry for bad format of everything. I did it never :)
>> 
>> --- Makefile-orig   2017-01-16 12:06:44.367684776 +0100
>> +++ Makefile~   2017-01-16 12:22:47.198478933 +0100
>> @@ -1,14 +1,14 @@
>> include  $(TOPDIR)/rules.mk
>> 
>> PKG_NAME:=syslog-ng
>> -PKG_VERSION:=3.8.1
>> -PKG_RELEASE:=3
>> +PKG_VERSION:=3.9.1
>> +PKG_RELEASE:=1
>> 
>> PKG_MAINTAINER:=W. Michael Petullo 
>> 
>> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
>> 
>> PKG_SOURCE_URL:=https://github.com/balabit/syslog-ng/releases/download/$(PKG_NAME)-$(PKG_VERSION)/
>> 
>> -PKG_MD5SUM:=acf14563cf5ce435db8db35486ce66af
>> +PKG_MD5SUM:=1b48da9ef620cf06e55e481b5abb677a
>> 
>> PKG_INSTALL:=1
>> 
>> @@ -41,7 +41,7 @@
>> CONFIGURE_ARGS += \
>>   $(call autoconf_bool,CONFIG_IPV6,ipv6) \
>>  --disable-dependency-tracking \
>> - --disable-ampq \
>> + --disable-amqp \
>>  --disable-tcp-wrapper \
>>  --disable-glibtest \
>>  --disable-mongodb \
>> 
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 4/4] x86: Add APU2 LED Driver

2017-01-18 Thread Philip Prindeville 

> On Jan 14, 2017, at 9:20 AM, Chris Blake  wrote:
> 
> The following patch adds LED support for the PC Engines APU2/APU3 board
> on LEDE.
> 
> Signed-off-by: Chris Blake 
> ---
> target/linux/x86/64/config-default |   2 +
> target/linux/x86/files/drivers/leds/leds-apu2.c| 374 +
> .../x86/patches-4.4/800-add-apu2-led-driver.patch  |  30 ++
> 3 files changed, 406 insertions(+)
> create mode 100644 target/linux/x86/files/drivers/leds/leds-apu2.c
> create mode 100644 target/linux/x86/patches-4.4/800-add-apu2-led-driver.patch
> 
> diff --git a/target/linux/x86/64/config-default 
> b/target/linux/x86/64/config-default
> index d2e2774..5657832 100644
> --- a/target/linux/x86/64/config-default
> +++ b/target/linux/x86/64/config-default
> @@ -170,6 +170,8 @@ CONFIG_ITCO_WDT=y
> # CONFIG_KVM_DEBUG_FS is not set
> CONFIG_KVM_GUEST=y
> # CONFIG_LCD_CLASS_DEVICE is not set
> +CONFIG_LEDS_APU2=y
> +CONFIG_LEDS_GPIO=y
> # CONFIG_LEGACY_VSYSCALL_EMULATE is not set
> # CONFIG_LEGACY_VSYSCALL_NATIVE is not set
> CONFIG_LEGACY_VSYSCALL_NONE=y
> diff --git a/target/linux/x86/files/drivers/leds/leds-apu2.c 
> b/target/linux/x86/files/drivers/leds/leds-apu2.c
> new file mode 100644
> index 000..8da8a2d
> --- /dev/null
> +++ b/target/linux/x86/files/drivers/leds/leds-apu2.c
> @@ -0,0 +1,374 @@
> +/*
> + *  APU2 LED/GPIO Driver
> + *  Copyright (c) 2016 Christian Lamparter 
> + *
> + *  Based on gpio-apu2.c - AMD FCH GPIO support for PC-Engines APU-2 board
> + *
> + *  Copyright (c) 2015  Carsten Spiess 
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program; if not, write to the Free Software
> + *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> + #include 
> + #include 
> + #include 
> + #include 
> + #include 
> + #include 
> + #include 
> + #include 
> + #include 
> + #include 
> + #include 
> + #include 
> + #include 
> +
> + #include 
> + #include 
> + #include 
> +
> + #define DEVNAME "leds-apu2"
> +
> + #define FCH_ACPI_MMIO_BASE  0xFED8
> + #define FCH_GPIO_BASE   (FCH_ACPI_MMIO_BASE + 0x1500)
> + #define FCH_GPIO_SIZE   0x300
> +
> + #define APU_NUM_GPIO4
> +
> + #define GPIO_BIT_DIR23
> + #define GPIO_BIT_WRITE  22
> + #define GPIO_BIT_READ   16
> +
> + /* internal variables */
> + static struct pci_dev *gpio_apu2_pci;
> + static DEFINE_SPINLOCK (gpio_lock);
> +
> + /* the watchdog platform device */
> + static struct platform_device *gpio_apu2_platform_device;
> + static struct platform_device *leddev;
> + static struct platform_device *keydev;
> +
> + static const struct pci_device_id gpio_apu2_pci_tbl[] ={
> + {PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS, PCI_ANY_ID, 
> PCI_ANY_ID},
> + { 0, } /* End of list */
> + };
> + MODULE_DEVICE_TABLE (pci, gpio_apu2_pci_tbl);
> +
> + /* EGPIO89=GPIO32, AGPIO68=GPIO57, AGPIO69=GPIO58, AGPIO70=GPIO59 */
> + static u8 gpio_offset[APU_NUM_GPIO] = {89, 68, 69, 70};
> +
> + static void __iomem *gpio_addr[APU_NUM_GPIO] = {NULL, NULL, NULL, NULL};
> +
> + static int gpio_apu2_get_dir (struct gpio_chip *chip, unsigned offset)
> + {
> + u32 val;
> +
> + val = ~ioread32 (gpio_addr[offset]);
> +
> + return (val >> GPIO_BIT_DIR) & 1;
> + }
> +
> + static int gpio_apu2_dir_in (struct gpio_chip *gc, unsigned offset)
> + {
> + u32 val;
> +
> + spin_lock_bh (&gpio_lock);
> +
> + val = ioread32 (gpio_addr[offset]);
> + val &= ~BIT(GPIO_BIT_DIR);
> + iowrite32 (val, gpio_addr[offset]);
> +
> + spin_unlock_bh (&gpio_lock);
> +
> + return 0;
> + }
> +
> + static int gpio_apu2_dir_out (struct gpio_chip *chip, unsigned offset,
> + int value)
> + {
> + u32 val;
> +
> + spin_lock_bh (&gpio_lock);
> +
> + val = ioread32 (gpio_addr[offset]);
> + val |= BIT(GPIO_BIT_DIR);
> + iowrite32 (val, gpio_addr[offset]);
> +
> + spin_unlock_bh (&gpio_lock);
> +
> + return 0;
> + }
> +
> + static int gpio_apu2_get_data (struct gpio_chip *chip, unsigned offset)
> + {
> + u32 val;
> +
> + val = ioread32 (gpio_addr[offset]);
> +
> + return (val >> GPIO_BIT_READ) & 1;
> + }
> +
> + static void gpio_apu2_set_data (struct gpio_chip *chip, unsigned offset, 
> int value)
> + {
> + u32 val;
> +
> + spin_lock_bh (&gpio_lock);
> +
> + val = ioread32 (gpio_addr[offset]);
> +

[LEDE-DEV] RT5350 spi half duplex?

2017-01-18 Thread Giuseppe Lippolis 
Hi,
I’m experimenting the spi interface on a RT5350 target.
Its spi driver set the interface as half duplex

    master->dev.of_node = pdev->dev.of_node;
    master->mode_bits = RT2880_SPI_MODE_BITS;
    master->bits_per_word_mask = SPI_BPW_MASK(8);
    master->min_speed_hz = clk_get_rate(clk) / 128;
    master->max_speed_hz = clk_get_rate(clk) / 2;
    master->flags = SPI_MASTER_HALF_DUPLEX;
    master->setup = rt2880_spi_setup;
    master->prepare_message = rt2880_spi_prepare_message;
    master->set_cs = rt2880_spi_set_cs;
    master->transfer_one = rt2880_spi_transfer_one,

but from the datasheet it seems that the device is full duplex capable.
There are some reason to set the driver in this way?

Thanks, bye. 



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Race condition in openssh build?

2017-01-18 Thread Philip Prindeville 
I did a “make dirclean” and then “make -j12” and I end up seeing the following 
(it’s reproducible):

...
 make[3] -C feeds/packages/utils/bash compile
 make[3] -C feeds/packages/utils/bc compile
 make[3] -C feeds/packages/net/bmon compile
 make[3] -C package/network/utils/iptables compile
 make[3] -C feeds/packages/libs/liboping compile
 make[3] -C package/network/utils/iproute2 compile
 make[3] -C feeds/packages/net/isc-dhcp compile
 make[3] -C feeds/packages/net/openssh compile
 make[3] -C feeds/packages/net/openssh compile
 make[3] -C feeds/packages/net/openssh compile
 make[3] -C feeds/packages/net/openssh compile
 make[3] -C feeds/packages/net/openssh compile
 make[3] -C feeds/packages/net/openssh compile
make -r world: build failed. Please re-run make with -j1 V=s to see what's 
going on
/home/philipp/bertram/bmu-philip/openwrt/include/toplevel.mk:192: recipe for 
target 'world' failed
make: *** [world] Error 1

philipp@ubuntu16:~/bertram/bmu-philip/openwrt$ make -j4 package/openssh/clean 
 make[1] package/openssh/clean
 make[2] -C feeds/packages/net/openssh clean
 make[2] -C feeds/packages/net/openssh clean
 make[2] -C feeds/packages/net/openssh clean
 make[2] -C feeds/packages/net/openssh clean
 make[2] -C feeds/packages/net/openssh clean
 make[2] -C feeds/packages/net/openssh clean
 make[2] -C feeds/packages/net/openssh clean
philipp@ubuntu16:~/bertram/bmu-philip/openwrt$ 
philipp@ubuntu16:~/bertram/bmu-philip/openwrt$ make -j12 package/openssh/compile
 make[1] package/openssh/compile
 make[2] -C package/libs/toolchain compile
 make[2] -C feeds/packages/libs/libpam compile
 make[2] -C package/libs/zlib compile
 make[2] -C package/libs/openssl compile
 make[2] -C feeds/packages/net/openssh compile
 make[2] -C feeds/packages/net/openssh compile
 make[2] -C feeds/packages/net/openssh compile
 make[2] -C feeds/packages/net/openssh compile
 make[2] -C feeds/packages/net/openssh compile
 make[2] -C feeds/packages/net/openssh compile
 make[2] -C feeds/packages/net/openssh compile
philipp@ubuntu16:~/bertram/bmu-philip/openwrt$ 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev