[OpenWrt-Devel] Fw: add support for netgear R6020

2020-05-28 Thread Evan Jobling
>
>
>From: Evan Jobling 
>Sent: Friday, 29 May 2020 2:45 PM
>To: openwrt-devel@lists.openwrt.org
>Subject: add support for netgear R6020
>
>Hi All.
>
>Apologies if this isn't the correct method of submitting a patch.
>
>There was a patch on github for adding the R6020?
>
>Didn't look like it went anywhere.
>I recall issues with the LED naming on that one?
>
>Just so it doesn't get lost to time, I figured i'd email my modifications.
>
>Please find patch attached.

Apologies, I forgot to include the modifications, and only put in the new file.
Please find additional file attached.

>
> I may still have an original boot log, if you want it?
>
>Cheers,
>Evan.
>

diff --git target/linux/ramips/dts/mt7628an_netgear_r6020.dts target/linux/ramips/dts/mt7628an_netgear_r6020.dts
new file mode 100644
index 00..3492273840
--- /dev/null
+++ target/linux/ramips/dts/mt7628an_netgear_r6020.dts
@@ -0,0 +1,149 @@
+/dts-v1/;
+
+#include "mt7628an.dtsi"
+
+#include 
+#include 
+
+/ {
+	compatible = "netgear,r6020", "mediatek,mt7628an-soc";
+	model = "Netgear AC750 R6020";
+
+	aliases {
+		led-boot = _power;
+		led-failsafe = _power;
+		led-running = _power;
+		led-upgrade = _power;
+	};
+
+	memory@0 {
+		device_type = "memory";
+		reg = <0x0 0x400>;
+	};
+
+	gpio-keys-polled {
+		compatible = "gpio-keys-polled";
+		poll-interval = <20>;
+
+		reset {
+			label = "reset";
+			gpios = < 6 GPIO_ACTIVE_LOW>;
+			linux,code = ;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		lan {
+			label = "r6020:green:lan";
+			gpios = < 12 GPIO_ACTIVE_LOW>;
+		};
+
+		led_power: power {
+			label = "r6020:green:power";
+			gpios = < 11 GPIO_ACTIVE_LOW>;
+		};
+
+		wlan {
+			label = "r6020:green:wlan2g";
+			gpios = < 10 GPIO_ACTIVE_LOW>;
+		};
+
+		wlan_orange {
+			label = "r6020:orange:wlan2g";
+			gpios = < 9 GPIO_ACTIVE_LOW>;
+		};
+
+		wlan5 {
+			label = "r6020:green:wlan5g";
+			gpios = < 8 GPIO_ACTIVE_LOW>;
+		};
+
+		wlan5_orange {
+			label = "r6020:orange:wlan5g";
+			gpios = < 7 GPIO_ACTIVE_LOW>;
+		};
+	};
+};
+
+ {
+	state_default: pinctrl0 {
+		gpio {
+			ralink,group = "p0led_an", "p1led_an", "p2led_an",
+   "p3led_an", "p4led_an", "wdt", "wled_an";
+			ralink,function = "gpio";
+		};
+	};
+};
+
+ {
+	status = "okay";
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <1000>;
+		m25p,chunked-io = <32>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+label = "u-boot";
+reg = <0x0 0x4>;
+read-only;
+			};
+
+			factory: partition@4 {
+label = "factory";
+reg = <0x4 0x2>;
+read-only;
+			};
+
+			nvram: partition@6 {
+label = "nvram";
+reg = <0x6 0x3>;
+read-only;
+			};
+
+			partition@9 {
+compatible = "denx,uimage";
+label = "firmware";
+reg = <0x9 0x6f>;
+			};
+
+			partition@78 {
+label = "reserved";
+reg = <0x78 0x8>;
+read-only;
+			};
+		};
+	};
+};
+
+ {
+	status = "okay";
+	mtd-mac-address = < 0x100b0>;
+	mediatek,mtd-eeprom = < 0x2>;
+};
+
+ {
+	mtd-mac-address = < 0x100b0>;
+};
+
+ {
+	status = "okay";
+};
+
+ {
+	wifi@0,0 {
+		reg = <0x 0 0 0 0>;
+		mediatek,mtd-eeprom = < 0x8000>;
+		ieee80211-freq-limit = <500 600>;
+		mtd-mac-address = < 0x100b0>;
+		mtd-mac-address-increment = <(2)>;
+	};
+};
diff --git target/linux/ramips/image/mt76x8.mk target/linux/ramips/image/mt76x8.mk
index e2890c98e6..03707d1db3 100644
--- target/linux/ramips/image/mt76x8.mk
+++ target/linux/ramips/image/mt76x8.mk
@@ -187,6 +187,25 @@ define Device/netgear_r6120
 endef
 TARGET_DEVICES += netgear_r6120
 
+define Device/netgear_r6020
+  BLOCKSIZE := 64k
+  IMAGE_SIZE := 7270k
+  DEVICE_TITLE := Netgear AC750 R6020
+  DEVICE_PACKAGES := kmod-mt76x2 kmod-usb2 kmod-usb-ohci
+  SERCOMM_KERNEL_OFFSET := 0x9
+  SERCOMM_HWID := CFR
+  SERCOMM_HWVER := A001
+  SERCOMM_SWVER := 0x0040
+  IMAGES += factory.img
+  IMAGE/default := append-kernel | pad-to (BLOCKSIZE)| append-rootfs | pad-rootfs
+  IMAGE/sysupgrade.bin := $$(IMAGE/default) | append-metadata | check-size (IMAGE_SIZE)
+  IMAGE/factory.img := pad-extra 576k | $$(IMAGE/default) | \
+	pad-to (BLOCKSIZE) | sercom-footer | pad-to 128 | zip R6020.bin | \
+	sercom-seal
+endef
+TARGET_DEVICES += netgear_r6020
+
+
 define Device/onion_omega2
   IMAGE_SIZE := 16064k
   DEVICE_VENDOR := Onion
diff --git target/linux/ramips/mt76x8/base-files/etc/board.d/01_leds target/linux/ramips/mt76x8/base-files/etc/board.d/01_leds
index c66e13d3c5..8d8605e4ad 100755
--- target/linux/ramips/mt76x8/base-files/etc/board.d/01_leds
+++ target/linux/ramips/mt76x8/base-files/etc/board.d/01_leds
@@ -40,6 +40,11 @@ hiwifi,hc5761a)
 mediatek,linkit-smart-7688)
 	ucidef_set_led_wlan "wifi" "wifi" "linkit-smart-7688:orange:wifi" "phy0tpt"
 	;;
