Re: [OpenWrt-Devel] [PATCH 0/4] mediatek: add mt7629 subtarget

2019-10-31 Thread Chuanhong Guo 
On Fri, Nov 1, 2019 at 11:29 AM Chuanhong Guo  wrote:
>
> This patchset adds support for mt7629 and its rfb from mediatek.
> Currently, the secondary CPU doesn't bootup even if I backported
> the related commit, and wifi isn't available due to lack of driver.
> But beside those, everything else seems to work just fine.
>
> Chuanhong Guo (4):
>   mediatek: fix Unielec U7623 dts in 4.19
>   mediatek: backport upstream patches related to mt7629 support

This commit is too long that it can't be sent to mail list. Full patchset can be
found here:

https://git.openwrt.org/?p=openwrt/staging/981213.git;a=shortlog;h=refs/heads/mt7629_target

>   mediatek: cosmetic fixes for mt7629-lynx-rfb
>   mediatek: add mt7629 subtarget with rfb image
>

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

[OpenWrt-Devel] [PATCH 3/4] mediatek: cosmetic fixes for mt7629-lynx-rfb

2019-10-31 Thread Chuanhong Guo 
This patch did the following things:
1. rename device compatible string
2. add earlycon into cmdline
3. add mac address location according to mt7629 eeprom layout
4. rename mtd partitions

Signed-off-by: Chuanhong Guo 
---
 .../files-4.19/arch/arm/boot/dts/mt7629-lynx-rfb.dts | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git 
