[OpenWrt-Devel] [PATCH] add pkgconfig information for popt library
Modify makefile to record pkgconfig information for the popt library.
Signed-off-by: Mike Brady mikebr...@eircom.net
---
package/libs/popt/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/package/libs/popt/Makefile b/package/libs/popt/Makefile
index bd2e6e2..b31b311 100644
--- a/package/libs/popt/Makefile
+++ b/package/libs/popt/Makefile
@@ -45,6 +45,8 @@ define Build/InstallDev
$(CP) $(PKG_INSTALL_DIR)/usr/include/popt.h $(1)/usr/include/
$(INSTALL_DIR) $(1)/usr/lib
$(CP) $(PKG_INSTALL_DIR)/usr/lib/libpopt.{a,so*} $(1)/usr/lib/
+ $(INSTALL_DIR) $(1)/usr/lib/pkgconfig
+ $(CP) $(PKG_INSTALL_DIR)/usr/lib/pkgconfig/popt.pc
$(1)/usr/lib/pkgconfig/
endef
define Package/libpopt/install
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: fix default led configuration for rt-n14u
use new helper function to generate default led configuration Signed-off-by: Pavel Löbl lobl.pa...@gmail.com --- target/linux/ramips/base-files/etc/board.d/01_leds | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds b/target/linux/ramips/base-files/etc/board.d/01_leds index 405a6c0..c42b31f 100755 --- a/target/linux/ramips/base-files/etc/board.d/01_leds +++ b/target/linux/ramips/base-files/etc/board.d/01_leds @@ -191,8 +191,8 @@ case $board in ;; rt-n14u) ucidef_set_led_default power power asus:blue:power 1 - ucidef_set_led_interafce lan asus:blue:lan - ucidef_set_led_netdev wan asus:blue:wan + ucidef_set_led_netdev lan lan asus:blue:lan eth0.1 + ucidef_set_led_netdev wan wan asus:blue:wan eth0.2 set_wifi_led asus:blue:air set_usb_led asus:blue:usb ;; -- 2.1.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH uclient] support for connection timeout
On 2015-01-15 16:40, Rafał Miłecki wrote:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
uclient-fetch.c | 4
uclient.c | 25 -
uclient.h | 4
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/uclient.c b/uclient.c
index ab2d5b6..a405179 100644
--- a/uclient.c
+++ b/uclient.c
@@ -207,12 +207,31 @@ int uclient_write(struct uclient *cl, char *buf, int
len)
return cl-backend-write(cl, buf, len);
}
+static void uclient_request_timeout(struct uloop_timeout *timeout)
+{
+ struct uclient *cl = container_of(timeout, struct uclient,
request_timeout);
+
+ if (cl-backend-disconnect)
+ cl-backend-disconnect(cl);
+
+ uclient_backend_set_error(cl, UCLIENT_ERROR_TIMEDOUT);
+}
+
int uclient_request(struct uclient *cl)
{
+ int err;
+
if (!cl-backend-request)
return -1;
- return cl-backend-request(cl);
+ err = cl-backend-request(cl);
+ if (err)
+ return err;
+
+ cl-request_timeout.cb = uclient_request_timeout;
+ uloop_timeout_set(cl-request_timeout,
UCLIENT_DEFAULT_CONNECTION_TIMEOUT_MS);
Please store the timeout value in struct uclient and initialize it at
alloc time. I don't like forced hardcoded values.
+
+ return 0;
}
int uclient_read(struct uclient *cl, char *buf, int len)
@@ -225,6 +244,8 @@ int uclient_read(struct uclient *cl, char *buf, int len)
void uclient_disconnect(struct uclient *cl)
{
+ uloop_timeout_cancel(cl-request_timeout);
+
if (!cl-backend-disconnect)
return;
@@ -243,6 +264,8 @@ static void __uclient_backend_change_state(struct
uloop_timeout *timeout)
static void uclient_backend_change_state(struct uclient *cl)
{
+ uloop_timeout_cancel(cl-request_timeout);
+
cl-timeout.cb = __uclient_backend_change_state;
uloop_timeout_set(cl-timeout, 1);
}
The timeout should be cancelled or refreshed when the HTTP response is
received, and on new incoming data. It should probably be cancelled if
the receive buffer is full (since the data reception is throttled by the
user).
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH uclient] support for connection timeout
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
uclient-fetch.c | 4
uclient.c | 25 -
uclient.h | 4
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/uclient-fetch.c b/uclient-fetch.c
index 22f15c6..0617a02 100644
--- a/uclient-fetch.c
+++ b/uclient-fetch.c
@@ -194,6 +194,10 @@ static void handle_uclient_error(struct uclient *cl, int
code)
type = Connection failed;
error_ret = 4;
break;
+ case UCLIENT_ERROR_TIMEDOUT:
+ type = Connection timed out;
+ error_ret = 4;
+ break;
case UCLIENT_ERROR_SSL_INVALID_CERT:
type = Invalid SSL certificate;
ignore = !verify;
diff --git a/uclient.c b/uclient.c
index ab2d5b6..a405179 100644
--- a/uclient.c
+++ b/uclient.c
@@ -207,12 +207,31 @@ int uclient_write(struct uclient *cl, char *buf, int len)
return cl-backend-write(cl, buf, len);
}
+static void uclient_request_timeout(struct uloop_timeout *timeout)
+{
+ struct uclient *cl = container_of(timeout, struct uclient,
request_timeout);
+
+ if (cl-backend-disconnect)
+ cl-backend-disconnect(cl);
+
+ uclient_backend_set_error(cl, UCLIENT_ERROR_TIMEDOUT);
+}
+
int uclient_request(struct uclient *cl)
{
+ int err;
+
if (!cl-backend-request)
return -1;
- return cl-backend-request(cl);
+ err = cl-backend-request(cl);
+ if (err)
+ return err;
+
+ cl-request_timeout.cb = uclient_request_timeout;
+ uloop_timeout_set(cl-request_timeout,
UCLIENT_DEFAULT_CONNECTION_TIMEOUT_MS);
+
+ return 0;
}
int uclient_read(struct uclient *cl, char *buf, int len)
@@ -225,6 +244,8 @@ int uclient_read(struct uclient *cl, char *buf, int len)
void uclient_disconnect(struct uclient *cl)
{
+ uloop_timeout_cancel(cl-request_timeout);
+
if (!cl-backend-disconnect)
return;
@@ -243,6 +264,8 @@ static void __uclient_backend_change_state(struct
uloop_timeout *timeout)
static void uclient_backend_change_state(struct uclient *cl)
{
+ uloop_timeout_cancel(cl-request_timeout);
+
cl-timeout.cb = __uclient_backend_change_state;
uloop_timeout_set(cl-timeout, 1);
}
diff --git a/uclient.h b/uclient.h
index d5a0d5b..095d894 100644
--- a/uclient.h
+++ b/uclient.h
@@ -24,12 +24,15 @@
#include libubox/ustream.h
#include libubox/ustream-ssl.h
+#define UCLIENT_DEFAULT_CONNECTION_TIMEOUT_MS 3
+
struct uclient_cb;
struct uclient_backend;
enum uclient_error_code {
UCLIENT_ERROR_UNKNOWN,
UCLIENT_ERROR_CONNECT,
+ UCLIENT_ERROR_TIMEDOUT,
UCLIENT_ERROR_SSL_INVALID_CERT,
UCLIENT_ERROR_SSL_CN_MISMATCH,
UCLIENT_ERROR_MISSING_SSL_CONTEXT,
@@ -67,6 +70,7 @@ struct uclient {
int status_code;
struct blob_attr *meta;
+ struct uloop_timeout request_timeout;
struct uloop_timeout timeout;
};
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] sunxi: implement board_detect for device-tree kernels
board_detect previously relied on parsing the kernel cmdline
out of the U-Boot environment stored on the the MMC card in order
to get the board= parameter.
Use /proc/device-tree/model instead.
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
target/linux/sunxi/base-files/lib/sunxi.sh | 168 ++---
1 file changed, 130 insertions(+), 38 deletions(-)
diff --git a/target/linux/sunxi/base-files/lib/sunxi.sh
b/target/linux/sunxi/base-files/lib/sunxi.sh
index adf9f84..b0a3874 100644
--- a/target/linux/sunxi/base-files/lib/sunxi.sh
+++ b/target/linux/sunxi/base-files/lib/sunxi.sh
@@ -1,45 +1,137 @@
#!/bin/sh
# defaults
-SUNXI_BOARD_NAME=generic sunxi
-SUNXI_BOARD_MODEL=generic sunxi
-SUNXI_ENV_DEV=/dev/mmcblk0
-
-#Helper functions
-get_cmdline_opt()
-{
-cat /proc/cmdline | awk -F$1= '{print $2}' | awk '{print $1}'
-}
+SUNXI_BOARD_NAME=generic
+SUNXI_BOARD_MODEL=Generic sunxi board
-#Since fw_getenv doesn't work with blockdevs let's make a hack
-uboot_getenv()
-{
-dd if=$SUNXI_ENV_DEV bs=1024 skip=544 count=128 2dev/null |\strings|grep
$1|cut -d= -f2
-}
+sunxi_board_detect() {
+ local board
+ local model
-#Actual routines go below
-sunxi_env_dev()
-{
-local dev
-dev=`get_cmdline_opt root|cut -dp -f1`
-SUNXI_ENV_DEV=$dev
-echo probing $dev for uboot env data
-}
+ [ -e /tmp/sysinfo/ ] || mkdir -p /tmp/sysinfo/
-sunxi_board_detect() {
-local board
-local model
-sunxi_env_dev
-[ -e /tmp/sysinfo/ ] || mkdir -p /tmp/sysinfo/
-board=`uboot_getenv wrt_board`
-model=`uboot_getenv wrt_model`
-if [ $board != ]; then
- SUNXI_BOARD_NAME=$board
-fi
-if [ $model != ]; then
- SUNXI_BOARD_MODEL=$model
-fi
-echo $SUNXI_BOARD_NAME /tmp/sysinfo/board_name
-echo $SUNXI_BOARD_MODEL /tmp/sysinfo/model
-echo Detected $SUNXI_BOARD_NAME // $SUNXI_BOARD_MODEL
+ model=$( cat /proc/device-tree/model )
+
+ case $model in
+ Mele A1000)
+ board=a1000
+ ;;
+
+ BA10 tvbox)
+ board=ba10-tvbox
+ ;;
+
+ Cubietech Cubieboard)
+ board=cubieboard
+ ;;
+
+ Miniand Hackberry)
+ board=hackberry
+ ;;
+
+ INet-97F Rev 02)
+ board=inet97fv2
+ ;;
+
+ PineRiver Mini X-Plus)
+ board=mini-xplus
+ ;;
+
+ Olimex A10-OLinuXino-LIME)
+ board=olinuxino-lime
+ ;;
+
+ LinkSprite pcDuino)
+ board=pcduino
+ ;;
+
+ Olimex A10s-Olinuxino Micro)
+ board=olinuxino-micro
+ ;;
+
+ R7 A10s hdmi tv-stick)
+ board=r7-tv-dongle
+ ;;
+
+ HSG H702)
+ board=hsg-h702
+ ;;
+
+ Olimex A13-Olinuxino)
+ board=olinuxino
+ ;;
+
+ Olimex A13-Olinuxino Micro)
+ board=olinuxino-micro
+ ;;
+
+ Allwinner A31 APP4 EVB1 Evaluation Board)
+ board=app4-evb1
+ ;;
+
+ WITS A31 Colombus Evaluation Board)
+ board=colombus
+ ;;
+
+ Merrii A31 Hummingbird)
+ board=hummingbird
+ ;;
+
+ Mele M9 / A1000G Quad top set box)
+ board=m9
+ ;;
+
+ LeMaker Banana Pi)
+ board=bananapi
+ ;;
+
+ LeMaker Banana Pro)
+ board=bananapro
+ ;;
+
+ Cubietech Cubieboard2)
+ board=cubieboard2
+ ;;
+
+ Cubietech Cubietruck)
+ board=cubietruck
+ ;;
+
+ Merrii A20 Hummingbird)
+ board=hummingbird
+ ;;
+
+ I12 / Q5 / QT840A A20 tvbox)
+ board=i12-tvbox
+ ;;
+
+ Olimex A20-OLinuXino-LIME)
+ board=olinuxino-lime
+ ;;
+
+ Olimex A20-Olinuxino Micro)
+ board=olinuxino-micro
+ ;;
+
+ LinkSprite pcDuino3)
+ board=pcduino3
+ ;;
+
+ Ippo Q8H Dual Core Tablet (v5))
+ board=ippo-q8h-v5
+ ;;
+ esac
+
+ if [ $board != ]; then
+
[OpenWrt-Devel] [PATCH] ramips: add support for Intenso Memory 2 Move USB 3.0
This adds support for a rt5350-based portable nas solution
from Intenso. The board comes with 32M RAM and 8M Flash, the
built-in HDD is connected/accessible via a usb3.0-sata
bridge VLI VL701.
The device has 1 Ethernet port (100M/10M), 1 micro b usb 3.0
socket (for charging the battery, or accessing the hdd directly).
Wireless connectivity is provided by the rt5350 SoC [i.e.:
802.11n 1x1 2.4 GHz with a pcb antenna.]
Serial, leds, wifi, ethernet and usb are tested and
as far as I can tell: they are working fine (tm).
Signed-off-by: Christian Lamparter chunk...@googlemail.com
---
Any comments/suggestions or wishes? Most of the work is
based/taken from other devices. So apart from some non-obvious
stuff, it should all be fine too.
What is a bit unique: the way of flashing the device. This
will require a tftp server [hardcoded to 192.168.1.201]
and a few cables to the uart. I'll write a how to flash
openwrt on a m2m once this patch [or a better version] is
accepted.
Regards,
Christian
---
target/linux/ramips/base-files/etc/board.d/01_leds | 4 +
.../linux/ramips/base-files/etc/board.d/02_network | 5 +
target/linux/ramips/base-files/etc/diag.sh | 3 +
target/linux/ramips/base-files/lib/ramips.sh | 3 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ramips/dts/M2M.dts| 113 +
target/linux/ramips/image/Makefile | 3 +
target/linux/ramips/rt305x/profiles/m2m.mk | 21
8 files changed, 153 insertions(+)
create mode 100644 target/linux/ramips/dts/M2M.dts
create mode 100644 target/linux/ramips/rt305x/profiles/m2m.mk
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 405a6c0..7b29ac0 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -148,6 +148,10 @@ case $board in
nw718)
set_usb_led nw718:amber:usb
;;
+ m2m)
+ set_wifi_led m2m:blue:wifi
+ ucidef_set_led_netdev eth Ethernet m2m:green:wan eth0
+ ;;
omni-emb-hpm)
ucidef_set_led_default power POWER emb:orange:power 1
ucidef_set_led_netdev eth ETH emb:green:eth eth0
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index a86466e..e425510 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -62,6 +62,11 @@ ramips_setup_interfaces()
ucidef_set_interface_lan eth0.2
;;
+ m2m)
+ ucidef_add_switch switch0 4
+ ucidef_set_interface_lan eth0
+ ;;
+
wizard8800 | \
wl-330n | \
wmr300)
diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index 103dfcd..c43cb54 100755
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -79,6 +79,9 @@ get_status_led() {
hw550-3g)
status_led=hw550-3g:green:status
;;
+ m2m)
+ status_led=m2m:blue:wifi
+ ;;
m3)
status_led=m3:blue:status
;;
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 540da33..f783065 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -211,6 +211,9 @@ ramips_board_detect() {
*NW718)
name=nw718
;;
+ *Intenso Memory 2 Move)
+ name=m2m
+ ;;
*Omnima EMB HPM)
name=omni-emb-hpm
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 95cad63..2d48192 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -55,6 +55,7 @@ platform_check_image() {
ht-tm02 | \
hw550-3g | \
ip2202 | \
+ m2m | \
m3 | \
m4 | \
mlw221 | \
diff --git a/target/linux/ramips/dts/M2M.dts b/target/linux/ramips/dts/M2M.dts
new file mode 100644
index 000..aa98991
--- /dev/null
+++ b/target/linux/ramips/dts/M2M.dts
@@ -0,0 +1,113 @@
+/dts-v1/;
+
+/include/ rt5350.dtsi
+
+/ {
+ compatible = M2M, ralink,rt5350-soc;
+ model = Intenso Memory 2 Move;
+
+ chosen {
+ bootargs = console=ttyS1,57600n8 root=/dev/mtdblock5;
+ };
+
+ palmbus@1000 {
+ uart@500 {
+ status = okay;
+ };
+
+ spi@b00 {
+ status = okay;
+ m25p80@0 {
+
[OpenWrt-Devel] [PATCH 2/2] sunxi: introduce sunxi_board_name() in /lib/sunxi.sh
Simiarl to other hardware targets, this can then be used for board-specific
stuff in preinit and uci-default scripts.
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
target/linux/sunxi/base-files/lib/sunxi.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/target/linux/sunxi/base-files/lib/sunxi.sh
b/target/linux/sunxi/base-files/lib/sunxi.sh
index b0a3874..af9b5eb 100644
--- a/target/linux/sunxi/base-files/lib/sunxi.sh
+++ b/target/linux/sunxi/base-files/lib/sunxi.sh
@@ -135,3 +135,12 @@ sunxi_board_detect() {
echo $SUNXI_BOARD_MODEL /tmp/sysinfo/model
echo Detected $SUNXI_BOARD_NAME // $SUNXI_BOARD_MODEL
}
+
+sunxi_board_name() {
+ local name
+
+ [ -f /tmp/sysinfo/board_name ] name=$(cat /tmp/sysinfo/board_name)
+ [ -z $name ] name=unknown
+
+ echo $name
+}
--
2.2.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ddns-scripts sleep 10 before updating?
Am 15.01.2015 um 06:17 schrieb Catalin Patulea: On Tue, Jan 13, 2015 at 8:56 AM, Christian Schoenebeck christian.schoeneb...@gmail.com wrote: from my point of view 10 seconds to wait before sending an update to the ddns provider is not a big deal because it takes up to 5 minutes until nslookup [yourhost] 8.8.8.8 gives you back a static answer after a change. So Google's mameserver need up to 5 Minutes to sync themselves. How did you conclude about the 5 minutes? Technically caching DNS servers should respect the TTL of the original record. RFC 1035 even allows zero TTL to prevent caching. I agree that some servers may actually impose a minimum TTL, but ddns-scripts should not make any assumptions about this. In my case, I have DDNS records which are rarely accessed (are not likely to be cached by intermediate DNS servers). When a client makes a DNS request for my DDNS name, it will be forwarded the entire way to the authoritative DNS server. So the openwrt update latency dominates the delay, not TTL expiration, so it's useful for me to update ASAP after the interfaces gets an address. Are you still planning on running some tests on your side? I did some quick test. You are right that netifd calls hotplug now if ip-setup finished. I also looked into my email history and found the point where this sleep comes into the script. I did a lot of testing with a user using satellite Internet connection. He quickly gets his IP from the modem but he needs to use a global dns server to verify his registered ip via tcp because the modem buffers all udp dns requests not looking for any timeouts. For him it takes same seconds until the connection was established to the web after getting his ip from the modem. The 5 minutes I tested the easy way. On my ubuntu box I ran nslookup for my own ddns-address against Google's public dns in an endless loop. Then I send out a new ip to my ddns provider via ddns-scripts and wait. The longest time it takes to have a stable answer from nslookup was 4 minutes 10 seconds. Plus reserve = 5 minutes. Also the reason why check_interval minimum is set to 5 minutes = 300 seconds in line 176 of dynamic_dns_updater.sh. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Is Linksys/Belkin lying (again) about being open source (WRT1200AC router) ?
Hi, Great email Valent, and I fully agree with your comments. We have had this discussion here in the past and nothing much changed from Belkin side (actually it got worse as they disappeared apparently) showing a total failure on product release. I'm not entirely sure of the status of WRT1200AC, but if there is nothing here in OpenWRT and nothing else much can be found on the web they are once again lying. They are publishing intentions as if it was something that was already done and consolidated, ready for any buyer to enjoy. If there is something going on between them and OpenWRT we are not aware, at least not via this list. I personally consider a big slap in the face of consumers Marketing doing what they do in Belkin, like if they didn't care at all. This is not simply 'a mistake' or 'a misunderstanding' , it's complete dishonesty and they are probably fully aware of this but simply don't care at all cause they just want to reach their marketing target. Probably people there might not even have a basic idea about what is open-source. As mentioned Marvel is doing some progress with the Wifi driver, which is great for WRT1900AC owners, but that's Marvel only. What has Belkin done about their share of the work BEFORE they release this new product ? I not sure if much or any. I hope they are able to show me I am wrong on my comments. Regards, Fernando On 14/01/2015 13:05, valent.turko...@gmail.com wrote: Linksys/Belking marketing is again doing one thing and saying another? This time they say that WRT1200AC router is open source: http://www.zdnet.com/article/ces-2015-linksys-1200ac-an-inexpensive-open-source-802-11ac-wi-fi-router/ I have tracked progress with WRT1900AC and saw how they failed to give us open source driver, so I hope that this time they will actually keep their (marketing) promise. I really, really, really hope that this time they have reached out and contacted any of you OpenWrt developers and that we will get truly open source driver from them. So please let us know if any of you have heard anything regarding WRT1200AC router and it's drivers. Cheers, Valent. ___ 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
[OpenWrt-Devel] [PATCH] mwlwifi - dont break fw upload timing with log prints
The patch included here is needed if debug logging in mwlwifi
is enabled to a high enough level that the log prints are done
during time critical parts of firmware loading.
Enabling debug logging is, unfortuneatly, not as simple as defining
MWLDBG on the module make command line.
Something like this is also needed:
diff --git a/mwl_debug.c b/mwl_debug.c
index 821b0c0..f8644a8 100644
--- a/mwl_debug.c
+++ b/mwl_debug.c
@@ -41,7 +41,7 @@
/* PRIVATE VARIABLES
*/
-static u32 dbg_levels = 0;
+static u32 dbg_levels = 0x;
/* PUBLIC FUNCTION DEFINITION
*/
or dbg_levels set to some suitable integer that enables the logging
required. But that's another story.
This change is meant to avoid the firmware loading problem if anyone
does use the logging, and that's all.
Signed-off-by: Ian Kent ra...@themaw.net
---
...nt-break-fw-upload-timing-with-log-prints.patch | 82
1 file changed, 82 insertions(+)
create mode 100644
package/kernel/mwlwifi/patches/002-dont-break-fw-upload-timing-with-log-prints.patch
diff --git
a/package/kernel/mwlwifi/patches/002-dont-break-fw-upload-timing-with-log-prints.patch
b/package/kernel/mwlwifi/patches/002-dont-break-fw-upload-timing-with-log-prints.patch
new file mode 100644
index 000..e112606
--- /dev/null
+++
b/package/kernel/mwlwifi/patches/002-dont-break-fw-upload-timing-with-log-prints.patch
@@ -0,0 +1,82 @@
+mwlwifi - dont break fw upload timing with log prints
+
+From: Ian Kent ra...@themaw.net
+
+In the function mwl_fwdl_download_firmware() there's a comment that it
+takes ~1300 nSec for the register change that acknowledges each chunk
+of the firmware uploaded. But if you take too long to get to the check
+you can miss the event altogether.
+
+The Function mwl_fwdl_trig_pcicmd_bootcode() contains log prints that
+can take several miliseconds to complete and it is called from the above
+function to transfer a chunk of the firmware at a time. When logging is
+enabled it breaks the firware upload.
+
+So remove the function call that uploads the chunk (and contains log prints)
+and add its code in-line to avoid inadvertantly breaking the firmware upload
+by enabling logging.
+
+Signed-off-by: Ian Kent ra...@themaw.net
+---
+ mwl_fwdl.c | 29 ++---
+ 1 file changed, 10 insertions(+), 19 deletions(-)
+
+diff --git a/mwl_fwdl.c b/mwl_fwdl.c
+index 5f9ef91..46b61ed 100644
+--- a/mwl_fwdl.c
b/mwl_fwdl.c
+@@ -40,7 +40,6 @@
+ */
+
+ static void mwl_fwdl_trig_pcicmd(struct mwl_priv *priv);
+-static void mwl_fwdl_trig_pcicmd_bootcode(struct mwl_priv *priv);
+
+ /* PUBLIC FUNCTION DEFINITION
+ */
+@@ -99,9 +98,12 @@ int mwl_fwdl_download_firmware(struct ieee80211_hw *hw)
+ */
+ memcpy((char *)priv-pcmd_buf[0], (fw-data +
size_fw_downloaded), len);
+
+- /* this function writes pdata to c10, then write 2 to c18
++ /* write pdata to c10, then write 2 to c18
+ */
+- mwl_fwdl_trig_pcicmd_bootcode(priv);
++ writel(priv-pphys_cmd_buf, priv-iobase1 + MACREG_REG_GEN_PTR);
++ writel(0x00, priv-iobase1 + MACREG_REG_INT_CODE);
++ writel(MACREG_H2ARIC_BIT_DOOR_BELL,
++ priv-iobase1 + MACREG_REG_H2A_INTERRUPT_EVENTS);
+
+ curr_iteration = FW_MAX_NUM_CHECKS; /* this is arbitrary per
your platform; we use 0x */
+
+@@ -110,6 +112,11 @@ int mwl_fwdl_download_firmware(struct ieee80211_hw *hw)
+* the write of event 2 to C1C == 2 is ~1300 nSec. Hence the
checkings on host
+* has to consider how efficient your code can be to meet this
timing, or you
+* can alternatively tweak this routines to fit your platform
++ *
++ * NOTE: not only does the register change take ~1300 nSec
++ * but if you take too long to get to the check below, such
++ * as issuing a printk() for logging, you can miss the event
++ * altogether.
+*/
+ do {
+
+@@ -201,19 +208,3 @@ static void mwl_fwdl_trig_pcicmd(struct mwl_priv *priv)
+
+ WLDBG_EXIT(DBG_LEVEL_1);
+ }
+-
+-static void mwl_fwdl_trig_pcicmd_bootcode(struct mwl_priv *priv)
+-{
+- WLDBG_ENTER(DBG_LEVEL_1);
+-
+- BUG_ON(!priv);
+-
+- writel(priv-pphys_cmd_buf, priv-iobase1 + MACREG_REG_GEN_PTR);
+-
+- writel(0x00, priv-iobase1 + MACREG_REG_INT_CODE);
+-
+- writel(MACREG_H2ARIC_BIT_DOOR_BELL,
+- priv-iobase1 + MACREG_REG_H2A_INTERRUPT_EVENTS);
+-
+- WLDBG_EXIT(DBG_LEVEL_1);
+-}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Is Linksys/Belkin lying (again) about being open source (WRT1200AC router) ?
Is the 1200 out yet? The article that was posted earlier did say that they recognized that they had made mistakes with the 1900 and were planning to not do the same thing with the 1200 and have everything ready at the release date. If the release date is not here yet we can't say that they haven't improved. Now, this isn't the same as having the support upstream in openwrt, which is what we all want, but if they do release the full source at the time of the router release, it is better than most. David Lang On Fri, 16 Jan 2015, Fernando Frediani wrote: Hi, Great email Valent, and I fully agree with your comments. We have had this discussion here in the past and nothing much changed from Belkin side (actually it got worse as they disappeared apparently) showing a total failure on product release. I'm not entirely sure of the status of WRT1200AC, but if there is nothing here in OpenWRT and nothing else much can be found on the web they are once again lying. They are publishing intentions as if it was something that was already done and consolidated, ready for any buyer to enjoy. If there is something going on between them and OpenWRT we are not aware, at least not via this list. I personally consider a big slap in the face of consumers Marketing doing what they do in Belkin, like if they didn't care at all. This is not simply 'a mistake' or 'a misunderstanding' , it's complete dishonesty and they are probably fully aware of this but simply don't care at all cause they just want to reach their marketing target. Probably people there might not even have a basic idea about what is open-source. As mentioned Marvel is doing some progress with the Wifi driver, which is great for WRT1900AC owners, but that's Marvel only. What has Belkin done about their share of the work BEFORE they release this new product ? I not sure if much or any. I hope they are able to show me I am wrong on my comments. Regards, Fernando On 14/01/2015 13:05, valent.turko...@gmail.com wrote: Linksys/Belking marketing is again doing one thing and saying another? This time they say that WRT1200AC router is open source: http://www.zdnet.com/article/ces-2015-linksys-1200ac-an-inexpensive-open-source-802-11ac-wi-fi-router/ I have tracked progress with WRT1900AC and saw how they failed to give us open source driver, so I hope that this time they will actually keep their (marketing) promise. I really, really, really hope that this time they have reached out and contacted any of you OpenWrt developers and that we will get truly open source driver from them. So please let us know if any of you have heard anything regarding WRT1200AC router and it's drivers. Cheers, Valent. ___ 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] [PATCH] procd: delay inittab workers until the tty exists.
nack, using magic delays is a no go
On 16/01/2015 04:15, Owen Kirby wrote:
If a process with a tty is specified in inittab, delay the worker
process until the tty exists.
This allows starting consoles with terminals that get delayed until
after procd is reads inittab,
and it also allows hotplugging USB-to-serial adapters attached long
after booting.
Signed-off-by: Owen Kirby o...@exegin.com
---
inittab.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/inittab.c b/inittab.c
index 623103d..73c113f 100644
--- a/inittab.c
+++ b/inittab.c
@@ -99,9 +99,15 @@ static void fork_worker(struct init_action *a)
if (!a-proc.pid) {
p = setsid();
-fd = dev_open(a-id);
-if (fd != -1)
-{
+if (a-id) {
+struct timespec tm;
+tm.tv_sec = a-respawn / 1000;
+tm.tv_nsec = (a-respawn % 1000) * 100;
+
+while ((fd = dev_open(a-id)) == -1)
+if (nanosleep(tm, NULL) == -1)
+exit(-1);
+
dup2(fd, STDIN_FILENO);
dup2(fd, STDOUT_FILENO);
dup2(fd, STDERR_FILENO);
@@ -157,7 +163,7 @@ static void askfirst(struct init_action *a)
{
int i;
-if (!dev_exist(a-id) || (console !strcmp(console, a-id))) {
+if (console !strcmp(console, a-id)) {
DEBUG(4, Skipping %s\n, a-id);
return;
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] procd: delay inittab workers until the tty exists.
If a process with a tty is specified in inittab, delay the worker process until
the tty exists.
This allows starting consoles with terminals that get delayed until after procd
is reads inittab,
and it also allows hotplugging USB-to-serial adapters attached long after
booting.
Signed-off-by: Owen Kirby o...@exegin.com
---
inittab.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/inittab.c b/inittab.c
index 623103d..73c113f 100644
--- a/inittab.c
+++ b/inittab.c
@@ -99,9 +99,15 @@ static void fork_worker(struct init_action *a)
if (!a-proc.pid) {
p = setsid();
- fd = dev_open(a-id);
- if (fd != -1)
- {
+ if (a-id) {
+ struct timespec tm;
+ tm.tv_sec = a-respawn / 1000;
+ tm.tv_nsec = (a-respawn % 1000) * 100;
+
+ while ((fd = dev_open(a-id)) == -1)
+ if (nanosleep(tm, NULL) == -1)
+ exit(-1);
+
dup2(fd, STDIN_FILENO);
dup2(fd, STDOUT_FILENO);
dup2(fd, STDERR_FILENO);
@@ -157,7 +163,7 @@ static void askfirst(struct init_action *a)
{
int i;
- if (!dev_exist(a-id) || (console !strcmp(console, a-id))) {
+ if (console !strcmp(console, a-id)) {
DEBUG(4, Skipping %s\n, a-id);
return;
}
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] build: explicitly unexport CONFIG_SITE
On systems with CONFIG_SITE in the environment (e.g. OpenSUSE) make will export the CONFIG_SITE set in include/package.mk by default. This will cause host builds to get the target site configuration, leading to all kinds of weirdness (wrong pointer size, wrong endianess). Fix this by explicitly unexporting CONFIG_SITE. The explicit export for the target builds overrides the unexport, so the target builds will still correctly get the site config. Signed-off-by: Matthias Schiffer mschif...@universe-factory.net --- This bug was reported on openwrt-devel by Luiz Angelo Daros de Luca some months ago, and now I hit it myself. This should also be backported to BB. include/package.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/package.mk b/include/package.mk index a1b90da..e85e395 100644 --- a/include/package.mk +++ b/include/package.mk @@ -95,7 +95,7 @@ CONFIG_SITE:=$(INCLUDE_DIR)/site/$(REAL_GNU_TARGET_NAME) CUR_MAKEFILE:=$(filter-out Makefile,$(firstword $(MAKEFILE_LIST))) SUBMAKE:=$(NO_TRACE_MAKE) $(if $(CUR_MAKEFILE),-f $(CUR_MAKEFILE)) PKG_CONFIG_PATH=$(STAGING_DIR)/usr/lib/pkgconfig:$(STAGING_DIR)/usr/share/pkgconfig -unexport QUIET +unexport QUIET CONFIG_SITE ifeq ($(DUMP)$(filter prereq clean refresh update,$(MAKECMDGOALS)),) ifneq ($(if $(QUILT),,$(CONFIG_AUTOREBUILD)),) -- 2.2.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ddns-scripts sleep 10 before updating?
On Thu, Jan 15, 2015 at 3:28 PM, Christian Schoenebeck christian.schoeneb...@gmail.com wrote: I did a lot of testing with a user using satellite Internet connection. He quickly gets his IP from the modem but he needs to use a global dns server to verify his registered ip via tcp because the modem buffers all udp dns requests not looking for any timeouts. For him it takes same seconds until the connection was established to the web after getting his ip from the modem. Let me see if I understand.. so after his interface comes up, dynamic_dns_updater was getting stuck on get_registered_ip because the connection to the web is not yet up? Perhaps this could be handled by a timeout on the host/nslookup command? I also think this is an edge case - in most cases, you can call get_registered_ip immediately and it will work. The 5 minutes I tested the easy way. On my ubuntu box I ran nslookup for my own ddns-address against Google's public dns in an endless loop. Then I send out a new ip to my ddns provider via ddns-scripts and wait. The longest time it takes to have a stable answer from nslookup was 4 minutes 10 seconds. Plus reserve = 5 minutes. Also the reason why check_interval minimum is set to 5 minutes = 300 seconds in line 176 of dynamic_dns_updater.sh. I understand that the latency through Google public dns is 5 minutes, but not everyone uses Google public dns, and your test is not representative of queries for cache-cold records. I tried adding a new record to my domain to see what happens on a query that is not already in the cache. This is the same case as updating an existing DDNS entry that hasn't been accessed in a long time. The record was immediately (15 seconds, while I typed the commands) available in my DNS provider's server, my ISP's server, and 8.8.8.8. The intermediate servers didn't even know if the record exists, so they had to contact the authoritative server. Probably if I update the IP now, it will take a long time to propagate, but this is not a common case for me. What I want is that if I get a new IP/router crashes/power outage, for my IP to be updated in the authoritative DNS server as soon as possible. It is rare that I access my DDNS just before this (crash/power outage/etc.) happens, so the record will not be cached, so if I access it now, I will see the fresh IP in any DNS server. In this case the sleep 10 is the limiting factor. I think probably this is the case for most DDNS users - they probably access their records very rarely, so they are not cached, so sleep 10 is the biggest factor to how quickly their new address is visible. But I can't speak definitively about any but my case. Perhaps the sleep could be a configuration option which defaults to 0. Specific users can set it if they need it. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox 2/2] usock: set socket flags right after creating it
Otherwise some flags like USOCK_NONBLOCK wouldn't work as expected
(O_NONBLOCK affects connect behavior).
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
usock.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/usock.c b/usock.c
index 39909c1..7bde620 100644
--- a/usock.c
+++ b/usock.c
@@ -38,7 +38,7 @@ static void usock_set_flags(int sock, unsigned int type)
fcntl(sock, F_SETFL, fcntl(sock, F_GETFL) | O_NONBLOCK);
}
-static int usock_connect(struct sockaddr *sa, int sa_len, int family, int
socktype, bool server)
+static int usock_connect(int type, struct sockaddr *sa, int sa_len, int
family, int socktype, bool server)
{
int sock;
@@ -46,6 +46,8 @@ static int usock_connect(struct sockaddr *sa, int sa_len, int
family, int sockty
if (sock 0)
return -1;
+ usock_set_flags(sock, type);
+
if (server) {
const int one = 1;
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, one, sizeof(one));
@@ -62,7 +64,7 @@ static int usock_connect(struct sockaddr *sa, int sa_len, int
family, int sockty
return -1;
}
-static int usock_unix(const char *host, int socktype, bool server)
+static int usock_unix(int type, const char *host, int socktype, bool server)
{
struct sockaddr_un sun = {.sun_family = AF_UNIX};
@@ -72,7 +74,7 @@ static int usock_unix(const char *host, int socktype, bool
server)
}
strcpy(sun.sun_path, host);
- return usock_connect((struct sockaddr*)sun, sizeof(sun), AF_UNIX,
socktype, server);
+ return usock_connect(type, (struct sockaddr*)sun, sizeof(sun),
AF_UNIX, socktype, server);
}
static int usock_inet(int type, const char *host, const char *service, int
socktype, bool server)
@@ -92,7 +94,7 @@ static int usock_inet(int type, const char *host, const char
*service, int sockt
return -1;
for (rp = result; rp != NULL; rp = rp-ai_next) {
- sock = usock_connect(rp-ai_addr, rp-ai_addrlen,
rp-ai_family, socktype, server);
+ sock = usock_connect(type, rp-ai_addr, rp-ai_addrlen,
rp-ai_family, socktype, server);
if (sock = 0)
break;
}
@@ -107,14 +109,13 @@ int usock(int type, const char *host, const char
*service) {
int sock;
if (type USOCK_UNIX)
- sock = usock_unix(host, socktype, server);
+ sock = usock_unix(type, host, socktype, server);
else
sock = usock_inet(type, host, service, socktype, server);
if (sock 0)
return -1;
- usock_set_flags(sock, type);
return sock;
}
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox 1/2] usock: add helper waiting for socket to be ready
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
usock.c | 30 ++
usock.h | 11 +++
2 files changed, 41 insertions(+)
diff --git a/usock.c b/usock.c
index 04ed4ee..39909c1 100644
--- a/usock.c
+++ b/usock.c
@@ -117,3 +117,33 @@ int usock(int type, const char *host, const char *service)
{
usock_set_flags(sock, type);
return sock;
}
+
+int usock_wait_ready(int fd, int msecs) {
+ fd_set fds;
+ struct timeval tv;
+ int res;
+
+ FD_ZERO(fds);
+ FD_SET(fd, fds);
+
+ tv.tv_sec = msecs / 1000;
+ tv.tv_usec = (msecs % 1000) * 1000;
+
+ res = select(fd + 1, NULL, fds, NULL, tv);
+ if (res 0) {
+ return errno;
+ } else if (res == 0) {
+ return -ETIMEDOUT;
+ } else {
+ int err = 0;
+ socklen_t optlen = sizeof(err);
+
+ res = getsockopt(fd, SOL_SOCKET, SO_ERROR, err, optlen);
+ if (res)
+ return errno;
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
diff --git a/usock.h b/usock.h
index 8f30add..c97fc40 100644
--- a/usock.h
+++ b/usock.h
@@ -32,4 +32,15 @@
int usock(int type, const char *host, const char *service);
+/**
+ * Wait for a socket to become ready.
+ *
+ * This may be useful for users of USOCK_NONBLOCK to wait (with a timeout)
+ * for a socket.
+ *
+ * @param fd file descriptor of socket
+ * @param msecs timeout in microseconds
+ */
+int usock_wait_ready(int fd, int msecs);
+
#endif /* USOCK_H_ */
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH libubox 1/2] usock: add helper waiting for socket to be ready
On 2015-01-15 12:42, Rafał Miłecki wrote:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
usock.c | 30 ++
usock.h | 11 +++
2 files changed, 41 insertions(+)
diff --git a/usock.c b/usock.c
index 04ed4ee..39909c1 100644
--- a/usock.c
+++ b/usock.c
@@ -117,3 +117,33 @@ int usock(int type, const char *host, const char
*service) {
usock_set_flags(sock, type);
return sock;
}
+
+int usock_wait_ready(int fd, int msecs) {
+ fd_set fds;
+ struct timeval tv;
+ int res;
+
+ FD_ZERO(fds);
+ FD_SET(fd, fds);
+
+ tv.tv_sec = msecs / 1000;
+ tv.tv_usec = (msecs % 1000) * 1000;
+
+ res = select(fd + 1, NULL, fds, NULL, tv);
Wouldn't it be better to use poll() here? The fd bitmask crap that
select uses is quite ugly.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V2 libubox 1/2] usock: add helper waiting for socket to be ready
On 2015-01-15 12:59, Rafał Miłecki wrote: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- V2: Use poll instead of select Both applied, thanks. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V2 libubox 1/2] usock: add helper waiting for socket to be ready
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
V2: Use poll instead of select
---
usock.c | 27 +++
usock.h | 11 +++
2 files changed, 38 insertions(+)
diff --git a/usock.c b/usock.c
index 04ed4ee..5bdd3ff 100644
--- a/usock.c
+++ b/usock.c
@@ -20,6 +20,7 @@
#include sys/socket.h
#include sys/un.h
#include netdb.h
+#include poll.h
#include stdlib.h
#include unistd.h
#include fcntl.h
@@ -117,3 +118,29 @@ int usock(int type, const char *host, const char *service)
{
usock_set_flags(sock, type);
return sock;
}
+
+int usock_wait_ready(int fd, int msecs) {
+ struct pollfd fds[1];
+ int res;
+
+ fds[0].fd = fd;
+ fds[0].events = POLLOUT;
+
+ res = poll(fds, 1, msecs);
+ if (res 0) {
+ return errno;
+ } else if (res == 0) {
+ return -ETIMEDOUT;
+ } else {
+ int err = 0;
+ socklen_t optlen = sizeof(err);
+
+ res = getsockopt(fd, SOL_SOCKET, SO_ERROR, err, optlen);
+ if (res)
+ return errno;
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
diff --git a/usock.h b/usock.h
index 8f30add..c97fc40 100644
--- a/usock.h
+++ b/usock.h
@@ -32,4 +32,15 @@
int usock(int type, const char *host, const char *service);
+/**
+ * Wait for a socket to become ready.
+ *
+ * This may be useful for users of USOCK_NONBLOCK to wait (with a timeout)
+ * for a socket.
+ *
+ * @param fd file descriptor of socket
+ * @param msecs timeout in microseconds
+ */
+int usock_wait_ready(int fd, int msecs);
+
#endif /* USOCK_H_ */
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH uclient] http: wait for socket to be ready before using it
On 2015-01-15 12:50, Rafał Miłecki wrote: This is required as we use USOCK_NONBLOCK. Are you sure? Theoretically, ustream should already handle it properly. The first write fails if the socket is not connected yet, so ustream will buffer the data and send it out again once epoll tells it that the fd is writable. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH uclient] http: wait for socket to be ready before using it
This is required as we use USOCK_NONBLOCK.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
uclient-http.c | 5 +
uclient.h | 2 ++
2 files changed, 7 insertions(+)
diff --git a/uclient-http.c b/uclient-http.c
index c25e52f..82bef8a 100644
--- a/uclient-http.c
+++ b/uclient-http.c
@@ -108,6 +108,7 @@ static int uclient_do_connect(struct uclient_http *uh,
const char *port)
{
socklen_t sl;
int fd;
+ int err;
if (uh-uc.url-port)
port = uh-uc.url-port;
@@ -116,6 +117,10 @@ static int uclient_do_connect(struct uclient_http *uh,
const char *port)
if (fd 0)
return -1;
+ err = usock_wait_ready(fd, UCLIENT_DEFAULT_CONNECTION_TIMEOUT_MS);
+ if (err)
+ return err;
+
ustream_fd_init(uh-ufd, fd);
memset(uh-uc.local_addr, 0, sizeof(uh-uc.local_addr));
diff --git a/uclient.h b/uclient.h
index d5a0d5b..d90b00a 100644
--- a/uclient.h
+++ b/uclient.h
@@ -24,6 +24,8 @@
#include libubox/ustream.h
#include libubox/ustream-ssl.h
+#define UCLIENT_DEFAULT_CONNECTION_TIMEOUT_MS 3
+
struct uclient_cb;
struct uclient_backend;
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Hardlock in ath9k
On 2015-01-15 12:48, Gianluca Anzolin wrote: Il 15/01/2015 04:25, Felix Fietkau ha scritto: On 2015-01-14 20:19, Gianluca Anzolin wrote: Hi, I was just testing this evening, just for fun, a new build with the just released musl libc (1.1.6) on my new router (Archer C7) but unfortunately it bricked my router. Initially I feared that I did something wrong when updating the libc but this turned out not to be the case. With the help of a serial cable I noticed that the router freezed when trying to bring up the wireless interface (in the NG band). I skimmed through the commits and reverted the last ath9k commit: git-svn-id: svn://svn.openwrt.org/openwrt/trunk@43971 3c298f89-4303-0410-b956-a3cf2f4a3e73 I rebuilt the image and the router worked. I haven't had the time to look at the actual commit yet, I just wanted to let you know. Please try applying http://nbd.name/ath79-irq-disable.patch to your kernel tree and see if it fixes the issue. - Felix I still get freezes when bringing up the wifi interface even with that patch applied I just finished debugging this and I'm going to commit fixes very soon. Turns out it was a rather nasty cascade of bugs. My patch would have fixed the bug of being unable to disable the WMAC/PCI interrupts, however disable_irq() on MIPS CPU irqs is completely broken as well (and has been for many years). This led to some nasty IRQ storms. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH uclient] http: wait for socket to be ready before using it
On 15 January 2015 at 13:17, Felix Fietkau n...@openwrt.org wrote: On 2015-01-15 12:50, Rafał Miłecki wrote: This is required as we use USOCK_NONBLOCK. Are you sure? Theoretically, ustream should already handle it properly. The first write fails if the socket is not connected yet, so ustream will buffer the data and send it out again once epoll tells it that the fd is writable. Maybe we were just thinking about different issues? See two of mine below: 1) time ./uclient-fetch http://192.168.0.1/ Downloading 'http://192.168.0.1/' Connecting to Unknown:32533 HTTP error 401 real0m0.008s (this Unknown:32533 should be IP + port) 2) time ./uclient-fetch http://192.168.1.15/ Downloading 'http://192.168.1.15/' Connecting to Unknown:32656 real2m7.191s (so it finally silently quits, but it takes 2 minutes, more than one could want to wait) -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: add references to openwrt alternative button handling
From: Karl Palsson ka...@remake.is Add documentation that makes it easier to find the alternative, recommended, and default handling for buttons in OpenWrt. Signed-off-by: Karl Palsson ka...@tweak.net.au --- I was having a hard time discovering buttons, and getting conflicts after enabling the input-gpio-keys* modules. zajec on IRC suggested I could submit patches to improve the docs and hopefully help with discovering gpio-button-hotplug. package/kernel/linux/modules/input.mk | 6 ++ 1 file changed, 6 insertions(+) diff --git a/package/kernel/linux/modules/input.mk b/package/kernel/linux/modules/input.mk index 32adc1e..f42cbae 100644 --- a/package/kernel/linux/modules/input.mk +++ b/package/kernel/linux/modules/input.mk @@ -82,6 +82,9 @@ endef define KernelPackage/input-gpio-keys/description This driver implements support for buttons connected to GPIO pins of various CPUs (and some other chips). + + See also gpio-button-hotplug which is an alternative, lower overhead + implementation that generates uevents instead of kernel input events. endef $(eval $(call KernelPackage,input-gpio-keys)) @@ -101,6 +104,9 @@ endef define KernelPackage/input-gpio-keys-polled/description Kernel module for support polled GPIO keys input device + + See also gpio-button-hotplug which is an alternative, lower overhead + implementation that generates uevents instead of kernel input events. endef $(eval $(call KernelPackage,input-gpio-keys-polled)) -- 1.8.3.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