+netgear,r6020)
+	ucidef_set_led_switch "lan" "lan" 

[OpenWrt-Devel] add support for netgear R6020

2020-05-28 Thread Evan Jobling
Hi All.

Apologies if this isn't the correct method of submitting a patch.

There was a patch on github for adding the R6020?

Didn't look like it went anywhere.
I recall issues with the LED naming on that one?

Just so it doesn't get lost to time, I figured i'd email my modifications.

Please find patch attached.

 I may still have an original boot log, if you want it?

Cheers,
Evan.

diff --git target/linux/ramips/dts/mt7628an_netgear_r6020.dts target/linux/ramips/dts/mt7628an_netgear_r6020.dts
new file mode 100644
index 00..3492273840
--- /dev/null
+++ target/linux/ramips/dts/mt7628an_netgear_r6020.dts
@@ -0,0 +1,149 @@
+/dts-v1/;
+
+#include "mt7628an.dtsi"
+
+#include 
+#include 
+
+/ {
+	compatible = "netgear,r6020", "mediatek,mt7628an-soc";
+	model = "Netgear AC750 R6020";
+
+	aliases {
+		led-boot = _power;
+		led-failsafe = _power;
+		led-running = _power;
+		led-upgrade = _power;
+	};
+
+	memory@0 {
+		device_type = "memory";
+		reg = <0x0 0x400>;
+	};
+
+	gpio-keys-polled {
+		compatible = "gpio-keys-polled";
+		poll-interval = <20>;
+
+		reset {
+			label = "reset";
+			gpios = < 6 GPIO_ACTIVE_LOW>;
+			linux,code = ;
+		};
+	};
+
+	gpio-leds {
+		compatible = "gpio-leds";
+
+		lan {
+			label = "r6020:green:lan";
+			gpios = < 12 GPIO_ACTIVE_LOW>;
+		};
+
+		led_power: power {
+			label = "r6020:green:power";
+			gpios = < 11 GPIO_ACTIVE_LOW>;
+		};
+
+		wlan {
+			label = "r6020:green:wlan2g";
+			gpios = < 10 GPIO_ACTIVE_LOW>;
+		};
+
+		wlan_orange {
+			label = "r6020:orange:wlan2g";
+			gpios = < 9 GPIO_ACTIVE_LOW>;
+		};
+
+		wlan5 {
+			label = "r6020:green:wlan5g";
+			gpios = < 8 GPIO_ACTIVE_LOW>;
+		};
+
+		wlan5_orange {
+			label = "r6020:orange:wlan5g";
+			gpios = < 7 GPIO_ACTIVE_LOW>;
+		};
+	};
+};
+
+ {
+	state_default: pinctrl0 {
+		gpio {
+			ralink,group = "p0led_an", "p1led_an", "p2led_an",
+   "p3led_an", "p4led_an", "wdt", "wled_an";
+			ralink,function = "gpio";
+		};
+	};
+};
+
+ {
+	status = "okay";
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <1000>;
+		m25p,chunked-io = <32>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			partition@0 {
+label = "u-boot";
+reg = <0x0 0x4>;
+read-only;
+			};
+
+			factory: partition@4 {
+label = "factory";
+reg = <0x4 0x2>;
+read-only;
+			};
+
+			nvram: partition@6 {
+label = "nvram";
+reg = <0x6 0x3>;
+read-only;
+			};
+
+			partition@9 {
+compatible = "denx,uimage";
+label = "firmware";
+reg = <0x9 0x6f>;
+			};
+
+			partition@78 {
+label = "reserved";
+reg = <0x78 0x8>;
+read-only;
+			};
+		};
+	};
+};
+
+ {
+	status = "okay";
+	mtd-mac-address = < 0x100b0>;
+	mediatek,mtd-eeprom = < 0x2>;
+};
+
+ {
+	mtd-mac-address = < 0x100b0>;
+};
+
+ {
+	status = "okay";
+};
+
+ {
+	wifi@0,0 {
+		reg = <0x 0 0 0 0>;
+		mediatek,mtd-eeprom = < 0x8000>;
+		ieee80211-freq-limit = <500 600>;
+		mtd-mac-address = < 0x100b0>;
+		mtd-mac-address-increment = <(2)>;
+	};
+};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] Odp: ZNC openwrt variant

2020-05-28 Thread a
what about fingerprints how to save them?





Dnia 28 maja 2020 13:37 a pentelja...@o2.pl napisał(a):



 1. /etc/config/znc doesnt support hiding password sha + salt or if its 
supporting that  whats the pattern.  2. It is required to type network name to 
join  that network which is not mentioned under documentation  openwrt.org 
openwrt.org  /quote PASS username/Default:password  3. how to generate ssl cert 
NOT as root ?  4. Variable channel `` Specifies one or more channels to join on 
connect. The required format is “channelname [password]”.``   
leaving that in state    list channel#test    // with 
empty string   causing   Thu May 28 13:29:36 2020 daemon.info procd: Instance 
znc::instance1 s in a crash loop 6 crashes, 0 seconds since last crash  5. In 
general its hard to debug for me , all i can do its service start/stop without 
any output, theres any way to get more verbose data?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] bcm63xx: AD1018: generate a factory image

2020-05-28 Thread Daniel González Cabanelas
Currently there is no image that can be flashed without opening the case
and accessing the serial port on the Sercomm AD1018 router.

We can use an unencrypted factory image to flash Openwrt through the
stock firmware. The router comes with 2 stock firmwares, we must perform
the flash operation from the 2nd one.

1st option: using the factory busybox CLI:
  - boot the second firmware
  flash_eraseall /dev/mtd8
  flash_eraseall /dev/mtd9
  echo -n "eRcOmM.000" | dd of=/dev/mtdblock8
  echo -n "eRcOmM.001" | dd of=/dev/mtdblock9
  reboot
 - flash the Openwrt factory image
  flash_eraseall -j /dev/mtd6
  dd if=openwrt-factory.bin of=/dev/mtdblock6
 - boot the first firmware
  flash_eraseall /dev/mtd8
  echo -n "eRcOmM.002" | dd of=/dev/mtdblock8
  reboot

2nd option: using the factory web UI
  - with sercomm make_img proprietary utility and the openwrt-factory.bin
