Re: [OpenWrt-Devel] [ModemManager] How can I make ModemManager work right?
Hello Alexander and people in the list,
Let me provide some additional information and new test log messages.
The problem I reported is improved one setp. Originally it was like:
root at LEDE:~# mmcli -L
error: couldn't create manager: Timeout was reached
Now it is like:
root@LEDE:~# mmcli -L
No modems were found
I had to enable "dbus-utils" under "Utilities" of openwrt make menuconfig.
So it seems that now mmcli talks with ModemManager at last. The problem now
belongs to ModemManager not in the mmcli.
And I created the rule file you provided:
# vim /lib/udev/rules.d/78-mm-custom.rules to fit to my modem:
ACTION!="add|change|move", GOTO="mm_custom_end"
DEVPATH=="/sys/devices/platform/1a0c.usb/usb2/2-1",
ENV{ID_MM_TTY_BAUDRATE}="115200"
DEVPATH=="/sys/devices/platform/1a0c.usb/usb2/2-1",
ENV{ID_MM_TTY_FLOW_CONTROL}="xon-xoff"
LABEL="mm_custom_end"
I wonder if these rule files are supposed to be provided from the modem
provider. In my case, it is Hucom wireless.
Can I ask them to provide this file?
My modem is supposed to operate with this configs:
device : /dev/ttyUSB1
baudrate : 115200,
parity: none,
data : 8,
stop : 1,
flow : xon_xoff
And I added config section like shown below in the /etc/config/network:
config interface 'broadband'
option device '/sys/devices/platform/1a0c.usb/usb2/2-1'
option proto 'modemmanager'
option apn '5g-internet.sktelecom.com'
option username ''
option password ''
option pincode ''
option lowpower '1'
I don't know the username and password, but maybe it wouldn't be needed at
all. the pincode... I have no idea with this..
And also I added "--debug" in the start script /etc/rc.d/S70modemmanager:
procd_set_param command /usr/sbin/ModemManager --debug
And with these conditions, I rebooted my linux box and after the reboot is
done, maybe 5 minutes later I captured log message:
logread > logread_last.log
And I attached it in this email. Please find the log message and see it
through.
And you wanted to know what modem is mine:
The modem is HUCOM HM-900
Kernel message related to the hucom modem:
[hucom_wwan_bind] : HUCOM HM9xx
qmi_wwan_hucom 2-1:1.2: cdc-wdm0: USB WDM device
HUCOM usbnet bind here
qmi_wwan_hucom 2-1:1.2 wwan0: register 'qmi_wwan_hucom' at
usb-1a0c.usb-1, HUCOM wwan/QMI device, a2:25:55:58:dd:dd
[hucom_wwan_bind] : HUCOM HM9xx
ahci 1a20.sata: couldn't get PHY in node sata: -517
qmi_wwan_hucom: probe of 2-1:1.3 failed with error -22
[hucom_wwan_bind] : HUCOM HM9xx
qmi_wwan_hucom: probe of 2-1:1.4 failed with error -22
usbcore: registered new interface driver qmi_wwan_hucom
l2tp_ppp: PPPoL2TP kernel driver, V2.0
usbcore: registered new interface driver option
usbserial: USB Serial support registered for GSM modem (1-port)
option 2-1:1.0: GSM modem (1-port) converter detected
usb 2-1: GSM modem (1-port) converter now attached to ttyUSB0
option 2-1:1.1: GSM modem (1-port) converter detected
ahci 1a20.sata: couldn't get PHY in node sata: -517
usb 2-1: GSM modem (1-port) converter now attached to ttyUSB1
option 2-1:1.3: GSM modem (1-port) converter detected
ahci 1a20.sata: couldn't get PHY in node sata: -517
option 2-1:1.4: GSM modem (1-port) converter detected
ahci 1a20.sata: couldn't get PHY in node sata: -517
option 2-1:1.5: GSM modem (1-port) converter detected
ahci 1a20.sata: couldn't get PHY in node sata: -517
usb 2-1: GSM modem (1-port) converter now attached to ttyUSB4
ahci 1a20.sata: couldn't get PHY in node sata: -517
kmodloader: done loading kernel modules from /etc/modules.d/*
My system environement(HW/SW) :
Target Model: MediaTek MT7622 AC4300rfb1 board
Firmware Version : LEDE Reboot 17.01-SNAPSHOT unknown / LuCI
Kernel Version : 4.4.124
Modem : HUCOM HM-900
ModemManager
Version : 1.12.8
menuconfig : (QMI on, MBIM off)
It is QMI device.
qmichannel: /dev/cdc-wdm0
usbnet_adapter : /sys/class/net/wwan0
/sys/bus/usb/devices/2-1/manufacturer : QCOM
/sys/bus/usb/devices/2-1/idVendor:05C6
/sys/bus/usb/devices/2-1/idProduct :90db
/sys/bus/usb/devices/2-1/speed :5000
/sys/bus/usb/devices/2-1/product :SDXPRAIRIE-MTP _SN:B02CE51B
/sys/bus/usb/devices/2-1/version :3.20
/sys/bus/usb/devices/2-1:1.2/net/wwan0
/sys/bus/usb/devices/2-1:1.2/net/wwan0/device/driver
/sys/bus/usb/devices/2-1:1.2/net/wwan0/device
/sys/bus/usb/devices/2-1:1.2/usbmisc/cdc-wdm0
/sys/devices/platform/1a0c.usb/usb2/2-1/2-1:1.2
Kernel modules watched via lsmod
cdc_wdm 8821 1 qmi_wwan
qmi_wwan6252 0
usbcore 153512 20
Re: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix it in 19.07.3 (?)
Hi! On Wed, May 6, 2020 at 1:36 AM pedrowrt wrote: > > I tested it using Staging tree of Chuanhong Guo [1], and it worked. Good > job. What are the next steps related to this? > > I understand to not be included in future release (no problem, we can > inject the patch on our own), but in fact, it is not just a bug, it is a > regression, because it worked in 18.06.x releases. > > I don't know how many devices have this switch in their hardware and are > affected too. What I know is that I detected it too late, and in that > moment nobody knew it. That could mean that nobody is using this feature > (or hardware), or that the people that use it this way are giving up or > sticking to 18.06.x release (?). > > If we are not including it for this release, as this looks pretty > confirmed and we have a fix, I would point it in the wiki. > > Thank you all, > Pedro > > [1] https://git.openwrt.org/?p=openwrt/staging/981213.git;a=summary > > On 5/5/20 5:16 PM, Roger Pueyo Centelles | Guifi.net wrote: > > Hi, > > > > Thanks Chuanghong, I was unaware of it. > > > > I could verify the commit to work in master and 19.07, for both ath79 > > and ar71xx. > > > > Best, > > > > Roger Thanks for your testing. As the patch is pretty straightforward I've pushed the commit to both master and 19.07 branch. -- Regards, Chuanhong Guo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] mpc85xx: restructure image receipts
Hi, > +include p1010.mk > endif You may take up John's idea for [1] here and just do include $(SUBTARGET).mk without all the ifs. Best Adrian [1] https://github.com/openwrt/openwrt/commit/220f43e0f2a0870305d40add4c3314edf150f9be openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH fstools] blockd: use uloop_process for calling /sbin/hotplug-call mount
From: Rafał Miłecki
As blockd uses uloop calling any script and using waitpid() can easily
result in a lock. It's enough for script to use /bin/ubus to cause that.
It's not an option to drop waitpid() as it's important to e.g. call
mount scripts with ACTION=remove before unmounting devices. So solving
this problem requires using uloop_process.
Unfortunately this means:
1. Using callbacks making code slightly more complex
2. Dropping that nice devices_update_cb()
With this change however hotplug.d "mount" scripts can safely call
"ubus".
Signed-off-by: Rafał Miłecki
---
block.c | 4 --
blockd.c | 127 +++
2 files changed, 80 insertions(+), 51 deletions(-)
diff --git a/block.c b/block.c
index c4ae88a..ac95464 100644
--- a/block.c
+++ b/block.c
@@ -1218,10 +1218,6 @@ static int main_autofs(int argc, char **argv)
blockd_notify(pr->dev, m, pr);
}
- } 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;
diff --git a/blockd.c b/blockd.c
index 6e53a13..2fc1bb6 100644
--- a/blockd.c
+++ b/blockd.c
@@ -25,6 +25,11 @@
#define AUTOFS_TIMEOUT 30
#define AUTOFS_EXPIRE_TIMER(5 * 1000)
+struct hotplug_context {
+ struct uloop_process process;
+ struct device *device;
+};
+
struct device {
struct vlist_node node;
struct blob_attr *msg;
@@ -108,15 +113,49 @@ block(char *cmd, char *action, char *device)
return ret;
}
-static void
-device_free(struct device *device)
+static void hotplug_call_mount(const char *action, struct device *device,
+ uloop_process_handler cb)
{
- char *mp;
+ char * const argv[] = { "hotplug-call", "mount", NULL };
+ struct hotplug_context *c = NULL;
+ pid_t pid;
- if (!device->autofs)
- return;
+ if (cb) {
+ c = calloc(1, sizeof(*c));
+ if (!c)
+ return;
+ }
+
+ pid = fork();
+ switch (pid) {
+ case -1:
+ ULOG_ERR("fork() failed\n");
+ break;
+ case 0:
+ uloop_end();
+
+ setenv("ACTION", action, 1);
+ setenv("DEVICE", device->name, 1);
+
+ execv("/sbin/hotplug-call", argv);
+ exit(-1);
+ break;
+ default:
+ if (c) {
+ c->process.pid = pid;
+ c->process.cb = cb;
+ c->device = device;
+ uloop_process_add(>process);
+ }
+ break;
+ }
+}
- block("autofs", "unavailable", device->name);
+static void device_mount_remove_hotplug_cb(struct uloop_process *p, int stat)
+{
+ struct hotplug_context *c = container_of(p, struct hotplug_context,
process);
+ struct device *device = c->device;
+ char *mp;
if (device->target)
unlink(device->target);
@@ -126,17 +165,21 @@ device_free(struct device *device)
block("autofs", "remove", device->name);
free(mp);
}
+
+ free(device);
+ free(c);
}
-static void
-device_add(struct device *device)
+static void device_mount_remove(struct device *device)
+{
+ hotplug_call_mount("remove", device, device_mount_remove_hotplug_cb);
+}
+
+static void device_mount_add(struct device *device)
{
struct stat st;
char path[64];
- if (!device->autofs)
- return;
-
snprintf(path, sizeof(path), "/tmp/run/blockd/%s", device->name);
if (!lstat(device->target, )) {
if (S_ISLNK(st.st_mode))
@@ -147,7 +190,7 @@ device_add(struct device *device)
if (symlink(path, device->target))
ULOG_ERR("failed to symlink %s->%s (%d) - %m\n",
device->target, path, errno);
else
- block("autofs", "available", device->name);
+ hotplug_call_mount("add", device, NULL);
}
static int
@@ -177,36 +220,13 @@ device_move(struct device *device_o, struct device
*device_n)
return 0;
}
-static void
-devices_update_cb(struct vlist_tree *tree, struct vlist_node *node_new,
- struct vlist_node *node_old)
+static void vlist_nop_update(struct vlist_tree *tree,
+struct vlist_node *node_new,
+struct vlist_node *node_old)
{
- struct device *device_o = NULL, *device_n = NULL;
-
- if (node_old)
- device_o = container_of(node_old, struct device, node);
-
- if (node_new)
- device_n = container_of(node_new, struct device, node);
-
- if (device_o &&
[OpenWrt-Devel] [PATCH 2/2] mpc85xx: restructure image receipts
Move the image receipts into separate per-subtarget files like it is done on most other targets. Signed-off-by: David Bauer --- target/linux/mpc85xx/image/Makefile | 100 +--- target/linux/mpc85xx/image/p1010.mk | 36 ++ target/linux/mpc85xx/image/p1020.mk | 41 target/linux/mpc85xx/image/p2020.mk | 15 + 4 files changed, 95 insertions(+), 97 deletions(-) create mode 100644 target/linux/mpc85xx/image/p1010.mk create mode 100644 target/linux/mpc85xx/image/p1020.mk create mode 100644 target/linux/mpc85xx/image/p2020.mk diff --git a/target/linux/mpc85xx/image/Makefile b/target/linux/mpc85xx/image/Makefile index 225f871699..a0e00c982a 100644 --- a/target/linux/mpc85xx/image/Makefile +++ b/target/linux/mpc85xx/image/Makefile @@ -5,8 +5,6 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/image.mk -DEVICE_VARS += TPLINK_HWID TPLINK_HWREV TPLINK_FLASHLAYOUT TPLINK_HEADER_VERSION - define Build/copy-file cat "$(1)" > "$@" endef @@ -22,107 +20,15 @@ define Device/Default endef ifeq ($(SUBTARGET),p1010) - -define Device/tplink_tl-wdr4900-v1 - DEVICE_VENDOR := TP-Link - DEVICE_MODEL := TL-WDR4900 - DEVICE_VARIANT := v1 - TPLINK_HEADER_VERSION := 1 - TPLINK_HWID := 0x4901 - TPLINK_HWREV := 1 - TPLINK_FLASHLAYOUT := 16Mppc - KERNEL_SIZE := 2684k - KERNEL_NAME := simpleImage.tl-wdr4900-v1 - KERNEL_INITRAMFS := - KERNEL := kernel-bin | uImage none - KERNEL_ENTRY := 0x100 - KERNEL_LOADADDR := 0x100 - SUPPORTED_DEVICES += tl-wdr4900-v1 - ARTIFACTS := fdt.bin - ARTIFACT/fdt.bin := append-dtb - IMAGES := fdt.bin factory.bin sysupgrade.bin - IMAGE/sysupgrade.bin := tplink-v1-image sysupgrade | append-metadata - IMAGE/factory.bin := tplink-v1-image factory -endef -TARGET_DEVICES += tplink_tl-wdr4900-v1 - -define Device/sophos_red-15w-rev1 - DEVICE_VENDOR := Sophos - DEVICE_MODEL := RED 15w - DEVICE_VARIANT := Rev.1 - # Original firmware uses a dedicated DTB-partition. - # The bootloader however supports FIT-images. - KERNEL = kernel-bin | gzip | fit gzip $(KDIR)/image-$$(DEVICE_DTS).dtb - IMAGES := sysupgrade.bin - IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata -endef -TARGET_DEVICES += sophos_red-15w-rev1 - +include p1010.mk endif ifeq ($(SUBTARGET),p1020) - -define Device/aerohive_hiveap-330 - DEVICE_VENDOR := Aerohive - DEVICE_MODEL := HiveAP-330 - DEVICE_PACKAGES := kmod-tpm-i2c-atmel - BLOCKSIZE := 128k - KERNEL := kernel-bin | gzip | uImage gzip - KERNEL_SIZE := 8m - KERNEL_INITRAMFS := copy-file $(KDIR)/vmlinux-initramfs | uImage none - IMAGES := fdt.bin sysupgrade.bin - IMAGE/fdt.bin := append-dtb - IMAGE/sysupgrade.bin := append-dtb | pad-to 256k | check-size 256k | \ - append-uImage-fakehdr ramdisk | pad-to 256k | check-size 512k | \ - append-rootfs | pad-rootfs $$(BLOCKSIZE) | pad-to 41216k | check-size 41216k | \ - append-kernel | append-metadata -endef -TARGET_DEVICES += aerohive_hiveap-330 - -define Device/enterasys_ws-ap3710i - DEVICE_VENDOR := Enterasys - DEVICE_MODEL := WS-AP3710i - BLOCKSIZE := 128k - KERNEL = kernel-bin | lzma | fit lzma $(KDIR)/image-$$(DEVICE_DTS).dtb - IMAGES := sysupgrade.bin - IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | append-metadata -endef -TARGET_DEVICES += enterasys_ws-ap3710i - -define Device/ocedo_panda - DEVICE_VENDOR := OCEDO - DEVICE_MODEL := Panda - DEVICE_PACKAGES := kmod-rtc-ds1307 uboot-envtools - KERNEL = kernel-bin | gzip | fit gzip $(KDIR)/image-$$(DEVICE_DTS).dtb - PAGESIZE := 2048 - SUBPAGESIZE := 512 - BLOCKSIZE := 128k - IMAGES := fdt.bin sysupgrade.bin - IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata - IMAGE/fdt.bin := append-dtb -endef -TARGET_DEVICES += ocedo_panda - +include p1020.mk endif ifeq ($(SUBTARGET),p2020) - -define Device/freescale_p2020rdb - DEVICE_VENDOR := Freescale - DEVICE_MODEL := P2020RDB - DEVICE_DTS_DIR := $(DTS_DIR)/fsl - DEVICE_PACKAGES := kmod-hwmon-lm90 kmod-rtc-ds1307 \ - kmod-gpio-pca953x kmod-eeprom-at24 - BLOCKSIZE := 128k - KERNEL := kernel-bin | gzip | \ - fit gzip $$(KDIR)/image-$$(firstword $$(DEVICE_DTS)).dtb - SUPPORTED_DEVICES := fsl,P2020RDB - IMAGES := sysupgrade.bin - IMAGE/sysupgrade.bin := append-kernel | append-rootfs | \ - pad-rootfs $$(BLOCKSIZE) | append-metadata -endef -TARGET_DEVICES += freescale_p2020rdb - +include p2020.mk endif $(eval $(call BuildImage)) diff --git a/target/linux/mpc85xx/image/p1010.mk b/target/linux/mpc85xx/image/p1010.mk new file mode 100644 index 00..e12621e82c --- /dev/null +++ b/target/linux/mpc85xx/image/p1010.mk @@ -0,0 +1,36 @@ +DEVICE_VARS += TPLINK_HWID TPLINK_HWREV TPLINK_FLASHLAYOUT TPLINK_HEADER_VERSION + +define Device/tplink_tl-wdr4900-v1 + DEVICE_VENDOR := TP-Link + DEVICE_MODEL := TL-WDR4900 + DEVICE_VARIANT := v1 + TPLINK_HEADER_VERSION := 1 + TPLINK_HWID := 0x4901 + TPLINK_HWREV := 1 + TPLINK_FLASHLAYOUT :=
[OpenWrt-Devel] [PATCH 1/2] mpc85xx: rename generic subtarget to p1010
The mpc85xx-generic subtarget supports the QorIQ SoCs of the p1010
family. Rename the subtarget to reflect this affiliation as it's the
case with the other mpc85xx subtargets.
Signed-off-by: David Bauer
---
target/linux/mpc85xx/Makefile | 2 +-
target/linux/mpc85xx/image/Makefile | 2 +-
target/linux/mpc85xx/{generic => p1010}/config-default| 0
.../linux/mpc85xx/{generic => p1010}/profiles/00-default.mk | 2 +-
target/linux/mpc85xx/{generic => p1010}/target.mk | 4 ++--
5 files changed, 5 insertions(+), 5 deletions(-)
rename target/linux/mpc85xx/{generic => p1010}/config-default (100%)
rename target/linux/mpc85xx/{generic => p1010}/profiles/00-default.mk (81%)
rename target/linux/mpc85xx/{generic => p1010}/target.mk (53%)
diff --git a/target/linux/mpc85xx/Makefile b/target/linux/mpc85xx/Makefile
index 4bb4d8812d..2ffdfeddcd 100644
--- a/target/linux/mpc85xx/Makefile
+++ b/target/linux/mpc85xx/Makefile
@@ -11,7 +11,7 @@ BOARD:=mpc85xx
BOARDNAME:=Freescale MPC85xx
CPU_TYPE:=8540
FEATURES:=squashfs ramdisk
-SUBTARGETS:=generic p1020 p2020
+SUBTARGETS:=p1010 p1020 p2020
KERNEL_PATCHVER:=5.4
diff --git a/target/linux/mpc85xx/image/Makefile
b/target/linux/mpc85xx/image/Makefile
index 40002c13c4..225f871699 100644
--- a/target/linux/mpc85xx/image/Makefile
+++ b/target/linux/mpc85xx/image/Makefile
@@ -21,7 +21,7 @@ define Device/Default
SUPPORTED_DEVICES := $(subst _,$(comma),$(1))
endef
-ifeq ($(SUBTARGET),generic)
+ifeq ($(SUBTARGET),p1010)
define Device/tplink_tl-wdr4900-v1
DEVICE_VENDOR := TP-Link
diff --git a/target/linux/mpc85xx/generic/config-default
b/target/linux/mpc85xx/p1010/config-default
similarity index 100%
rename from target/linux/mpc85xx/generic/config-default
rename to target/linux/mpc85xx/p1010/config-default
diff --git a/target/linux/mpc85xx/generic/profiles/00-default.mk
b/target/linux/mpc85xx/p1010/profiles/00-default.mk
similarity index 81%
rename from target/linux/mpc85xx/generic/profiles/00-default.mk
rename to target/linux/mpc85xx/p1010/profiles/00-default.mk
index 67507ace8a..5356aaa939 100644
--- a/target/linux/mpc85xx/generic/profiles/00-default.mk
+++ b/target/linux/mpc85xx/p1010/profiles/00-default.mk
@@ -9,7 +9,7 @@ define Profile/Default
endef
define Profile/Default/Description
- Default package set compatible with most MPC85xx boards.
+ Default package set compatible with most P1010 boards.
endef
$(eval $(call Profile,Default))
diff --git a/target/linux/mpc85xx/generic/target.mk
b/target/linux/mpc85xx/p1010/target.mk
similarity index 53%
rename from target/linux/mpc85xx/generic/target.mk
rename to target/linux/mpc85xx/p1010/target.mk
index f826fe4d15..12ed78ace1 100644
--- a/target/linux/mpc85xx/generic/target.mk
+++ b/target/linux/mpc85xx/p1010/target.mk
@@ -1,8 +1,8 @@
-BOARDNAME:=Generic
+BOARDNAME:=P1010
FEATURES+=nand
KERNELNAME:=simpleImage.tl-wdr4900-v1
define Target/Description
- Build firmware images for generic MPC85xx based boards.
+ Build firmware images for P1010 based boards.
endef
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix it in 19.07.3 (?)
I tested it using Staging tree of Chuanhong Guo [1], and it worked. Good job. What are the next steps related to this? I understand to not be included in future release (no problem, we can inject the patch on our own), but in fact, it is not just a bug, it is a regression, because it worked in 18.06.x releases. I don't know how many devices have this switch in their hardware and are affected too. What I know is that I detected it too late, and in that moment nobody knew it. That could mean that nobody is using this feature (or hardware), or that the people that use it this way are giving up or sticking to 18.06.x release (?). If we are not including it for this release, as this looks pretty confirmed and we have a fix, I would point it in the wiki. Thank you all, Pedro [1] https://git.openwrt.org/?p=openwrt/staging/981213.git;a=summary On 5/5/20 5:16 PM, Roger Pueyo Centelles | Guifi.net wrote: > Hi, > > Thanks Chuanghong, I was unaware of it. > > I could verify the commit to work in master and 19.07, for both ath79 > and ar71xx. > > Best, > > Roger > > El 5/5/20 a les 13:16, pedrowrt ha escrit: >> We discussed a bit in IRC, Chuanhong coded a new patch and suggested me >> to try it >> >> https://git.openwrt.org/?p=openwrt/staging/981213.git;a=commit;h=b34165fd386158cbb4d8c09e2c5127b3dee3219a ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: add kmod-ledtrig-mtd as a kernel module
Hi Florian, Actually I was preparing the same patch just a moment ago, and found out that LEDS_TRIGGER_MTD is a bool, not tristate. On 2020-05-04 19:26, Florian Eckert wrote: Not every target needs this LED trigger. Therefore this trigger can be installed as kernel module. Signed-off-by: Florian Eckert --- This is a followup patch form the discussion: https://patchwork.ozlabs.org/project/openwrt/patch/20181129132538.20179-3...@dev.tdt.de/#2043062 package/kernel/linux/modules/leds.mk | 15 +++ 1 file changed, 15 insertions(+) diff --git a/package/kernel/linux/modules/leds.mk b/package/kernel/linux/modules/leds.mk index 59ea6edbcd..fa9756ff39 100644 --- a/package/kernel/linux/modules/leds.mk +++ b/package/kernel/linux/modules/leds.mk @@ -131,6 +131,21 @@ endef $(eval $(call KernelPackage,ledtrig-oneshot)) +define KernelPackage/ledtrig-mtd + SUBMENU:=$(LEDS_MENU) + TITLE:=LED MTD (NAND/NOR) Trigger + KCONFIG:=CONFIG_LEDS_TRIGGER_MTD + FILES:=$(LED_TRIGGER_DIR)/ledtrig-mtd.ko + AUTOLOAD:=$(call AutoLoad,50,ledtrig-mtd) +endef + +define KernelPackage/ledtrig-mtd/description + Kernel module that allows LEDs to be controlled by MTD activity. +endef + +$(eval $(call KernelPackage,ledtrig-mtd)) + + define KernelPackage/leds-pca963x SUBMENU:=$(LEDS_MENU) TITLE:=PCA963x LED support ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [ModemManager] How can I make ModemManager work right?
Hey Jeonghum, > Thank you for the very kind message! > I tried "mmcli -L" and received an error message: > root at LEDE:~# mmcli -L > error: couldn't create manager: Timeout was reached > This is extremely weird, and it would show some issue with your setup, maybe with how DBus is installed/running in the system. mmcli should never fail in that way; if the ModemManager daemon owns the well-known-name in DBus, a manager object should be created; and if there is no MM daemon running, mmcli would just return with a different error (couldn't find the ModemManager process in the bus). The fact that you're getting a timeout when trying to talk to the DBus server is not expected at all. > I added "--debug" option into the ModemManager start command. > I used device path: "/sys/devices/platform/1a0c.usb/usb2/2-1" in the > /etc/config/network. > > And I got an logread output file. > I will attach it to this email. > > I already posted this question to the ModemManager maillist also: > https://lists.freedesktop.org/archives/modemmanager-devel/2020-May/007798.html > > So now I'm waiting Alexander's reply message about my problem. I'm also in this mailing list :D > But, If you have any idea, please let me know. > Did you try with the suggestion to configure baudrate and flow control settings? Looking at the kind of modem you're working with, I highly doubt those port settings will have any effect at the end, as you're really a device that exposes the TTY via USB port, and it also looks like you have a cdc-wdm+wwan pair (QMI? MBIM?). What modem manufacturer/model is this? -- Aleksander https://aleksander.es ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix it in 19.07.3 (?)
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 --- Hi, Thanks Chuanghong, I was unaware of it. I could verify the commit to work in master and 19.07, for both ath79 and ar71xx. Best, Roger El 5/5/20 a les 13:16, pedrowrt ha escrit: > We discussed a bit in IRC, Chuanhong coded a new patch and suggested me > to try it > > https://git.openwrt.org/?p=openwrt/staging/981213.git;a=commit;h=b34165fd386158cbb4d8c09e2c5127b3dee3219a --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix it in 19.07.3 (?)
We discussed a bit in IRC, Chuanhong coded a new patch and suggested me to try it https://git.openwrt.org/?p=openwrt/staging/981213.git;a=commit;h=b34165fd386158cbb4d8c09e2c5127b3dee3219a ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix it in 19.07.3 (?)
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 --- Hi, You're right, it's a bug and not a patch which we've been able to identify it's caused by commit https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c8c2ef1d495dd3fd3096ac508e91a02f9c583ea8 As you can see, it's just a two-lines commit that resets the AR8216 switch during initialization, but it's part of a longer series of AR8216-related commits. Reverting it makes IPv6 multicast work again on the NanoStation XW, and probably others, but it could also break other devices' switched networking (e.g., those QCA9558+AR8326 ones). I understand it can't go wildly into 19.07.3 but, now that we're discussing it, maybe the author of the patch can shed some light on the issue. Best, Roger El 5/5/20 a les 11:44, m...@adrianschmutzler.de ha escrit: > Hi, > >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of pedrowrt >> Sent: Dienstag, 5. Mai 2020 10:36 >> To: openwrt-devel@lists.openwrt.org >> Cc: yn...@true.cz >> Subject: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix >> it >> in 19.07.3 (?) >> >> ff02::2 multicast is not working in nanostation xw, but roger pueyo find a >> way >> to solve it: revert commit >> c8c2ef1d495dd3fd3096ac508e91a02f9c583ea8 (which is very short) >> >> I don't know the implications of doing it. But it fixes a bug that affects >> us a lot >> (we have lots of these devices and they do routing through cable) >> >> https://bugs.openwrt.org/index.php?do=details_id=2848 > if I checked correctly, this is not applied to master or even proposed as > patch? > > Then, you might be too late for this stable release. Normally, stuff should > stay in master for a few days before being backported. > > Best > > Adrian > >> ___ >> 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 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix it in 19.07.3 (?)
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of pedrowrt > Sent: Dienstag, 5. Mai 2020 10:36 > To: openwrt-devel@lists.openwrt.org > Cc: yn...@true.cz > Subject: [OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix it > in 19.07.3 (?) > > ff02::2 multicast is not working in nanostation xw, but roger pueyo find a way > to solve it: revert commit > c8c2ef1d495dd3fd3096ac508e91a02f9c583ea8 (which is very short) > > I don't know the implications of doing it. But it fixes a bug that affects us > a lot > (we have lots of these devices and they do routing through cable) > > https://bugs.openwrt.org/index.php?do=details_id=2848 if I checked correctly, this is not applied to master or even proposed as patch? Then, you might be too late for this stable release. Normally, stuff should stay in master for a few days before being backported. Best Adrian > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Multicast issue in 19.07.x release and master, fix it in 19.07.3 (?)
ff02::2 multicast is not working in nanostation xw, but roger pueyo find a way to solve it: revert commit c8c2ef1d495dd3fd3096ac508e91a02f9c583ea8 (which is very short) I don't know the implications of doing it. But it fixes a bug that affects us a lot (we have lots of these devices and they do routing through cable) https://bugs.openwrt.org/index.php?do=details_id=2848 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
