Re: [OpenWrt-Devel] OpenWRT Wiki License changed?
On 2015-01-23 14:52, Riley Baird wrote: Hi, A while ago I submitted content to the OpenWRT wiki, It said that my contributions were under CC BY-SA 3.0. Now, however, it says that they are under CC BY-NC-SA 3.0. Is there a reason for this? Ping. It doesn't look like there was an answer to this; is Riley mistaken, or was the license on the wiki content in fact changed? And if so, why? Can we change it back? Was there some sort of discussion leading up to the change that we missed? Personally, I'd rather my contributions be CC BY-SA rather than CC BY-NC-SA (I don't see how the NC clause helps us, but I can sure see ways how it hurts us), and I imagine that anyone who contributed something before the license-change would have expected that their contributions were not just going to be relicensed to include a NC clause I note that the wiki footer does say Except where otherwise noted...; should we go through and put explicit This section is license under CC BY-SA statements all over the place? :) -- Don't be afraid to ask (λf.((λx.xx) (λr.f(rr. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] ar71xx/image: add template tplink-16mlzma
Signed-off-by: Alexander Couzens lyn...@fe80.eu --- target/linux/ar71xx/image/Makefile | 6 ++ 1 file changed, 6 insertions(+) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index a4ebccb..234e1b6 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -156,6 +156,12 @@ $(Device/tplink) IMAGE_SIZE := 7936k endef +define Device/tplink-16mlzma +$(Device/tplink) + TPLINK_FLASHLAYOUT := 16Mlzma + IMAGE_SIZE := 15872k +endef + define Device/tl-wdr4300-v1 $(Device/tplink-8mlzma) BOARDNAME = TL-WDR4300 -- 2.3.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3] ar71xx/image: move TPLINK-LZMA image to new build code
There are 2 images missing: TLWR2543 TLWR1043V2 which have special properties Signed-off-by: Alexander Couzens lyn...@fe80.eu --- target/linux/ar71xx/image/Makefile | 370 - 1 file changed, 325 insertions(+), 45 deletions(-) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 234e1b6..4819ab9 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -196,6 +196,331 @@ $(Device/tl-wdr4300-v1) endef TARGET_DEVICES += tl-wdr3500-v1 tl-wdr3600-v1 tl-wdr4300-v1 tl-wdr4300-v1-il tl-wdr4310-v1 mw4530r-v1 +define Device/archer-c5 +$(Device/tplink-16mlzma) +BOARDNAME := ARCHER-C5 +DEVICE_PROFILE := ARCHERC5 +TPLINK_HWID := 0xc501 +endef + +define Device/archer-c7-v1 +$(Device/tplink-8mlzma) +BOARDNAME := ARCHER-C7 +DEVICE_PROFILE := ARCHERC7V1 +TPLINK_HWID := 0x7501 +endef + +define Device/archer-c7-v2 +$(Device/tplink-16mlzma) +BOARDNAME := ARCHER-C7 +DEVICE_PROFILE := ARCHERC7V2 +TPLINK_HWID := 0xc702 +endef + +define Device/el-m150 +$(Device/tplink-8mlzma) +BOARDNAME := EL-M150 +DEVICE_PROFILE := ELM150 +TPLINK_HWID := 0x01500101 +CONSOLE := ttyATH0,115200 +endef + +define Device/el-mini +$(Device/tplink-8mlzma) +BOARDNAME := EL-MINI +DEVICE_PROFILE := ELMINI +TPLINK_HWID := 0x01530001 +CONSOLE := ttyATH0,115200 +endef + +define Device/gl-inet-6408A-v1 +$(Device/tplink-8mlzma) +BOARDNAME := GL-INET +DEVICE_PROFILE := GLINET6408A +TPLINK_HWID := 0x0801 +CONSOLE := ttyATH0,115200 +endef + +define Device/gl-inet-6416A-v1 +$(Device/tplink-16mlzma) +BOARDNAME := GL-INET +DEVICE_PROFILE := GLINET6416A +TPLINK_HWID := 0x0801 +CONSOLE := ttyATH0,115200 +endef + +define Device/mc-mac1200r +$(Device/tplink-8mlzma) +BOARDNAME := MC-MAC1200R +DEVICE_PROFILE := MAC1200R +TPLINK_HWID := 0x1201 +endef + +define Device/tl-mr10u-v1 +$(Device/tplink-4mlzma) +BOARDNAME := TL-MR10U +DEVICE_PROFILE := TLMR10U +TPLINK_HWID := 0x00100101 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-mr11u-v1 +$(Device/tplink-4mlzma) +BOARDNAME := TL-MR11U +DEVICE_PROFILE := TLMR11UV1 +TPLINK_HWID := 0x00110101 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-mr11u-v2 +$(Device/tplink-4mlzma) +BOARDNAME := TL-MR11U +DEVICE_PROFILE := TLMR11UV2 +TPLINK_HWID := 0x00110102 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-mr12u-v1 +$(Device/tplink-4mlzma) +BOARDNAME := TL-MR13U +DEVICE_PROFILE := TLMR12U +TPLINK_HWID := 0x00120101 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-mr13u-v1 +$(Device/tplink-4mlzma) +BOARDNAME := TL-MR13U +DEVICE_PROFILE := TLMR13U +TPLINK_HWID := 0x00130101 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-mr3020-v1 +$(Device/tplink-4mlzma) +BOARDNAME := TL-MR3020 +DEVICE_PROFILE := TLMR3020 +TPLINK_HWID := 0x3021 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-mr3040-v1 +$(Device/tplink-4mlzma) +BOARDNAME := TL-MR3040 +DEVICE_PROFILE := TLMR3040V1 +TPLINK_HWID := 0x3041 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-mr3040-v2 +$(Device/tplink-4mlzma) +BOARDNAME := TL-MR3040-v2 +DEVICE_PROFILE := TLMR3040V2 +TPLINK_HWID := 0x3042 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-mr3220-v2 +$(Device/tplink-4mlzma) +BOARDNAME := TL-MR3220-v2 +DEVICE_PROFILE := TLMR3220V2 +TPLINK_HWID := 0x3222 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-mr3420-v2 +$(Device/tplink-4mlzma) +BOARDNAME := TL-MR3420-v2 +DEVICE_PROFILE := TLMR3420V2 +TPLINK_HWID := 0x3422 +endef + +define Device/tl-wa701nd-v2 +$(Device/tplink-4mlzma) +BOARDNAME := TL-WA701ND-v2 +DEVICE_PROFILE := TLWA701NV2 +TPLINK_HWID := 0x07010002 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-wa7210n-v2 +$(Device/tplink-4mlzma) +BOARDNAME := TL-WA7210N-v2 +DEVICE_PROFILE := TLWA7210NV2 +TPLINK_HWID := 0x7212 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-wr703n-v1 +$(Device/tplink-4mlzma) +BOARDNAME := TL-WR703N +DEVICE_PROFILE := TLWR703 +TPLINK_HWID := 0x07030101 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-wr710n-v1 +$(Device/tplink-8mlzma) +BOARDNAME := TL-WR710N +DEVICE_PROFILE := TLWR710 +TPLINK_HWID := 0x0711 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-wr720n-v3 +$(Device/tplink-4mlzma) +BOARDNAME := TL-WR720N-v3 +DEVICE_PROFILE := TLWR720NV3 +TPLINK_HWID := 0x07200103 +CONSOLE := ttyATH0,115200 +endef + +define Device/tl-wr740n-v4 +$(Device/tplink-4mlzma) +BOARDNAME := TL-WR741ND-v4 +DEVICE_PROFILE := TLWR740NV4 +TPLINK_HWID := 0x0744 +CONSOLE := ttyATH0,115200
[OpenWrt-Devel] [PATCH 1/3] ar71xx/image: fix imagesize of template tplink-8mlzma
The new image size is verified by a running tplink device and checked against mktplinkfw source code. Signed-off-by: Alexander Couzens lyn...@fe80.eu --- target/linux/ar71xx/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 8766756..a4ebccb 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -153,7 +153,7 @@ endef define Device/tplink-8mlzma $(Device/tplink) TPLINK_FLASHLAYOUT := 8Mlzma - IMAGE_SIZE := 8000k + IMAGE_SIZE := 7936k endef define Device/tl-wdr4300-v1 -- 2.3.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: fix ethernet packet loss issues on OM5P-AN
On 2015-04-10 17:39, Daniel Golle wrote: Hi! Sorry for hijacking this thread... I observed some recent ubiquiti gear suffering from similar issues, suspected the hardware being broken or some EE functionality missing in the driver as the issue usually occurs after some time of inactivity... My logs repeatedly get filled with stuff like that: Fri Apr 10 17:31:07 2015 kern.info kernel: [75029.02] eth0: tx timeout Fri Apr 10 17:31:07 2015 kern.info kernel: [75029.02] eth0: link down Fri Apr 10 17:31:08 2015 kern.info kernel: [75029.85] eth0: link up (100Mbps/Full duplex) Observed on ubnt nanostation loco m5 xw and recent bullet m5 with phy having phy_id 0x004dd041 Please post a full boot log of both affected devices. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ag71xx unstable link problems on AR7241r1
On 11/04/15 11:25, Daniel Golle wrote: On Fri, Apr 10, 2015 at 07:06:24PM +0200, Daniel Golle wrote: On Fri, Apr 10, 2015 at 05:58:04PM +0200, Sven Eckelmann wrote: I had problems in the past with some optimization by from Felix which caused situations like that. For some reason the device was not correctly reseted on errors. This looked like it was caused by his reset optimizations. When this device uses the ag71xx driver, is a ar724x device and you suspect that this is a partial reset problem then you may try something like this I flashed the affected device (turns out to be a non-XW nanostation) with your testing patch applied. I'll see how it goes, I'll let you know in the next days if the ethernet link is more stable now. Result: the problem persists also with your patch applied... I am seeing trouble like this on an OM2P. I suspect it is due to pause frames. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] Mips SIMD architecture (MSA)
As far i can understand MSA is a feature that is only present in the MIPS Warrior cores and, for now, seems that could be only needed in malta [1] target. As you can see in arch/mips/Kconfig MIPS32R2 and MIPS64R2 select CPU_SUPPORTS_MSA which does not apply to the majority of the mips targets in OpenWRT. Deleting select CPU_SUPPORTS_MSA in [2] and [3] and changing [4] with depends CPU_MIPS32_R2 || CPU_MIPS64_R2 will make MSA selectable and should make the kernel smaller. [1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n311 [2]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n1256 [3]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n1290 [4]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n2135 Regards: Pepe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] Mips SIMD architecture (MSA)
2015-04-13 11:15 GMT+02:00, Paul Burton paul.bur...@imgtec.com: On Mon, Apr 13, 2015 at 10:54:05AM +0200, José Vázquez wrote: As far i can understand MSA is a feature that is only present in the MIPS Warrior cores and, for now, seems that could be only needed in malta [1] target. As you can see in arch/mips/Kconfig MIPS32R2 and MIPS64R2 select CPU_SUPPORTS_MSA which does not apply to the majority of the mips targets in OpenWRT. Deleting select CPU_SUPPORTS_MSA in [2] and [3] and changing [4] with depends CPU_MIPS32_R2 || CPU_MIPS64_R2 will make MSA selectable and should make the kernel smaller. Hello, I'm not sure I understand the problem here - CPU_HAS_MSA should already be configurable via Kconfig, so you can just disable it if you don't need it (as indicated in the Kconfig help text). The CPU_SUPPORTS_MSA entries are there just to enforce that you can only enable CPU_HAS_MSA on a system which might possibly include MSA (ie. MIPSr2+, well really MIPSr5+). In essence, the fact that your system selects CPU_SUPPORTS_MSA shouldn't increase the size of your kernel unless you also enable the configurable CPU_HAS_MSA. Am I missing something? Thanks, Paul [1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n311 [2]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n1256 [3]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n1290 [4]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n2135 Regards: Pepe MSA is not selectable if in Kconfig the target selects SYS_HAS_CPU_MIPS32_R2 or SYS_HAS_CPU_MIPS64_R2, like Lantiq, PMC_MSP, Ralink and some others because of [2] and [3]. I.e., in the case of EVA it is only selected if SYS_HAS_CPU_MIPS32_R3_5. Pepe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: fix ethernet packet loss issues on OM5P-AN
Hi, Observed on ubnt nanostation loco m5 xw and recent bullet m5 with phy having phy_id 0x004dd041 Please post a full boot log of both affected devices. I assume that Daniel is referring to this issue: https://dev.openwrt.org/ticket/19085 I just uploaded the output of dmesg: https://dev.openwrt.org/attachment/ticket/19085/nanostation_loco_xw_boot.log Cheers, Lars ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] trunk: Ethernet LEDs not visible in Sysfs
just for the archive, this patch solved my problem: commit f3129943ca6748d867ea6e9930b962b65d01ee47 Author: juhosg juhosg@3c298f89-4303-0410-b956-a3cf2f4a3e73 AuthorDate: Tue Mar 31 21:31:36 2015 + Commit: juhosg juhosg@3c298f89-4303-0410-b956-a3cf2f4a3e73 CommitDate: Tue Mar 31 21:31:36 2015 + ar71xx: fix platform device support in the gpio-74x164 driver Platform device support has been removed from the gpio-74x164 driver in 3.14. Restore that. Signed-off-by: Gabor Juhos juh...@openwrt.org Best Christian Am 20.03.2015 um 16:38 schrieb Christian Mehlis: hi, my Archer-c5 and tplink 4300 routers do have 10 LEDs, but in the sysfs only the following LEDs are usable/visible: $ ls /sys/class/leds ath9k-phy1 tp-link:blue:wlan2g tp-link:green:usb2 tp-link:blue:qss tp-link:blue:wlan5g tp-link:blue:system tp-link:green:usb1 $ cat /sys/kernel/debug/gpio GPIOs 0-23, ath79: gpio-12 (tp-link:blue:wlan2g ) out lo gpio-13 (RFKILL switch ) in lo gpio-14 (tp-link:blue:system ) out lo gpio-15 (tp-link:blue:qss) out hi gpio-16 (Reset button) in hi gpio-17 (tp-link:blue:wlan5g ) out lo gpio-18 (tp-link:green:usb1 ) out hi gpio-19 (tp-link:green:usb2 ) out hi gpio-21 (USB2 power ) out hi gpio-22 (USB1 power ) out hi All LAN and WAN LEDs are missing in sysfs. Can someone tell me how to make them visible in sysfs in again? Best Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] Mips SIMD architecture (MSA)
2015-04-13 12:28 GMT+02:00, Paul Burton paul.bur...@imgtec.com: On Mon, Apr 13, 2015 at 11:59:20AM +0200, José Vázquez wrote: 2015-04-13 11:15 GMT+02:00, Paul Burton paul.bur...@imgtec.com: On Mon, Apr 13, 2015 at 10:54:05AM +0200, José Vázquez wrote: As far i can understand MSA is a feature that is only present in the MIPS Warrior cores and, for now, seems that could be only needed in malta [1] target. As you can see in arch/mips/Kconfig MIPS32R2 and MIPS64R2 select CPU_SUPPORTS_MSA which does not apply to the majority of the mips targets in OpenWRT. Deleting select CPU_SUPPORTS_MSA in [2] and [3] and changing [4] with depends CPU_MIPS32_R2 || CPU_MIPS64_R2 will make MSA selectable and should make the kernel smaller. Hello, I'm not sure I understand the problem here - CPU_HAS_MSA should already be configurable via Kconfig, so you can just disable it if you don't need it (as indicated in the Kconfig help text). The CPU_SUPPORTS_MSA entries are there just to enforce that you can only enable CPU_HAS_MSA on a system which might possibly include MSA (ie. MIPSr2+, well really MIPSr5+). In essence, the fact that your system selects CPU_SUPPORTS_MSA shouldn't increase the size of your kernel unless you also enable the configurable CPU_HAS_MSA. Am I missing something? Thanks, Paul [1]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n311 [2]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n1256 [3]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n1290 [4]https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/arch/mips/Kconfig?id=refs/tags/v3.18.11#n2135 Regards: Pepe MSA is not selectable if in Kconfig the target selects SYS_HAS_CPU_MIPS32_R2 or SYS_HAS_CPU_MIPS64_R2, like Lantiq, PMC_MSP, Ralink and some others because of [2] and [3]. I.e., in the case of EVA it is only selected if SYS_HAS_CPU_MIPS32_R3_5. Pepe ...but [2] [3] both only select CPU_SUPPORTS_MSA, not CPU_HAS_MSA. You should still be able to disable CPU_HAS_MSA in your configuration. Nothing depends upon or selects CPU_HAS_MSA, so you should always be able to disable it regardless of the platform you build for. To take one of your examples I just checked out v3.18.11, started from the Lantiq xway_defconfig and ran menuconfig. MSA is disabled by default as expected, and can be enabled if ( only if) its dependency CONFIG_MIPS_O32_FP64_SUPPORT is enabled. Even when that is enabled MSA is still disabled by default. I still don't see what you're trying to do here - MSA can already always be disabled via Kconfig, and is automatically enforced disabled on systems where it doesn't make sense. Thanks, Paul You are right. Sorry and thanks for the clarification. Best regards: Pepe ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ubus: Fix issues reported by static code analysis tool Klocwork
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
examples/client.c | 4 +++-
examples/server.c | 3 +++
lua/ubus.c| 19 +--
ubusd_event.c | 3 ++-
ubusd_obj.c | 3 +++
ubusd_proto.c | 9 +++--
6 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/examples/client.c b/examples/client.c
index b586eaf..952ab54 100644
--- a/examples/client.c
+++ b/examples/client.c
@@ -106,8 +106,10 @@ static void test_count(struct uloop_timeout *timeout)
count_to += count_progression;
s = count_to_number(count_to);
- if (!s)
+ if (!s) {
fprintf(stderr, Could not allocate memory to count up to
'%u'\n, count_to);
+ return;
+ }
fprintf(stderr, Sending count up to '%u'; string has length '%u'\n,
count_to, (uint32_t)strlen(s));
diff --git a/examples/server.c b/examples/server.c
index b8b751e..e0cde0b 100644
--- a/examples/server.c
+++ b/examples/server.c
@@ -93,6 +93,9 @@ static int test_hello(struct ubus_context *ctx, struct
ubus_object *obj,
msgstr = blobmsg_data(tb[HELLO_MSG]);
hreq = calloc(1, sizeof(*hreq) + strlen(format) + strlen(obj-name) +
strlen(msgstr) + 1);
+ if (!hreq)
+ return UBUS_STATUS_UNKNOWN_ERROR;
+
sprintf(hreq-data, format, obj-name, msgstr);
ubus_defer_request(ctx, req, hreq-req);
hreq-timeout.cb = test_hello_reply;
diff --git a/lua/ubus.c b/lua/ubus.c
index 92fb0a1..362f932 100644
--- a/lua/ubus.c
+++ b/lua/ubus.c
@@ -382,6 +382,9 @@ static int ubus_lua_load_methods(lua_State *L, struct
ubus_method *m)
/* setup the policy pointers */
p = malloc(sizeof(struct blobmsg_policy) * plen);
+ if (!p)
+ return 1;
+
memset(p, 0, sizeof(struct blobmsg_policy) * plen);
m-policy = p;
lua_pushnil(L);
@@ -417,6 +420,9 @@ static struct ubus_object* ubus_lua_load_object(lua_State
*L)
/* setup object pointers */
obj = malloc(sizeof(struct ubus_lua_object));
+ if (!obj)
+ return NULL;
+
memset(obj, 0, sizeof(struct ubus_lua_object));
obj-o.name = lua_tostring(L, -2);
@@ -427,6 +433,11 @@ static struct ubus_object* ubus_lua_load_object(lua_State
*L)
/* setup type pointers */
obj-o.type = malloc(sizeof(struct ubus_object_type));
+ if (!obj-o.type) {
+ free(obj);
+ return NULL;
+ }
+
memset(obj-o.type, 0, sizeof(struct ubus_object_type));
obj-o.type-name = lua_tostring(L, -2);
obj-o.type-id = 0;
@@ -529,10 +540,11 @@ ubus_lua_call_cb(struct ubus_request *req, int type,
struct blob_attr *msg)
{
lua_State *L = (lua_State *)req-priv;
- if (!msg)
+ if (!msg L)
lua_pushnil(L);
- ubus_lua_parse_blob_array(L, blob_data(msg), blob_len(msg), true);
+ if (msg L)
+ ubus_lua_parse_blob_array(L, blob_data(msg), blob_len(msg),
true);
}
static int
@@ -598,6 +610,9 @@ ubus_lua_load_event(lua_State *L)
struct ubus_lua_event* event = NULL;
event = malloc(sizeof(struct ubus_lua_event));
+ if (!event)
+ return NULL;
+
memset(event, 0, sizeof(struct ubus_lua_event));
event-e.cb = ubus_event_handler;
diff --git a/ubusd_event.c b/ubusd_event.c
index 85031a6..6d4ddcf 100644
--- a/ubusd_event.c
+++ b/ubusd_event.c
@@ -267,6 +267,7 @@ void ubusd_event_init(void)
{
ubus_init_string_tree(patterns, true);
event_obj = ubusd_create_object_internal(NULL,
UBUS_SYSTEM_OBJECT_EVENT);
- event_obj-recv_msg = ubusd_event_recv;
+ if (event_obj != NULL)
+ event_obj-recv_msg = ubusd_event_recv;
}
diff --git a/ubusd_obj.c b/ubusd_obj.c
index 8923821..62c2331 100644
--- a/ubusd_obj.c
+++ b/ubusd_obj.c
@@ -58,6 +58,9 @@ static struct ubus_object_type *ubus_create_obj_type(struct
blob_attr *sig)
int rem;
type = calloc(1, sizeof(*type));
+ if (!type)
+ return NULL;
+
type-refcount = 1;
if (!ubus_alloc_id(obj_types, type-id, 0))
diff --git a/ubusd_proto.c b/ubusd_proto.c
index 6b068eb..991a70a 100644
--- a/ubusd_proto.c
+++ b/ubusd_proto.c
@@ -487,6 +487,9 @@ void ubus_notify_subscription(struct ubus_object *obj)
blob_put_int8(b, UBUS_ATTR_ACTIVE, active);
ub = ubus_msg_from_blob(false);
+ if (!ub)
+ return;
+
ubus_msg_init(ub, UBUS_MSG_NOTIFY, ++obj-invoke_seq, 0);
ubus_msg_send(obj-client, ub, true);
}
@@ -500,8 +503,10 @@ void ubus_notify_unsubscribe(struct ubus_subscription *s)
blob_put_int32(b, UBUS_ATTR_TARGET, s-target-id.id);
ub = ubus_msg_from_blob(false);
- ubus_msg_init(ub, UBUS_MSG_UNSUBSCRIBE, ++s-subscriber-invoke_seq, 0);
- ubus_msg_send(s-subscriber-client, ub, true);
+ if (ub != NULL) {
+