as the input, generate the openwrt-factory.img encrypted image
  - boot the second firmware
  flash_eraseall /dev/mtd8
  flash_eraseall /dev/mtd9
  echo -n "eRcOmM.000" | dd of=/dev/mtdblock8
  echo -n "eRcOmM.001" | dd of=/dev/mtdblock9
  reboot
  - flash the openwrt-factory.img image using the factory web UI

Signed-off-by: Daniel González Cabanelas 
---
 target/linux/bcm63xx/image/bcm63xx_nand.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/linux/bcm63xx/image/bcm63xx_nand.mk 
b/target/linux/bcm63xx/image/bcm63xx_nand.mk
index 5483c73077..510a6f26c8 100644
--- a/target/linux/bcm63xx/image/bcm63xx_nand.mk
+++ b/target/linux/bcm63xx/image/bcm63xx_nand.mk
@@ -113,6 +113,8 @@ TARGET_DEVICES += netgear_dgnd3700-v2
 ### Sercomm ###
 define Device/sercomm_ad1018
   $(Device/bcm63xx-nand)
+  IMAGES += factory.bin
+  IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | append-ubi
   IMAGE/cfe.bin := append-kernel | pad-to (KERNEL_SIZE) | 
ad1018-jffs2-cferam | append-ubi | cfe-wfi-tag
   DEVICE_VENDOR := Sercomm
   DEVICE_MODEL := AD1018
-- 
2.26.2





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


[OpenWrt-Devel] [PATCH] mvebu: switch to kernel 5.4

2020-05-28 Thread Adrian Schmutzler
Last reports with kernel 5.4 have all been positive [1], so let's open
this to a wider range of testers.

[1] https://github.com/openwrt/openwrt/pull/2804

Signed-off-by: Adrian Schmutzler 

---

I consider merging the DSA PR shortly after the kernel bump:
https://github.com/openwrt/openwrt/pull/2935
---
 target/linux/mvebu/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/mvebu/Makefile b/target/linux/mvebu/Makefile
index b954a88f6d..b9a6a79fe5 100644
--- a/target/linux/mvebu/Makefile
+++ b/target/linux/mvebu/Makefile
@@ -11,7 +11,7 @@ BOARDNAME:=Marvell EBU Armada
 FEATURES:=fpu usb pci pcie gpio nand squashfs ramdisk boot-part rootfs-part
 SUBTARGETS:=cortexa9 cortexa53 cortexa72
 
-KERNEL_PATCHVER:=4.19
+KERNEL_PATCHVER:=5.4
 KERNEL_TESTING_PATCHVER:=5.4
 
 include $(INCLUDE_DIR)/target.mk
-- 
2.20.1


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


[OpenWrt-Devel] [PATCH] kernel: iio: add drivers for st_lsm6dsx IMU MEMS sensors

2020-05-28 Thread Tim Harvey
Add kmod for the ST LSM6DSX IMU driver.

Signed-off-by: Tim Harvey 
---
 package/kernel/linux/modules/iio.mk | 48 +
 1 file changed, 48 insertions(+)

diff --git a/package/kernel/linux/modules/iio.mk 
b/package/kernel/linux/modules/iio.mk
index b52ec8c..5fbe2ee 100644
--- a/package/kernel/linux/modules/iio.mk
+++ b/package/kernel/linux/modules/iio.mk
@@ -364,6 +364,54 @@ endef
 $(eval $(call KernelPackage,iio-st_accel-spi))
 
 
+define KernelPackage/iio-lsm6dsx
+  SUBMENU:=$(IIO_MENU)
+  DEPENDS:=+kmod-iio-core +kmod-iio-kfifo-buf
+  TITLE:=ST LSM6DSx driver for IMU MEMS sensors
+  KCONFIG:=CONFIG_IIO_ST_LSM6DSX
+  FILES:=$(LINUX_DIR)/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.ko
+  AUTOLOAD:=$(call AutoProbe,st_lsm6dsx)
+endef
+
+define KernelPackage/iio-lsm6dsx/description
+ Support for the ST LSM6DSx and related IMU MEMS sensors.
+endef
+
+$(eval $(call KernelPackage,iio-lsm6dsx))
+
+
+define KernelPackage/iio-lsm6dsx-i2c
+  SUBMENU:=$(IIO_MENU)
+  DEPENDS:=+kmod-iio-lsm6dsx +kmod-i2c-core
+  TITLE:=ST LSM6DSx driver for IMU MEMS sensors (I2C)
+  KCONFIG:=CONFIG_IIO_ST_LSM6DSX
+  FILES:=$(LINUX_DIR)/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_i2c.ko
+  AUTOLOAD:=$(call AutoProbe,st_lsm6dsx-i2c)
+endef
+
+define KernelPackage/iio-lsm6dsx-i2c/description
+ Support for the ST LSM6DSx and related IMU MEMS I2C sensors.
+endef
+
+$(eval $(call KernelPackage,iio-lsm6dsx-i2c))
+
+
+define KernelPackage/iio-lsm6dsx-spi
+  SUBMENU:=$(IIO_MENU)
+  DEPENDS:=+kmod-iio-lsm6dsx +kmod-regmap-spi
+  TITLE:=ST LSM6DSx driver for IMU MEMS sensors (SPI)
+  KCONFIG:=CONFIG_IIO_ST_LSM6DSX
+  FILES:=$(LINUX_DIR)/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_spi.ko
+  AUTOLOAD:=$(call AutoProbe,st_lsm6dsx-spi)
+endef
+
+define KernelPackage/iio-lsm6dsx-spi/description
+ Support for the ST LSM6DSx and related IMU MEMS SPI sensors.
+endef
+
+$(eval $(call KernelPackage,iio-lsm6dsx-spi))
+
+
 define KernelPackage/iio-sps30
   SUBMENU:=$(IIO_MENU)
   DEPENDS:=@!LINUX_4_14 +kmod-i2c-core +kmod-iio-core 
+kmod-industrialio-triggered-buffer +kmod-lib-crc8
-- 
2.7.4


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


[OpenWrt-Devel] [PATCH] kernel: iio: fix st_accel_{i2c, spi} driver

2020-05-28 Thread Tim Harvey
Add missing kernel module and rename driver

Signed-off-by: Tim Harvey 
---
 package/kernel/linux/modules/iio.mk | 46 -
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/package/kernel/linux/modules/iio.mk 
b/package/kernel/linux/modules/iio.mk
index 17ffdc3..b52ec8c 100644
--- a/package/kernel/linux/modules/iio.mk
+++ b/package/kernel/linux/modules/iio.mk
@@ -328,20 +328,40 @@ endef
 $(eval $(call KernelPackage,iio-st_accel))
 
 