a/target/linux/mediatek/files-4.19/arch/arm/boot/dts/mt7629-lynx-rfb.dts 
b/target/linux/mediatek/files-4.19/arch/arm/boot/dts/mt7629-lynx-rfb.dts
index f3fadd301a..17ce6046da 100644
--- a/target/linux/mediatek/files-4.19/arch/arm/boot/dts/mt7629-lynx-rfb.dts
+++ b/target/linux/mediatek/files-4.19/arch/arm/boot/dts/mt7629-lynx-rfb.dts
@@ -10,7 +10,7 @@
 
 / {
model = "MediaTek MT7629 reference board";
-   compatible = "mediatek,mt7629-rfb", "mediatek,mt7629";
+   compatible = "mediatek,mt7629-lynx-rfb", "mediatek,mt7629";
 
aliases {
serial0 = 
@@ -18,6 +18,7 @@
 
chosen {
stdout-path = "serial0:115200n8";
+   bootargs = "earlycon=uart8250,mmio32,0x11002000";
};
 
gpio-keys {
@@ -75,6 +76,7 @@
 gmac0: mac@0 {
 compatible = "mediatek,eth-mac";
 reg = <0>;
+   mtd-mac-address = < 0x2a>;
 phy-mode = "sgmii";
 fixed-link {
 speed = <1000>;
@@ -86,6 +88,7 @@
 gmac1: mac@1 {
 compatible = "mediatek,eth-mac";
 reg = <1>;
+   mtd-mac-address = < 0x24>;
 phy-handle = <>;
 };
 
@@ -153,13 +156,13 @@
};
 
factory: partition@7 {
-   label = "Factory";
+   label = "factory";
reg = <0x7 0x4>;
read-only;
};
 
partition@b {
-   label = "Kernel";
+   label = "firmware";
reg = <0xb 0xb5>;
};
};
-- 
2.21.0


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

[OpenWrt-Devel] [PATCH 0/4] mediatek: add mt7629 subtarget

2019-10-31 Thread Chuanhong Guo 
This patchset adds support for mt7629 and its rfb from mediatek.
Currently, the secondary CPU doesn't bootup even if I backported
the related commit, and wifi isn't available due to lack of driver.
But beside those, everything else seems to work just fine.

Chuanhong Guo (4):
  mediatek: fix Unielec U7623 dts in 4.19
  mediatek: backport upstream patches related to mt7629 support
  mediatek: cosmetic fixes for mt7629-lynx-rfb
  mediatek: add mt7629 subtarget with rfb image

 target/linux/mediatek/Makefile| 2 +-
 .../arch/arm/boot/dts/mt7629-lynx-rfb.dts | 9 +-
 target/linux/mediatek/image/Makefile  |14 +-
 target/linux/mediatek/image/mt7629.mk | 8 +
 .../mt7629/base-files/etc/board.d/02_network  |34 +
 .../mt7629/base-files/lib/upgrade/platform.sh |16 +
 target/linux/mediatek/mt7629/config-4.19  |   369 +
 .../linux/mediatek/mt7629/profiles/default.mk |15 +
 target/linux/mediatek/mt7629/target.mk|17 +
 ...ediatek-add-MT7623a-smp-bringup-code.patch |51 +
 ...ediatek-add-MT7629-smp-bring-up-code.patch |57 +
 ...tek-add-clock-support-for-MT7629-SoC.patch |  1339 ++
 .../0005-pinctrl-mediatek-sync-with-5.3.patch | 15922 
 ...quadspi-add-SNOR_HWCAPS_READ-to-spi_.patch |34 +
 .../0227-arm-dts-Add-Unielec-U7623-DTS.patch  |19 +-
 15 files changed, 17881 insertions(+), 25 deletions(-)
 create mode 100644 target/linux/mediatek/image/mt7629.mk
 create mode 100755 
target/linux/mediatek/mt7629/base-files/etc/board.d/02_network
 create mode 100755 
target/linux/mediatek/mt7629/base-files/lib/upgrade/platform.sh
 create mode 100644 target/linux/mediatek/mt7629/config-4.19
 create mode 100644 target/linux/mediatek/mt7629/profiles/default.mk
 create mode 100644 target/linux/mediatek/mt7629/target.mk
 create mode 100644 
target/linux/mediatek/patches-4.19/0002-Revert-ARM-mediatek-add-MT7623a-smp-bringup-code.patch
 create mode 100644 
target/linux/mediatek/patches-4.19/0003-arm-mediatek-add-MT7629-smp-bring-up-code.patch
 create mode 100644 
target/linux/mediatek/patches-4.19/0004-clk-mediatek-add-clock-support-for-MT7629-SoC.patch
 create mode 100644 
target/linux/mediatek/patches-4.19/0005-pinctrl-mediatek-sync-with-5.3.patch
 create mode 100644 
target/linux/mediatek/patches-4.19/0006-mtd-spi-nor-mtk-quadspi-add-SNOR_HWCAPS_READ-to-spi_.patch

-- 
2.21.0


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

[OpenWrt-Devel] [PATCH 4/4] mediatek: add mt7629 subtarget with rfb image

2019-10-31 Thread Chuanhong Guo 
base-files are added into subtarget directory like what's done
recently in ath79. For this subtarget, metadata checks are enforced
and a SUPPORTED_DEVICE is added to generate proper metadata.
Since we only have mt7629 support in 4.19, override KERNEL_PATCHVER
in target.mk for now.

Signed-off-by: Chuanhong Guo 
---
 target/linux/mediatek/Makefile|   2 +-
 target/linux/mediatek/image/Makefile  |  14 +-
 target/linux/mediatek/image/mt7629.mk |   8 +
 .../mt7629/base-files/etc/board.d/02_network  |  34 ++
 .../mt7629/base-files/lib/upgrade/platform.sh |  16 +
 target/linux/mediatek/mt7629/config-4.19  | 369 ++
 .../linux/mediatek/mt7629/profiles/default.mk |  15 +
 target/linux/mediatek/mt7629/target.mk|  17 +
 8 files changed, 471 insertions(+), 4 deletions(-)
 create mode 100644 target/linux/mediatek/image/mt7629.mk
 create mode 100755 
target/linux/mediatek/mt7629/base-files/etc/board.d/02_network
 create mode 100755 
target/linux/mediatek/mt7629/base-files/lib/upgrade/platform.sh
 create mode 100644 target/linux/mediatek/mt7629/config-4.19
 create mode 100644 target/linux/mediatek/mt7629/profiles/default.mk
 create mode 100644 target/linux/mediatek/mt7629/target.mk

diff --git a/target/linux/mediatek/Makefile b/target/linux/mediatek/Makefile
index 0fda718714..28101a70d9 100644
--- a/target/linux/mediatek/Makefile
+++ b/target/linux/mediatek/Makefile
@@ -5,7 +5,7 @@ include $(TOPDIR)/rules.mk
 ARCH:=arm
 BOARD:=mediatek
 BOARDNAME:=MediaTek Ralink ARM
-SUBTARGETS:=mt7622 mt7623
+SUBTARGETS:=mt7622 mt7623 mt7629
 FEATURES:=squashfs nand ramdisk fpu
 MAINTAINER:=John Crispin 
 
diff --git a/target/linux/mediatek/image/Makefile 
b/target/linux/mediatek/image/Makefile
index d14c12ee7c..ddf4e435c7 100644
--- a/target/linux/mediatek/image/Makefile
+++ b/target/linux/mediatek/image/Makefile
@@ -16,6 +16,10 @@ ifeq ($(SUBTARGET),mt7622)
 KERNEL_LOADADDR = 0x4108
 endif
 
+ifeq ($(SUBTARGET),mt7629)
+KERNEL_LOADADDR = 0x40008000
+endif
+
 define Build/sysupgrade-emmc
rm -f $@.recovery
mkfs.fat -C $@.recovery 3070
@@ -33,13 +37,13 @@ define Device/Default
   FILESYSTEMS := squashfs
   DEVICE_DTS_DIR := $(DTS_DIR)
   IMAGES := sysupgrade.bin
-  IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | 
append-metadata 
+  IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | 
append-metadata
+  SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
 ifeq ($(SUBTARGET),mt7623)
   KERNEL_NAME := zImage
   KERNEL := kernel-bin | append-dtb | uImage none
   KERNEL_INITRAMFS := kernel-bin | append-dtb | uImage none
-endif
-ifeq ($(SUBTARGET),mt7622)
+else
   KERNEL_NAME := Image
   KERNEL = kernel-bin | lzma | fit lzma $$(KDIR)/image-$$(firstword 
$$(DEVICE_DTS)).dtb
   KERNEL_INITRAMFS = kernel-bin | lzma | fit lzma $$(KDIR)/image-$$(firstword 
$$(DEVICE_DTS)).dtb
@@ -54,6 +58,10 @@ ifeq ($(SUBTARGET),mt7623)
 include mt7623.mk
 endif
 
+ifeq ($(SUBTARGET),mt7629)
+include mt7629.mk
+endif
+
 define Image/Build
$(call Image/Build/$(1),$(1))
 endef
diff --git a/target/linux/mediatek/image/mt7629.mk 
b/target/linux/mediatek/image/mt7629.mk
new file mode 100644
index 00..ba1daefa03
--- /dev/null
+++ b/target/linux/mediatek/image/mt7629.mk
@@ -0,0 +1,8 @@
+define Device/mediatek_mt7629-lynx-rfb
+  DEVICE_VENDOR := MediaTek
+  DEVICE_MODEL := MT7629 Lynx reference board
+  DEVICE_DTS := mt7629-lynx-rfb
+  DEVICE_PACKAGES := swconfig
+endef
+TARGET_DEVICES += mediatek_mt7629-lynx-rfb
+
diff --git a/target/linux/mediatek/mt7629/base-files/etc/board.d/02_network 
b/target/linux/mediatek/mt7629/base-files/etc/board.d/02_network
new file mode 100755
index 00..757a390c24
--- /dev/null
+++ b/target/linux/mediatek/mt7629/base-files/etc/board.d/02_network
@@ -0,0 +1,34 @@
+#!/bin/sh
+
+. /lib/functions.sh
+. /lib/functions/uci-defaults.sh
+. /lib/functions/system.sh
+
+mediatek_setup_interfaces()
+{
+   local board="$1"
+
+   case $board in
+   mediatek,mt7629-lynx-rfb)
+   ucidef_set_interfaces_wan "eth1"
+   ucidef_add_switch "switch0" \
+   "0:lan" "1:lan" "2:lan" "3:lan" "6@eth0"
+   ;;
+   esac
+}
+
+mediatek_setup_macs()
+{
+   local board="$1"
+
+   case $board in
+   esac
+}
+
+board_config_update
+board=$(board_name)
+mediatek_setup_interfaces $board
+mediatek_setup_macs $board
+board_config_flush
+
+exit 0
diff --git a/target/linux/mediatek/mt7629/base-files/lib/upgrade/platform.sh 
b/target/linux/mediatek/mt7629/base-files/lib/upgrade/platform.sh
new file mode 100755
index 00..9a613c43b1
--- /dev/null
+++ b/target/linux/mediatek/mt7629/base-files/lib/upgrade/platform.sh
@@ -0,0 +1,16 @@
+PART_NAME=firmware
+REQUIRE_IMAGE_METADATA=1
+
+platform_check_image() {
+   return 0
+}
+
+platform_do_upgrade() {
+   local board=$(board_name)
+
+   case "$board" in
+   *)
+   default_do_upgrade

[OpenWrt-Devel] [PATCH 1/4] mediatek: fix Unielec U7623 dts in 4.19

2019-10-31 Thread Chuanhong Guo 
remove duplicated pinctrl nodes.

Signed-off-by: Chuanhong Guo 
---
 .../0227-arm-dts-Add-Unielec-U7623-DTS.patch  | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git 
a/target/linux/mediatek/patches-4.19/0227-arm-dts-Add-Unielec-U7623-DTS.patch 
b/target/linux/mediatek/patches-4.19/0227-arm-dts-Add-Unielec-U7623-DTS.patch
index 88222908ea..6561e8d5a7 100644
--- 
a/target/linux/mediatek/patches-4.19/0227-arm-dts-Add-Unielec-U7623-DTS.patch
+++ 
b/target/linux/mediatek/patches-4.19/0227-arm-dts-Add-Unielec-U7623-DTS.patch
@@ -44,7 +44,7 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +};
 --- /dev/null
 +++ b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi
-@@ -0,0 +1,366 @@
+@@ -0,0 +1,349 @@
 +/*
 + * Copyright 2018 Kristian Evensen 
 + *
@@ -324,23 +324,6 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +  };
 +  };
 +
-+  pwm_pins_a: pwm@0 {
-+  pins_pwm {
-+  pinmux = ,
-+   ,
-+   ,
-+   ,
-+   ;
-+  };
-+  };
-+
-+  uart2_pins_b: uart@2 {
-+  pins_dat {
-+  pinmux = ,
-+   ;
-+  };
-+  };
-+
 +  pcie_default: pcie_pin_default {
 +  pins_cmd_dat {
 +  pinmux = 
,
-- 
2.21.0


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

[OpenWrt-Devel] [PATCH v2] hostapd: add IEEE 802.11k support

2019-10-31 Thread Kyle Copperfield via openwrt-devel 
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 ---
Enables radio resource management to be reported by hostapd to clients.

Ref: https://github.com/lede-project/source/pull/1430
Co-developed-by: Lorenzo Santina 
Signed-off-by: Lorenzo Santina 
Signed-off-by: Kyle Copperfield 
---
 package/network/services/hostapd/files/hostapd.sh | 13 +
 1 file changed, 13 insertions(+)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 8da8539e8a..f0dc997e91 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -223,6 +223,8 @@ hostapd_common_add_bss_config() {
config_add_int time_advertisement
config_add_string time_zone
 
+   config_add_boolean ieee80211k rrm_neighbor_report rrm_beacon_report
+
config_add_boolean ieee80211r pmk_r1_push ft_psk_generate_local 
ft_over_ds
config_add_int r0_key_lifetime reassociation_deadline
config_add_string mobility_domain r1_key_holder
@@ -489,6 +491,17 @@ hostapd_set_bss_options() {
append bss_conf "bss_transition=$bss_transition" "$N"
fi
 
+   json_get_vars ieee80211k
+   set_default ieee80211k 0
+   if [ "$ieee80211k" -eq "1" ]; then
+   json_get_vars rrm_neighbor_report rrm_beacon_report
+
+   set_default rrm_neighbor_report 1
+   set_default rrm_beacon_report 1
+   append bss_conf "rrm_neighbor_report=$rrm_neighbor_report" "$N"
+   append bss_conf "rrm_beacon_report=$rrm_beacon_report" "$N"
+   fi
+
if [ "$wpa" -ge "1" ]; then
json_get_vars ieee80211r
set_default ieee80211r 0
-- 
2.23.0


--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] hostapd: add IEEE 802.11k support

2019-10-31 Thread Kyle Copperfield via openwrt-devel 
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 ---
Enables radio resource management to be reported by hostapd to clients.

Ref: https://github.com/lede-project/source/pull/1430
Co-developed-by: Lorenzo Santina 
Signed-off-by: Lorenzo Santina 
Signed-off-by: Kyle Copperfield 
---
 package/network/services/hostapd/files/hostapd.sh | 13 +
 1 file changed, 13 insertions(+)

diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index 8da8539e8a..f0dc997e91 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -223,6 +223,8 @@ hostapd_common_add_bss_config() {
config_add_int time_advertisement
config_add_string time_zone

+   config_add_boolean ieee80211k rrm_neighbor_report rrm_beacon_report
+
config_add_boolean ieee80211r pmk_r1_push ft_psk_generate_local 
ft_over_ds
config_add_int r0_key_lifetime reassociation_deadline
config_add_string mobility_domain r1_key_holder
@@ -489,6 +491,17 @@ hostapd_set_bss_options() {
append bss_conf "bss_transition=$bss_transition" "$N"
fi

+   json_get_vars ieee80211k
+   set_default ieee80211k 0
+   if [ "$ieee80211k" -eq "1" ]; then
+   json_get_vars rrm_neighbor_report rrm_beacon_report
+
+   set_default rrm_neighbor_report 1
+   set_default rrm_beacon_report 1
+   append bss_conf "rrm_neighbor_report=$rrm_neighbor_report" "$N"
+   append bss_conf "rrm_beacon_report=$rrm_beacon_report" "$N"
+   fi
+
if [ "$wpa" -ge "1" ]; then
json_get_vars ieee80211r
set_default ieee80211r 0
-- 
2.23.0






--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] v5.4 as next kernel

2019-10-31 Thread Paul Oranje 



> Op 30 okt. 2019, om 22:16 heeft Stefan Lippers-Hollmann  het 
> volgende geschreven:
> 
> Hi
> 
> On 2019-10-30, Adrian Schmutzler wrote:
>> 1. We currently have work-in-progress 4.19 support PRs for ramips,
>> ipq806x and bcm63xx, still with considerable work to do at least for
>> the first two (IIRC).
> 
> Kernel 4.19 has been working fine on ipq806x (nbg6817) for me so far,
> I've been using it a for couple of months now and the pending pull
> request[0] is functional. Yes, there might be further optimization steps
> possible, but none of that is necessary to switch ipq806x from v4.14 to
> v4.19 now'ish (routing throughput is already significantly better in
> v4.19, jumbo frames no longer crash stmmac, so I do consider the current
> state of the v4.19 patches for ipq806x to be an improvement over v4.14).
Absolutely.

> 
> Regards
>   Stefan Lippers-Hollmann
> 
> [0]   https://github.com/openwrt/openwrt/pull/2472
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


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

[OpenWrt-Devel] [PATCH v3] ath79: add support for Netgear WNDR4300

2019-10-31 Thread Michal Cieslakiewicz 
This patch adds ath79 support for Netgear WNDR4300.
Router was previously supported by ar71xx target only.
Note: device requires 'ar934x-nand' driver in kernel.

Specification
=
  * Description: Netgear WNDR4300
  * Loader: U-boot
  * SOC: Atheros AR9344 (560 MHz)
  * RAM: 128 MiB
  * Flash: 128 MiB (NAND)
- U-boot binary: 256 KiB
- U-boot environment: 256 KiB
- ART: 256 KiB
- POT: 512 KiB
- Language: 2 MiB
- Config: 512 KiB
- Traffic Meter: 3 MiB
- Firmware: 25 MiB
- ART Backup: 256 KiB
- Reserved: 96 MiB
  * Ethernet: 5 x 10/100/1000 (4 x LAN, 1 x WAN) (AR8327)
  * Wireless:
- 2.4 GHz b/g/n (internal)
- 5 GHz a/n (AR9580)
  * USB: yes, 1 x USB 2.0
  * Buttons:
- Reset
- WiFi (rfkill)
- WPS
  * LEDs:
- Power (amber/green)
- WAN (amber/green)
- WLAN 2G (green)
- WLAN 5G (blue)
- 4 x LAN (amber/green)
- USB (green)
- WPS (amber/green)
  * UART: 4-pin connector JP1, 3.3V (Vcc, TX, RX, GND), 115200 8N1
  * Power supply: DC 12V 2.5A
  * MAC addresses: LAN=WLAN2G on case label, WAN +1, WLAN5G +2

Installation

  * TFTP recovery
  * TFTP via U-boot prompt
  * sysupgrade
  * Web interface

Note about partitioning: firmware partition offset (0x6c) is
hardcoded into vendor's u-boot, so this partition cannot be moved
and resized to include Netgear-specific flash areas (pot, language,
config, traffic_meter) not used by OpenWrt.

Test build configuration

CONFIG_TARGET_ath79=y
CONFIG_TARGET_ath79_nand=y
CONFIG_TARGET_ath79_nand_DEVICE_netgear_wndr4300=y
CONFIG_ALL_KMODS=y
CONFIG_DEVEL=y
CONFIG_CCACHE=y
CONFIG_COLLECT_KERNEL_DEBUG=y
CONFIG_IMAGEOPT=y

Signed-off-by: Michal Cieslakiewicz 
---
 package/boot/uboot-envtools/files/ath79   |   3 +
 .../ath79/dts/ar9344_netgear_wndr4300.dts | 293 ++
 target/linux/ath79/image/nand.mk  |  32 ++
 .../ath79/nand/base-files/etc/board.d/01_leds |   3 +
 .../nand/base-files/etc/board.d/02_network|   7 +
 .../etc/hotplug.d/firmware/10-ath9k-eeprom|  13 +
 .../nand/base-files/lib/upgrade/platform.sh   |   1 +
 7 files changed, 352 insertions(+)
 create mode 100644 target/linux/ath79/dts/ar9344_netgear_wndr4300.dts

diff --git a/package/boot/uboot-envtools/files/ath79 
b/package/boot/uboot-envtools/files/ath79
index cc9741cedf..5da5df2420 100644
--- a/package/boot/uboot-envtools/files/ath79
+++ b/package/boot/uboot-envtools/files/ath79
@@ -33,6 +33,9 @@ yuncore,a770)
 buffalo,wzr-hp-ag300h)
ubootenv_add_uci_config "/dev/mtd3" "0x0" "0x1" "0x1"
;;
+netgear,wndr4300)
+   ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x4" "0x2"
+   ;;
 qihoo,c301)
ubootenv_add_uci_config "/dev/mtd9" "0x0" "0x1" "0x1"
;;
diff --git a/target/linux/ath79/dts/ar9344_netgear_wndr4300.dts 
b/target/linux/ath79/dts/ar9344_netgear_wndr4300.dts
new file mode 100644
index 00..c2c395e8cf
--- /dev/null
+++ b/target/linux/ath79/dts/ar9344_netgear_wndr4300.dts
@@ -0,0 +1,293 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include 
+#include 
+
+#include "ar9344.dtsi"
+
+/ {
+   compatible = "netgear,wndr4300", "qca,ar9344";
+   model = "Netgear WNDR4300";
+
+   chosen {
+   bootargs = "console=ttyS0,115200n8";
+   };
+
+   aliases {
+   led-boot = _amber;
+   led-failsafe = _amber;
+   led-running = _green;
+   led-upgrade = _amber;
+   label-mac-device = 
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   wps {
+   label = "wps";
+   linux,code = ;
+   gpios = < 12 GPIO_ACTIVE_LOW>;
+   };
+
+   reset {
+   label = "reset";
+   linux,code = ;
+   gpios = < 21 GPIO_ACTIVE_LOW>;
+   };
+
+   rfkill {
+   label = "rfkill";
+   linux,code = ;
+   gpios = < 15 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio_11>;
+
+   power_green: power_green {
+   label = "netgear:green:power";
+   gpios = < 0 GPIO_ACTIVE_LOW>;
+   };
+
+   power_amber: power_amber {
+   label = "netgear:amber:power";
+   gpios = < 2 GPIO_ACTIVE_LOW>;
+   default-state = "keep";
+   };
+
+   wan_green {
+   label = "netgear:green:wan";
+   gpios = < 1 GPIO_ACTIVE_LOW>;
+   };
+
+   wan_amber

Re: [OpenWrt-Devel] [PATCH v3] ath79: add support for Netgear WNDR4300

2019-10-31 Thread Michal Cieslakiewicz 
Hello,

Changelog from v2:

* nand-netgear.mk file merged into main nand.mk makefile
* image filenames (factory and sysupgrade) changed to standard ones
  ('ubi-' prefix removed)

IMHO 'caldata' and 'caldata_backup' partitions should retain their names
to match both vendor and ar71xx labels, so this hasn't been changed.

Regards
Michal

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

Re: [OpenWrt-Devel] Any interest in a 'ct' iperf3?

2019-10-31 Thread Ben Greear 

On 10/31/19 5:50 AM, Petr Štetiar wrote:

Ben Greear  [2019-10-29 06:23:52]:


The original SO_BINDTODEVICE patches were offered upstream
and there is no interest.


It seems like there's finally some interest[1] and you do a good job over there.


Someone asked me to create a different branch, and asked for some other feature,
but no serious code review or comments that make me think anyone is seriously
looking at the patches.

Thanks,
Ben




My recent changes would need rebasing to clean them up before upstreaming,
and I am not going to spend any serious time on that since I'd still have to
run my own tree to get the SO_BINDTODEVICE patches and anything else not
accepted upstream.


I think, that there's no need for iperf3-ct package.  In general, I would like
to move iperf3 to package feeds, where I think it belongs[2].

I assume, that nobody is going to object against any additional upstreamable
patches on top of iperf3 package if they provide widely useful
features/improvements and fixes. It should be enough to just put relevant link
to the upstream PR/patchwork/mailinglist to get them included.

1. https://github.com/esnet/iperf/pull/817
2. http://lists.infradead.org/pipermail/openwrt-devel/2019-August/018399.html

-- ynezz




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com


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

Re: [OpenWrt-Devel] [PATCH] ramips: ethernet: fix to interrupt handling

2019-10-31 Thread Mingyu Li 
the upstream kernel. the function mtk_napi_rx always be called if it have
packet to receive. it doesn't check status register.
but on openwrt code. check the status register first. then call fe_poll_rx.
if you clear status register. fe_poll_rx will will not be called next time.

Rosen Penev  於 2019年10月30日 週三 上午12:51寫道：
>
> On Wed, Mar 6, 2019 at 12:37 AM Mingyu Li  wrote:
> >
> > the original code use status register to keep there still have some
> > pkts in buffer.
> > need next napi call to receive it.
> >
> > if 128 packets in buffer. you clear status first. because napi max
> > handle 64 packets in buffer.
> > so 64 packets need to handle in next napi poll. if no new packet
> > comming. the status register will not set.
> > so fe_poll function will not call fe_poll_tx or fe_poll_rx. that would
> > be a problem.
> >
> > the status register also use to control napi interrupt enable. must
> > make sure no packets need to
> > handle then enable interrupt.
> I took a look at this again. The upstream kernel driver does the same
> as this patch: 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/ethernet/mediatek/mtk_eth_soc.c?h=v4.14.151#n1189
> >
> > Rosen Penev  於 2019年3月6日 週三 下午12:08寫道：
> > >
> > > From: NeilBrown 
> > >
> > > The current code acknowledged interrupts *after* polling.
> > > This is the wrong way around, and could cause an interrupt to
> > > be missed.
> > > This is not likely to be fatal as another packet, and so another
> > > interrupt, should come along soon.  But maybe it is causing
> > > problems, so let's fix it anyway.
> > >
> > > Signed-off-by: NeilBrown 
> > > Signed-off-by: Rosen Penev 
> > > ---
> > >  .../drivers/net/ethernet/mediatek/mtk_eth_soc.c   | 11 +--
> > >  1 file changed, 5 insertions(+), 6 deletions(-)
> > >
> > > diff --git 
> > > a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > >  
> > > b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > index e0bc0ab818..2e0c8f94ca 100644
> > > --- 
> > > a/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > +++ 
> > > b/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> > > @@ -876,6 +876,8 @@ static int fe_poll_rx(struct napi_struct *napi, int 
> > > budget,
> > > struct fe_rx_dma *rxd, trxd;
> > > int done = 0, pad;
> > >
> > > +   fe_reg_w32(rx_intr, FE_REG_FE_INT_STATUS);
> > > +
> > > if (netdev->features & NETIF_F_RXCSUM)
> > > checksum_bit = soc->checksum_bit;
> > > else
> > > @@ -963,9 +965,6 @@ release_desc:
> > > done++;
> > > }
> > >
> > > -   if (done < budget)
> > > -   fe_reg_w32(rx_intr, FE_REG_FE_INT_STATUS);
> > > -
> > > return done;
> > >  }
> > >
> > > @@ -981,6 +980,8 @@ static int fe_poll_tx(struct fe_priv *priv, int 
> > > budget, u32 tx_intr,
> > > u32 idx, hwidx;
> > > struct fe_tx_ring *ring = >tx_ring;
> > >
> > > +   fe_reg_w32(tx_intr, FE_REG_FE_INT_STATUS);
> > > +
> > > idx = ring->tx_free_idx;
> > > hwidx = fe_reg_r32(FE_REG_TX_DTX_IDX0);
> > >
> > > @@ -1004,9 +1005,7 @@ static int fe_poll_tx(struct fe_priv *priv, int 
> > > budget, u32 tx_intr,
> > > if (idx == hwidx) {
> > > /* read hw index again make sure no new tx packet */
> > > hwidx = fe_reg_r32(FE_REG_TX_DTX_IDX0);
> > > -   if (idx == hwidx)
> > > -   fe_reg_w32(tx_intr, FE_REG_FE_INT_STATUS);
> > > -   else
> > > +   if (idx != hwidx)
> > > *tx_again = 1;
> > > } else {
> > > *tx_again = 1;
> > > --
> > > 2.17.1
> > >
> > >
> > > ___
> > > openwrt-devel mailing list
> > > openwrt-devel@lists.openwrt.org
> > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel

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

[OpenWrt-Devel] 回复:Re: [PATCH-19.07] build: fix module strip invalid

2019-10-31 Thread 刘礼雄 
Thank you for your answer.___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear WNR2200

2019-10-31 Thread Michal Cieslakiewicz 
> 
> Hi,
> sorry for the foo, patch fails to apply, kindly rebase/resend it
>   John
> 

Hello John,

That's strange... Anyway, I rebased it again for master (fresh commit
df60a0852caf21de6684d38107f32a4eebc4579b) but it produces exactly the
same patch as v2. Tested and applied without problems on clean clone as
well...

