Re: [OpenWrt-Devel] $5 OpenWRT Device on Kickstarter

2016-08-05 Thread Jeff Baitis
Awesome. I wish someone would do an 802.11A version.
Thanks, Boken.

On Fri, Aug 5, 2016 at 4:41 PM, Marc Juul  wrote:

>
>
> On Fri, Aug 5, 2016 at 2:26 PM, Boken Lin  wrote:
>
>> Hi all,
>>
>> We have recently launched a Kickstarter campaign for a low cost OpenWRT
>> development board based on MT7688. The board is available starting at just
>> $5.
>>
>> If you are interested, please check out our campaign here:
>> http://kck.st/2aet59m
>
>
> How do I order more than one?
>
> --
> marc/juul
>
> ___
> 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] $5 OpenWRT Device on Kickstarter

2016-08-05 Thread Boken Lin
Hi all,

We have recently launched a Kickstarter campaign for a low cost OpenWRT 
development board based on MT7688. The board is available starting at just $5. 

If you are interested, please check out our campaign here: http://kck.st/2aet59m

Thanks!
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


[OpenWrt-Devel] [PATCH] regmap: Fix debugfs for write-only devices

2016-08-05 Thread Cody Harris
In its current implementation, regmap's debugfs interface fails to
correctly print out register values for write-only devices.

The implementation of regmap's debugfs interface doesn't facilitate dumping
out register values for write-only devices because it requires readability
in the sense that the register exists in a map and can be read over the
bus.  Write-only devices fail this criteria despite regmap holding cached
values of the register contents.

Executing 'cat /sys/kernel/debug/regmap//registers' against a
write-only device results in a WARN_ON in dmesg and nothing printed to
stdout.

My patch makes the following changes: in addition to checking if the
register is unreadable, it must also be uncached by regmap in order to be
skipped. In other words, write-only devices should have their cached
register values (if they exist) printed out the same as read-write devices.
Checks for cached values are added in several places where regmap-debugfs.c
checks for the existence of a register.

I originally wrote this patch for 15.05/kernel 3.18 which supports the
LinkIt7688 and its breakout board. Though there isn't LinkIt support for
4.4 in trunk yet, I managed to cobble enough together to test this change.

Signed-off-by: Cody Harris 
---

