[OpenWrt-Devel] [PATCH 1/4] mvebu: add Turris Omnia LED support
The kernel driver is directly pulled from TurrisOS.
https://gitlab.labs.nic.cz/turris/turris-build/commit/60f75b6b
I have added the associated extension of the device tree.
Signed-off-by: Klaus Kudielka
---
.../mvebu/patches-4.14/490-omnia-leds.patch | 568 ++
1 file changed, 568 insertions(+)
create mode 100644 target/linux/mvebu/patches-4.14/490-omnia-leds.patch
diff --git a/target/linux/mvebu/patches-4.14/490-omnia-leds.patch
b/target/linux/mvebu/patches-4.14/490-omnia-leds.patch
new file mode 100644
index 00..e819eb247f
--- /dev/null
+++ b/target/linux/mvebu/patches-4.14/490-omnia-leds.patch
@@ -0,0 +1,568 @@
+--- a/drivers/leds/Kconfig
b/drivers/leds/Kconfig
+@@ -632,6 +632,13 @@ config LEDS_IS31FL32XX
+
+ comment "LED driver for blink(1) USB RGB LED is under Special HID drivers
(HID_THINGM)"
+
++config LEDS_OMNIA
++ tristate "LED support for the Turris Omnia board"
++ depends on LEDS_CLASS
++ help
++ Say Y here to include support for the LED driver on Turris Omnia
++ board.
++
+ config LEDS_BLINKM
+ tristate "LED support for the BlinkM I2C RGB LED"
+ depends on LEDS_CLASS
+--- a/drivers/leds/Makefile
b/drivers/leds/Makefile
+@@ -73,6 +73,7 @@ obj-$(CONFIG_LEDS_PM8058)+= leds-pm805
+ obj-$(CONFIG_LEDS_MLXCPLD)+= leds-mlxcpld.o
+ obj-$(CONFIG_LEDS_NIC78BX)+= leds-nic78bx.o
+ obj-$(CONFIG_LEDS_MT6323) += leds-mt6323.o
++obj-$(CONFIG_LEDS_OMNIA) += leds-omnia.o
+
+ # LED SPI Drivers
+ obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
+--- /dev/null
b/drivers/leds/leds-omnia.c
+@@ -0,0 +1,457 @@
++/*
++ * Copyright 2016 CZ.NIC, z.s.p.o.
++ *
++ * Author: Tomas Hlavacek
++ *
++ * This program is free software; you can redistribute it and/or modify
++ * it under the terms of the GNU General Public License version 2 as
++ * published by the Free Software Foundation.
++ */
++
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++
++#define MAX_LEDS 13
++#define ALL_LEDS_INDEX 12
++
++#define LED_AUTONOMOUS_ADDR 3
++#define LED_ONOFF_ADDR 4
++#define LED_COLOR_ADDR 5
++#define GLOB_BRIGHTNESS_READ 8
++#define GLOB_BRIGHTNESS_WRITE 7
++
++
++
++struct omnia_platform_data {
++struct led_platform_data leds;
++};
++
++static const struct i2c_device_id omnia_id[] = {
++ { "omnia", 0 },
++ { }
++};
++MODULE_DEVICE_TABLE(i2c, omnia_id);
++
++struct omnia_led_mcu {
++ struct mutex mutex;
++ struct i2c_client *client;
++ struct omnia_led *leds;
++};
++
++struct omnia_led {
++ struct omnia_led_mcu *chip;
++ struct led_classdev led_cdev;
++ int led_num; /* 0 .. 11 + 12=ALL */
++ char name[32];
++ u8 autonomous;
++ u8 r;
++ u8 g;
++ u8 b;
++ struct work_struct work;
++ enum led_brightness new_brightness;
++};
++
++static int omnia_led_brightness_set(struct omnia_led *led,
++ enum led_brightness brightness)
++{
++ int ret;
++
++ mutex_lock(>chip->mutex);
++
++ ret = i2c_smbus_write_byte_data(led->chip->client, LED_ONOFF_ADDR,
++ (led->led_num | ((brightness != LED_OFF)<<4)));
++
++ mutex_unlock(>chip->mutex);
++ return ret;
++}
++
++static int omnia_led_autonomous_set(struct omnia_led *led, int autonomous)
++{
++ int ret, i;
++
++ mutex_lock(>chip->mutex);
++
++ if (led->autonomous == (autonomous != 0)) {
++ mutex_unlock(>chip->mutex);
++ return 0;
++ }
++
++ led->autonomous = (autonomous != 0);
++
++ if (led->led_num == ALL_LEDS_INDEX) {
++ for (i=0; i<(MAX_LEDS-1); i++)
++ led->chip->leds[i].autonomous = led->autonomous;
++ }
++
++ ret = i2c_smbus_write_byte_data(led->chip->client, LED_AUTONOMOUS_ADDR,
++ (u8)(led->led_num | ((!led->autonomous) << 4)));
++
++ mutex_unlock(>chip->mutex);
++ return ret;
++}
++
++static int omnia_glob_brightness_set(struct omnia_led_mcu *chip,
++ int glob_brightness)
++{
++ int ret;
++
++ mutex_lock(>mutex);
++
++ ret = i2c_smbus_write_byte_data(chip->client, GLOB_BRIGHTNESS_WRITE,
++ (u8)glob_brightness);
++
++ mutex_unlock(>mutex);
++ return ret;
++}
++
++static int omnia_glob_brightness_get(struct omnia_led_mcu *chip)
++{
++ int ret;
++
++ mutex_lock(>mutex);
++
++ ret = i2c_smbus_read_byte_data(chip->client, GLOB_BRIGHTNESS_READ);
++
++ mutex_unlock(>mutex);
++ return ret;
++}
++
++static int omnia_led_color_set(struct omnia_led *led, u8 r, u8 g, u8 b)
++{
++ int ret, i;
++ u8 buf[5];
++
++ buf[0] = LED_COLOR_ADDR;
++ buf[1] = led->led_num;
++ buf[2] = r;
++ buf[3] = g;
++ buf[4] = b;
++
++
[OpenWrt-Devel] [PATCH 4/4] mvebu: add Turris Omnia LED configuration
With this commit users are able to configure all extra features of the
Turris Omnia LED driver (global brightness, individual LED color,
individual autonomous flag). For example:
uci set omnia_led.main.global_brightness='6'
uci set omnia_led.power.color='255 0 0'
service omnia_led start
uci commit
This is achieved by the /etc/init.d/omnia_led script, which generates its
own default configuration /etc/config/omnia_led upon the first boot.
In the default configuration, all LAN and PCI LEDs (5+3) function
autonomously. The remaining 4 LEDs are driven by software
(autonomous=0) and have sensible UCI defaults.
The WAN LED uses the netdev trigger (benefit: this also works with SFP).
Signed-off-by: Klaus Kudielka
---
.../mvebu/base-files/etc/board.d/01_leds | 6 ++
.../mvebu/base-files/etc/init.d/omnia_led | 90 +++
2 files changed, 96 insertions(+)
create mode 100755 target/linux/mvebu/base-files/etc/init.d/omnia_led
diff --git a/target/linux/mvebu/base-files/etc/board.d/01_leds
b/target/linux/mvebu/base-files/etc/board.d/01_leds
index ff8d4a21c0..96723d0295 100755
--- a/target/linux/mvebu/base-files/etc/board.d/01_leds
+++ b/target/linux/mvebu/base-files/etc/board.d/01_leds
@@ -41,6 +41,12 @@ armada-385-linksys-venom)
ucidef_set_led_usbport "usb2" "USB 2" "pca963x:venom:blue:usb3_1"
"usb2-port1" "usb3-port1"
ucidef_set_led_usbport "usb2_ss" "USB 2 SS" "pca963x:venom:blue:usb3_2"
"usb3-port1"
;;
+armada-385-turris-omnia)
+ ucidef_set_led_default "power" "POWER" "omnia-led:power" "1"
+ ucidef_set_led_netdev "wan" "WAN" "omnia-led:wan" "eth2"
+ ucidef_set_led_default "user1" "A" "omnia-led:user1" "0"
+ ucidef_set_led_default "user2" "B" "omnia-led:user2" "0"
+ ;;
armada-xp-linksys-mamba)
ucidef_set_led_netdev "wan" "WAN" "mamba:white:wan" "eth1"
ucidef_set_led_usbport "usb1" "USB 1" "mamba:white:usb2" "usb1-port1"
diff --git a/target/linux/mvebu/base-files/etc/init.d/omnia_led
b/target/linux/mvebu/base-files/etc/init.d/omnia_led
new file mode 100755
index 00..bbe605d75a
--- /dev/null
+++ b/target/linux/mvebu/base-files/etc/init.d/omnia_led
@@ -0,0 +1,90 @@
+#!/bin/sh /etc/rc.common
+
+START=96
+
+. /lib/functions/leds.sh
+
+config=omnia_led
+
+omnia_set() {
+ local type
+ local sect
+
+ type=$1
+ sect=$2
+ uci set $config.$sect=$type
+ shift
+ shift
+ while [ -n "$1" ]; do
+ uci set $config.$sect.$1="$2"
+ shift
+ shift
+ done
+}
+
+omnia_generate_config() {
+ echo "Generating /etc/config/$config"
+ touch /etc/config/$config
+ omnia_set controller main global_brightness 100
+ omnia_set led all sysfs omnia-led:all color "255 255 255"
+ omnia_set led power sysfs omnia-led:power autonomous 0
+ omnia_set led lan0 sysfs omnia-led:lan0 autonomous 1
+ omnia_set led lan1 sysfs omnia-led:lan1 autonomous 1
+ omnia_set led lan2 sysfs omnia-led:lan2 autonomous 1
+ omnia_set led lan3 sysfs omnia-led:lan3 autonomous 1
+ omnia_set led lan4 sysfs omnia-led:lan4 autonomous 1
+ omnia_set led wan sysfs omnia-led:wan autonomous 0
+ omnia_set led pci1 sysfs omnia-led:pci1 autonomous 1
+ omnia_set led pci2 sysfs omnia-led:pci2 autonomous 1
+ omnia_set led pci3 sysfs omnia-led:pci3 autonomous 1
+ omnia_set led user1 sysfs omnia-led:user1 autonomous 0
+ omnia_set led user2 sysfs omnia-led:user2 autonomous 0
+ uci commit $config
+}
+
+omnia_load_global_brightness() {
+ local path
+ local global_brightness
+
+ path=/sys/bus/i2c/devices/1-002b
+ config_get global_brightness main global_brightness 100
+
+ [ -d $path ] && {
+ echo "Setting up led controller"
+ echo "$global_brightness" >$path/global_brightness 2>/dev/null
||
+ echo " Failed to set global_brightness to
'$global_brightness'"
+ } || echo "Could not find led controller at $path"
+}
+
+omnia_load_led() {
+ local sysfs
+ local color
+ local autonomous
+
+ config_get sysfs $1 sysfs
+ config_get color $1 color
+ config_get autonomous $1 autonomous
+
+ [ -n "$sysfs" ] && {
+ [ -d "/sys/class/leds/$sysfs" ] && {
+ echo "Setting up $sysfs"
+ [ -n "$color" ] && {
+ led_set_attr "$sysfs" color "$color"
2>/dev/null ||
+ echo " Failed to set color to '$color'"
+ } || true
+ [ -n "$autonomous" ] && {
+ led_set_attr "$sysfs" autonomous "$autonomous"
2>/dev/null ||
+ echo " Failed to set autonomous to
'$autonomous'"
+ } || true
+ } || echo "Could not find $sysfs in /sys/class/leds"
+ } || echo
[OpenWrt-Devel] [PATCH 2/4] mvebu: enable Turris Omnia LED support as module
leds.mk: - Define kmod-leds-omnia including dependencies. - Load early, in order to support LED diagnostics during preinit. cortex-a9.mk: - Select kmod-leds-omnia for the turris-omnia image. i2c.mk: - LED controller is behind i2c mux. Therefore, load i2c-mux-pca954x early as well. Signed-off-by: Klaus Kudielka --- package/kernel/linux/modules/i2c.mk | 2 +- package/kernel/linux/modules/leds.mk | 16 target/linux/mvebu/image/cortex-a9.mk | 1 + 3 files changed, 18 insertions(+), 1 deletion(-) diff --git a/package/kernel/linux/modules/i2c.mk b/package/kernel/linux/modules/i2c.mk index 4cf37dae07..d7a07a733f 100644 --- a/package/kernel/linux/modules/i2c.mk +++ b/package/kernel/linux/modules/i2c.mk @@ -176,7 +176,7 @@ I2C_MUX_PCA954x_MODULES:= \ CONFIG_I2C_MUX_PCA954x:drivers/i2c/muxes/i2c-mux-pca954x define KernelPackage/i2c-mux-pca954x - $(call i2c_defaults,$(I2C_MUX_PCA954x_MODULES),51) + $(call i2c_defaults,$(I2C_MUX_PCA954x_MODULES),51,1) TITLE:=Philips PCA954x I2C mux/switches DEPENDS:=kmod-i2c-mux endef diff --git a/package/kernel/linux/modules/leds.mk b/package/kernel/linux/modules/leds.mk index 7019f04779..a8673c4af9 100644 --- a/package/kernel/linux/modules/leds.mk +++ b/package/kernel/linux/modules/leds.mk @@ -145,3 +145,19 @@ define KernelPackage/leds-pca963x/description endef $(eval $(call KernelPackage,leds-pca963x)) + + +define KernelPackage/leds-omnia + SUBMENU:=$(LEDS_MENU) + TITLE:=Turris Omnia LED support + DEPENDS:=@TARGET_mvebu_cortexa9 +kmod-i2c-core +kmod-i2c-mux +kmod-i2c-mux-pca954x + KCONFIG:=CONFIG_LEDS_OMNIA + FILES:=$(LINUX_DIR)/drivers/leds/leds-omnia.ko + AUTOLOAD:=$(call AutoLoad,60,leds-omnia,1) +endef + +define KernelPackage/leds-omnia/description + Driver for the Turris Omnia LED controller. +endef + +$(eval $(call KernelPackage,leds-omnia)) diff --git a/target/linux/mvebu/image/cortex-a9.mk b/target/linux/mvebu/image/cortex-a9.mk index 79c3bc7bdb..272e381db0 100644 --- a/target/linux/mvebu/image/cortex-a9.mk +++ b/target/linux/mvebu/image/cortex-a9.mk @@ -162,6 +162,7 @@ define Device/turris-omnia DEVICE_TITLE := Turris Omnia DEVICE_PACKAGES := \ mkf2fs e2fsprogs kmod-fs-vfat kmod-nls-cp437 kmod-nls-iso8859-1 \ +kmod-leds-omnia \ wpad-basic kmod-ath9k kmod-ath10k-ct ath10k-firmware-qca988x-ct IMAGES := $$(IMAGE_PREFIX)-sysupgrade.img.gz omnia-medkit-$$(IMAGE_PREFIX)-initramfs.tar.gz IMAGE/$$(IMAGE_PREFIX)-sysupgrade.img.gz := boot-img | sdcard-img | gzip | append-metadata -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/4] mvebu: add Turris Omnia LED support
This patchset adds LED support for the Turris Omnia, enables LED diagnostics, and adds UCI configuration capability for the non-standard features of the driver (color, autonomous, global_brightness). Tested on my Turris Omnia. Klaus Kudielka (4): mvebu: add Turris Omnia LED support mvebu: enable Turris Omnia LED support as module mvebu: enable LED diagnostics for Turris Omnia mvebu: add Turris Omnia LED configuration package/kernel/linux/modules/i2c.mk | 2 +- package/kernel/linux/modules/leds.mk | 16 + .../mvebu/base-files/etc/board.d/01_leds | 6 + target/linux/mvebu/base-files/etc/diag.sh | 3 + .../mvebu/base-files/etc/init.d/omnia_led | 90 +++ .../base-files/lib/preinit/09_initialize_leds | 12 + target/linux/mvebu/image/cortex-a9.mk | 1 + .../mvebu/patches-4.14/490-omnia-leds.patch | 568 ++ 8 files changed, 697 insertions(+), 1 deletion(-) create mode 100755 target/linux/mvebu/base-files/etc/init.d/omnia_led create mode 100644 target/linux/mvebu/base-files/lib/preinit/09_initialize_leds create mode 100644 target/linux/mvebu/patches-4.14/490-omnia-leds.patch -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/4] mvebu: enable LED diagnostics for Turris Omnia
Just before starting LED diagnostics, a preinit hook disables
the 'autonomous' flag for all LEDs. This way, the power LED will
start blinking during preinit, as desired. As a benefit, all
other LEDs remain dark, until boot is finished (and the desired
LED configuration is loaded). This avoids the rather distracting
on/off behaviour of some LAN LEDs during boot.
Signed-off-by: Klaus Kudielka
---
target/linux/mvebu/base-files/etc/diag.sh| 3 +++
.../mvebu/base-files/lib/preinit/09_initialize_leds | 12
2 files changed, 15 insertions(+)
create mode 100644 target/linux/mvebu/base-files/lib/preinit/09_initialize_leds
diff --git a/target/linux/mvebu/base-files/etc/diag.sh
b/target/linux/mvebu/base-files/etc/diag.sh
index 327a82df93..f81dba083f 100644
--- a/target/linux/mvebu/base-files/etc/diag.sh
+++ b/target/linux/mvebu/base-files/etc/diag.sh
@@ -22,6 +22,9 @@ get_status_led() {
armada-385-linksys-venom)
status_led="venom:blue:power"
;;
+ armada-385-turris-omnia)
+ status_led="omnia-led:power"
+ ;;
armada-xp-linksys-mamba)
status_led="mamba:white:power"
;;
diff --git a/target/linux/mvebu/base-files/lib/preinit/09_initialize_leds
b/target/linux/mvebu/base-files/lib/preinit/09_initialize_leds
new file mode 100644
index 00..c83fa671e1
--- /dev/null
+++ b/target/linux/mvebu/base-files/lib/preinit/09_initialize_leds
@@ -0,0 +1,12 @@
+#!/bin/sh
+
+do_initialize_leds() {
+ case $(board_name) in
+ armada-385-turris-omnia)
+ led_set_attr omnia-led:all autonomous 0
+ ;;
+ esac
+}
+
+boot_hook_add preinit_main do_initialize_leds
+
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/5] ath79: Add support for Ubiquiti Nanostation M (XW)
FYI, I've moved with version v2 of this patch series to GitHub[1]. 1. https://github.com/openwrt/openwrt/pull/1632 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hostapd 2.7 released
On 2018-12-12 14:37, Hauke Mehrtens wrote: On 12/12/18 10:39 AM, Daniel Golle wrote: Hi! hostapd 2.7 has been released on December 2nd: http://w1.fi/cgit/hostap/plain/hostapd/ChangeLog I've updated the hostapd package to use the hostapd_2_7 tag with our patches on top, find it in my staging tree: https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=c494eadb6555c02eb5d00b4274c4fc955291516c I've compile-tested all build variants and run-time tested wpad(-full). Please test and report back, so we shall have this merged in master asap. Cheers Daniel Hi Daniel, I also prepared this yesterday, see here: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commit;h=95215ae8eb738fd47a991cfcae0fe20ab44f4116 When I activate psk3-mixed mode + iee80211r mode my Debian stable client does not can to connect any more, I do not know if this is a regression, an already existing problem or a problem on the client side. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel I have a problem similar to that, except only on certain Android devices. Both of my Ubuntu laptops can connect fine. (Disabling FT-SAE allows the androids to connect again.) There also isn't any useful logging output on the androids. Does the Debian system log anything when it fails? Michael ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] ath10k-ct: Update to 2018-12-11 and use version based on 4.19
This updates the ath10k-ct driver to the version from 2018-12-11 and
selects the ath10k-ct version based on kernel 4.19 by default.
CONFIG_ATH10K_CE was introduced between kernel 4.16 and 4.19 and is a
mandatory option.
Signed-off-by: Hauke Mehrtens
---
changes since v1:
* Add description
* update to 2018-12-11 which adds additional features and fixes
package/kernel/ath10k-ct/Makefile | 12 +-
.../ath10k-ct/patches/100-kernel_compat.patch | 2 +-
...h-all-IEs-for-variant-before-falling-back.patch | 8 +-
...-controlling-support-for-various-chipsets.patch | 544 -
...02-ath10k-4.16-use-tpt-trigger-by-default.patch | 41 +-
5 files changed, 583 insertions(+), 24 deletions(-)
diff --git a/package/kernel/ath10k-ct/Makefile
b/package/kernel/ath10k-ct/Makefile
index d47ab8655c..ae477ab74b 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -8,14 +8,14 @@ PKG_LICENSE_FILES:=
PKG_SOURCE_URL:=https://github.com/greearb/ath10k-ct.git
PKG_SOURCE_PROTO:=git
-PKG_SOURCE_DATE:=2018-09-29
-PKG_SOURCE_VERSION:=b9989fbd5d6e3269b3e49ab3ec71b4174a02209e
-PKG_MIRROR_HASH:=67bb1c81518aea5880757d521023db25190d9cca21ba67bf1c7e577efd287430
+PKG_SOURCE_DATE:=2018-12-11
+PKG_SOURCE_VERSION:=812d90c08ca8ce8dcbd1b2281e89ff562c7096e1
+PKG_MIRROR_HASH:=986feafd27a828801be96ce4177886204998beea305cda40aafe92a9636db852
-# Build the 4.13 ath10k-ct driver version. Other options are "-4.9", or
+# Build the 4.19 ath10k-ct driver version. Other options are "-4.16", or
# leave un-defined for 4.7 kernel. Probably this should match as closely as
# possible to whatever mac80211 backports version is being used.
-CT_KVER="-4.16"
+CT_KVER="-4.19"
PKG_MAINTAINER:=Ben Greear
PKG_BUILD_PARALLEL:=1
@@ -58,7 +58,7 @@ ifdef CONFIG_PACKAGE_MAC80211_MESH
NOSTDINC_FLAGS += -DCONFIG_MAC80211_MESH
endif
-CT_MAKEDEFS += CONFIG_ATH10K=m CONFIG_ATH10K_PCI=m
+CT_MAKEDEFS += CONFIG_ATH10K=m CONFIG_ATH10K_PCI=m CONFIG_ATH10K_CE=y
# This AHB logic is needed for IPQ4019 radios
CT_MAKEDEFS += CONFIG_ATH10K_AHB=m
diff --git a/package/kernel/ath10k-ct/patches/100-kernel_compat.patch
b/package/kernel/ath10k-ct/patches/100-kernel_compat.patch
index df7a3b2a86..ea4c849179 100644
--- a/package/kernel/ath10k-ct/patches/100-kernel_compat.patch
+++ b/package/kernel/ath10k-ct/patches/100-kernel_compat.patch
@@ -108,7 +108,7 @@
return;
--- a/ath10k-4.16/wmi.c
+++ b/ath10k-4.16/wmi.c
-@@ -4061,7 +4061,7 @@ static void ath10k_dfs_radar_report(stru
+@@ -4063,7 +4063,7 @@ static void ath10k_dfs_radar_report(stru
ATH10K_DFS_STAT_INC(ar, pulses_detected);
diff --git
a/package/kernel/ath10k-ct/patches/160-ath10k-search-all-IEs-for-variant-before-falling-back.patch
b/package/kernel/ath10k-ct/patches/160-ath10k-search-all-IEs-for-variant-before-falling-back.patch
index 3788b81102..cb7aec06f5 100644
---
a/package/kernel/ath10k-ct/patches/160-ath10k-search-all-IEs-for-variant-before-falling-back.patch
+++
b/package/kernel/ath10k-ct/patches/160-ath10k-search-all-IEs-for-variant-before-falling-back.patch
@@ -249,7 +249,7 @@ Origin: backport,
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
goto success;
--- a/ath10k-4.16/core.c
+++ b/ath10k-4.16/core.c
-@@ -1559,14 +1559,61 @@ out:
+@@ -1560,14 +1560,61 @@ out:
return ret;
}
@@ -314,7 +314,7 @@ Origin: backport,
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
ar->normal_mode_fw.board = ath10k_fetch_fw_file(ar,
ar->hw_params.fw.dir,
-@@ -1604,73 +1651,28 @@ static int ath10k_core_fetch_board_data_
+@@ -1605,73 +1652,28 @@ static int ath10k_core_fetch_board_data_
data += magic_len;
len -= magic_len;
@@ -397,7 +397,7 @@ Origin: backport,
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
return 0;
err:
-@@ -1679,12 +1681,12 @@ err:
+@@ -1680,12 +1682,12 @@ err:
}
static int ath10k_core_create_board_name(struct ath10k *ar, char *name,
@@ -412,7 +412,7 @@ Origin: backport,
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux
scnprintf(variant, sizeof(variant), ",variant=%s",
ar->id.bdf_ext);
-@@ -1710,21 +1712,31 @@ out:
+@@ -1711,21 +1713,31 @@ out:
static int ath10k_core_fetch_board_file(struct ath10k *ar)
{
diff --git
a/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
b/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
index 67774dcc15..ae03e5c272 100644
---
a/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
+++
b/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
@@ -161,7 +161,7 @@ v13:
Re: [OpenWrt-Devel] brcm2708: add kernel 4.14 support
On 7/12/18 05:06, Stijn Tintel wrote: > On 11/11/18 18:37, Stijn Tintel wrote: >> Hi, >> >> I have just pushed support for the 4.14 kernel on the brcm2708 target to >> my staging tree [1], and would like to get some feedback before pushing >> it to master. It would also be nice if people could do runtime tests on >> bcm2709 and bcm2710, as I don't own such hardware. >> >> Thanks, >> Stijn >> >> [1] >> https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/brcm2708-4_14 >> > Updated [1]: > - based on 4.14.86 > - split kmod changes in separate commits > - kept lan78xx patches except those that are superseded by upstream > changes, added another one that attempts to fix broken ethernet and > "kevent 4 may have been dropped" flood > - added missing compatible strings using upstream names for compute modules > - no longer removing the sense HAT patch, I might add kmod packages for > that later > > Compile-tested all 3 subtargets again with CONFIG_ALL_KMODS=y, and > runtime-tested bcm2708 on RPi0W and bcm2710 on RPi3B+. The wired > interface on the latter seems to be usable now. > > I'm planning to push this to master as soon as Koen pushed the 4.14.86 > bump. If there are any objections, please speak up ASAP. > After flashing one of my RPi0W's running headless, it didn't come back. When testing it on my desk, it works just fine. After some digging I found that not having HDMI plugged in during boot causes the problem. This happens because brcmfmac fails to load due to a "vmalloc: allocation failure": [ 17.527326] vmap allocation for size 253952 failed: use vmalloc= to increase size [ 17.540014] kmodloader: vmalloc: allocation failure: 249856 bytes, mode:0x14000c0(GFP_KERNEL), nodemask=(null) [ 17.554778] CPU: 0 PID: 212 Comm: kmodloader Tainted: G C O 4.14.87 #0 [ 17.566819] Hardware name: BCM2835 [ 17.572486] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 17.584649] [] (show_stack) from [] (warn_alloc+0xac/0x168) [ 17.594362] [] (warn_alloc) from [] (__vmalloc_node_range+0x1f0/0x238) [ 17.607085] [] (__vmalloc_node_range) from [] (module_alloc+0x3c/0x4c) [ 17.620019] [] (module_alloc) from [] (load_module+0x7fc/0x2160) [ 17.632592] [] (load_module) from [] (SyS_init_module+0x138/0x168) [ 17.645312] [] (SyS_init_module) from [] (ret_fast_syscall+0x0/0x54) [ 17.658224] Mem-Info: [ 17.662897] active_anon:232 inactive_anon:0 isolated_anon:0 [ 17.662897] active_file:2793 inactive_file:1495 isolated_file:0 [ 17.662897] unevictable:0 dirty:104 writeback:0 unstable:0 [ 17.662897] slab_reclaimable:670 slab_unreclaimable:1282 [ 17.662897] mapped:258 shmem:3 pagetables:21 bounce:0 [ 17.662897] free:102979 free_pcp:75 free_cma:3749 [ 17.708759] Node 0 active_anon:928kB inactive_anon:0kB active_file:11172kB inactive_file:5980kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:1032kB dirty:416kB writeback:0kB shmem:12kB writeback_tmp:0kB unstable:0kB al l_unreclaimable? no [ 17.740097] Normal free:411916kB min:2624kB low:3280kB high:3936kB active_anon:928kB inactive_anon:0kB active_file:11172kB inactive_file:5980kB unevictable:0kB writepending:416kB present:458752kB managed:447900kB mlocked:0kB kernel_st ack:360kB pagetables:84kB bounce:0kB free_pcp:300kB local_pcp:300kB free_cma:14996kB [ 17.777379] lowmem_reserve[]: 0 0 [ 17.782966] Normal: 3*4kB (UMC) 32*8kB (UMEC) 18*16kB (MEC) 7*32kB (UMC) 2*64kB (UC) 3*128kB (MC) 2*256kB (EC) 1*512kB (U) 2*1024kB (ME) 1*2048kB (C) 99*4096kB (MC) = 411916kB [ 17.805336] 4291 total pagecache pages [ 17.811267] 0 pages in swap cache [ 17.816776] Swap cache stats: add 0, delete 0, find 0/0 [ 17.824208] Free swap = 0kB [ 17.829227] Total swap = 0kB [ 17.834223] 114688 pages RAM [ 17.839137] 0 pages HighMem/MovableOnly [ 17.845094] 2713 pages reserved [ 17.850284] 4096 pages cma reserved I'm running into this problem because I have both kmod-video-bcm2835 and kmod-drm-vc4 enabled in my config. If I remove the related files that load these modules from /etc/modules.d, brcmfmac loads fine without HDMI attached. If I manually load either of the disabled modules afterwards, this fails the same way. I'm going to report this problem upstream, and will hold off pushing this to master until a fix is available. Stijn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hostapd 2.7 released
On 12/12/18 10:39 AM, Daniel Golle wrote: > Hi! > > hostapd 2.7 has been released on December 2nd: > http://w1.fi/cgit/hostap/plain/hostapd/ChangeLog > > I've updated the hostapd package to use the hostapd_2_7 tag with our > patches on top, find it in my staging tree: > https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=c494eadb6555c02eb5d00b4274c4fc955291516c > > I've compile-tested all build variants and run-time tested wpad(-full). > Please test and report back, so we shall have this merged in master > asap. > > > Cheers > > > Daniel > Hi Daniel, I also prepared this yesterday, see here: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=commit;h=95215ae8eb738fd47a991cfcae0fe20ab44f4116 When I activate psk3-mixed mode + iee80211r mode my Debian stable client does not can to connect any more, I do not know if this is a regression, an already existing problem or a problem on the client side. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath10k-firmware: update all CT firmware variants
Wave-1 firmware (988x, 9887): bug fixes Wave-2 firmware (4019, 9888, 99x0, 9984): fix protected management frames, rate-ctrl fixes, and performance improvements Signed-off-by: Michael Yartys --- package/firmware/ath10k-firmware/Makefile | 64 +++ 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/package/firmware/ath10k-firmware/Makefile b/package/firmware/ath10k-firmware/Makefile index 39b1b7da98..185fcc074b 100644 --- a/package/firmware/ath10k-firmware/Makefile +++ b/package/firmware/ath10k-firmware/Makefile @@ -64,92 +64,92 @@ define Download/ct-firmware-htt URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) endef -QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-21.bin.lede.002 +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.001 define Download/ath10k-firmware-qca988x-ct $(call Download/ct-firmware,QCA988X,) - HASH:=354b8a116a406ba6521a8bf6165ea2dce76996ab36e7905cd71e772ea240017d + HASH:=7c03642a4f342fc6f9916485c47270893cdc75b4ba2e7fcdd8fbdfa03e8c551b endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) -QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-21.bin.lede.002 +QCA988X_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.001 define Download/ath10k-firmware-qca988x-ct-htt $(call Download/ct-firmware-htt,QCA988X,) - HASH:=7a8369b33f07200bf0bbf8c88617c25c7f3435a51f8ca0e330d220586338f991 + HASH:=afe5ead5058727ed3fc8a0fdc738e705d53295369691e4d1376f85f8a98cefb1 endef $(eval $(call Download,ath10k-firmware-qca988x-ct-htt)) -QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-21.bin.lede.001 +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.001 define Download/ath10k-firmware-qca9887-ct $(call Download/ct-firmware,QCA9887,ath10k-9887) - HASH:=ab8ef9afae5117f1cf71bbf80abde225f9f104620ba04a9734da51268e139803 + HASH:=ba543d0966d4c3ca53a732613ea8aea14b9d3c388792ba914110f8c8609da4c8 endef $(eval $(call Download,ath10k-firmware-qca9887-ct)) -QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-21.bin.lede.001 +QCA9887_FIRMWARE_FILE_CT_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.001 define Download/ath10k-firmware-qca9887-ct-htt $(call Download/ct-firmware-htt,QCA9887,ath10k-9887) - HASH:=bb16a90ec8e7f80539ad016ebf5e3542bfc95a0e1a58c9f1b91e408a130ac058 + HASH:=7d9e3abbbe12dab13447c96707dcb747c90d0663c7a687352c9bba55e2f4debc endef $(eval $(call Download,ath10k-firmware-qca9887-ct-htt)) -QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-11.bin-lede.001 +QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.001 define Download/ath10k-firmware-qca99x0-ct - $(call Download/ct-firmware,QCA99X0,ath10k-10-4) - HASH:=f5c1caaf5a7fb8a07d0e292bab853311a1e826b5de7e76a06e4d801e33827a49 + $(call Download/ct-firmware,QCA99X0,ath10k-10-4b) + HASH:=9da5863aa92e416c1c4fd66b128f0f14d88840500b3d0b32b9b39cd7985794d9 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct)) -QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-11.bin-lede.001 +QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.001 define Download/ath10k-firmware-qca99x0-ct-htt - $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4) - HASH:=a78a457a76f28e2ef34a7a3b1beef06064f7512680e14beafe02625d94d11619 + $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b) + HASH:=c7a1616e03a05b6456b94230c967da91253a69c000547f0d22b3fbb0f735495b endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-htt)) -QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-11.bin-lede.001 +QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.001 define Download/ath10k-firmware-qca9984-ct - $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4) - HASH:=204dde43a107911cd48ac04f6450365722fba6121487e49d4ef36b8aaa83339b + $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b) + HASH:=c68c7e2b1d517fe69e6e94d640630453930c12de2982ed7d2e9132edf476d1b2 endef $(eval $(call Download,ath10k-firmware-qca9984-ct)) -QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-11.bin-lede.001 +QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.001 define Download/ath10k-firmware-qca9984-ct-htt - $(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4) - HASH:=e60b6033e96a9b14f43aae360e6a35e1217f3e94a4578821ccdb3e2da8521fae + $(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b) + HASH:=7d8a733b109d6226c287fd2b3782858e4e5b0b21ba2c29812d5d546d73d76f44 endef $(eval $(call Download,ath10k-firmware-qca9984-ct-htt)) -QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-11.bin-lede.001 +QCA4019_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.001 define Download/ath10k-firmware-qca4019-ct - $(call Download/ct-firmware,QCA4019,ath10k-4019-10-4) - HASH:=3daa439104806b1796c90e65bcafb18164358f0bd9e4d444302f7caf1c220dad + $(call
[OpenWrt-Devel] [PATCH v3] ath79: add support for TP-Link Archer A7
This patch adds support for TP-Link Archer A7 Specification: - SOC: QCA9563 - Flash: 16 MiB (SPI) - RAM: 128 MiB (DDR2) - Ethernet: 4x 1Gbps LAN + 1x 1Gbps WAN - Wireless: - 2.4GHz (bgn) SoC internal - 5GHz (ac) QCA988x - USB: 1x USB 2.0 port - Button: 1x power, 1x reset, 1x wps - LED: 10x LEDs - UART: holes in PCB - Vcc, GND, RX, TX from ethernet port side - 115200n8 Flash instructions: Upload openwrt-ath79-generic-tplink_archer-a7-v5-squashfs-factory.bin via the Webinterface. Flash instruction using tftp recovery: 1. Connect the computer to one of the LAN ports of the Archer A7 2. Set the computer IP to 192.168.0.66 3. Start a tftp server with the OpenWrt factory image in the tftp root directory renamed to ArcherC7v5_tp_recovery.bin 2. Connect power cable to Archer A7, press and hold the reset button and turn the router on 3. Keep the reset button pressed for ~5 seconds 4. Wait ~150 seconds to complete flashing Changes since first revision: - Flash instructions using stock image webinterface - Changed "Version 5" in model string to "v5" - Split DTS file in qca9563_tplink_archer-x7-v5.dtsi and qca9563_tplink_archer-a7-v5.dts - Firmware image is now build with dynamic partitioning - Default to ath10k-ct Changes since second revision: - Changed uboot@0 to uboot@2 in DTS file - Fixed ordering issue in board led script - Specify firmware partition format in DTS file - Rebased Makefile device definition on common Device/tplink-safeloader-uimage definition - Merged switch section in network script (same configuration as tplink,tl-wdr3600 and tplink,tl-wdr4300) Signed-off-by: Karl-Felix Glatzer --- .../ath79/base-files/etc/board.d/01_leds | 7 + .../ath79/base-files/etc/board.d/02_network | 1 + .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 + .../ath79/dts/qca9563_tplink_archer-a7-v5.dts | 50 + .../dts/qca9563_tplink_archer-x7-v5.dtsi | 202 ++ target/linux/ath79/image/generic-tp-link.mk | 12 ++ tools/firmware-utils/src/tplink-safeloader.c | 42 +++- 7 files changed, 314 insertions(+), 1 deletion(-) create mode 100644 target/linux/ath79/dts/qca9563_tplink_archer-a7-v5.dts create mode 100644 target/linux/ath79/dts/qca9563_tplink_archer-x7-v5.dtsi diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds b/target/linux/ath79/base-files/etc/board.d/01_leds index 06fb8f4791..96cc5d5c13 100755 --- a/target/linux/ath79/base-files/etc/board.d/01_leds +++ b/target/linux/ath79/base-files/etc/board.d/01_leds @@ -52,6 +52,13 @@ pcs,cr3000) ucidef_set_led_switch "lan3" "LAN3" "pcs:blue:lan3" "switch0" "0x10" ucidef_set_led_switch "lan4" "LAN4" "pcs:blue:lan4" "switch0" "0x02" ;; +tplink,archer-a7-v5) + ucidef_set_led_switch "wan" "WAN" "tp-link:green:wan" "switch0" "0x02" + ucidef_set_led_switch "lan1" "LAN1" "tp-link:green:lan1" "switch0" "0x04" + ucidef_set_led_switch "lan2" "LAN2" "tp-link:green:lan2" "switch0" "0x08" + ucidef_set_led_switch "lan3" "LAN3" "tp-link:green:lan3" "switch0" "0x10" + ucidef_set_led_switch "lan4" "LAN4" "tp-link:green:lan4" "switch0" "0x20" + ;; tplink,archer-c58-v1|\ tplink,archer-c59-v1) ucidef_set_led_switch "lan" "LAN" "tp-link:green:lan" "switch0" "0x1E" diff --git a/target/linux/ath79/base-files/etc/board.d/02_network b/target/linux/ath79/base-files/etc/board.d/02_network index fa7a618909..1eeb4b50a0 100755 --- a/target/linux/ath79/base-files/etc/board.d/02_network +++ b/target/linux/ath79/base-files/etc/board.d/02_network @@ -132,6 +132,7 @@ ath79_setup_interfaces() ucidef_add_switch "switch0" \ "0@eth1" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" ;; + tplink,archer-a7-v5|\ tplink,tl-wdr3600|\ tplink,tl-wdr4300) ucidef_add_switch "switch0" \ diff --git a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata index 82c23e3079..9ecda22244 100644 --- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata +++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata @@ -104,6 +104,7 @@ case "$FIRMWARE" in ath10kcal_extract "ART" 20480 2116 ath10kcal_patch_mac $(macaddr_add $(cat /sys/class/net/eth0/address) +16) ;; + tplink,archer-a7-v5|\ tplink,archer-c7-v2) ath10kcal_extract "art" 20480 2116 ath10kcal_patch_mac $(macaddr_add $(cat /sys/class/net/eth1/address) -1) diff --git a/target/linux/ath79/dts/qca9563_tplink_archer-a7-v5.dts b/target/linux/ath79/dts/qca9563_tplink_archer-a7-v5.dts new file mode 100644 index 00..8cf86c0bc4 --- /dev/null +++ b/target/linux/ath79/dts/qca9563_tplink_archer-a7-v5.dts @@ -0,0 +1,50 @@ +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT +/dts-v1/;
Re: [OpenWrt-Devel] Changes in support for Mikrotik RB493G
09/12/2018 21:44, W. Michael Petullo: Changes in the last year or so have left me a little confused with the OpenWrt support for the Mikrotik RB493G. I generally compile my kernels and root disk images myself, namely by running "make menuconfig" and "make" in an OpenWrt source tree. I then go on to install the built artifacts by booting my router using TFTP and so on. First, it seems that OpenWrt master has dropped YAFFS support. I cannot find a clear statement on this, but I also cannot find how to build an OpenWrt image that supports YAFFS. kernel2minor was introduced to get rid of YAFFS [0]. It adds the YAFFS magic to the kernel binary, which is required by the bootloader to locate the kernel on flash[1]. Because of this, I rely on an old openwrt-ar71xx-nand-vmlinux-initramfs.elf which does contain YAFFS support to install a kernel. /dev/mtdblock5 contains the kernel, and this device bears a YAFFS filesystem on my Mikrotik RB493G. How am I to install a kernel after booting a current openwrt-ar71xx-nand-vmlinux-initramfs.elf when there is no YAFFS support? Aren't you supposed to load any of the nand-*-initramfs-kernel.bin? The initramfs-lzma.elf is some legacy image build code leftover. Second, things are configured to use UBIFS for the root filesystem. I have figured out how to set this up, but it seems rather involved: 1. Extract openwrt-ar71xx-mikrotik-device-nand-64m-rootfs.tar.gz on my build host, and use mkfs.ubifs on my build host to produce an UBIFS from its contents. 2. On the router, run ubinize, ubidetach, and ubiformat to install the UBIFS on /dev/mtd6. I suppose I am surprised that the OpenWrt build process does not build an UBIFS image as it does with tar.gz, ext4, and squashfs images. Am I missing something? Indeed, an ubinized image - which can be written to flash using the mtd command - is missing. Instead of adding such an image, I would like to propose another - hopefully easier - method to get OpenWrt installed on mikrotik nand boards. Would you please give the mikrotik branch from my staging tree[2] a try. The commands required are mentioned in the commit message. Be aware, due to lack of hardware it's not runtime tested. Mathias [0] https://git.openwrt.org/17ee6bb8f3 [1] https://git.io/fpHJx [2] https://git.openwrt.org/?p=openwrt/staging/mkresin.git ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] blockd: unmount device explicitly when it disappears
From: Rafał Miłecki
To keep autofs behavior consistent blockd should request both: mounting
and unmounting when needed. It's important as autofs-related actions may
require slightly different handling.
Without this patch:
1) autofs mounts were handled using TYPE_AUTOFS
2) autofs unmounts were handled using TYPE_HOTPLUG
Signed-off-by: Rafał Miłecki
---
blockd.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/blockd.c b/blockd.c
index 29d16f2..a00a5b3 100644
--- a/blockd.c
+++ b/blockd.c
@@ -111,8 +111,19 @@ block(char *cmd, char *action, char *device)
static void
device_free(struct device *device)
{
- if (device->autofs && device->target)
+ char *mp;
+
+ if (!device->autofs)
+ return;
+
+ if (device->target)
unlink(device->target);
+
+ mp = _find_mount_point(device->name);
+ if (mp) {
+ block("autofs", "remove", device->name);
+ free(mp);
+ }
}
static void
--
2.13.7
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] block(d): improve hotplug.d "mount" events for the autofs
From: Rafał Miłecki
So far - when using autofs - "add" and "remove" action events were
triggered on every (un)mount. It wasn't very helpful when using autofs
due to its nature.
The point of blockd & autofs is to have block devices mounted on an
access request. Its users should not care / know if it's currently
mounted or not. Mounting should be handled transparently.
To make that work it requires informing listeners whenever device:
1) Becomes *ready* for mounting (by triggering "add" action)
2) Becomes *unavailable* (by triggering "remove" action)
The current mounting state is something that autofs & blockd should
handle internally and should not notify listeners about.
This is implemented by:
1) block generating events for non-autofs cases only (when (un)mounting)
2) blockd informing block when autofs resource becomes (un)available
Signed-off-by: Rafał Miłecki
---
block.c | 31 ++-
blockd.c | 4
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/block.c b/block.c
index f7fdc27..cfc8727 100644
--- a/block.c
+++ b/block.c
@@ -1113,12 +1113,13 @@ static int mount_device(struct probe_info *pr, int type)
handle_swapfiles(true);
- hotplug_call_mount("add", device);
+ if (type != TYPE_AUTOFS)
+ hotplug_call_mount("add", device);
return 0;
}
-static int umount_device(char *path)
+static int umount_device(char *path, int type)
{
char *mp;
int err;
@@ -1127,7 +1128,8 @@ static int umount_device(char *path)
if (!mp)
return -1;
- hotplug_call_mount("remove", basename(path));
+ if (type != TYPE_AUTOFS)
+ hotplug_call_mount("remove", basename(path));
err = umount2(mp, MNT_DETACH);
if (err) {
@@ -1154,7 +1156,7 @@ static int mount_action(char *action, char *device, int
type)
if (type == TYPE_HOTPLUG)
blockd_notify(device, NULL, NULL);
- umount_device(path);
+ umount_device(path, type);
return 0;
} else if (strcmp(action, "add")) {
@@ -1177,6 +1179,8 @@ static int main_hotplug(int argc, char **argv)
static int main_autofs(int argc, char **argv)
{
+ int err = 0;
+
if (argc < 3)
return -1;
@@ -1199,13 +1203,22 @@ static int main_autofs(int argc, char **argv)
blockd_notify(pr->dev, m, pr);
}
- return 0;
+ } else if (!strcmp(argv[2], "available")) {
+ err = hotplug_call_mount("add", argv[3]);
+ } else if (!strcmp(argv[2], "unavailable")) {
+ err = hotplug_call_mount("remove", argv[3]);
+ } else {
+ if (argc < 4)
+ return -EINVAL;
+
+ err = mount_action(argv[2], argv[3], TYPE_AUTOFS);
}
- if (argc < 4)
- return -EINVAL;
+ if (err) {
+ ULOG_ERR("autofs: \"%s\" action has failed: %d\n", argv[2],
err);
+ }
- return mount_action(argv[2], argv[3], TYPE_AUTOFS);
+ return err;
}
static int find_block_mtd(char *name, char *part, int plen)
@@ -1612,7 +1625,7 @@ static int main_umount(int argc, char **argv)
if (m && m->extroot)
continue;
- umount_device(pr->dev);
+ umount_device(pr->dev, TYPE_DEV);
}
return 0;
diff --git a/blockd.c b/blockd.c
index a00a5b3..88fe168 100644
--- a/blockd.c
+++ b/blockd.c
@@ -116,6 +116,8 @@ device_free(struct device *device)
if (!device->autofs)
return;
+ block("autofs", "unavailable", device->name);
+
if (device->target)
unlink(device->target);
@@ -137,6 +139,8 @@ device_add(struct device *device)
snprintf(path, sizeof(path), "/tmp/run/blockd/%s", device->name);
if (symlink(path, device->target))
ULOG_ERR("failed to symlink %s->%s\n", device->target, path);
+ else
+ block("autofs", "available", device->name);
}
static int
--
2.13.7
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] ath79: Add support for Ubiquiti Nanostation M (XW)
Mathias Kresin [2018-12-12 13:40:40]:
Hi,
> > + {
> > + status = "okay";
> > +
> > + phy-mode = "mii";
> > + phy-handle = <>;
> > + mtd-mac-address = < 0x0>;
>
> Can't the mtd-mac-address be moved to the ar9342_ubnt_xw.dtsi?
yes, I'll do it.
> Don't we need pll-data here?
Well, I don't think so, as it seems that those defined ar934x.dtsi are good
enough
and match what is in ar71xx today. So I've droped it. I'll make it more clear in
v2.
> > +define Device/ubnt_nano-m-xw
> > + $(Device/ubnt-xw)
> > + DEVICE_TITLE := Ubiquiti Nanostation M (XW)
> > + SUPPORTED_DEVICES += nano-m-xw nanostation-m-xw
>
> I can not find an ar71xx board which uses "nano-m-xw" as userspace
> boardname. What's the purpose of adding the string to the supported devices?
I think, that I've forget to remove nano-m-xw since that's one is added
automatically from device name, but I've added nanostation-m-xw, because I
wasn't able to upgrade from ar71xx without -F.
I wanted to make it first as separate patch with the error message included,
but I've then decided to just add it in the board support patch. Anyway, I've
returned my Nanostation already, so it's going to take some time to reproduce
it again and provide proper explanation for you.
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] ath79: ubnt-bullet-m-xw: Move common DTS bits into XW include file
Mathias Kresin [2018-12-12 13:27:17]:
Hi Mathias,
> > phy-mask = <4>;
> > +
> > phy4: ethernet-phy@4 {
> > - phy-mode = "rgmii";
> > reg = <4>;
> > + phy-mode = "rgmii";
> > };
> > };
>
> Unrelated noop change. Please drop it.
Ok.
> >{
> > status = "okay";
> > - pll-data = <0x0600 0x0101 0x1313>;
>
> You drop the pll-data without adding them to the dtsi. This looks wrong and
> doesn't match the "move from dts to dtsi" from the commit message.
Yes, my bad, sorry. I've removed the pll-data since those defined in
ar934x.dtsi work and matches what is in ar71xx.
> > +++ b/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
> > @@ -117,3 +117,11 @@
> > mtd-cal-data = < 0x1000>;
> > mtd-mac-address = < 0x1002>;
> > };
> > +
> > + {
> > + status = "disabled";
> > +};
>
> This one is new and therefore doesn't match what is described in the commit
> message.
Ok, I'll make it clear.
Thanks for the review!
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/5] ath79: ubnt-xw: Add LED aliases for diag and status LED support
12/12/2018 13:46, Petr Štetiar:
Mathias Kresin [2018-12-12 13:22:08]:
--- a/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
+++ b/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
@@ -9,15 +9,22 @@
compatible = "ubnt,xw", "qca,ar9342";
model = "Ubiquiti Networks XW board";
+ aliases {
+ led-boot =
+ led-failsafe =
+ led-running =
+ led-upgrade =
+ };
+
gpio-leds {
compatible = "gpio-leds";
- link1 {
+ upgrade: link1 {
label = "ubnt:red:link1";
gpios = < 11 GPIO_ACTIVE_LOW>;
};
- link2 {
+ failsafe: link2 {
label = "ubnt:orange:link2";
gpios = < 16 GPIO_ACTIVE_LOW>;
};
@@ -27,7 +34,7 @@
gpios = < 13 GPIO_ACTIVE_LOW>;
};
- link4 {
+ boot: link4 {
label = "ubnt:green:link4";
gpios = < 14 GPIO_ACTIVE_LOW>;
};
Aren't these LEDs some kind of singal strength indicator? If so, they
shouldn't be used to indicate a running system. I'm fine to temporary hijack
the LEDs to indicate boot, failsafe and upgrade. But better use the same LED
for all of these (link1)?
I've simply thought, that while having so many LEDs available, it would be
better for UX (User Experience). Orange to signal failsafe mode, red to signal
ongoing upgrade. Using just one green LED to signal all the states might be
confusing and since we're using those LEDs only in cases when it's requested
by the user (failsafe/upgrade), I don't see it as a big deal to hijack them
for better UX as the RSSI won't be probably working at that time anyway
(not tested this scenario).
We had the discussion dozen times. The LEDs have a defined function on
these boards. Stick to this function.
Using different link LEDs might be obvious to you, every one else need
to have a look at the dts, to see which state is indicated by which
misused led.
Mathias
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/5] ath79: ubnt-xw: Add LED aliases for diag and status LED support
Mathias Kresin [2018-12-12 13:22:08]:
> > --- a/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
> > +++ b/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
> > @@ -9,15 +9,22 @@
> > compatible = "ubnt,xw", "qca,ar9342";
> > model = "Ubiquiti Networks XW board";
> > + aliases {
> > + led-boot =
> > + led-failsafe =
> > + led-running =
> > + led-upgrade =
> > + };
> > +
> > gpio-leds {
> > compatible = "gpio-leds";
> > - link1 {
> > + upgrade: link1 {
> > label = "ubnt:red:link1";
> > gpios = < 11 GPIO_ACTIVE_LOW>;
> > };
> > - link2 {
> > + failsafe: link2 {
> > label = "ubnt:orange:link2";
> > gpios = < 16 GPIO_ACTIVE_LOW>;
> > };
> > @@ -27,7 +34,7 @@
> > gpios = < 13 GPIO_ACTIVE_LOW>;
> > };
> > - link4 {
> > + boot: link4 {
> > label = "ubnt:green:link4";
> > gpios = < 14 GPIO_ACTIVE_LOW>;
> > };
> >
>
> Aren't these LEDs some kind of singal strength indicator? If so, they
> shouldn't be used to indicate a running system. I'm fine to temporary hijack
> the LEDs to indicate boot, failsafe and upgrade. But better use the same LED
> for all of these (link1)?
I've simply thought, that while having so many LEDs available, it would be
better for UX (User Experience). Orange to signal failsafe mode, red to signal
ongoing upgrade. Using just one green LED to signal all the states might be
confusing and since we're using those LEDs only in cases when it's requested
by the user (failsafe/upgrade), I don't see it as a big deal to hijack them
for better UX as the RSSI won't be probably working at that time anyway
(not tested this scenario).
-- ynezz
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 5/5] ath79: Add support for Ubiquiti Nanostation M (XW)
Hey Petr,
more comments inline.
Mathias
10/12/2018 23:46, Petr Štetiar:
CPU: AR9342 SoC
RAM: 64 MB DDR2
Flash: 8 MB NOR SPI
Ports: 2x100 MBit (24V PoE in, 24V PoE out), AR8236 switch
WLAN: 2.4/5 GHz
UART: 1 UART
LEDs:Power, 2x Ethernet, 4x RSSI LEDs (orange, red, 2x green)
Buttons: Reset
Flashing instructions using recovery method over TFTP
1. Unplug the ethernet cable from the router.
2. Using paper clip press and hold the router's reset button. Make sure
you can feel it depressed by the paper clip. Do not release the button
until step 4.
3. While keeping the reset button pressed in, plug the ethernet cable
back into the AP. Keep the reset button depressed until you see the
device's LEDs flashing in upgrade mode (alternating LED1/LED3 and
LED2/LED4), this may take up to 25 seconds.
4. You may release the reset button, now the device should be in TFTP
transfer mode.
5. Set a static IP on your Computer's NIC. A static IP of 192.168.1.25/24
should work.
6. Plug the PoE injector's LAN cable directly to your computer.
7. Start tftp client and issue following commands:
tftp> binary
tftp> connect 192.168.1.20
tftp> put openwrt-ath79-generic-ubnt-nano-m-xw-squashfs-factory.bin
Tested-by: Joe Ayers
Signed-off-by: Petr Štetiar
---
target/linux/ath79/base-files/etc/board.d/01_leds | 1 +
.../linux/ath79/base-files/etc/board.d/02_network | 4 +++
target/linux/ath79/dts/ar9342_ubnt_nano-m-xw.dts | 38 ++
target/linux/ath79/image/generic-ubnt.mk | 7
4 files changed, 50 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_nano-m-xw.dts
diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds
b/target/linux/ath79/base-files/etc/board.d/01_leds
index 06fb8f4..0f725c0 100755
--- a/target/linux/ath79/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/base-files/etc/board.d/01_leds
@@ -104,6 +104,7 @@ tplink,tl-wr841-v11)
ubnt,bullet-m|\
ubnt,bullet-m-xw|\
ubnt,nano-m|\
+ubnt,nano-m-xw|\
ubnt,rocket-m)
ucidef_set_rssimon "wlan0" "20" "1"
ucidef_set_led_rssi "rssilow" "RSSILOW" "ubnt:red:link1" "wlan0" "1"
"100"
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index fa7a618..7e1ec4c 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -188,6 +188,10 @@ ath79_setup_interfaces()
ucidef_add_switch "switch0" \
"0@eth1" "2:lan:3" "3:lan:2" "4:lan:1"
;;
+ ubnt,nano-m-xw)
+ ucidef_add_switch "switch0" \
+ "0@eth0" "5:lan" "1:wan"
+ ;;
ubnt,nanostation-ac|\
ubnt,unifiac-mesh-pro|\
ubnt,unifiac-pro)
diff --git a/target/linux/ath79/dts/ar9342_ubnt_nano-m-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_nano-m-xw.dts
new file mode 100644
index 000..eb5f0b4
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_nano-m-xw.dts
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,nano-m-xw", "ubnt,xw";
+ model = "Ubiquiti Nanostation M (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy4-mii-enable;
+ phy-mask = <0x23>;
+
+ phy4: ethernet-phy@4 {
+ reg = <0>;
+ phy-mode = "mii";
+ };
+};
+
+ {
+ status = "okay";
+
+ phy-mode = "mii";
+ phy-handle = <>;
+ mtd-mac-address = < 0x0>;
Can't the mtd-mac-address be moved to the ar9342_ubnt_xw.dtsi? Don't we
need pll-data here?
I guess it is related to the issues in "[PATCH 2/5] ath79:
ubnt-bullet-m-xw: Move common DTS bits into XW include file".
+
+ gmac-config {
+ device = <>;
+ mii-gmac0 = <1>;
+ mii-gmac0-slave = <1>;
+ };
+};
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index cb65aed..e1ba72c 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -113,6 +113,13 @@ define Device/ubnt_nano-m
endef
TARGET_DEVICES += ubnt_nano-m
+define Device/ubnt_nano-m-xw
+ $(Device/ubnt-xw)
+ DEVICE_TITLE := Ubiquiti Nanostation M (XW)
+ SUPPORTED_DEVICES += nano-m-xw nanostation-m-xw
I can not find an ar71xx board which uses "nano-m-xw" as userspace
boardname. What's the purpose of adding the string to the supported devices?
+endef
+TARGET_DEVICES += ubnt_nano-m-xw
+
define Device/ubnt_lap-120
$(Device/ubnt-wa)
DEVICE_TITLE := Ubiquiti LiteAP ac (LAP-120)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/5] ath79: gmac: ar934x: Add parser for mii-gmac0-slave
10/12/2018 23:46, Petr Štetiar:
In ar71xx/mach-ubnt-xm.c there's following code:
static void __init ubnt_xw_init(void) {
...
ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_MII_GMAC0 |
AR934X_ETH_CFG_MII_GMAC0_SLAVE);
...
}
But I couldn't find a way how to set it up via DTS.
Would you please add an explanation to the commit message what the
devicetree property does and why we might need it.
Mathias
Tested-by: Joe Ayers
Signed-off-by: Petr Štetiar
---
.../linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_gmac.c | 1 +
1 file changed, 1 insertion(+)
diff --git
a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_gmac.c
b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_gmac.c
index e69abb6..cc0a15d 100644
--- a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_gmac.c
+++ b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_gmac.c
@@ -53,6 +53,7 @@ static void ag71xx_setup_gmac_934x(struct device_node *np,
void __iomem *base)
ag71xx_of_bit(np, "rgmii-gmac0", , AR934X_ETH_CFG_RGMII_GMAC0);
ag71xx_of_bit(np, "mii-gmac0", , AR934X_ETH_CFG_MII_GMAC0);
+ ag71xx_of_bit(np, "mii-gmac0-slave", ,
AR934X_ETH_CFG_MII_GMAC0_SLAVE);
ag71xx_of_bit(np, "gmii-gmac0", , AR934X_ETH_CFG_GMII_GMAC0);
ag71xx_of_bit(np, "switch-phy-swap", , AR934X_ETH_CFG_SW_PHY_SWAP);
ag71xx_of_bit(np, "switch-only-mode", ,
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/5] ath79: ubnt-bullet-m-xw: Move common DTS bits into XW include file
Hey Petr,
find my comments inline.
Mathias
10/12/2018 23:46, Petr Štetiar:
Most of the M/XW platform settings can be shared so move those common
DTS bits into include file.
Tested-by: Joe Ayers
Signed-off-by: Petr Štetiar
---
target/linux/ath79/dts/ar9342_ubnt_bullet-m-xw.dts | 11 +++
target/linux/ath79/dts/ar9342_ubnt_xw.dtsi | 8
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-m-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_bullet-m-xw.dts
index ad98075..7e4862e 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_bullet-m-xw.dts
+++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-m-xw.dts
@@ -15,20 +15,19 @@
status = "okay";
phy-mask = <4>;
+
phy4: ethernet-phy@4 {
- phy-mode = "rgmii";
reg = <4>;
+ phy-mode = "rgmii";
};
};
Unrelated noop change. Please drop it.
{
status = "okay";
- pll-data = <0x0600 0x0101 0x1313>;
You drop the pll-data without adding them to the dtsi. This looks wrong
and doesn't match the "move from dts to dtsi" from the commit message.
- mtd-mac-address = < 0x0>;
-
phy-mode = "rgmii";
phy-handle = <>;
+ mtd-mac-address = < 0x0>;
gmac-config {
device = <>;
@@ -36,7 +35,3 @@
rxdv-delay = <3>;
};
};
-
- {
- status = "disabled";
-};
diff --git a/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
b/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
index 742df11..812810f 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
+++ b/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
@@ -117,3 +117,11 @@
mtd-cal-data = < 0x1000>;
mtd-mac-address = < 0x1002>;
};
+
+ {
+ status = "disabled";
+};
This one is new and therefore doesn't match what is described in the
commit message.
+
+ {
+ status = "disabled";
+};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/5] ath79: ubnt-xw: Add LED aliases for diag and status LED support
10/12/2018 23:46, Petr Štetiar:
Currently there is no LED signalization for various system states
implemented in diag.sh, so this patch adds support for it.
Tested-by: Joe Ayers
Signed-off-by: Petr Štetiar
---
target/linux/ath79/dts/ar9342_ubnt_xw.dtsi | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
b/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
index b104bc6..742df11 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
+++ b/target/linux/ath79/dts/ar9342_ubnt_xw.dtsi
@@ -9,15 +9,22 @@
compatible = "ubnt,xw", "qca,ar9342";
model = "Ubiquiti Networks XW board";
+ aliases {
+ led-boot =
+ led-failsafe =
+ led-running =
+ led-upgrade =
+ };
+
gpio-leds {
compatible = "gpio-leds";
- link1 {
+ upgrade: link1 {
label = "ubnt:red:link1";
gpios = < 11 GPIO_ACTIVE_LOW>;
};
- link2 {
+ failsafe: link2 {
label = "ubnt:orange:link2";
gpios = < 16 GPIO_ACTIVE_LOW>;
};
@@ -27,7 +34,7 @@
gpios = < 13 GPIO_ACTIVE_LOW>;
};
- link4 {
+ boot: link4 {
label = "ubnt:green:link4";
gpios = < 14 GPIO_ACTIVE_LOW>;
};
Aren't these LEDs some kind of singal strength indicator? If so, they
shouldn't be used to indicate a running system. I'm fine to temporary
hijack the LEDs to indicate boot, failsafe and upgrade. But better use
the same LED for all of these (link1)?
Mathias
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] hostapd 2.7 released
Hi! hostapd 2.7 has been released on December 2nd: http://w1.fi/cgit/hostap/plain/hostapd/ChangeLog I've updated the hostapd package to use the hostapd_2_7 tag with our patches on top, find it in my staging tree: https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=c494eadb6555c02eb5d00b4274c4fc955291516c I've compile-tested all build variants and run-time tested wpad(-full). Please test and report back, so we shall have this merged in master asap. Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 18.06-snapshots?
Hi, > Just wondering if there are snapshots built for the backports etc > done onto the 18.06 tree (e.g. in preparation for 18.06.2), or after > release are there only adhoc builds for release candidates for the > point release? http://downloads.openwrt.org/releases/18.06-SNAPSHOT/ > If there are snapshots could the link be added to > https://downloads.openwrt.org so that interested parties could use > them (and link to them e.g. on wiki if applicable). I'd rather not. The folder is intentionally hidden to not confuse people looking for fixed release builds. 18.06-SNAPSHOT is not intended for production use, among other things it offers no long term kmod availability. ~ Jo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