-define KernelPackage/iio-st_sensors-i2c
+define KernelPackage/iio-st_accel-i2c
   SUBMENU:=$(IIO_MENU)
   TITLE:=STMicroelectronics accelerometer 3-Axis Driver (I2C)
   DEPENDS:=+kmod-iio-st_accel +kmod-i2c-core +kmod-regmap-i2c
   KCONFIG:= CONFIG_IIO_ST_ACCEL_I2C_3AXIS
-  FILES:=$(LINUX_DIR)/drivers/iio/common/st_sensors/st_sensors_i2c.ko
-  AUTOLOAD:=$(call AutoLoad,56,st_sensors_i2c)
+  FILES:= \
+   $(LINUX_DIR)/drivers/iio/accel/st_accel_i2c.ko \
+   $(LINUX_DIR)/drivers/iio/common/st_sensors/st_sensors_i2c.ko
+  AUTOLOAD:=$(call AutoLoad,56,st_accel_i2c)
 endef
 
-define KernelPackage/iio-st_sensors-i2c/description
+define KernelPackage/iio-st_accel-i2c/description
  This package adds support for STMicroelectronics I2C based accelerometers
 endef
 
-$(eval $(call KernelPackage,iio-st_sensors-i2c))
+$(eval $(call KernelPackage,iio-st_accel-i2c))
+
+
+define KernelPackage/iio-st_accel-spi
+  SUBMENU:=$(IIO_MENU)
+  TITLE:=STMicroelectronics accelerometer 3-Axis Driver (SPI)
+  DEPENDS:=+kmod-iio-st_accel +kmod-regmap-spi
+  KCONFIG:= CONFIG_IIO_ST_ACCEL_SPI_3AXIS
+  FILES:= \
+   $(LINUX_DIR)/drivers/iio/accel/st_accel_spi.ko \
+   $(LINUX_DIR)/drivers/iio/common/st_sensors/st_sensors_spi.ko
+  AUTOLOAD:=$(call AutoLoad,56,st_accel_spi)
+endef
+
+define KernelPackage/iio-st_accel-spi/description
+ This package adds support for STMicroelectronics SPI based accelerometers
+endef
+
+$(eval $(call KernelPackage,iio-st_accel-spi))
 
 
 define KernelPackage/iio-sps30
@@ -360,22 +380,6 @@ endef
 $(eval $(call KernelPackage,iio-sps30))
 
 
-define KernelPackage/iio-st_sensors-spi
-  SUBMENU:=$(IIO_MENU)
-  TITLE:=STMicroelectronics accelerometer 3-Axis Driver (SPI)
-  DEPENDS:=+kmod-iio-st_accel +kmod-regmap-spi
-  KCONFIG:= CONFIG_IIO_ST_ACCEL_SPI_3AXIS
-  FILES:=$(LINUX_DIR)/drivers/iio/common/st_sensors/st_sensors_spi.ko
-  AUTOLOAD:=$(call AutoLoad,56,st_sensors_spi)
-endef
-
-define KernelPackage/iio-st_sensors-spi/description
- This package adds support for STMicroelectronics SPI based accelerometers
-endef
-
-$(eval $(call KernelPackage,iio-st_sensors-spi))
-
-
 define KernelPackage/iio-tsl4531
   SUBMENU:=$(IIO_MENU)
   DEPENDS:=+kmod-i2c-core +kmod-iio-core
-- 
2.7.4


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


[OpenWrt-Devel] [PATCH] octeontx: fix gpio irq request

2020-05-28 Thread Tim Harvey
This fixes a regression in 5.4 that causes a crash when a driver requests
an ARM GPIO for an IRQ.

Signed-off-by: Tim Harvey 
---
 ...2-gpio-thunderx-fix-irq_request_resources.patch | 46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 
target/linux/octeontx/patches-5.4/0002-gpio-thunderx-fix-irq_request_resources.patch

diff --git 
a/target/linux/octeontx/patches-5.4/0002-gpio-thunderx-fix-irq_request_resources.patch
 