Regards
Michal

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

Re: [OpenWrt-Devel] [RFC] firewall3: zones: Use ipsets instead of interfaces in zone rules

2019-10-31 Thread Kristian Evensen 
Hi all,

On Wed, Aug 28, 2019 at 7:37 PM Kristian Evensen
 wrote:
>
> firewall3 currently creates one rule for each interface that is a member of a
> zone. On for example devices with multiple interfaces, the current firewall3
> behavior quickly leads to a lot of rules. In order to reduce the number of
> rules, this patch replaces the per-interface rules with ipset matches (if 
> ipset
> is available). Since 2011, ipset has supported the set type "hash:net,iface".
> By adding (and matching on) on pairs consiting of the v4/v6 any-address and an
> interface name, we get the same behavior as the current interface-rules.
>
> After applying this patch (and assuming ipset is available), the following
> actions are performed when a zone is created:
>
> * We creates (allocate) an ipset of type "hash:net,iface" for each zone. The
> name follows the following format: zone__<4/6>_set.
> * If creating a set fails, then we ignore the zone. This is something we can
> change, but my reason for this behavior is to have consistent firewall rules.
> I.e., zone-rules either match on ipset or interface names, and not a mix.
> * Each set is populated with pairs consisting of the IPv4/IPv6 any-address and
> an interface name, for example "0.0.0.0/0, eth0.2".
> * Instead of one rule per device, a single rule is created matching on the
> ipset.
> * The check used to select the OUTPUT/PREROUTING-chain when adding rules to 
> the
> raw-table has been moved to print_interface_rules_{default,set}. The 
> motivation
> behind this move was to avoid changing print_interface_rule() too much. As far
> as I can see (and have tested), the logic for selecting chain/creating the
> rules is the same as before.
>
> Because the change introduced by this patch is quite intrusive and I am sure
> there will be comments/disagreements/suggestions, I have sent this patch as an
> RFC. One thing that I am aware of and will fix before the final submission, is
> to add support for printing ipsets. Right now "fw3 print" prints per-interface
> rules.

I have had the chance to run this patch in production for a while, and
thought I should share my experiences. All in all, switching to ipsets
seems to work well and, with one exception, I have not found any
configurations or configuration steps that break. Also, in some of my
setups, the number of iptables rules are greatly reduced. While I
haven't measured any performance improvements, fewer rules makes the
rule set easier to work with. The need to reload the firewall on ifup
is also removed (it is sufficient to update the set), which removes an
annoying gap or interruption in traffic on some of the devices I am
running.

What (currently) breaks is wildcard interface names, ipset currently
has no wildcard-support. I have submitted a patch upstream adding
support for wildcard naming, and have received positive feedback but
no final decision.

BR,
Kristian

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

[OpenWrt-Devel] I beg you to forward the mail to your purchasing manager

2019-10-31 Thread Jacqueline Bell 
*hello there.Dear friends!Thank you very much for checking my email, I am
very happy!I hope that you can spend a minute to see the whole email.I
believe it will be of great help to your business.We are a professional
watch trading company.Production of Michael Kors watches, Armani
watches, **Daniel
Wellington*




















* watches, Hugo Boss watches, Calvin Klein watches and Tissot watches.Our
watches are sold in more than 10 countries, and we will cooperate with you,
you will get a lot of advantages in quality and price, welcome wholesalers
and retailers.Samples are welcome to be sampled for quality inspection and
a wholesale order is issued after that. I hope we can build long-term
business relationships. If you are interested in our products, please feel
free to contact us!About purchasing samples:You can purchase 1-5 samples at
our wholesale price, which can be paid via paypal and bank transfer.About
delivery time:After the payment is successful, we will mail the goods out
within 3 working days.About logistics and transportation:Our company will
use DHL and FedEx will mail the goods for you.You will receive the goods
within 4-7 days.About the issue of return:If the watch has quality
problems, we will replace it for you for free!Promotions:Our company will
launch 1-2 models of watches every month for special wholesale, which is
5%-10% lower than the normal wholesale price.If you are interested, or want
to know more, please reply to my email: ruby4657...@gmail.com
, we will reply you within 2 hours!*








*Please believe us：Our company's Facebook public
homepage: @watchtradingcoltdMy Whatsapp: +86 18378686888Give you the best
wishes, I hope to be your friend!Xin Shangyi Trading Co., Ltd*
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [openwrt] Patch notification: 1 patch updated

2019-10-31 Thread Patchwork 
Hello,

The following patch (submitted by you) has been updated in Patchwork:

 * openwrt: [OpenWrt-Devel] hostapd: add IEEE 802.11k support
 - http://patchwork.ozlabs.org/patch/1187244/
 - for: OpenWrt development
was: New
now: Changes Requested

This email is a notification only - you do not need to respond.

Happy patchworking.

--

This is an automated mail sent by the Patchwork system at
patchwork.ozlabs.org. To stop receiving these notifications, edit
your mail settings at:
  http://patchwork.ozlabs.org/mail/

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

Re: [OpenWrt-Devel] [PATCH] hostapd: add IEEE 802.11k support

2019-10-31 Thread Petr Štetiar 
Kyle Copperfield via openwrt-devel  
[2019-10-31 06:50:55]:

Hi,

you should fix your mail setup:

> 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.

as a next step, please kindly read https://openwrt.org/submitting-patches one
more time and fix your patch accordingly.

> Add IEEE802.11k neighbor and beacon report

 "commit description: it should explain to a competent reader why you made this 
commit."

>  Original patch by Lorenzo Santina @BigNerd95 on GH
>  

  From 
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by

 "Co-developed-by: states that the patch was co-created by multiple
  developers; it is a used to give attribution to co-authors (in addition to the
  author attributed by the From: tag) when several people work on a single
  patch. Since Co-developed-by: denotes authorship, every Co-developed-by: must
  be immediately followed by a Signed-off-by: of the associated co-author.
  Standard sign-off procedure applies, i.e. the ordering of Signed-off-by: tags
  should reflect the chronological history of the patch insofar as possible,
  regardless of whether the author is attributed via From: or Co-developed-by:.
  Notably, the last Signed-off-by: must always be that of the developer
  submitting the patch."

>  Original patch by Lorenzo Santina @BigNerd95 on GH

GH -> simply add 'Ref: http://some/url' tag.

And one very important one:

 "all commits must contain Signed-off-by: My Name  where you
  write your real name and real email address!

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419

2019-10-31 Thread Daniel Danzberger 
It turned out that the wifi wasn't working because of a missmatch in the mtd
"art" partition naming. The ath10k caldata hotplug script was expecting it named
"0:ART" instead of "art".
Wifi seems to work fine now.
I will drop those files in the next PR.

On 10/31/19 1:12 PM, Robert Marko wrote:
> On Thu, 31 Oct 2019 at 13:10, Daniel Danzberger  wrote:
>>
>> Hi Jeff,
>>>
>>>  .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi   | 1142 +
>>>  .../include/dt-bindings/msm/msm-bus-ids.h |  869 +
>>>
>>> The sudden appearance of a need the MSM bus and its IDs worries me.
>>>
>>> With 25 devices already on the ipq40xx platform without them, it feels
>>> like something is missing if they are needed by this one.
>>
>> I already tried it without those files, but the wifi won't get detected in 
>> that
>> case.
> That is because you are trying to reuse QSDK DTS, this wont wont
> neither its supported.
> You need to convert it to OpenWrt/Upstream kernel style and bindings.
> There are lot of examples in ipq40xx already.
>>
>>>
>>>
 diff --git a/target/linux/ipq40xx/config-4.19 
 b/target/linux/ipq40xx/config-4.19
 index 8948b73ff7..3ee921abed 100644
 --- a/target/linux/ipq40xx/config-4.19
 +++ b/target/linux/ipq40xx/config-4.19
 @@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
   CONFIG_MTD_NAND_QCOM=y
   CONFIG_MTD_SPI_NAND=y
   CONFIG_MTD_SPI_NOR=y
 +CONFIG_MTD_SPINAND_MT29F=y
 +CONFIG_MTD_SPINAND_GIGADEVICE=y
 +CONFIG_MTD_SPINAND_ONDIEECC=y