--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -105,8 +105,9 @@ static unsigned int regmap_debugfs_get_d
if (list_empty(>debugfs_off_cache)) {
for (; i <= map->max_register; i += map->reg_stride) {
/* Skip unprinted registers, closing off cache entry */
-   if (!regmap_readable(map, i) ||
-   regmap_precious(map, i)) {
+   if ((regcache_lookup_reg(map, i) < 0
+   && !regmap_readable(map, i)) ||
+   regmap_precious(map, i)) {
if (c) {
c->max = p - 1;
c->max_reg = i - map->reg_stride;
@@ -204,7 +205,7 @@ static ssize_t regmap_read_debugfs(struc
start_reg = regmap_debugfs_get_dump_start(map, from, *ppos, );

for (i = start_reg; i <= to; i += map->reg_stride) {
-   if (!regmap_readable(map, i))
+   if (!regmap_readable(map, i) && regcache_lookup_reg(map, i) < 0)
continue;

if (regmap_precious(map, i))
@@ -592,7 +593,8 @@ void regmap_debugfs_init(struct regmap *
debugfs_create_file("range", 0400, map->debugfs,
map, _reg_ranges_fops);

-   if (map->max_register || regmap_readable(map, 0)) {
+   if (map->max_register || regmap_readable(map, 0)
+   || regcache_lookup_reg(map, 0) > 0) {
umode_t registers_mode;

 #if defined(REGMAP_ALLOW_WRITE_DEBUGFS)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] [LEDE-DEV] latency on PPPoA ADSL Annex A on using Lantiq

2016-08-05 Thread Kevin Darbyshire-Bryant
I can confirm this.  Have seen it myself on a DGN3500, reported at least
a month ago.  Router terminated traffic is slow, routed traffic to/from
internal lan is fine.  It's not bufferbloat.

On 04/08/16 16:20, Daniel Niasoff wrote:
> One more thing I forgot to mention is that router traffic is fine so if I 
> dnat to a host on the internal lan, performance is good.
> 
> So if it was bufferbloat it would affect all hosts
> 
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On 
> Behalf Of Daniel Niasoff
> Sent: 04 August 2016 20:29
> To: Rich Brown 
> Cc: lede-...@lists.infradead.org; openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [LEDE-DEV] latency on PPPoA ADSL Annex A on 
> using Lantiq
> 
> Hi Rich,
> 
> There is no traffic occurring when the latency is happening.
> 
> Also icmp requests do not have any latency and are consistently returning 
> with minimal latency.
> 
> It's only occurring in apps such as a ssh server. So whilst I was pinging and 
> getting good results, I ssh'd into the router and it was really sluggish, eg 
> to scroll down a 200 line file in vi is a nightmare.
> 
> So I guess this isn't bufferbloat?
> 
> Thanks
> 
> Daniel
> 
> -Original Message-
> From: Rich Brown [mailto:richb.hano...@gmail.com]
> Sent: 04 August 2016 20:20
> To: Daniel Niasoff 
> Cc: Donald Chisholm ; 
> lede-...@lists.infradead.org; openwrt-devel@lists.openwrt.org
> Subject: Re: [LEDE-DEV] [OpenWrt-Devel] latency on PPPoA ADSL Annex A on 
> using Lantiq
> 
> Hi Daniel,
> 
> (I feel like a one-trick pony here, but...) Could this be bufferbloat? Maybe 
> not, but here's how to test:
> 
> Use the procedure for "A Quick Test for Bufferbloat" at 
> https://www.bufferbloat.net/projects/cerowrt/wiki/Tests_for_Bufferbloat/#a-quick-test-for-bufferbloat
>  Watch to see if the ping times increase during download/uploads then drop 
> back down.
> 
> If the ping times do increase, consider installing luci-app-sqm as suggested 
> on 
> https://www.bufferbloat.net/projects/cerowrt/wiki/What_to_do_about_Bufferbloat/
> 
> Best regards,
> 
> Rich
> 
> 
>> On Aug 4, 2016, at 3:10 PM, Daniel Niasoff  wrote:
>>
>> Hi Donald,
>>
>> Thanks for responding
>>
>> The MTU seems fine.
>>
>> This is the WAN link
>>
>> pppoa-wan Link encap:Point-to-Point Protocol
>>  inet addr:2.25.173.155  P-t-P:172.16.11.136  Mask:255.255.255.255
>>  UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
>>  RX packets:94409 errors:0 dropped:0 overruns:0 frame:0
>>  TX packets:85742 errors:0 dropped:0 overruns:0 carrier:0
>>  collisions:0 txqueuelen:3
>>  RX bytes:75750172 (72.2 MiB)  TX bytes:14369708 (13.7 MiB)
>>
>> I sent a 1492 byte icmp request externally which got through.
>>
>> root@ubuntu:~# ping -s 1464 2.25.173.155 PING 2.25.173.155
>> (2.25.173.155) 1464(1492) bytes of data.
>> 1472 bytes from 2.25.173.155: icmp_seq=1 ttl=57 time=49.4 ms ^C
>> --- 2.25.173.155 ping statistics ---
>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt 
>> min/avg/max/mdev = 49.439/49.439/49.439/0.000 ms
>>
>> So MTU looks fine.
>>
>> Thanks
>>
>> Daniel
>>
>> From: Donald Chisholm [mailto:donald.chish...@gmail.com]
>> Sent: 04 August 2016 19:41
>> To: Daniel Niasoff 
>> Subject: Re: [OpenWrt-Devel] latency on PPPoA ADSL Annex A on using 
>> Lantiq
>>
>> Hi Daniel,
>>
>> I just saw your message on the LEDE mailing list.  The freezing and catching 
>> up sounds like a MTU problem.  Could there be a MTU mismatch on the ADSL 
>> interface (1500 <->1492)?
>>
>> Donald
>>
>> On Thu, Aug 4, 2016 at 6:47 AM, Daniel Niasoff 
>>  wrote:
>> Hi,
>>
>> I am quite desperate because I have a project going with these routers and I 
>> am running really late.
>>
>> Can anyone spare some time to help me, I am willing to pay an hourly rate 
>> for the time if it will help.
>>
>> This issue only occurs on ADSL. On VDSL performance is really good even 
>> using PPPoE.
>>
>> The issue is a sluggish access to the CPU interface via ADSL, so for example 
>> if you are typing in a SSH client, it will keep freezing for a second or 
>> two, than catch up.
>>
>> Routed traffic is fine.
>>
>> Thanks
>>
>> Daniel
>>
>> -Original Message-
>> From: Martin Blumenstingl
>> [mailto:mailto:martin.blumensti...@googlemail.com]
>> Sent: 03 August 2016 08:03
>> To: Alexander Couzens 
>> Cc: Daniel Niasoff ; 
>> mailto:openwrt-devel@lists.openwrt.org;
>> mailto:lede-...@lists.infradead.org; mailto:ha...@hauke-m.de; 
>> mailto:j...@phrozen.org
>> Subject: Re: [OpenWrt-Devel] latency on PPPoA ADSL Annex A on using 
>> Lantiq
>>
>> On Tue, Aug 2, 2016 at 6:10 PM, Alexander Couzens  
>> wrote:
>>> On Tue, 2 Aug 2016 13:38:55 +
>>> 

Re: [OpenWrt-Devel] [OpenWrt] Upstreaming related doubt

2016-08-05 Thread Felix Fietkau
On 2016-08-05 11:41, Abhijit Mahajani wrote:
> Hello All,
> 
>  
> 
> We have added Creator Ci40 into OpenWrt and its available at
> https://github.com/CreatorDev/openwrt. We want to upstream our port to
> the openwrt community. However currently we have based on 4.1 kernel..
> 
> I understand OpenWrt is with 4.4.14 right now, so If I want to create a
> pull request for upstreaming Ci40 port, then do I need to first move to
> 4.4 or pull request with 4.1 is also fine?
Please move to 4.4 first.

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


[OpenWrt-Devel] Upstreaming related doubt

2016-08-05 Thread Abhijit Mahajani
Hello All,

We have added Creator Ci40 into OpenWrt and its available at 
https://github.com/CreatorDev/openwrt. We want to upstream our port to the 
openwrt community. However currently we have based on 4.1 kernel..
I understand OpenWrt is with 4.4.14 right now, so If I want to create a pull 
request for upstreaming Ci40 port, then do I need to first move to 4.4 or pull 
request with 4.1 is also fine?

Thanks and Regards,
Abhijit A. Mahajani

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