b/target/linux/octeontx/patches-5.4/0002-gpio-thunderx-fix-irq_request_resources.patch
new file mode 100644
index 000..8c4de51
--- /dev/null
+++ 
b/target/linux/octeontx/patches-5.4/0002-gpio-thunderx-fix-irq_request_resources.patch
@@ -0,0 +1,46 @@
+From e8287ec10f21877eb0ac4c1fb4e89e42d8bc10da Mon Sep 17 00:00:00 2001
+From: Tim Harvey 
+Date: Wed, 11 Mar 2020 08:19:45 -0700
+Subject: [PATCH 2/7] gpio: thunderx: fix irq_request_resources
+
+If there are no parent resources do not call irq_chip_request_resources_parent
+at all as this will return an error.
+
+This resolves a regression where devices using a thunderx gpio as an interrupt
+would fail probing.
+
+Fixes: 0d04d0c ("gpio: thunderx: Use the default parent apis for 
{request,release}_resources")
+Signed-off-by: Tim Harvey 
+---
+ drivers/gpio/gpio-thunderx.c | 9 ++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/gpio/gpio-thunderx.c b/drivers/gpio/gpio-thunderx.c
+index 715371b..feda2a2 100644
+--- a/drivers/gpio/gpio-thunderx.c
 b/drivers/gpio/gpio-thunderx.c
+@@ -363,15 +363,18 @@ static int thunderx_gpio_irq_request_resources(struct 
irq_data *data)
+ {
+   struct thunderx_line *txline = irq_data_get_irq_chip_data(data);
+   struct thunderx_gpio *txgpio = txline->txgpio;
++  struct irq_data *parent_data = data->parent_data;
+   int r;
+ 
+   r = gpiochip_lock_as_irq(>chip, txline->line);
+   if (r)
+   return r;
+ 
+-  r = irq_chip_request_resources_parent(data);
+-  if (r)
+-  gpiochip_unlock_as_irq(>chip, txline->line);
++  if (parent_data && parent_data->chip->irq_request_resources) {
++  r = irq_chip_request_resources_parent(data);
++  if (r)
++  gpiochip_unlock_as_irq(>chip, txline->line);
++  }
+ 
+   return r;
+ }
+-- 
+2.7.4
+
-- 
2.7.4


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


[OpenWrt-Devel] [PATCH] octeontx: fix mcp251x can controller

2020-05-28 Thread Tim Harvey
Update the can-mcp251x-convert-to-half-duplex-SPI patch to fix reception

Some SPI host controllers such as the Cavium Thunder TX do not support
full-duplex SPI. Using half-duplex transfers allows the driver to work
with those host controllers.

This patch fixes the fact that mcp251x_hw_rx_frame was still relying on
a full-duplex transfer where bits were being shifted on MOSI at the same time
as MISO. After splitting the transaction into a spi_write_then_read() care
must be taken to ignore the first byte.

Signed-off-by: Tim Harvey 
---
 ...03-can-mcp251x-convert-to-half-duplex-SPI.patch | 31 +-
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git 
a/target/linux/octeontx/patches-5.4/0003-can-mcp251x-convert-to-half-duplex-SPI.patch
 
b/target/linux/octeontx/patches-5.4/0003-can-mcp251x-convert-to-half-duplex-SPI.patch
index 6096fcf..54906b7 100644
--- 
a/target/linux/octeontx/patches-5.4/0003-can-mcp251x-convert-to-half-duplex-SPI.patch
+++ 
b/target/linux/octeontx/patches-5.4/0003-can-mcp251x-convert-to-half-duplex-SPI.patch
@@ -1,20 +1,22 @@
-From 6edfb172ff1dd3cfc84c19790c245a4005474bb7 Mon Sep 17 00:00:00 2001
+From 097cc81ee5c15913ad330ba2e3dea09bdad0 Mon Sep 17 00:00:00 2001
 From: Tim Harvey 
-Date: Tue, 25 Feb 2020 12:01:36 -0800
-Subject: [PATCH 03/12] can: mcp251x: convert to half-duplex SPI
+Date: Thu, 30 Aug 2018 15:16:08 -0700
+Subject: [PATCH] can: mcp251x: convert driver to half-duplex SPI
 
-Some SPI host controllers such as the Cavium Thunder do not support
+Some SPI host controllers such as the Cavium Thunder TX do not support
 full-duplex SPI. Using half-duplex transfers allows the driver to work
 with those host controllers.
 
 Signed-off-by: Tim Harvey 
 ---
- drivers/net/can/spi/mcp251x.c | 10 +-
- 1 file changed, 5 insertions(+), 5 deletions(-)
+ drivers/net/can/spi/mcp251x.c | 15 ---
+ 1 file changed, 8 insertions(+), 7 deletions(-)
 
+diff --git a/drivers/net/can/spi/mcp251x.c b/drivers/net/can/spi/mcp251x.c
+index bb20a9b..dc0574a 100644
 --- a/drivers/net/can/spi/mcp251x.c
 +++ b/drivers/net/can/spi/mcp251x.c
-@@ -291,23 +291,23 @@ static u8 mcp251x_read_reg(struct spi_de
+@@ -291,23 +291,23 @@ static u8 mcp251x_read_reg(struct spi_device *spi, u8 
reg)
priv->spi_tx_buf[0] = INSTRUCTION_READ;
priv->spi_tx_buf[1] = reg;
  
@@ -43,3 +45,18 @@ Signed-off-by: Tim Harvey 
  }
  
  static void mcp251x_write_reg(struct spi_device *spi, u8 reg, u8 val)
+@@ -398,8 +398,9 @@ static void mcp251x_hw_rx_frame(struct spi_device *spi, u8 
*buf,
+   buf[i] = mcp251x_read_reg(spi, RXBCTRL(buf_idx) + i);
+   } else {
+   priv->spi_tx_buf[RXBCTRL_OFF] = INSTRUCTION_READ_RXB(buf_idx);
+-  mcp251x_spi_trans(spi, SPI_TRANSFER_BUF_LEN);
+-  memcpy(buf, priv->spi_rx_buf, SPI_TRANSFER_BUF_LEN);
++  spi_write_then_read(spi, priv->spi_tx_buf, 1, priv->spi_rx_buf,
++  SPI_TRANSFER_BUF_LEN);
++  memcpy(buf + 1, priv->spi_rx_buf, SPI_TRANSFER_BUF_LEN - 1);
+   }
+ }
+ 
+-- 
+2.7.4
+
-- 
2.7.4


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


[OpenWrt-Devel] [PATCH] imx6: image: increase max ubifs file-system size

2020-05-28 Thread Tim Harvey
The latest 2GiB NAND flash parts used by Gateworks ventana are 2K page-size.

Signed-off-by: Tim Harvey 
---
 target/linux/imx6/image/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/imx6/image/Makefile b/target/linux/imx6/image/Makefile
index 232dc42..2c9d03c 100644
--- a/target/linux/imx6/image/Makefile
+++ b/target/linux/imx6/image/Makefile
@@ -35,7 +35,7 @@ define Build/boot-overlay
 
$(STAGING_DIR_HOST)/bin/mkfs.ubifs \
--space-fixup --compr=zlib --squash-uids \
-   $(MKUBIFS_OPTS) -c 8124 \
+   $(MKUBIFS_OPTS) -c 16248 \
-o $@.boot.ubifs -d $@.boot
 
$(TAR) -C $@.boot -cf $@.boot.tar .
-- 
2.7.4


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


[OpenWrt-Devel] [PATCH] imx6: add I2C retries for ventana i2c1

2020-05-28 Thread Tim Harvey
The GSC sitting on i2c1 can NAK I2C transactions if it is busy
performing an ADC cycle. Allow enough retries to work around this.

Signed-off-by: Tim Harvey 
---
 ...x-add-retries-for-NAK-s-on-ventana-boards.patch | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 
target/linux/imx6/patches-5.4/200-i2c-imx-add-retries-for-NAK-s-on-ventana-boards.patch

diff --git 
a/target/linux/imx6/patches-5.4/200-i2c-imx-add-retries-for-NAK-s-on-ventana-boards.patch
 
b/target/linux/imx6/patches-5.4/200-i2c-imx-add-retries-for-NAK-s-on-ventana-boards.patch
new file mode 100644
index 000..5f45342
--- /dev/null
+++ 
b/target/linux/imx6/patches-5.4/200-i2c-imx-add-retries-for-NAK-s-on-ventana-boards.patch
@@ -0,0 +1,42 @@
+From be183fc2af49e6020bb0b1ac8359351707383f63 Mon Sep 17 00:00:00 2001
+From: Tim Harvey 
+Date: Tue, 12 May 2020 12:41:32 -0700
+Subject: [PATCH] i2c: imx: add retries for NAK's on ventana boards
+
+Ventana boards have a Gateworks System Controller (gsc) module that can
+nak i2c transactions when its busy in an ADC loop. In order to not have to
+hack up the pca953x and ds1672 device drivers which the GSC emulates we will
+just add i2c retries around NAK's.
+
+Signed-off-by: Tim Harvey 
+---
+ drivers/i2c/busses/i2c-imx.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
+index a3b6133..b2378d8 100644
+--- a/drivers/i2c/busses/i2c-imx.c
 b/drivers/i2c/busses/i2c-imx.c