>>>
>>>
>>> The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND
>>>
>>>
   CONFIG_MTD_SPLIT_FIRMWARE=y
   CONFIG_MTD_SPLIT_FIT_FW=y
   CONFIG_MTD_UBI=y

 [...]

 diff --git
 a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
 b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
 new file mode 100644
 index 00..5553bbd166
 --- /dev/null
 +++ 
 b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
 @@ -0,0 +1,371 @@
 +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
 + * Copyright (c) 2019, Nguyen Dinh Phi 
 + *
 + * 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.
 + *
 + */
 +

 [...]

 +
 +spi_0: spi@78b5000 {
 +pinctrl-0 = <_0_pins>;
 +pinctrl-names = "default";
 +status = "okay";
 +cs-gpios = < 12 GPIO_ACTIVE_HIGH>, < 41 
 GPIO_ACTIVE_HIGH>;
 +num-cs = <2>;
 +
 +m25p80@0 {
 +#address-cells = <1>;
 +#size-cells = <1>;
 +reg = <0>;
 +linux,modalias = "m25p80", "n25q128a11";
 +compatible = "jedec,spi-nor", "n25q128a11";
 +spi-max-frequency = <2400>;
>>>
>>>
>>> I don't think you need linux,modalias here, nor the chip type in the 
>>> compatible
>>> line.
>>> I believe that the following compatible line is sufficient
>>>
>>> compatible = "jedec,spi-nor";
>>>
>>>
>>> You might also want to consider "flash@0" or "nor@0" or "nor_flash@0",
>>> or the like, rather than a chip-specific name. (I'm not a committer.)
>>>
>>>
 +
 +partitions {
 +compatible = "fixed-partitions";
 +
 +partition@0 {
 +label = "0:SBL1";
 +reg = <0x00 0x04>;
 +read-only;
 +};
 +
 +partition@4 {
 +label = "0:MIBIB";
 +reg = <0x04 0x02>;
 +read-only;
 +};
 +
 +partition@6 {
 +label = "0:QSEE";
 +reg = <0x06 0x06>;
 +read-only;
 +};
 +
 +partition@c {
 +label = "0:CDT";
 +reg = <0x0c 0x01>;

Re: [OpenWrt-Devel] Merge Pull Request in GitHub

2019-10-31 Thread Adrian Schmutzler 
> Indeed, GitHub is just a mirror, so it won't work and disabling it makes
> sense.

"You must select at least one option."

So, I left "Allow rebase merging". 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Merge Pull Request in GitHub

2019-10-31 Thread Petr Štetiar 
Adrian Schmutzler  [2019-10-31 13:54:26]:

Hi,

welcome to the team! :-)

> does not seem to use Merge commits (which I'm glad about).

Same here.

> In case that a merge via GitHub won't be accepted at all (as it's just a
> mirror), I'd like to disable the merge button at all by the same set of
> options.

Indeed, GitHub is just a mirror, so it won't work and disabling it makes
sense.

FYI I think, that it just be default in all sub-projects, so I've added
fast-forward as the only allowed merging method to the gitweb2gitlab migration
script.

1. 
https://gitlab.com/openwrtorg/gitlab-evaluation/blob/master/gitweb/gitweb2gitlab.py#L77

-- ynezz

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

[OpenWrt-Devel] Merge Pull Request in GitHub

2019-10-31 Thread Adrian Schmutzler 
Hi,

GitHub features the "Merge Pull Request" button, which will add a Pull Request 
to master with Merge commit.
OpenWrt master does not seem to use Merge commits (which I'm glad about).

I'd like to disable this option in the projects GitHub options, so if someone 
clicks on that button (by accident), he will do a Rebase commit that does not 
spoil previous common use (even if reverted).

In case that a merge via GitHub won't be accepted at all (as it's just a 
mirror), I'd like to disable the merge button at all by the same set of options.

Opinions?

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Any interest in a 'ct' iperf3?

2019-10-31 Thread Petr Štetiar 
Ben Greear  [2019-10-29 06:23:52]:

> The original SO_BINDTODEVICE patches were offered upstream
> and there is no interest.

It seems like there's finally some interest[1] and you do a good job over there.

> My recent changes would need rebasing to clean them up before upstreaming,
> and I am not going to spend any serious time on that since I'd still have to
> run my own tree to get the SO_BINDTODEVICE patches and anything else not
> accepted upstream.

I think, that there's no need for iperf3-ct package.  In general, I would like
to move iperf3 to package feeds, where I think it belongs[2].

I assume, that nobody is going to object against any additional upstreamable
patches on top of iperf3 package if they provide widely useful
features/improvements and fixes. It should be enough to just put relevant link
to the upstream PR/patchwork/mailinglist to get them included.

1. https://github.com/esnet/iperf/pull/817
2. http://lists.infradead.org/pipermail/openwrt-devel/2019-August/018399.html

-- ynezz

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

Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear WNR2200

2019-10-31 Thread John Crispin 

On 30/10/2019 10:07, Michal Cieslakiewicz wrote:

This patch adds ath79 support for Netgear WNR2200.
Router was previously supported by ar71xx target only (8 MiB variant).
Netgear WNR2200 has two flash versions - 8MiB sold in EU, US etc. and
16 MiB for Russia and China markets. Apart from flash size both variants
share the same hardware specification.

Specification
=
   * Description: Netgear WNR2200
   * Loader: U-boot
   * SOC: Atheros AR7241 (360 MHz)
   * RAM: 64 MiB
   * Flash: 8 MiB or 16 MiB (SPI NOR)
- U-boot binary: 256 KiB
- U-boot environment: 64 KiB
- Firmware: 7808 KiB or 16000 KiB
- ART: 64 KiB
   * Ethernet: 4 x 10/100 LAN + 1 x 10/100 WAN
   * Wireless: 2.4 GHz b/g/n (Atheros AR9287)
   * USB: yes, 1 x USB 2.0
   * Buttons:
- Reset
- WiFi (rfkill)
- WPS
   * LEDs:
- Power (amber/green)
- WAN (amber/green)
- WLAN (blue)
- 4 x LAN (amber/green)
- WPS (green)
   * UART: 4-pin connector JP1, 3.3V (Vcc, TX, RX, GND), 115200 8N1
   * Power supply: DC 12V 1.5A
   * MAC addresses: LAN on case label, WAN +1, WLAN +2

Installation

   * TFTP recovery
   * TFTP via U-boot prompt
   * sysupgrade
   * Web interface

Test build configuration

CONFIG_TARGET_ath79=y
CONFIG_TARGET_ath79_generic=y
CONFIG_TARGET_ath79_generic_DEVICE_netgear_wnr2200-8m=y
CONFIG_ALL_KMODS=y
CONFIG_DEVEL=y
CONFIG_CCACHE=y
CONFIG_COLLECT_KERNEL_DEBUG=y
CONFIG_IMAGEOPT=y
CONFIG_KERNEL_DEBUG_INFO=y
CONFIG_KERNEL_DEBUG_KERNEL=y




Hi,
sorry for the foo, patch fails to apply, kindly rebase/resend it
John





Signed-off-by: Michal Cieslakiewicz 
---
  package/boot/uboot-envtools/files/ath79   |   2 +
  .../ath79/dts/ar7241_netgear_wnr2200-16m.dts  |  34 +++
  .../ath79/dts/ar7241_netgear_wnr2200-8m.dts   |  34 +++
  .../ath79/dts/ar7241_netgear_wnr2200.dtsi | 207 ++
  .../generic/base-files/etc/board.d/01_leds|  12 +
  .../generic/base-files/etc/board.d/02_network |   6 +
  .../etc/hotplug.d/firmware/10-ath9k-eeprom|   2 +
  target/linux/ath79/image/generic.mk   |  34 +++
  8 files changed, 331 insertions(+)
  create mode 100644 target/linux/ath79/dts/ar7241_netgear_wnr2200-16m.dts
  create mode 100644 target/linux/ath79/dts/ar7241_netgear_wnr2200-8m.dts
  create mode 100644 target/linux/ath79/dts/ar7241_netgear_wnr2200.dtsi

diff --git a/package/boot/uboot-envtools/files/ath79 
b/package/boot/uboot-envtools/files/ath79
index d5b94823fd..cc9741cedf 100644
--- a/package/boot/uboot-envtools/files/ath79
+++ b/package/boot/uboot-envtools/files/ath79
@@ -22,6 +22,8 @@ glinet,gl-ar300m-nor|\
  librerouter,librerouter-v1|\
  netgear,ex6400|\
  netgear,ex7300|\
+netgear,wnr2200-8m|\
+netgear,wnr2200-16m|\
  ocedo,koala|\
  ocedo,raccoon|\
  openmesh,om5p-ac-v2|\
diff --git a/target/linux/ath79/dts/ar7241_netgear_wnr2200-16m.dts 
b/target/linux/ath79/dts/ar7241_netgear_wnr2200-16m.dts
new file mode 100644
index 00..d182b58c05
--- /dev/null
+++ b/target/linux/ath79/dts/ar7241_netgear_wnr2200-16m.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "ar7241_netgear_wnr2200.dtsi"
+
+/ {
+   compatible = "netgear,wnr2200-16m", "qca,ar7241";
+   model = "Netgear WNR2200 (16M)";
+};
+
+ {
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x4>;
+   read-only;
+   };
+
+   partition@4 {
+   label = "u-boot-env";
+   reg = <0x4 0x1>;
+   };
+
+   partition@5 {
+   label = "firmware";
+   reg = <0x5 0xfa>;
+   compatible = "netgear,uimage";
+   };
+
+   art: partition@ff {
+   label = "art";
+   reg = <0xff 0x1>;
+   read-only;
+   };
+};
diff --git a/target/linux/ath79/dts/ar7241_netgear_wnr2200-8m.dts 
b/target/linux/ath79/dts/ar7241_netgear_wnr2200-8m.dts
new file mode 100644
index 00..e926c17893
--- /dev/null
+++ b/target/linux/ath79/dts/ar7241_netgear_wnr2200-8m.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "ar7241_netgear_wnr2200.dtsi"
+
+/ {
+   compatible = "netgear,wnr2200-8m", "qca,ar7241";
+   model = "Netgear WNR2200 (8M)";
+};
+
+ {
+   partition@0 {
+   label = "u-boot";
+   reg = <0x0 0x4>;
+   read-only;
+   };
+
+   partition@4 {
+   label = "u-boot-env";
+   reg = <0x4 0x1>;
+   };
+
+   partition@5 {
+   label = "firmware";
+   reg = <0x5 0x7a>;
+   compatible = "netgear,uimage";
+   };
+
+   art: partition@7f {
+   label = "art";
+   reg = <0x7f 0x1>;
+   read-only;
+   };
+};
diff --git

Re: [OpenWrt-Devel] [PATCH v2] fstools: add a hook before mounting the overlay

2019-10-31 Thread Alin Năstac 
On Thu, Oct 24, 2019 at 11:24 PM Karl Palsson  wrote:
>
>
> Alin Nastac  wrote:
> > From: Alin Nastac 
> >
> > Scripts located in the directory /etc/mount_root.d will be
> > executed before mounting the overlay. It can be used to
> > implement configuration merges between old & new setup after
> > doing sysupgrade.
>
> >From the name of the directory it's unclear when these would be
> executed. (You say pre, it's what you needed, but what if I
> wanted afterwards? where would they go?)
>
> Perhaps these could be made compatible with the hotplug.d
> scripts, where they have environment variables passed to them
> with the ACTION (pre/post) and so on. See
> https://openwrt.org/docs/guide-user/base-system/hotplug
>
> You could even just have another directory under /etc/hotplug.d ?

The only action handled in my scripts is "pre-overlay-activation" and
I used it to merge parts of the old config into the new overlay file
system. If community finds this useful, I can move the scripts to
/etc/hotplug.d/overlay and run the equivalent of the shell command
   ACTION=activate /sbin/hotplug-call overlay

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

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419

2019-10-31 Thread Robert Marko 
On Thu, 31 Oct 2019 at 13:10, Daniel Danzberger  wrote:
>
> Hi Jeff,
> >
> >  .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi   | 1142 +
> >  .../include/dt-bindings/msm/msm-bus-ids.h |  869 +
> >
> > The sudden appearance of a need the MSM bus and its IDs worries me.
> >
> > With 25 devices already on the ipq40xx platform without them, it feels
> > like something is missing if they are needed by this one.
>
> I already tried it without those files, but the wifi won't get detected in 
> that
> case.
That is because you are trying to reuse QSDK DTS, this wont wont
neither its supported.
You need to convert it to OpenWrt/Upstream kernel style and bindings.
There are lot of examples in ipq40xx already.
>
> >
> >
> >> diff --git a/target/linux/ipq40xx/config-4.19 
> >> b/target/linux/ipq40xx/config-4.19
> >> index 8948b73ff7..3ee921abed 100644
> >> --- a/target/linux/ipq40xx/config-4.19
> >> +++ b/target/linux/ipq40xx/config-4.19
> >> @@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
> >>   CONFIG_MTD_NAND_QCOM=y
> >>   CONFIG_MTD_SPI_NAND=y
> >>   CONFIG_MTD_SPI_NOR=y
> >> +CONFIG_MTD_SPINAND_MT29F=y
> >> +CONFIG_MTD_SPINAND_GIGADEVICE=y
> >> +CONFIG_MTD_SPINAND_ONDIEECC=y
> >
> >
> > The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND
> >
> >
> >>   CONFIG_MTD_SPLIT_FIRMWARE=y
> >>   CONFIG_MTD_SPLIT_FIT_FW=y
> >>   CONFIG_MTD_UBI=y
> >>
> >> [...]
> >>
> >> diff --git
> >> a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
> >> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
> >> new file mode 100644
> >> index 00..5553bbd166
> >> --- /dev/null
> >> +++ 
> >> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
> >> @@ -0,0 +1,371 @@
> >> +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
> >> + * Copyright (c) 2019, Nguyen Dinh Phi 
> >> + *
> >> + * 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.
> >> + *
> >> + */
> >> +
> >>
> >> [...]
> >>
> >> +
> >> +spi_0: spi@78b5000 {
> >> +pinctrl-0 = <_0_pins>;
> >> +pinctrl-names = "default";
> >> +status = "okay";
> >> +cs-gpios = < 12 GPIO_ACTIVE_HIGH>, < 41 
> >> GPIO_ACTIVE_HIGH>;
> >> +num-cs = <2>;
> >> +
> >> +m25p80@0 {
> >> +#address-cells = <1>;
> >> +#size-cells = <1>;
> >> +reg = <0>;
> >> +linux,modalias = "m25p80", "n25q128a11";
> >> +compatible = "jedec,spi-nor", "n25q128a11";
> >> +spi-max-frequency = <2400>;
> >
> >
> > I don't think you need linux,modalias here, nor the chip type in the 
> > compatible
> > line.
> > I believe that the following compatible line is sufficient
> >
> > compatible = "jedec,spi-nor";
> >
> >
> > You might also want to consider "flash@0" or "nor@0" or "nor_flash@0",
> > or the like, rather than a chip-specific name. (I'm not a committer.)
> >
> >
> >> +
> >> +partitions {
> >> +compatible = "fixed-partitions";
> >> +
> >> +partition@0 {
> >> +label = "0:SBL1";
> >> +reg = <0x00 0x04>;
> >> +read-only;
> >> +};
> >> +
> >> +partition@4 {
> >> +label = "0:MIBIB";
> >> +reg = <0x04 0x02>;
> >> +read-only;
> >> +};
> >> +
> >> +partition@6 {
> >> +label = "0:QSEE";
> >> +reg = <0x06 0x06>;
> >> +read-only;
> >> +};
> >> +
> >> +partition@c {
> >> +label = "0:CDT";
> >> +reg = <0x0c 0x01>;
> >> +read-only;
> >> +};
> >
> >
> > Someone may rip on you for capitalization of labels. (I'm not a committer.)
> >
> >
> >> +
> >> +partition@d {
> >> +label = "0:DDRPARAMS";
> >> +reg =

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419

2019-10-31 Thread Daniel Danzberger 
Hi Jeff,
> 
>  .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi   | 1142 +
>  .../include/dt-bindings/msm/msm-bus-ids.h |  869 +
> 
> The sudden appearance of a need the MSM bus and its IDs worries me.
> 
> With 25 devices already on the ipq40xx platform without them, it feels
> like something is missing if they are needed by this one.

I already tried it without those files, but the wifi won't get detected in that
case.

> 
> 
>> diff --git a/target/linux/ipq40xx/config-4.19 
>> b/target/linux/ipq40xx/config-4.19
>> index 8948b73ff7..3ee921abed 100644
>> --- a/target/linux/ipq40xx/config-4.19
>> +++ b/target/linux/ipq40xx/config-4.19
>> @@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
>>   CONFIG_MTD_NAND_QCOM=y
>>   CONFIG_MTD_SPI_NAND=y
>>   CONFIG_MTD_SPI_NOR=y
>> +CONFIG_MTD_SPINAND_MT29F=y
>> +CONFIG_MTD_SPINAND_GIGADEVICE=y
>> +CONFIG_MTD_SPINAND_ONDIEECC=y
> 
> 
> The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND
> 
> 
>>   CONFIG_MTD_SPLIT_FIRMWARE=y
>>   CONFIG_MTD_SPLIT_FIT_FW=y
>>   CONFIG_MTD_UBI=y
>>
>> [...]
>>
>> diff --git
>> a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>> new file mode 100644
>> index 00..5553bbd166
>> --- /dev/null
>> +++ 
>> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>> @@ -0,0 +1,371 @@
>> +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
>> + * Copyright (c) 2019, Nguyen Dinh Phi 
>> + *
>> + * 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.
>> + *
>> + */
>> +
>>
>> [...]
>>
>> +
>> +    spi_0: spi@78b5000 {
>> +    pinctrl-0 = <_0_pins>;
>> +    pinctrl-names = "default";
>> +    status = "okay";
>> +    cs-gpios = < 12 GPIO_ACTIVE_HIGH>, < 41 
>> GPIO_ACTIVE_HIGH>;
>> +    num-cs = <2>;
>> +
>> +    m25p80@0 {
>> +    #address-cells = <1>;
>> +    #size-cells = <1>;
>> +    reg = <0>;
>> +    linux,modalias = "m25p80", "n25q128a11";
>> +    compatible = "jedec,spi-nor", "n25q128a11";
>> +    spi-max-frequency = <2400>;
> 
> 
> I don't think you need linux,modalias here, nor the chip type in the 
> compatible
> line.
> I believe that the following compatible line is sufficient
> 
>     compatible = "jedec,spi-nor";
> 
> 
> You might also want to consider "flash@0" or "nor@0" or "nor_flash@0",
> or the like, rather than a chip-specific name. (I'm not a committer.)
> 
> 
>> +
>> +    partitions {
>> +    compatible = "fixed-partitions";
>> +
>> +    partition@0 {
>> +    label = "0:SBL1";
>> +    reg = <0x00 0x04>;
>> +    read-only;
>> +    };
>> +
>> +    partition@4 {
>> +    label = "0:MIBIB";
>> +    reg = <0x04 0x02>;
>> +    read-only;
>> +    };
>> +
>> +    partition@6 {
>> +    label = "0:QSEE";
>> +    reg = <0x06 0x06>;
>> +    read-only;
>> +    };
>> +
>> +    partition@c {
>> +    label = "0:CDT";
>> +    reg = <0x0c 0x01>;
>> +    read-only;
>> +    };
> 
> 
> Someone may rip on you for capitalization of labels. (I'm not a committer.)
> 
> 
>> +
>> +    partition@d {
>> +    label = "0:DDRPARAMS";
>> +    reg = <0x0d 0x01>;
>> +    read-only;
>> +    };
>> +
>> +    partition@e {
>> +    label = "u-boot-env";
>> +    reg = <0x0e 0x01>;
>> +    read-only;
>> +    };
> 
> 
> U-Boot environment may want/need to be writable
> 
> 
>> +
>> +    partition@f {
>> +    label = "u-boot";
>> +    reg = <0x0f 0x08>;
>> +

[OpenWrt-Devel] [PATCH] ath79: remove further redundant mtd-mac-address for wmac

2019-10-31 Thread Adrian Schmutzler 
For several devices, wmac MAC address is set from art 0x1002
explicitly by using mtd-mac-address although mtd-cal-data is
pulled from art 0x1000.

With the MAC address in 0x1002, the driver should automatically
use it when reading caldata from 0x1000. Thus, remove the
redundant mtd-mac-address for those devices.

This patch addresses the cases where the calibration data partition
is not labelled art, having been overlooked in the first patch.

Signed-off-by: Adrian Schmutzler 
---
 target/linux/ath79/dts/ar9342_ubnt_nanostation-ac.dts | 1 -
 target/linux/ath79/dts/ar9342_ubnt_wa.dtsi| 1 -
 target/linux/ath79/dts/ar9342_ubnt_xw.dtsi| 1 -
 target/linux/ath79/dts/qca9533_ubnt_acb-isp.dts   | 1 -
 4 files changed, 4 deletions(-)

diff --git a/target/linux/ath79/dts/ar9342_ubnt_nanostation-ac.dts 
b/target/linux/ath79/dts/ar9342_ubnt_nanostation-ac.dts
index 2ace37ad68..b591925154 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_nanostation-ac.dts
+++ b/target/linux/ath79/dts/ar9342_ubnt_nanostation-ac.dts
@@ -74,5 +74,4 @@
status = "okay";
 
mtd-cal-data = < 0x1000>;
-   mtd-mac-address = < 0x1002>;
 };
diff --git a/target/linux/ath79/dts/ar9342_ubnt_wa.dtsi 
b/target/linux/ath79/dts/ar9342_ubnt_wa.dtsi
index df5cb4be69..30fa299638 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_wa.dtsi
+++ b/target/linux/ath79/dts/ar9342_ubnt_wa.dtsi
@@ -89,5 +89,4 @@
 
qca,disable-5ghz;
mtd-cal-data = < 0x1000>;
-   mtd-mac-address = < 0x1002>;
 };
diff --git a/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi 
b/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
index 76c5c5efca..24fe34b3a7 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
+++ b/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
@@ -116,7 +116,6 @@
status = "okay";
 
mtd-cal-data = < 0x1000>;
-   mtd-mac-address = < 0x1002>;
 };
 
  {
diff --git a/target/linux/ath79/dts/qca9533_ubnt_acb-isp.dts 
b/target/linux/ath79/dts/qca9533_ubnt_acb-isp.dts
index 590ec448e9..629899e1a2 100644
--- a/target/linux/ath79/dts/qca9533_ubnt_acb-isp.dts
+++ b/target/linux/ath79/dts/qca9533_ubnt_acb-isp.dts
@@ -95,5 +95,4 @@
  {
status = "okay";
mtd-cal-data = < 0x1000>;
-   mtd-mac-address = < 0x1002>;
 };
-- 
2.20.1


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

Re: [OpenWrt-Devel] v5.4 as next kernel

2019-10-31 Thread Tom Psyborg 
On 31/10/2019, Bjørn Mork  wrote:
> John Crispin  writes:
>
>> Hi,
>> should we use v5.4 as our next kernel ?
>
> Hello John!
>
> I am still struggling to understand how the project makes release
> decisions.  I don't think your question makes sense without considering
> target release dates, at least in a yearly resolution, given the massive
> amount of work involved with switching kernel versions.
>
> So my question is: Is it realistic to expect an OpenWrt release with
> v5.4 next year?
>
> Because if it isn't, then v5.4 is really a waste of time IMHO. You
> should target the next longterm kernel after v5.4 instead for the first
> 2021 release.
>
> And of course, if you think a 2020 release with v5.4 is realistic, then
> there's an open question on what to do with v4.19.  Are two OpenWrt
> releases next year likely/possible?  If not, then v5.4 should probably
> replace v4.19 as the current target kernel as soon as possible.
>
> Yes, I know what your meeting minutes says.  But two releases in 2019 is
> obviously not going to happen. And personally I don't see how that's
> suddenly going to change for 2020 unless you do something drastic to
> simplify the release process. Yes, that means lowering the standards.
> Maybe making releases that won't be maintained, and therefore don't need
> to be "future proof"?
>
>
> Bjørn
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>

Yes, pretty strong arguments to skip 5.4 and just use 4.19 for the
20.xx release (which should not be 20.01 or 20.07 but more likely
20.10)

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

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419

2019-10-31 Thread Robert Marko 
Because of old MT29F driver, it was basically a hack just to get
SPI-NANDs working.

On Thu, 31 Oct 2019 at 11:34, Daniel Danzberger  wrote:
>
> Well, that makes sense and now it works :)
> I am just wondering why it has been working before with the other driver.
>
> On 10/31/19 11:30 AM, Robert Marko wrote:
> > On Thu, 31 Oct 2019 at 11:30, Daniel Danzberger  wrote:
> >>
> >> I am already using 'ubi.mtd=rootfs root=/dev/ubiblock0_1', which has 
> >> worked before
> > Well this is the issue, your ubi.mtd needs to be ubi.mtd=ubi
> >>
> >> On 10/31/19 11:26 AM, Robert Marko wrote:
> >>> On Thu, 31 Oct 2019 at 11:25, Daniel Danzberger  wrote:
> 
>  On the deprecated staging driver, it somehow directly came up as 
>  "rootfs" and
>  not "ubi". Even though it has been named "ubi" in the dts.
>  Now the image won't boot because no rootfs is detected:
> 
>  
>  [1.919001] Creating 1 MTD partitions on "spi0.1":
>  [1.925399] 0x-0x0800 : "ubi"
>  [1.940324] random: fast init done
>  ...
>  [3.170978] UBI error: cannot open mtd rootfs, error -2
>  [3.171027] hctosys: unable to open rtc device ([3.180802] 
>  Waiting for
>  root device /dev/ubiblock0_1...
> >>> This is due to your bootargs, you can either use bootargs-append to
> >>> set rootfs to ubi or change them in bootloader.
> >>> This is classic on boards derived from QCA reference designs
>  
> 
> 
>  On 10/31/19 11:19 AM, Robert Marko wrote:
> > On Thu, 31 Oct 2019 at 11:17, Daniel Danzberger  
> > wrote:
> >>
> >> Using 'compatible = "spi-nand"' worked and the device got detected by 
> >> the
> >> driver. However it won't create and "rootfs" partition like it did 
> >> before.
> >>
> >> ---
> >> [1.901930] spi-nand spi0.1: GigaDevice SPI NAND was found.
> >> [1.905266] spi-nand spi0.1: 128 MiB, block size: 128 KiB, page 
> >> size: 2048,
> >> OOB size: 128
> >> [1.911015] 1 fixed-partitions partitions found on MTD device spi0.1
> >> [1.919010] Creating 1 MTD partitions on "spi0.1":
> >> [1.925410] 0x-0x0800 : "ubi"
> > It creates the partitions like set in DTS, ubi partition contains both
> > kernel and rootfs.
> >> ---
> >>
> >>
> >> On 10/30/19 4:51 PM, Jeff Kletsky wrote:
> >>> On 10/30/19 4:27 AM, Daniel Danzberger wrote:
> >>>
>  This device contains 2 flash devices. One NOR (32M) and one NAND 
>  (128M).
>  U-boot and caldata are on the NOR, the firmware on the NAND.
> 
>   SoC:IPQ4019
>   CPU:4x 710MHz ARMv7
>   RAM:256MB
>   FLASH:  NOR:32MB NAND:128MB
> 
>  [...]
> 
> 
> >>>
> >>>  .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi   | 1142 
> >>> +
> >>>  .../include/dt-bindings/msm/msm-bus-ids.h |  869 +
> >>>
> >>> The sudden appearance of a need the MSM bus and its IDs worries me.
> >>>
> >>> With 25 devices already on the ipq40xx platform without them, it feels
> >>> like something is missing if they are needed by this one.
> >>>
> >>>
>  diff --git a/target/linux/ipq40xx/config-4.19 
>  b/target/linux/ipq40xx/config-4.19
>  index 8948b73ff7..3ee921abed 100644
>  --- a/target/linux/ipq40xx/config-4.19
>  +++ b/target/linux/ipq40xx/config-4.19
>  @@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
>    CONFIG_MTD_NAND_QCOM=y
>    CONFIG_MTD_SPI_NAND=y
>    CONFIG_MTD_SPI_NOR=y
>  +CONFIG_MTD_SPINAND_MT29F=y
>  +CONFIG_MTD_SPINAND_GIGADEVICE=y
>  +CONFIG_MTD_SPINAND_ONDIEECC=y
> >>>
> >>>
> >>> The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND
> >>>
> >>>
>    CONFIG_MTD_SPLIT_FIRMWARE=y
>    CONFIG_MTD_SPLIT_FIT_FW=y
>    CONFIG_MTD_UBI=y
> 
>  [...]
> 
>  diff --git
>  a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>  b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>  new file mode 100644
>  index 00..5553bbd166
>  --- /dev/null
>  +++ 
>  b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>  @@ -0,0 +1,371 @@
>  +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
>  + * Copyright (c) 2019, Nguyen Dinh Phi 
>  + *
>  + * 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

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419

2019-10-31 Thread Daniel Danzberger 
Well, that makes sense and now it works :)
I am just wondering why it has been working before with the other driver.

On 10/31/19 11:30 AM, Robert Marko wrote:
> On Thu, 31 Oct 2019 at 11:30, Daniel Danzberger  wrote:
>>
>> I am already using 'ubi.mtd=rootfs root=/dev/ubiblock0_1', which has worked 
>> before
> Well this is the issue, your ubi.mtd needs to be ubi.mtd=ubi
>>
>> On 10/31/19 11:26 AM, Robert Marko wrote:
>>> On Thu, 31 Oct 2019 at 11:25, Daniel Danzberger  wrote:

 On the deprecated staging driver, it somehow directly came up as "rootfs" 
 and
 not "ubi". Even though it has been named "ubi" in the dts.
 Now the image won't boot because no rootfs is detected:

 
 [1.919001] Creating 1 MTD partitions on "spi0.1":
 [1.925399] 0x-0x0800 : "ubi"
 [1.940324] random: fast init done
 ...
 [3.170978] UBI error: cannot open mtd rootfs, error -2
 [3.171027] hctosys: unable to open rtc device ([3.180802] Waiting 
 for
 root device /dev/ubiblock0_1...
>>> This is due to your bootargs, you can either use bootargs-append to
>>> set rootfs to ubi or change them in bootloader.
>>> This is classic on boards derived from QCA reference designs
 


 On 10/31/19 11:19 AM, Robert Marko wrote:
> On Thu, 31 Oct 2019 at 11:17, Daniel Danzberger  wrote:
>>
>> Using 'compatible = "spi-nand"' worked and the device got detected by the
>> driver. However it won't create and "rootfs" partition like it did 
>> before.
>>
>> ---
>> [1.901930] spi-nand spi0.1: GigaDevice SPI NAND was found.
>> [1.905266] spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 
>> 2048,
>> OOB size: 128
>> [1.911015] 1 fixed-partitions partitions found on MTD device spi0.1
>> [1.919010] Creating 1 MTD partitions on "spi0.1":
>> [1.925410] 0x-0x0800 : "ubi"
> It creates the partitions like set in DTS, ubi partition contains both
> kernel and rootfs.
>> ---
>>
>>
>> On 10/30/19 4:51 PM, Jeff Kletsky wrote:
>>> On 10/30/19 4:27 AM, Daniel Danzberger wrote:
>>>
 This device contains 2 flash devices. One NOR (32M) and one NAND 
 (128M).
 U-boot and caldata are on the NOR, the firmware on the NAND.

  SoC:IPQ4019
  CPU:4x 710MHz ARMv7
  RAM:256MB
  FLASH:  NOR:32MB NAND:128MB

 [...]


>>>
>>>  .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi   | 1142 +
>>>  .../include/dt-bindings/msm/msm-bus-ids.h |  869 +
>>>
>>> The sudden appearance of a need the MSM bus and its IDs worries me.
>>>
>>> With 25 devices already on the ipq40xx platform without them, it feels
>>> like something is missing if they are needed by this one.
>>>
>>>
 diff --git a/target/linux/ipq40xx/config-4.19 
 b/target/linux/ipq40xx/config-4.19
 index 8948b73ff7..3ee921abed 100644
 --- a/target/linux/ipq40xx/config-4.19
 +++ b/target/linux/ipq40xx/config-4.19
 @@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
   CONFIG_MTD_NAND_QCOM=y
   CONFIG_MTD_SPI_NAND=y
   CONFIG_MTD_SPI_NOR=y
 +CONFIG_MTD_SPINAND_MT29F=y
 +CONFIG_MTD_SPINAND_GIGADEVICE=y
 +CONFIG_MTD_SPINAND_ONDIEECC=y
>>>
>>>
>>> The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND
>>>
>>>
   CONFIG_MTD_SPLIT_FIRMWARE=y
   CONFIG_MTD_SPLIT_FIT_FW=y
   CONFIG_MTD_UBI=y

 [...]

 diff --git
 a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
 b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
 new file mode 100644
 index 00..5553bbd166
 --- /dev/null
 +++ 
 b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
 @@ -0,0 +1,371 @@
 +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
 + * Copyright (c) 2019, Nguyen Dinh Phi 
 + *
 + * 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,

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419

2019-10-31 Thread Robert Marko 
On Thu, 31 Oct 2019 at 11:30, Daniel Danzberger  wrote:
>
> I am already using 'ubi.mtd=rootfs root=/dev/ubiblock0_1', which has worked 
> before
Well this is the issue, your ubi.mtd needs to be ubi.mtd=ubi
>
> On 10/31/19 11:26 AM, Robert Marko wrote:
> > On Thu, 31 Oct 2019 at 11:25, Daniel Danzberger  wrote:
> >>
> >> On the deprecated staging driver, it somehow directly came up as "rootfs" 
> >> and
> >> not "ubi". Even though it has been named "ubi" in the dts.
> >> Now the image won't boot because no rootfs is detected:
> >>
> >> 
> >> [1.919001] Creating 1 MTD partitions on "spi0.1":
> >> [1.925399] 0x-0x0800 : "ubi"
> >> [1.940324] random: fast init done
> >> ...
> >> [3.170978] UBI error: cannot open mtd rootfs, error -2
> >> [3.171027] hctosys: unable to open rtc device ([3.180802] Waiting 
> >> for
> >> root device /dev/ubiblock0_1...
> > This is due to your bootargs, you can either use bootargs-append to
> > set rootfs to ubi or change them in bootloader.
> > This is classic on boards derived from QCA reference designs
> >> 
> >>
> >>
> >> On 10/31/19 11:19 AM, Robert Marko wrote:
> >>> On Thu, 31 Oct 2019 at 11:17, Daniel Danzberger  wrote:
> 
>  Using 'compatible = "spi-nand"' worked and the device got detected by the
>  driver. However it won't create and "rootfs" partition like it did 
>  before.
> 
>  ---
>  [1.901930] spi-nand spi0.1: GigaDevice SPI NAND was found.
>  [1.905266] spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 
>  2048,
>  OOB size: 128
>  [1.911015] 1 fixed-partitions partitions found on MTD device spi0.1
>  [1.919010] Creating 1 MTD partitions on "spi0.1":
>  [1.925410] 0x-0x0800 : "ubi"
> >>> It creates the partitions like set in DTS, ubi partition contains both
> >>> kernel and rootfs.
>  ---
> 
> 
>  On 10/30/19 4:51 PM, Jeff Kletsky wrote:
> > On 10/30/19 4:27 AM, Daniel Danzberger wrote:
> >
> >> This device contains 2 flash devices. One NOR (32M) and one NAND 
> >> (128M).
> >> U-boot and caldata are on the NOR, the firmware on the NAND.
> >>
> >>  SoC:IPQ4019
> >>  CPU:4x 710MHz ARMv7
> >>  RAM:256MB
> >>  FLASH:  NOR:32MB NAND:128MB
> >>
> >> [...]
> >>
> >>
> >
> >  .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi   | 1142 +
> >  .../include/dt-bindings/msm/msm-bus-ids.h |  869 +
> >
> > The sudden appearance of a need the MSM bus and its IDs worries me.
> >
> > With 25 devices already on the ipq40xx platform without them, it feels
> > like something is missing if they are needed by this one.
> >
> >
> >> diff --git a/target/linux/ipq40xx/config-4.19 
> >> b/target/linux/ipq40xx/config-4.19
> >> index 8948b73ff7..3ee921abed 100644
> >> --- a/target/linux/ipq40xx/config-4.19
> >> +++ b/target/linux/ipq40xx/config-4.19
> >> @@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
> >>   CONFIG_MTD_NAND_QCOM=y
> >>   CONFIG_MTD_SPI_NAND=y
> >>   CONFIG_MTD_SPI_NOR=y
> >> +CONFIG_MTD_SPINAND_MT29F=y
> >> +CONFIG_MTD_SPINAND_GIGADEVICE=y
> >> +CONFIG_MTD_SPINAND_ONDIEECC=y
> >
> >
> > The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND
> >
> >
> >>   CONFIG_MTD_SPLIT_FIRMWARE=y
> >>   CONFIG_MTD_SPLIT_FIT_FW=y
> >>   CONFIG_MTD_UBI=y
> >>
> >> [...]
> >>
> >> diff --git
> >> a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
> >> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
> >> new file mode 100644
> >> index 00..5553bbd166
> >> --- /dev/null
> >> +++ 
> >> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
> >> @@ -0,0 +1,371 @@
> >> +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
> >> + * Copyright (c) 2019, Nguyen Dinh Phi 
> >> + *
> >> + * 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

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419

2019-10-31 Thread Daniel Danzberger 
I am already using 'ubi.mtd=rootfs root=/dev/ubiblock0_1', which has worked 
before

On 10/31/19 11:26 AM, Robert Marko wrote:
> On Thu, 31 Oct 2019 at 11:25, Daniel Danzberger  wrote:
>>
>> On the deprecated staging driver, it somehow directly came up as "rootfs" and
>> not "ubi". Even though it has been named "ubi" in the dts.
>> Now the image won't boot because no rootfs is detected:
>>
>> 
>> [1.919001] Creating 1 MTD partitions on "spi0.1":
>> [1.925399] 0x-0x0800 : "ubi"
>> [1.940324] random: fast init done
>> ...
>> [3.170978] UBI error: cannot open mtd rootfs, error -2
>> [3.171027] hctosys: unable to open rtc device ([3.180802] Waiting for
>> root device /dev/ubiblock0_1...
> This is due to your bootargs, you can either use bootargs-append to
> set rootfs to ubi or change them in bootloader.
> This is classic on boards derived from QCA reference designs
>> 
>>
>>
>> On 10/31/19 11:19 AM, Robert Marko wrote:
>>> On Thu, 31 Oct 2019 at 11:17, Daniel Danzberger  wrote:

 Using 'compatible = "spi-nand"' worked and the device got detected by the
 driver. However it won't create and "rootfs" partition like it did before.

 ---
 [1.901930] spi-nand spi0.1: GigaDevice SPI NAND was found.
 [1.905266] spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 
 2048,
 OOB size: 128
 [1.911015] 1 fixed-partitions partitions found on MTD device spi0.1
 [1.919010] Creating 1 MTD partitions on "spi0.1":
 [1.925410] 0x-0x0800 : "ubi"
>>> It creates the partitions like set in DTS, ubi partition contains both
>>> kernel and rootfs.
 ---


 On 10/30/19 4:51 PM, Jeff Kletsky wrote:
> On 10/30/19 4:27 AM, Daniel Danzberger wrote:
>
>> This device contains 2 flash devices. One NOR (32M) and one NAND (128M).
>> U-boot and caldata are on the NOR, the firmware on the NAND.
>>
>>  SoC:IPQ4019
>>  CPU:4x 710MHz ARMv7
>>  RAM:256MB
>>  FLASH:  NOR:32MB NAND:128MB
>>
>> [...]
>>
>>
>
>  .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi   | 1142 +
>  .../include/dt-bindings/msm/msm-bus-ids.h |  869 +
>
> The sudden appearance of a need the MSM bus and its IDs worries me.
>
> With 25 devices already on the ipq40xx platform without them, it feels
> like something is missing if they are needed by this one.
>
>
>> diff --git a/target/linux/ipq40xx/config-4.19 
>> b/target/linux/ipq40xx/config-4.19
>> index 8948b73ff7..3ee921abed 100644
>> --- a/target/linux/ipq40xx/config-4.19
>> +++ b/target/linux/ipq40xx/config-4.19
>> @@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
>>   CONFIG_MTD_NAND_QCOM=y
>>   CONFIG_MTD_SPI_NAND=y
>>   CONFIG_MTD_SPI_NOR=y
>> +CONFIG_MTD_SPINAND_MT29F=y
>> +CONFIG_MTD_SPINAND_GIGADEVICE=y
>> +CONFIG_MTD_SPINAND_ONDIEECC=y
>
>
> The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND
>
>
>>   CONFIG_MTD_SPLIT_FIRMWARE=y
>>   CONFIG_MTD_SPLIT_FIT_FW=y
>>   CONFIG_MTD_UBI=y
>>
>> [...]
>>
>> diff --git
>> a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>> new file mode 100644
>> index 00..5553bbd166
>> --- /dev/null
>> +++ 
>> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>> @@ -0,0 +1,371 @@
>> +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
>> + * Copyright (c) 2019, Nguyen Dinh Phi 
>> + *
>> + * 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.
>> + *
>> + */
>> +
>>
>> [...]
>>
>> +
>> +spi_0: spi@78b5000 {
>> +pinctrl-0 = <_0_pins>;
>> +pinctrl-names = "default";
>> +status = "okay";
>> +cs-gpios = < 12 GPIO_ACTIVE_HIGH>, < 41 
>> GPIO_ACTIVE_HIGH>;
>> +num-cs = <2>;
>> +
>> +

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419

2019-10-31 Thread Robert Marko 
On Thu, 31 Oct 2019 at 11:25, Daniel Danzberger  wrote:
>
> On the deprecated staging driver, it somehow directly came up as "rootfs" and
> not "ubi". Even though it has been named "ubi" in the dts.
> Now the image won't boot because no rootfs is detected:
>
> 
> [1.919001] Creating 1 MTD partitions on "spi0.1":
> [1.925399] 0x-0x0800 : "ubi"
> [1.940324] random: fast init done
> ...
> [3.170978] UBI error: cannot open mtd rootfs, error -2
> [3.171027] hctosys: unable to open rtc device ([3.180802] Waiting for
> root device /dev/ubiblock0_1...
This is due to your bootargs, you can either use bootargs-append to
set rootfs to ubi or change them in bootloader.
This is classic on boards derived from QCA reference designs
> 
>
>
> On 10/31/19 11:19 AM, Robert Marko wrote:
> > On Thu, 31 Oct 2019 at 11:17, Daniel Danzberger  wrote:
> >>
> >> Using 'compatible = "spi-nand"' worked and the device got detected by the
> >> driver. However it won't create and "rootfs" partition like it did before.
> >>
> >> ---
> >> [1.901930] spi-nand spi0.1: GigaDevice SPI NAND was found.
> >> [1.905266] spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 
> >> 2048,
> >> OOB size: 128
> >> [1.911015] 1 fixed-partitions partitions found on MTD device spi0.1
> >> [1.919010] Creating 1 MTD partitions on "spi0.1":
> >> [1.925410] 0x-0x0800 : "ubi"
> > It creates the partitions like set in DTS, ubi partition contains both
> > kernel and rootfs.
> >> ---
> >>
> >>
> >> On 10/30/19 4:51 PM, Jeff Kletsky wrote:
> >>> On 10/30/19 4:27 AM, Daniel Danzberger wrote:
> >>>
>  This device contains 2 flash devices. One NOR (32M) and one NAND (128M).
>  U-boot and caldata are on the NOR, the firmware on the NAND.
> 
>   SoC:IPQ4019
>   CPU:4x 710MHz ARMv7
>   RAM:256MB
>   FLASH:  NOR:32MB NAND:128MB
> 
>  [...]
> 
> 
> >>>
> >>>  .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi   | 1142 +
> >>>  .../include/dt-bindings/msm/msm-bus-ids.h |  869 +
> >>>
> >>> The sudden appearance of a need the MSM bus and its IDs worries me.
> >>>
> >>> With 25 devices already on the ipq40xx platform without them, it feels
> >>> like something is missing if they are needed by this one.
> >>>
> >>>
>  diff --git a/target/linux/ipq40xx/config-4.19 
>  b/target/linux/ipq40xx/config-4.19
>  index 8948b73ff7..3ee921abed 100644
>  --- a/target/linux/ipq40xx/config-4.19
>  +++ b/target/linux/ipq40xx/config-4.19
>  @@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
>    CONFIG_MTD_NAND_QCOM=y
>    CONFIG_MTD_SPI_NAND=y
>    CONFIG_MTD_SPI_NOR=y
>  +CONFIG_MTD_SPINAND_MT29F=y
>  +CONFIG_MTD_SPINAND_GIGADEVICE=y
>  +CONFIG_MTD_SPINAND_ONDIEECC=y
> >>>
> >>>
> >>> The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND
> >>>
> >>>
>    CONFIG_MTD_SPLIT_FIRMWARE=y
>    CONFIG_MTD_SPLIT_FIT_FW=y
>    CONFIG_MTD_UBI=y
> 
>  [...]
> 
>  diff --git
>  a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>  b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>  new file mode 100644
>  index 00..5553bbd166
>  --- /dev/null
>  +++ 
>  b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>  @@ -0,0 +1,371 @@
>  +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
>  + * Copyright (c) 2019, Nguyen Dinh Phi 
>  + *
>  + * 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.
>  + *
>  + */
>  +
> 
>  [...]
> 
>  +
>  +spi_0: spi@78b5000 {
>  +pinctrl-0 = <_0_pins>;
>  +pinctrl-names = "default";
>  +status = "okay";
>  +cs-gpios = < 12 GPIO_ACTIVE_HIGH>, < 41 
>  GPIO_ACTIVE_HIGH>;
>  +num-cs = <2>;
>  +
>  +m25p80@0 {
>  +#address-cells = <1>;
>  +#size-cells = <1>;
>  +reg = <0>;
>

Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid

2019-10-31 Thread tapper via openwrt-devel 
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 31/10/2019 10:00, 大雄 wrote:

Hi,
     I think what  you said is right.
     But, logic is not the same with  openwrt 15.05

*From:* Felix Fietkau 
*Date:* 2019-10-31 17:50
*To:* 大雄 ; Hauke Mehrtens
; openwrt-devel

*Subject:* Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip
invalid
On 2019-10-31 10:43, 大雄 wrote:
 > Hi,
 >
 >     But sometimes,  .ko not in menuconfig option.
 >     It's in the kernel_menuconfig option.
 >     So is no through ipk processing.
In that case the solution is to add a package for it.
- Felix


openwrt 15.05 is very very very out of date!
What happens in openwrt 15.05 is not relevant!
We are getting ready to release OpenWrt 19.07


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




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419

2019-10-31 Thread Daniel Danzberger 
On the deprecated staging driver, it somehow directly came up as "rootfs" and
not "ubi". Even though it has been named "ubi" in the dts.
Now the image won't boot because no rootfs is detected:


[1.919001] Creating 1 MTD partitions on "spi0.1":
[1.925399] 0x-0x0800 : "ubi"
[1.940324] random: fast init done
...
[3.170978] UBI error: cannot open mtd rootfs, error -2
[3.171027] hctosys: unable to open rtc device ([3.180802] Waiting for
root device /dev/ubiblock0_1...



On 10/31/19 11:19 AM, Robert Marko wrote:
> On Thu, 31 Oct 2019 at 11:17, Daniel Danzberger  wrote:
>>
>> Using 'compatible = "spi-nand"' worked and the device got detected by the
>> driver. However it won't create and "rootfs" partition like it did before.
>>
>> ---
>> [1.901930] spi-nand spi0.1: GigaDevice SPI NAND was found.
>> [1.905266] spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 
>> 2048,
>> OOB size: 128
>> [1.911015] 1 fixed-partitions partitions found on MTD device spi0.1
>> [1.919010] Creating 1 MTD partitions on "spi0.1":
>> [1.925410] 0x-0x0800 : "ubi"
> It creates the partitions like set in DTS, ubi partition contains both
> kernel and rootfs.
>> ---
>>
>>
>> On 10/30/19 4:51 PM, Jeff Kletsky wrote:
>>> On 10/30/19 4:27 AM, Daniel Danzberger wrote:
>>>
 This device contains 2 flash devices. One NOR (32M) and one NAND (128M).
 U-boot and caldata are on the NOR, the firmware on the NAND.

  SoC:IPQ4019
  CPU:4x 710MHz ARMv7
  RAM:256MB
  FLASH:  NOR:32MB NAND:128MB

 [...]


>>>
>>>  .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi   | 1142 +
>>>  .../include/dt-bindings/msm/msm-bus-ids.h |  869 +
>>>
>>> The sudden appearance of a need the MSM bus and its IDs worries me.
>>>
>>> With 25 devices already on the ipq40xx platform without them, it feels
>>> like something is missing if they are needed by this one.
>>>
>>>
 diff --git a/target/linux/ipq40xx/config-4.19 
 b/target/linux/ipq40xx/config-4.19
 index 8948b73ff7..3ee921abed 100644
 --- a/target/linux/ipq40xx/config-4.19
 +++ b/target/linux/ipq40xx/config-4.19
 @@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
   CONFIG_MTD_NAND_QCOM=y
   CONFIG_MTD_SPI_NAND=y
   CONFIG_MTD_SPI_NOR=y
 +CONFIG_MTD_SPINAND_MT29F=y
 +CONFIG_MTD_SPINAND_GIGADEVICE=y
 +CONFIG_MTD_SPINAND_ONDIEECC=y
>>>
>>>
>>> The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND
>>>
>>>
   CONFIG_MTD_SPLIT_FIRMWARE=y
   CONFIG_MTD_SPLIT_FIT_FW=y
   CONFIG_MTD_UBI=y

 [...]

 diff --git
 a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
 b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
 new file mode 100644
 index 00..5553bbd166
 --- /dev/null
 +++ 
 b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
 @@ -0,0 +1,371 @@
 +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
 + * Copyright (c) 2019, Nguyen Dinh Phi 
 + *
 + * 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.
 + *
 + */
 +

 [...]

 +
 +spi_0: spi@78b5000 {
 +pinctrl-0 = <_0_pins>;
 +pinctrl-names = "default";
 +status = "okay";
 +cs-gpios = < 12 GPIO_ACTIVE_HIGH>, < 41 
 GPIO_ACTIVE_HIGH>;
 +num-cs = <2>;
 +
 +m25p80@0 {
 +#address-cells = <1>;
 +#size-cells = <1>;
 +reg = <0>;
 +linux,modalias = "m25p80", "n25q128a11";
 +compatible = "jedec,spi-nor", "n25q128a11";
 +spi-max-frequency = <2400>;
>>>
>>>
>>> I don't think you need linux,modalias here, nor the chip type in the 
>>> compatible
>>> line.
>>> I believe that the following compatible line is sufficient
>>>
>>> compatible = "jedec,spi-nor";
>>>
>>>
>>> You might also want to consider "flash@0" or "nor@0" or "nor_flash@0",
>>> or the like, rather than a

Re: [OpenWrt-Devel] v5.4 as next kernel

2019-10-31 Thread Koen Vandeputte 


On 29.10.19 06:37, John Crispin wrote:

Hi,
should we use v5.4 as our next kernel ?
John



From my point of view: yes
I also really like the cadence of just following LTS release schedule 
which doesn't enforce a hard deadline to do major bumps or risking 
drying up of fixes from Stable



Lots of stuff gets backported when newer kernels arrive, so maybe avoid 
that effort and invest it in just bumping the whole thing
I often hear from people around me that OpenWrt looks like a "garbage 
bin of files" due to all custom patches

This would be one way to reduce the amount ..

Still a lot of targets are on 4.14, we might as well just bump then to 
5.4 iso of first to 4.19 to eventually get to 5.4


By the time 19.07 will be released, 5.4 will probably be on our doorstep 
and I don't see us make another major release within 1 .. 2 months after 
19.07


Using mac80211 from a newer kernel seems to work well, but judging by 
the amount of changes in Hauke's updates
seems to indicate it's a lot more work if the gap between kernel and 
mac80211 versions widens up.



It's OK to be mainstream, but it's a lot more motivating (and fun!) to 
be bleeding edge.


Koen


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

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419

2019-10-31 Thread Robert Marko 
On Thu, 31 Oct 2019 at 11:17, Daniel Danzberger  wrote:
>
> Using 'compatible = "spi-nand"' worked and the device got detected by the
> driver. However it won't create and "rootfs" partition like it did before.
>
> ---
> [1.901930] spi-nand spi0.1: GigaDevice SPI NAND was found.
> [1.905266] spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 2048,
> OOB size: 128
> [1.911015] 1 fixed-partitions partitions found on MTD device spi0.1
> [1.919010] Creating 1 MTD partitions on "spi0.1":
> [1.925410] 0x-0x0800 : "ubi"
It creates the partitions like set in DTS, ubi partition contains both
kernel and rootfs.
> ---
>
>
> On 10/30/19 4:51 PM, Jeff Kletsky wrote:
> > On 10/30/19 4:27 AM, Daniel Danzberger wrote:
> >
> >> This device contains 2 flash devices. One NOR (32M) and one NAND (128M).
> >> U-boot and caldata are on the NOR, the firmware on the NAND.
> >>
> >>  SoC:IPQ4019
> >>  CPU:4x 710MHz ARMv7
> >>  RAM:256MB
> >>  FLASH:  NOR:32MB NAND:128MB
> >>
> >> [...]
> >>
> >>
> >
> >  .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi   | 1142 +
> >  .../include/dt-bindings/msm/msm-bus-ids.h |  869 +
> >
> > The sudden appearance of a need the MSM bus and its IDs worries me.
> >
> > With 25 devices already on the ipq40xx platform without them, it feels
> > like something is missing if they are needed by this one.
> >
> >
> >> diff --git a/target/linux/ipq40xx/config-4.19 
> >> b/target/linux/ipq40xx/config-4.19
> >> index 8948b73ff7..3ee921abed 100644
> >> --- a/target/linux/ipq40xx/config-4.19
> >> +++ b/target/linux/ipq40xx/config-4.19
> >> @@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
> >>   CONFIG_MTD_NAND_QCOM=y
> >>   CONFIG_MTD_SPI_NAND=y
> >>   CONFIG_MTD_SPI_NOR=y
> >> +CONFIG_MTD_SPINAND_MT29F=y
> >> +CONFIG_MTD_SPINAND_GIGADEVICE=y
> >> +CONFIG_MTD_SPINAND_ONDIEECC=y
> >
> >
> > The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND
> >
> >
> >>   CONFIG_MTD_SPLIT_FIRMWARE=y
> >>   CONFIG_MTD_SPLIT_FIT_FW=y
> >>   CONFIG_MTD_UBI=y
> >>
> >> [...]
> >>
> >> diff --git
> >> a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
> >> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
> >> new file mode 100644
> >> index 00..5553bbd166
> >> --- /dev/null
> >> +++ 
> >> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
> >> @@ -0,0 +1,371 @@
> >> +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
> >> + * Copyright (c) 2019, Nguyen Dinh Phi 
> >> + *
> >> + * 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.
> >> + *
> >> + */
> >> +
> >>
> >> [...]
> >>
> >> +
> >> +spi_0: spi@78b5000 {
> >> +pinctrl-0 = <_0_pins>;
> >> +pinctrl-names = "default";
> >> +status = "okay";
> >> +cs-gpios = < 12 GPIO_ACTIVE_HIGH>, < 41 
> >> GPIO_ACTIVE_HIGH>;
> >> +num-cs = <2>;
> >> +
> >> +m25p80@0 {
> >> +#address-cells = <1>;
> >> +#size-cells = <1>;
> >> +reg = <0>;
> >> +linux,modalias = "m25p80", "n25q128a11";
> >> +compatible = "jedec,spi-nor", "n25q128a11";
> >> +spi-max-frequency = <2400>;
> >
> >
> > I don't think you need linux,modalias here, nor the chip type in the 
> > compatible
> > line.
> > I believe that the following compatible line is sufficient
> >
> > compatible = "jedec,spi-nor";
> >
> >
> > You might also want to consider "flash@0" or "nor@0" or "nor_flash@0",
> > or the like, rather than a chip-specific name. (I'm not a committer.)
> >
> >
> >> +
> >> +partitions {
> >> +compatible = "fixed-partitions";
> >> +
> >> +partition@0 {
> >> +label = "0:SBL1";
> >> +reg = <0x00 0x04>;
> >> +read-only;
> >> +};
> >> +
> >> +partition@4 {
> >> +label = "0:MIBIB";
> >> +reg = <0x04 0x02>;
> >> +read-only;
> >> +};
>

Re: [OpenWrt-Devel] [PATCH 3/3] ipq40xx: ipq4019: Add new device Compex WPJ419

2019-10-31 Thread Daniel Danzberger 
Using 'compatible = "spi-nand"' worked and the device got detected by the
driver. However it won't create and "rootfs" partition like it did before.

---
[1.901930] spi-nand spi0.1: GigaDevice SPI NAND was found.
[1.905266] spi-nand spi0.1: 128 MiB, block size: 128 KiB, page size: 2048,
OOB size: 128
[1.911015] 1 fixed-partitions partitions found on MTD device spi0.1
[1.919010] Creating 1 MTD partitions on "spi0.1":
[1.925410] 0x-0x0800 : "ubi"
---


On 10/30/19 4:51 PM, Jeff Kletsky wrote:
> On 10/30/19 4:27 AM, Daniel Danzberger wrote:
> 
>> This device contains 2 flash devices. One NOR (32M) and one NAND (128M).
>> U-boot and caldata are on the NOR, the firmware on the NAND.
>>
>>  SoC:    IPQ4019
>>  CPU:    4x 710MHz ARMv7
>>  RAM:    256MB
>>  FLASH:  NOR:32MB NAND:128MB
>>
>> [...]
>>
>>
> 
>  .../arch/arm/boot/dts/qcom-ipq4019-bus.dtsi   | 1142 +
>  .../include/dt-bindings/msm/msm-bus-ids.h |  869 +
> 
> The sudden appearance of a need the MSM bus and its IDs worries me.
> 
> With 25 devices already on the ipq40xx platform without them, it feels
> like something is missing if they are needed by this one.
> 
> 
>> diff --git a/target/linux/ipq40xx/config-4.19 
>> b/target/linux/ipq40xx/config-4.19
>> index 8948b73ff7..3ee921abed 100644
>> --- a/target/linux/ipq40xx/config-4.19
>> +++ b/target/linux/ipq40xx/config-4.19
>> @@ -303,6 +303,9 @@ CONFIG_MTD_NAND_ECC=y
>>   CONFIG_MTD_NAND_QCOM=y
>>   CONFIG_MTD_SPI_NAND=y
>>   CONFIG_MTD_SPI_NOR=y
>> +CONFIG_MTD_SPINAND_MT29F=y
>> +CONFIG_MTD_SPINAND_GIGADEVICE=y
>> +CONFIG_MTD_SPINAND_ONDIEECC=y
> 
> 
> The CONFIG_SPINAND_* additions are not required for upstream SPI-NAND
> 
> 
>>   CONFIG_MTD_SPLIT_FIRMWARE=y
>>   CONFIG_MTD_SPLIT_FIT_FW=y
>>   CONFIG_MTD_UBI=y
>>
>> [...]
>>
>> diff --git
>> a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>> new file mode 100644
>> index 00..5553bbd166
>> --- /dev/null
>> +++ 
>> b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-wpj419.dts
>> @@ -0,0 +1,371 @@
>> +/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
>> + * Copyright (c) 2019, Nguyen Dinh Phi 
>> + *
>> + * 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.
>> + *
>> + */
>> +
>>
>> [...]
>>
>> +
>> +    spi_0: spi@78b5000 {
>> +    pinctrl-0 = <_0_pins>;
>> +    pinctrl-names = "default";
>> +    status = "okay";
>> +    cs-gpios = < 12 GPIO_ACTIVE_HIGH>, < 41 
>> GPIO_ACTIVE_HIGH>;
>> +    num-cs = <2>;
>> +
>> +    m25p80@0 {
>> +    #address-cells = <1>;
>> +    #size-cells = <1>;
>> +    reg = <0>;
>> +    linux,modalias = "m25p80", "n25q128a11";
>> +    compatible = "jedec,spi-nor", "n25q128a11";
>> +    spi-max-frequency = <2400>;
> 
> 
> I don't think you need linux,modalias here, nor the chip type in the 
> compatible
> line.
> I believe that the following compatible line is sufficient
> 
>     compatible = "jedec,spi-nor";
> 
> 
> You might also want to consider "flash@0" or "nor@0" or "nor_flash@0",
> or the like, rather than a chip-specific name. (I'm not a committer.)
> 
> 
>> +
>> +    partitions {
>> +    compatible = "fixed-partitions";
>> +
>> +    partition@0 {
>> +    label = "0:SBL1";
>> +    reg = <0x00 0x04>;
>> +    read-only;
>> +    };
>> +
>> +    partition@4 {
>> +    label = "0:MIBIB";
>> +    reg = <0x04 0x02>;
>> +    read-only;
>> +    };
>> +
>> +    partition@6 {
>> +    label = "0:QSEE";
>> +    reg = <0x06 0x06>;
>> +    read-only;
>> +    };
>> +
>> +    partition@c {
>> +    label = "0:CDT";
>> +    reg = <0x0c 0x01>;
>> +    read-only;
>> +   

Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid

2019-10-31 Thread 大雄 
Hi,
I think what  you said is right.
But, logic is not the same with  openwrt 15.05

 
From: Felix Fietkau
Date: 2019-10-31 17:50
To: 大雄; Hauke Mehrtens; openwrt-devel
Subject: Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid
On 2019-10-31 10:43, 大雄 wrote:
> Hi,
> 
> But sometimes,  .ko not in menuconfig option.
> It's in the kernel_menuconfig option.
> So is no through ipk processing.
In that case the solution is to add a package for it.
 
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid

2019-10-31 Thread Felix Fietkau 
On 2019-10-31 10:43, 大雄 wrote:
> Hi,
>     
>     But sometimes,  .ko not in menuconfig option.
>     It's in the kernel_menuconfig option.
>     So is no through ipk processing.
In that case the solution is to add a package for it.

- Felix

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

Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid

2019-10-31 Thread 大雄 
Hi,

But sometimes,  .ko not in menuconfig option.
It's in the kernel_menuconfig option.
So is no through ipk processing.
   
There is no such problem in OpenWRT 15.05

From: Felix Fietkau
Date: 2019-10-31 17:24
To: 大雄; Hauke Mehrtens; openwrt-devel
Subject: Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid
On 2019-10-31 09:19, 大雄 wrote:
> Hi,
> 
> I compile the kernel options, without any special open the DEBUG
> options.
> But the compiled KO module size is very big.
debug symbols are enabled by default. The .ko in the kernel tree is
quite big, but the one that ends up in the .ipk or on the root
filesystem should be small.
 
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] v5.4 as next kernel

2019-10-31 Thread Bjørn Mork 
John Crispin  writes:

> Hi,
> should we use v5.4 as our next kernel ?

Hello John!

I am still struggling to understand how the project makes release
decisions.  I don't think your question makes sense without considering
target release dates, at least in a yearly resolution, given the massive
amount of work involved with switching kernel versions.

So my question is: Is it realistic to expect an OpenWrt release with
v5.4 next year?

Because if it isn't, then v5.4 is really a waste of time IMHO. You
should target the next longterm kernel after v5.4 instead for the first
2021 release.

And of course, if you think a 2020 release with v5.4 is realistic, then
there's an open question on what to do with v4.19.  Are two OpenWrt
releases next year likely/possible?  If not, then v5.4 should probably
replace v4.19 as the current target kernel as soon as possible.

Yes, I know what your meeting minutes says.  But two releases in 2019 is
obviously not going to happen. And personally I don't see how that's
suddenly going to change for 2020 unless you do something drastic to
simplify the release process. Yes, that means lowering the standards.
Maybe making releases that won't be maintained, and therefore don't need
to be "future proof"?


Bjørn


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

Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid

2019-10-31 Thread Felix Fietkau 
On 2019-10-31 09:19, 大雄 wrote:
> Hi,
> 
>     I compile the kernel options, without any special open the DEBUG
> options.
>     But the compiled KO module size is very big.
debug symbols are enabled by default. The .ko in the kernel tree is
quite big, but the one that ends up in the .ipk or on the root
filesystem should be small.

- Felix

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

Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid

2019-10-31 Thread 大雄 
Hi,

I compile the kernel options, without any special open the DEBUG options.
But the compiled KO module size is very big.


 
From: Felix Fietkau
Date: 2019-10-31 15:31
To: 大雄; Hauke Mehrtens; openwrt-devel
Subject: Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid
Hi,
 
I don't think this patch is correct. The purpose of the existing
204-module_strip.patch is completely different from the stripping
behavior that you introduce, and you haven't described what issues you
have with the existing code.
Also, running strip inside the kernel build system is a bad idea,
because the build system already strips all kernel modules when packaging.
The .ko files inside the kernel tree should still contain debug symbols,
because that is needed for debugging.
 
- Felix
 
On 2019-10-31 02:46, 大雄 wrote:
> Build file drivers/net/ethernet/intel/e1000e/e1000e.ko size about 920KB
> for old PATCH.
> After the new patch is about 177KB
> 
> *From:* Hauke Mehrtens 
> *Date:* 2019-10-30 23:47
> *To:* daxiong ; openwrt-devel
> 
> *Subject:* Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip
> invalid
> On 10/30/19 11:14 AM, daxiong wrote:
> > Current modpost cannot reduce the module size.
> >
> > Use $(STRIP) command to replace the modpost patch,
> > I think to be compatibility will be better.
> >
> > Signed-off-by: daxiong 
>  
> Please base this against master, then we can backport it to 19.07.
>  
> Could you please elaborate a little bit more how module-strip provides
> better results than the previous patch? It would be nice if you could
> also provide some numbers to compare the previous size and the
> current size.
>  
> Would it make sense to do both together, what was done in this patch
> before and after your change?
>  
> Hauke
>  
> > ---
> >  .../linux/generic/hack-4.14/204-module_strip.patch | 216
> +++--
> >  1 file changed, 24 insertions(+), 192 deletions(-)
> >
> > diff --git a/target/linux/generic/hack-4.14/204-module_strip.patch
> b/target/linux/generic/hack-4.14/204-module_strip.patch
> > index d847adf..c22a507 100644
> > --- a/target/linux/generic/hack-4.14/204-module_strip.patch
> > +++ b/target/linux/generic/hack-4.14/204-module_strip.patch
> > @@ -1,104 +1,8 @@
> > -From a779a482fb9b9f8fcdf8b2519c789b4b9bb5dd05 Mon Sep 17 00:00:00
> 2001
> > -From: Felix Fietkau 
> > -Date: Fri, 7 Jul 2017 16:56:48 +0200
> > -Subject: build: add a hack for removing non-essential module info
> > -
> > -Signed-off-by: Felix Fietkau 
> > 
> > - include/linux/module.h  | 13 -
> > - include/linux/moduleparam.h | 15 ---
> > - init/Kconfig|  7 +++
> > - kernel/module.c |  5 -
> > - scripts/mod/modpost.c   | 12 
> > - 5 files changed, 43 insertions(+), 9 deletions(-)
> > -
> >  a/include/linux/module.h
> > -+++ b/include/linux/module.h
> > -@@ -158,6 +158,7 @@ extern void cleanup_module(void);
> > -
> > - /* Generic info of form tag = "info" */
> > - #define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
> > -+#define MODULE_INFO_STRIP(tag, info) __MODULE_INFO_STRIP(tag,
> tag, info)
> > -
> > - /* For userspace: you can also call me... */
> > - #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
> > -@@ -201,12 +202,12 @@ extern void cleanup_module(void);
> > -  * Author(s), use "Name " or just "Name", for multiple
> > -  * authors use multiple MODULE_AUTHOR() statements/lines.
> > -  */
> > --#define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
> > -+#define MODULE_AUTHOR(_author) MODULE_INFO_STRIP(author, _author)
> > -
> > - /* What your module does. */
> > --#define MODULE_DESCRIPTION(_description)
> MODULE_INFO(description, _description)
> > -+#define MODULE_DESCRIPTION(_description)
> MODULE_INFO_STRIP(description, _description)
> > -
> > --#ifdef MODULE
> > -+#if defined(MODULE) && !defined(CONFIG_MODULE_STRIPPED)
> > - /* Creates an alias so file2alias.c can find device table. */
> > - #define MODULE_DEVICE_TABLE(type, name) \
> > - extern typeof(name) __mod_##type##__##name##_device_table \
> > -@@ -233,7 +234,9 @@ extern typeof(name) __mod_##type##__##na
> > -  */
> > -
> > - #if defined(MODULE) || !defined(CONFIG_SYSFS)
> > --#define MODULE_VERSION(_version) MODULE_INFO(version, _version)
> > -+#define MODULE_VERSION(_version) MODULE_INFO_STRIP(version,
> _version)
> > -+#elif defined(CONFIG_MODULE_STRIPPED)
> > -+#define MODULE_VERSION(_version) __MODULE_INFO_DISABLED(version)
> > - #else
> > - #define

[OpenWrt-Devel] [PATCH] hostapd: add IEEE 802.11k support

2019-10-31 Thread Kyle Copperfield via openwrt-devel 
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 ---
Add IEEE802.11k neighbor and beacon report
 Original patch by Lorenzo Santina @BigNerd95 on GH
 
 Ported to latest OpenWRT

---
 package/network/services/hostapd/files/hostapd.sh | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index 8da8539e8a..dee436c6d2 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -223,6 +223,8 @@ hostapd_common_add_bss_config() {
config_add_int time_advertisement
config_add_string time_zone

+   config_add_boolean rrm_neighbor_report rrm_beacon_report
+
config_add_boolean ieee80211r pmk_r1_push ft_psk_generate_local 
ft_over_ds
config_add_int r0_key_lifetime reassociation_deadline
config_add_string mobility_domain r1_key_holder
@@ -265,7 +267,8 @@ hostapd_set_bss_options() {
iapp_interface eapol_version dynamic_vlan ieee80211w nasid \
acct_server acct_secret acct_port acct_interval \
bss_load_update_period chan_util_avg_period sae_require_mfp \
-   multi_ap multi_ap_backhaul_ssid multi_ap_backhaul_key
+   multi_ap multi_ap_backhaul_ssid multi_ap_backhaul_key \
+   rrm_neighbor_report rrm_beacon_report

set_default isolate 0
set_default maxassoc 0
@@ -489,6 +492,11 @@ hostapd_set_bss_options() {
append bss_conf "bss_transition=$bss_transition" "$N"
fi

+   set_default rrm_neighbor_report 0
+   set_default rrm_beacon_report 0
+   append bss_conf "rrm_neighbor_report=$rrm_neighbor_report" "$N"
+   append bss_conf "rrm_beacon_report=$rrm_beacon_report" "$N"
+
if [ "$wpa" -ge "1" ]; then
json_get_vars ieee80211r
set_default ieee80211r 0
-- 
2.23.0




--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip invalid

2019-10-31 Thread Felix Fietkau 
Hi,

I don't think this patch is correct. The purpose of the existing
204-module_strip.patch is completely different from the stripping
behavior that you introduce, and you haven't described what issues you
have with the existing code.
Also, running strip inside the kernel build system is a bad idea,
because the build system already strips all kernel modules when packaging.
The .ko files inside the kernel tree should still contain debug symbols,
because that is needed for debugging.

- Felix

On 2019-10-31 02:46, 大雄 wrote:
> Build file drivers/net/ethernet/intel/e1000e/e1000e.ko size about 920KB
> for old PATCH.
> After the new patch is about 177KB
> 
> *From:* Hauke Mehrtens 
> *Date:* 2019-10-30 23:47
> *To:* daxiong ; openwrt-devel
> 
> *Subject:* Re: [OpenWrt-Devel] [PATCH-19.07] build: fix module strip
> invalid
> On 10/30/19 11:14 AM, daxiong wrote:
> > Current modpost cannot reduce the module size.
> >
> > Use $(STRIP) command to replace the modpost patch,
> > I think to be compatibility will be better.
> >
> > Signed-off-by: daxiong 
>  
> Please base this against master, then we can backport it to 19.07.
>  
> Could you please elaborate a little bit more how module-strip provides
> better results than the previous patch? It would be nice if you could
> also provide some numbers to compare the previous size and the
> current size.
>  
> Would it make sense to do both together, what was done in this patch
> before and after your change?
>  
> Hauke
>  
> > ---
> >  .../linux/generic/hack-4.14/204-module_strip.patch | 216
> +++--
> >  1 file changed, 24 insertions(+), 192 deletions(-)
> >
> > diff --git a/target/linux/generic/hack-4.14/204-module_strip.patch
> b/target/linux/generic/hack-4.14/204-module_strip.patch
> > index d847adf..c22a507 100644
> > --- a/target/linux/generic/hack-4.14/204-module_strip.patch
> > +++ b/target/linux/generic/hack-4.14/204-module_strip.patch
> > @@ -1,104 +1,8 @@
> > -From a779a482fb9b9f8fcdf8b2519c789b4b9bb5dd05 Mon Sep 17 00:00:00
> 2001
> > -From: Felix Fietkau 
> > -Date: Fri, 7 Jul 2017 16:56:48 +0200
> > -Subject: build: add a hack for removing non-essential module info
> > -
> > -Signed-off-by: Felix Fietkau 
> > 
> > - include/linux/module.h  | 13 -
> > - include/linux/moduleparam.h | 15 ---
> > - init/Kconfig    |  7 +++
> > - kernel/module.c |  5 -
> > - scripts/mod/modpost.c   | 12 
> > - 5 files changed, 43 insertions(+), 9 deletions(-)
> > -
> >  a/include/linux/module.h
> > -+++ b/include/linux/module.h
> > -@@ -158,6 +158,7 @@ extern void cleanup_module(void);
> > -
> > - /* Generic info of form tag = "info" */
> > - #define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
> > -+#define MODULE_INFO_STRIP(tag, info) __MODULE_INFO_STRIP(tag,
> tag, info)
> > -
> > - /* For userspace: you can also call me... */
> > - #define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
> > -@@ -201,12 +202,12 @@ extern void cleanup_module(void);
> > -  * Author(s), use "Name " or just "Name", for multiple
> > -  * authors use multiple MODULE_AUTHOR() statements/lines.
> > -  */
> > --#define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
> > -+#define MODULE_AUTHOR(_author) MODULE_INFO_STRIP(author, _author)
> > -
> > - /* What your module does. */
> > --#define MODULE_DESCRIPTION(_description)
> MODULE_INFO(description, _description)
> > -+#define MODULE_DESCRIPTION(_description)
> MODULE_INFO_STRIP(description, _description)
> > -
> > --#ifdef MODULE
> > -+#if defined(MODULE) && !defined(CONFIG_MODULE_STRIPPED)
> > - /* Creates an alias so file2alias.c can find device table. */
> > - #define MODULE_DEVICE_TABLE(type, name) \
> > - extern typeof(name) __mod_##type##__##name##_device_table \
> > -@@ -233,7 +234,9 @@ extern typeof(name) __mod_##type##__##na
> > -  */
> > -
> > - #if defined(MODULE) || !defined(CONFIG_SYSFS)
> > --#define MODULE_VERSION(_version) MODULE_INFO(version, _version)
> > -+#define MODULE_VERSION(_version) MODULE_INFO_STRIP(version,
> _version)
> > -+#elif defined(CONFIG_MODULE_STRIPPED)
> > -+#define MODULE_VERSION(_version) __MODULE_INFO_DISABLED(version)
> > - #else
> > - #define MODULE_VERSION(_version) \
> > - static struct module_version_attribute ___modver_attr = { \
> > -@@ -255,7 +258,7 @@ extern typeof(name) __mod_##type##__##na
> > - /* Optional firmware file (or files) needed by the module
> > -  * format is simply firmware file name.  Multiple firmware
> >