+@@ -467,6 +467,8 @@ static int i2c_imx_acked(struct imx_i2c_struct *i2c_imx)
+ {
+   if (imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR) & I2SR_RXAK) {
+   dev_dbg(_imx->adapter.dev, "<%s> No ACK\n", __func__);
++  if (i2c_imx->adapter.retries)
++  return -EAGAIN;
+   return -ENXIO;  /* No ACK */
+   }
+ 
+@@ -1097,6 +1099,10 @@ static int i2c_imx_probe(struct platform_device *pdev)
+   i2c_imx->adapter.dev.of_node= pdev->dev.of_node;
+   i2c_imx->base   = base;
+   ACPI_COMPANION_SET(_imx->adapter.dev, ACPI_COMPANION(>dev));
++  if (of_machine_is_compatible("gw,ventana") && phy_addr == 0x021a) {
++  dev_info(>dev, "Adding retries for Ventana GSC\n");
++  i2c_imx->adapter.retries = 3;
++  }
+ 
+   /* Get I2C clock */
+   i2c_imx->clk = devm_clk_get(>dev, NULL);
+-- 
+2.7.4
+
-- 
2.7.4


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


[OpenWrt-Devel] [PATCH] imx6: backport v5.8 imx6qdl-gw dt patches

2020-05-28 Thread Tim Harvey
- add fxos8700 support to GW52xx/GW53xx/GW54xx
- add USB_OTG support to GW552x
- add LSM9DS1 IMU support to GW560x
- add LSM9DS1 IMU support to GW5904
- add CC1352 UART to GW5910
- add BCM4330 support to GW5910
- fix wlan regulator for GW5910

Signed-off-by: Tim Harvey 
---
 ...-ventana-add-fxos8700-on-gateworks-boards.patch | 66 
 7-ARM-dts-imx6qdl-gw5910-add-CC1352-UART.patch | 59 +++
 ...RM-dts-imx6qdl-gw552x-add-USB-OTG-support.patch | 50 +
 ...6qdl-gw560x-add-lsm9ds1-iio-imu-magn-supp.patch | 81 
 ...6qdl-gw5904-add-lsm9ds1-iio-imu-magn-supp.patch | 74 ++
 ...imx6qdl-gw5910-add-support-for-bcm4330-bt.patch | 87 ++
 ...ARM-dts-imx6qdl-gw5910-fix-wlan-regulator.patch | 38 ++
 7 files changed, 455 insertions(+)
 create mode 100644 
target/linux/imx6/patches-5.4/006-v5.7-ARM-dts-imx-ventana-add-fxos8700-on-gateworks-boards.patch
 create mode 100644 
target/linux/imx6/patches-5.4/006-v5.7-ARM-dts-imx6qdl-gw5910-add-CC1352-UART.patch
 create mode 100644 
target/linux/imx6/patches-5.4/006-v5.8-ARM-dts-imx6qdl-gw552x-add-USB-OTG-support.patch
 create mode 100644 
target/linux/imx6/patches-5.4/007-v5.8-ARM-dts-imx6qdl-gw560x-add-lsm9ds1-iio-imu-magn-supp.patch
 create mode 100644 
target/linux/imx6/patches-5.4/008-v5.8-ARM-dts-imx6qdl-gw5904-add-lsm9ds1-iio-imu-magn-supp.patch
 create mode 100644 
target/linux/imx6/patches-5.4/009-v5.8-ARM-dts-imx6qdl-gw5910-add-support-for-bcm4330-bt.patch
 create mode 100644 
target/linux/imx6/patches-5.4/010-v5.8-ARM-dts-imx6qdl-gw5910-fix-wlan-regulator.patch

diff --git 
a/target/linux/imx6/patches-5.4/006-v5.7-ARM-dts-imx-ventana-add-fxos8700-on-gateworks-boards.patch
 
b/target/linux/imx6/patches-5.4/006-v5.7-ARM-dts-imx-ventana-add-fxos8700-on-gateworks-boards.patch
new file mode 100644
index 000..e2c8980
--- /dev/null
+++ 
b/target/linux/imx6/patches-5.4/006-v5.7-ARM-dts-imx-ventana-add-fxos8700-on-gateworks-boards.patch
@@ -0,0 +1,66 @@
+From 66d19a4f8d0fa7539f90cad64d793b4dac6f6e5d Mon Sep 17 00:00:00 2001
+From: Robert Jones 
+Date: Fri, 14 Feb 2020 13:01:55 -0800
+Subject: [PATCH] ARM: dts: imx: ventana: add fxos8700 on gateworks boards
+
+Add fxos8700 iio imu entries for Gateworks ventana SBCs.
+
+Signed-off-by: Robert Jones 
+Signed-off-by: Shawn Guo 
+---
+ arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 5 +
+ arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 5 +
+ arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 5 +
+ 3 files changed, 15 insertions(+)
+
+diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+index 1a9a9d9..60563ff 100644
+--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
 b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+@@ -313,6 +313,11 @@
+   interrupts = <12 2>;
+   wakeup-gpios = < 12 GPIO_ACTIVE_LOW>;
+   };
++
++  accel@1e {
++  compatible = "nxp,fxos8700";
++  reg = <0x1e>;
++  };
+ };
+ 
+  {
+diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+index 54b2bea..8942bec 100644
+--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
 b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+@@ -304,6 +304,11 @@
+   interrupts = <11 2>;
+   wakeup-gpios = < 11 GPIO_ACTIVE_LOW>;
+   };
++
++  accel@1e {
++  compatible = "nxp,fxos8700";
++  reg = <0x1e>;
++  };
+ };
+ 
+  {
+diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+index 1b6c133..c40583d 100644
+--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
 b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+@@ -361,6 +361,11 @@
+   interrupts = <12 2>;
+   wakeup-gpios = < 12 GPIO_ACTIVE_LOW>;
+   };
++
++  accel@1e {
++  compatible = "nxp,fxos8700";
++  reg = <0x1e>;
++  };
+ };
+ 
+  {
+-- 
+2.7.4
+
diff --git 
a/target/linux/imx6/patches-5.4/006-v5.7-ARM-dts-imx6qdl-gw5910-add-CC1352-UART.patch
 
b/target/linux/imx6/patches-5.4/006-v5.7-ARM-dts-imx6qdl-gw5910-add-CC1352-UART.patch
new file mode 100644
index 000..5f5dc0a
--- /dev/null
+++ 
b/target/linux/imx6/patches-5.4/006-v5.7-ARM-dts-imx6qdl-gw5910-add-CC1352-UART.patch
@@ -0,0 +1,59 @@
+From d2cf2f91ba5b6d7696b1870e28017a3e1a7a1bb8 Mon Sep 17 00:00:00 2001
+From: Tim Harvey 
+Date: Fri, 28 Feb 2020 11:46:07 -0800
+Subject: [PATCH] ARM: dts: imx6qdl-gw5910: add CC1352 UART
+
+The GW5910-C revision adds a TI CC1352 connected to IMX UART4
+
+Signed-off-by: Tim Harvey 
+Signed-off-by: Shawn Guo 
+---
+ arch/arm/boot/dts/imx6qdl-gw5910.dtsi | 25 +
+ 1 file changed, 25 insertions(+)
+
+diff --git a/arch/arm/boot/dts/imx6qdl-gw5910.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
+index be1af74..30fe47f 100644
+--- a/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
 b/arch/arm/boot/dts/imx6qdl-gw5910.dtsi
+@@ -220,6 +220,14 @@
+   status = "okay";
+ };
+ 
++/* cc1352 */
++ {

Re: [OpenWrt-Devel] problems with virtual sub interfaces in firewall zones

2020-05-28 Thread Martin Schiller

On 2020-05-07 07:39, Martin Schiller wrote:

On 2020-05-07 06:47, Martin Schiller wrote:

Hi Jo,
Hi all,

I've encountered a problem with the change you made with commit
64bb88841fbc ("uqmi: inherit firewall zone membership to virtual sub
interfaces") which was introduced to fix FS#2122.

This change makes it impossible to move an interface from one zone to
another without a reconnect of that interface, because the related
zone is stored during interface setup and fw3 will use this value
even if the parent interface is already in another zone.

I have a case here, where the target zone of an (wwan/qmi) interface
is decided by an iface-hotplug script on an if-up event and i don't
want / can't reconnect the interface right after it's coming up.

Is there a possibility to get this working again?


What about storing the information (name) of the parent interface
instead of the zone and let fw3 dynamically take the zone of the
parent interface?



OK, so please have a look at the patch below. It works as expected
for me.

If there is a "parent" information (name of the parent interface)
in the data section of an interface, then let's check if this
parent interface is a member the current zone.

Of course, the proto handler(s) also need to be patched to save the
parent information instead of the zone.

---
 ubus.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/ubus.c b/ubus.c
index cf5c8b1..d77807c 100644
--- a/ubus.c
+++ b/ubus.c
@@ -228,6 +228,7 @@ void
 fw3_ubus_zone_devices(struct fw3_zone *zone)
 {
struct blob_attr *c, *cur, *dcur;
+   struct fw3_device *net;
unsigned r, rem, drem;
const char *name;
bool matches;
@@ -239,10 +240,20 @@ fw3_ubus_zone_devices(struct fw3_zone *zone)
blobmsg_for_each_attr(cur, c, rem) {
if (!strcmp(blobmsg_name(cur), "interface"))
name = blobmsg_get_string(cur);
-   else if (!strcmp(blobmsg_name(cur), "data"))
-   blobmsg_for_each_attr(dcur, cur, drem)
+   else if (!strcmp(blobmsg_name(cur), "data")) {
+   blobmsg_for_each_attr(dcur, cur, drem) {
if (!strcmp(blobmsg_name(dcur), "zone"))
matches = 
!strcmp(blobmsg_get_string(dcur), zone->name);
+   /* check, if the parent interface is in 
this zone */
+   else if (!strcmp(blobmsg_name(dcur), 
"parent")) {
+   list_for_each_entry(net, 
>networks, list)
+   {
+   if 
(!strcmp(blobmsg_get_string(dcur), net->name))
+   matches = true;
+   }
+   }
+   }
+   }
}

if (name && matches)
--



Regards,
Martin



___
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


Re: [OpenWrt-Devel] problems with virtual sub interfaces in firewall zones

2020-05-28 Thread Martin Schiller

On 2020-05-07 07:39, Martin Schiller wrote:

On 2020-05-07 06:47, Martin Schiller wrote:

Hi Jo,
Hi all,

I've encountered a problem with the change you made with commit
64bb88841fbc ("uqmi: inherit firewall zone membership to virtual sub
interfaces") which was introduced to fix FS#2122.

This change makes it impossible to move an interface from one zone to
another without a reconnect of that interface, because the related
zone is stored during interface setup and fw3 will use this value
even if the parent interface is already in another zone.

I have a case here, where the target zone of an (wwan/qmi) interface
is decided by an iface-hotplug script on an if-up event and i don't
want / can't reconnect the interface right after it's coming up.

Is there a possibility to get this working again?


What about storing the information (name) of the parent interface
instead of the zone and let fw3 dynamically take the zone of the
parent interface?



OK, so please have a look at the patch below. It works as expected
for me.

If there is a "parent" information (name of the parent interface)
in the data section of an interface, then let's check if this
parent interface is a member the current zone.

Of course, the proto handler(s) also need to be patched to save the
parent information instead of the zone.

---
 ubus.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/ubus.c b/ubus.c
index cf5c8b1..d77807c 100644
--- a/ubus.c
+++ b/ubus.c
@@ -228,6 +228,7 @@ void
 fw3_ubus_zone_devices(struct fw3_zone *zone)
 {
struct blob_attr *c, *cur, *dcur;
+   struct fw3_device *net;
unsigned r, rem, drem;
const char *name;
bool matches;
@@ -239,10 +240,20 @@ fw3_ubus_zone_devices(struct fw3_zone *zone)
blobmsg_for_each_attr(cur, c, rem) {
if (!strcmp(blobmsg_name(cur), "interface"))
name = blobmsg_get_string(cur);
-   else if (!strcmp(blobmsg_name(cur), "data"))
-   blobmsg_for_each_attr(dcur, cur, drem)
+   else if (!strcmp(blobmsg_name(cur), "data")) {
+   blobmsg_for_each_attr(dcur, cur, drem) {
if (!strcmp(blobmsg_name(dcur), "zone"))
matches = 
!strcmp(blobmsg_get_string(dcur), zone->name);
+   /* check, if the parent interface is in 
this zone */
+   else if (!strcmp(blobmsg_name(dcur), 
"parent")) {
+   list_for_each_entry(net, 
>networks, list)
+   {
+   if 
(!strcmp(blobmsg_get_string(dcur), net->name))
+   matches = true;
+   }
+   }
+   }
+   }
}

if (name && matches)
--


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


[OpenWrt-Devel] ZNC openwrt variant

2020-05-28 Thread a
1. /etc/config/znc doesnt support hiding password sha + salt or if its 
supporting that  whats the pattern.  2. It is required to type network name to 
join  that network which is not mentioned under documentation  openwrt.org 
openwrt.org  /quote PASS username/Default:password  3. how to generate ssl cert 
NOT as root ?  4. Variable channel `` Specifies one or more channels to join on 
connect. The required format is “channelname [password]”.``   
leaving that in state    list channel#test    // with 
empty string   causing   Thu May 28 13:29:36 2020 daemon.info procd: Instance 
znc::instance1 s in a crash loop 6 crashes, 0 seconds since last crash  5. In 
general its hard to debug for me , all i can do its service start/stop without 
any output, theres any way to get more verbose data?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] Goods Specification Inquiry

2020-05-28 Thread Logistics Manager 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 ---

openwrt-devel@lists.openwrt.org,

I'm Sequel to the inquiry i made on Alibaba, Sorry I've been silent for quiet 
sometime now its simply because we don't have much work then. But now we have 
commenced and on a bigger platform now

I actually saw the pictures on alibaba website and we seems to be interested on 
it because it looks unique, If you could check and advise the possible making 
of same specification.

http://alibaba.com/zhanc-trade_en/item10/picture231 
https://$@@@oxintrade.com/Alibaba_1/?login=openwrt-devel@lists.openwrt.org

Best regards.

Benson Xu | Business Director

LeYiDi International Medical Devices (Beijing) Co., LTD.

Add: Room 511, 5/F, No. 1 Building, No. 10 Yard, Zhuo Xiu Bei Street, Fangshan 
District, 102446,

Beijing, China.

Web: 

http://en.leyidi-intmed. http://en.leyidi-intmed.com/

com/

E-mail: 

gringold@gmail.com mailto:gringold@gmail.com

i...@delivers-solutions.com mailto:i...@delivers-solutions.com

Tel: +1 (303) 500-7386 4431; 

MOB/WeChat/WhatsApp: +1 (303) 500-7386

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


Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750

2020-05-28 Thread mail
Hi,

> > Tried sysupgrade --> results in platform_check failure.
> In the original device naming convention, E750 was named glinet,gl-e750
> However, in today's openwrt, the name of the device is glinet_gl-e750, so 
> platform_check failure is prompted.

But SUPPORTED_DEVICES should still contain the string with comma: glinet,gl-e750

https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/image/Makefile#L65

So, either that name is different on OEM firmware or the metadata is not 
present there, and we need custom code in upgrade/platform.sh

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] [PATCH] ath79: add support for gl-e750

2020-05-28 Thread Koen Vandeputte



On 28.05.20 04:42, luochong...@gl-inet.com wrote:

Hi Koen,

I'm really sorry that I missed your previous email.

Tried sysupgrade --> results in platform_check failure.
In the original device naming convention, E750 was named glinet,gl-e750
However, in today's openwrt, the name of the device is glinet_gl-e750, 
so platform_check failure is prompted.
You'd better use uboot to upgrade your firmware, follow the link below 
for the uboot upgrade steps

https://docs.gl-inet.com/en/3/troubleshooting/debrick/

this device also only has 1 ethernet port exposed on the board.
Yes, the E750 has only one ethernet port,
In E750, we only use GMAC0, but in ATH79 target, I had to initialize 
P4 via GMAC1 connected to the Ethernet switch, so you'll see eth0 and 
eth1 on your system.
I have tried to use GMAC0 to initialize P4 directly, but after 
initializing P4 in this way, the speed of P4 can only be 100M, not 
100M/10M.




*/Best Regards/*



Hi Chongjun,


Thanks for the details.


Could you send a V3 to ensure ethernet is working?

Currently, there seems to be a mismatch and I suspect the wrong eth is 
being assigned with an IP.



Basically, the device is totally unreachable with the current patchset.


Thanks for your efforts,


Koen


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


[OpenWrt-Devel] [PATCH] ccache: update to 3.7.9

2020-05-28 Thread DENG Qingfang
Update ccache to 3.7.9

Release notes:
https://ccache.dev/releasenotes.html#_ccache_3_7_9

Signed-off-by: DENG Qingfang 
---
 tools/ccache/Makefile   | 4 ++--
 tools/ccache/patches/100-honour-copts.patch | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/ccache/Makefile b/tools/ccache/Makefile
index 4e99207872..bf81f2d388 100644
--- a/tools/ccache/Makefile
+++ b/tools/ccache/Makefile
@@ -8,11 +8,11 @@ include $(TOPDIR)/rules.mk
 include $(INCLUDE_DIR)/target.mk
 
 PKG_NAME:=ccache
-PKG_VERSION:=3.7.7
+PKG_VERSION:=3.7.9
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 
PKG_SOURCE_URL:=https://github.com/ccache/ccache/releases/download/v$(PKG_VERSION)
-PKG_HASH:=b7c1d6d6fe42f18e424de92746af863e0bc85794da3d69e44300840c478c98cd
+PKG_HASH:=f893da7543bfb9172bd55e603fcbdfcd83e6def176a28689c13235695b4cf44b
 
 include $(INCLUDE_DIR)/host-build.mk
 
diff --git a/tools/ccache/patches/100-honour-copts.patch 
b/tools/ccache/patches/100-honour-copts.patch
index a3cef56213..31f70090e4 100644
--- a/tools/ccache/patches/100-honour-copts.patch
+++ b/tools/ccache/patches/100-honour-copts.patch
@@ -1,6 +1,6 @@
 --- a/src/ccache.c
 +++ b/src/ccache.c
-@@ -2220,6 +2220,7 @@ calculate_object_hash(struct args *args,
+@@ -2227,6 +2227,7 @@ calculate_object_hash(struct args *args,
"CPLUS_INCLUDE_PATH",
"OBJC_INCLUDE_PATH",
"OBJCPLUS_INCLUDE_PATH", // clang
-- 
2.16.6




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