[OpenWrt-Devel] [PATCH v4 1/2] Add ubnt_hsr platform flag and enable for UniFi Outdoor Plus

[Tim ODriscoll]

On Tue Jun 16 23:16:46 CEST 2015, Stefan Rompf wrote:

Add tuner for the HSR filter of the UniFi Outdoor Plus access point. Usage
of the tuner is controlled at runtime by ath9k_platform_data. The code can
be enabled or disabled by a compile time option.


Dear All,

How do I tell if the above mentioned patch has been applied to the  
squashfs images available on downloads.openwrt.org? I don't see it  
mentioned in the most recent changelog..


When is it likely this patch will be applied to those squashfs images?

Many thanks,

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

[OpenWrt-Devel] Q: procd / respawn if process dies

[Bastian Bittorf]

while trying to understand the procd
respawn-trigger, I wrote this testscript:

#!/bin/sh /etc/rc.common
START=50
USE_PROCD=1
PROG=/tmp/test.sh

start_service()
{
{
echo '#!/bin/sh'
echo 'logger START-$0 $$'
echo 'sleep 10'
echo 'logger READY-$0 $$'
} >$PROG
chmod +x $PROG

procd_set_param respawn ${threshold:-20} ${timeout:-5} ${retry:-3}
procd_open_instance
procd_set_param command "$PROG"
procd_close_instance
}

The script starts and ends, i can see it in syslog, but
it is not automatically restarted. Changing the exitcode
to != 0 does not change this and kill -9 $$ also does not
trigger a restart. What i'am doing wrong? when reading
https://wiki.openwrt.org/inbox/procd-init-scripts
it should work this way.

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

Re: [OpenWrt-Devel] Q: procd / respawn if process dies

[Bastian Bittorf]

* Yousong Zhou  [08.12.2015 15:59]:
> respawn is an instance attribute, moving that statement inside the
> open/close instance block should do the job

thanks for the hint, this works!

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

Re: [OpenWrt-Devel] Q: procd / respawn if process dies

[Yousong Zhou]

Am 08.12.2015 22:45 schrieb "Bastian Bittorf" :
>
> while trying to understand the procd
> respawn-trigger, I wrote this testscript:
>
> #!/bin/sh /etc/rc.common
> START=50
> USE_PROCD=1
> PROG=/tmp/test.sh
>
> start_service()
> {
> {
> echo '#!/bin/sh'
> echo 'logger START-$0 $$'
> echo 'sleep 10'
> echo 'logger READY-$0 $$'
> } >$PROG
> chmod +x $PROG
>
> procd_set_param respawn ${threshold:-20} ${timeout:-5} ${retry:-3}
> procd_open_instance
> procd_set_param command "$PROG"
> procd_close_instance

respawn is an instance attribute, moving that statement inside the
open/close instance block should do the job

 yousong

> }
>
> The script starts and ends, i can see it in syslog, but
> it is not automatically restarted. Changing the exitcode
> to != 0 does not change this and kill -9 $$ also does not
> trigger a restart. What i'am doing wrong? when reading
> https://wiki.openwrt.org/inbox/procd-init-scripts
> it should work this way.
>
> bye, bastian
> ___
> 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] [OpenWrt] openwrt build system costs: support of or foundation over?

[Dave Taht]

On Mon, Dec 7, 2015 at 8:26 PM, Eric Schultz
 wrote:
> Dave,
>
> Thanks for bringing this up. Based upon my conversations at the OpenWrt
> summit and observations, an official OpenWrt Foundation would be a positive
> development. I heard at least a few companies say that they want to help but
> they don't even know who to pay in some cases.

I was figuring that nobody knows who to pay in most cases!

This was why my thinking was more towards having a broker-like
arrangement for various things. We put up a spreadsheet of existing
costs. it's pretty easy to defend expanding the build cluster
system(s) to some point of diminishing return, and merely getting that
tiny amount done - with X number of companies contributing to it -
would be a start. Everybody can then point proudly at everything more
often lit up green at:

http://buildbot.openwrt.org:8010/grid

on their "what I'm doing for open source" promo material - and revel
in a personal or product build that works the first time more often -
and everybody's happy.

Having a set of goals clearly expressed by all sides on this, and
other matters, openly, would be a start.

What is happening instead: companies that should be investing a little
in basic infrastructure, into basic tools, and - building quality,
responsiveness, and good software engineering methods into everything
they use...

instead get focused on features that they want, that's "missing", and
the quality of the rest of the system is hit or miss.

I was struck a few days back looking at:

http://rdkcentral.com/about-rdk/

when 99.99% of the code, and quality, needs to be delivered in the
linux portion of the stack, which is otherwise represented as this
tiny, "obviously working" slice of the chart. They are still running
Linux 2.6 over there last I looked

progress and quality does not happen automagically. There has always
been a disconnect between engineers building better software, and
companies shipping products, and it would be nice to find more ways to
communicate across and close the gaps.

This is one of my all time favorite satires of the problems all sides
face in delivering good products:

https://www.youtube.com/watch?v=KowAEqHpftI

> There's lots of reasons why
> this has been the case but, in the end, more clarity in governance and
> process would go a long way to help here. I'm happy to personally help but
> the committers are really the ones who have to drive this.

And they are pretty busy and tend to disagree a lot. :) Which was part
of openwrt's strength during the Great recession - they couldn't be
bought and folded up like embedded alley and montavista were.

Something - whatever that thing is - needs to be democratic, neutral,
and trusted. Perhaps writing down everybody wishlist of needs would be
a start...

> On a related topic, prpl is contracting with me to facilitate and help build
> a distributed test platform for OpenWrt. The goal is somewhat similar in
> design to Kernel CI but handles testing of upstream nightlies on devices as
> well as boot. I'd like to have you involved and I'll be sending out the
> participation information soon for next week's  kickoff meeting. Obviously,
> that platform will require regularly built images so if those don't exist
> then we would have to address that.

Good. We need more and better testbeds, and I certainly agree that
getting to where stuff could be flashed, abused, and tested on a
regular basis would be great. I really hate it when I flash a brick.

testbed note here:

Over in make-wifi-fast land at kau.se we finally are doing testing of
the cake algorithms on a realistic testbed that can simulate long rtts
to 105mbit. It took 6 months to get to this point

And we are starting to boot up the ath9k based x86 testbed where we
hope to at least get to gbit, on the budget we had. It would be nice
to actually drive the testbed with 10GigE so as to get to at least
1.5Gbit (802.11ac) but oy, we costed that out and we're not going to
be able to do it.

So if there is a way for bufferbloat.net, my (or other interested unis
or orgs)  to apply to prpl for a grant to support the make-wifi-fast
project, it would be nice. prpl does not seem to have a public grant
process

> I personally didn't realize there were
> significant funding issues with the build infrastructure;

I see a few more servers have come online since last I checked.

Define "significant"? 220/mo is 1/10th my current base salary after tax.

> I know prpl in the
> past has offered to pay for the OpenWrt hosted build server but that offer
> wasn't accepted.

Oy. Nobody asked me... I'll send the last year's - or this month's,
worth of build cluster invoices - to anyone willing to foot the bill.

A more general question to ask is: to just, like, ask the list(s), is:
"my foundation has $XX,000/yr to contribute to making openwrt better.
how would y'all like to spend it? ".

"We also have one time grants available for X and Y amounts 

[OpenWrt-Devel] Fwd: [homenet] Protocol Action: 'Home Networking Control Protocol' to Proposed Standard (draft-ietf-homenet-hncp-10.txt)

[Dave Taht]

While I'm dreaming of steadier funding for things I care about,
ietf homenet wg's work is nearly complete.

*most* of the work is already done in openwrt to make all the ietf
homenet proposed standards work, and indeed, be the default in
openwrt. However nobody is funded anymore to take it further, and it
would be nice to see builds taking place and tested automagically - to
finally bring the dream of always interoperable, ipv6 capable cpe and
home routers, plugged in, every which way - a reality.

There are still many details left to make it happen well and be a
truly usable set of interoperable standards - I have a huge list of
things still not encapsulated or negotiated right within the hncp
stack, such as wifi channel selection and uplink bandwidth, and babel
is in need of some love, there are some state machine bugs that need
squashing.

-- Forwarded message --
From: The IESG 
Date: Tue, Dec 8, 2015 at 3:09 PM
Subject: [homenet] Protocol Action: 'Home Networking Control Protocol'
to Proposed Standard (draft-ietf-homenet-hncp-10.txt)
To: IETF-Announce 
Cc: homenet-cha...@ietf.org, m...@townsley.net,
draft-ietf-homenet-h...@ietf.org, The IESG ,
home...@ietf.org, terry.mander...@icann.org, rfc-edi...@rfc-editor.org


The IESG has approved the following document:
- 'Home Networking Control Protocol'
  (draft-ietf-homenet-hncp-10.txt) as Proposed Standard

This document is the product of the Home Networking Working Group.

The IESG contact persons are Brian Haberman and Terry Manderson.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/





Technical Summary

This document describes the Home Networking Control Protocol (HNCP),
an extensible distributed configuration protocol for “unmanaged”
(e.g., functions that are not configured manually or by a central
management server of some kind) home network devices. The intent is to
provide a distributed protocol for flooding of basic configuration
state essential to IP network functionality.

HNCP is described as a profile of and extension to the Distributed
Node Consensus Protocol (DNCP).  HNCP enables discovery of network
topology and borders, automated configuration of addresses (using the
algorithm defined in draft-ietf-homenet-prefix-assignment-08), name
resolution, and service discovery.

Working Group Summary

The earliest roots of HNCP are in draft-acee-ospf-ospfv3-autoconfig-00
(Oct 2011) which was eventually published as Standards Track RFC 7503,
 with the expectation that other documents would define
HOMENET-specific TLVs to be carried inside OSPFv3.

Strong resistance from the WG (as well as open source router software
developers) to this tight coupling between a specific routing protocol
and network configuration led to the split of HNCP as a standalone
protocol first defined in draft-stenberg-homenet-hncp-00.

Later, DNCP (generic aspects of HNCP concerning synchronization of
state among a set of nodes using Trickle[RFC6206]) were split from the
main HNCP document to allow for modularity and potential reuse. After
this final split, the HNCP document describes the HOMENET-specific
TLVs and the DNCP profile used to synchronize them across the home
network.

Document Quality

  Are there existing implementations of the protocol?

The reference “hnetd” implementation is at
https://github.com/sbyx/hnetd/ (project homepage at
http://www.homewrt.org/doku.php).

There is a second (fully independent and interoperable) implementation
available at https://github.com/jech/shncpd developed entirely from
the specification documents without referal to the reference
implementation.

There is a partial third implementation, though not fully independent,
available here: https://github.com/fingon/pysyma


  Have a significant number of vendors indicated their plan to
  implement the specification?


The reference implementation has been a part of routing feed of
OpenWrt since Barrier Breaker (14.07) release in July, 2014.

Google Nest, Comcast Xfinity, D-Link, Freebox, Technicolor, and Cisco
have all expressed interest in implementing and/or shipping HNCP. HNCP
is referenced in version 1.0 of the Thread Specification (Nest,
Samsung, etc.)

“Homenet” running either the early OSPF version and later HNCP (with
DNCP) has been demonstrated publicly at 9 IETF BnB events (every BnB
since BnB began, plus at least one “pre BnB” event), HNCP split off
from OSPF has been demontrated at the last 5 IETF BnB events. In
addition to IETF, Homenet Implementations have been presented at:

3 IPv6 World Congress events in Paris
1 CES Event in Las Vegas
1 Cablelabs Meeting in Denver, Co

Are there any reviewers that merit special mention as having done a
thorough review,  e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course

Re: [OpenWrt-Devel] Fwd: [homenet] Protocol Action: 'Home Networking Control Protocol' to Proposed Standard (draft-ietf-homenet-hncp-10.txt)

[L. D. Pinney]

Why has this been cross posted to the OpenWrt *Development* List?

I fail to see any relevance to the usual and prevailing use of this list.

On Tue, Dec 8, 2015 at 10:52 AM, Dave Taht  wrote:

> While I'm dreaming of steadier funding for things I care about,
> ietf homenet wg's work is nearly complete.
>
> *most* of the work is already done in openwrt to make all the ietf
> homenet proposed standards work, and indeed, be the default in
> openwrt. However nobody is funded anymore to take it further, and it
> would be nice to see builds taking place and tested automagically - to
> finally bring the dream of always interoperable, ipv6 capable cpe and
> home routers, plugged in, every which way - a reality.
>
> There are still many details left to make it happen well and be a
> truly usable set of interoperable standards - I have a huge list of
> things still not encapsulated or negotiated right within the hncp
> stack, such as wifi channel selection and uplink bandwidth, and babel
> is in need of some love, there are some state machine bugs that need
> squashing.
>
> -- Forwarded message --
> From: The IESG 
> Date: Tue, Dec 8, 2015 at 3:09 PM
> Subject: [homenet] Protocol Action: 'Home Networking Control Protocol'
> to Proposed Standard (draft-ietf-homenet-hncp-10.txt)
> To: IETF-Announce 
> Cc: homenet-cha...@ietf.org, m...@townsley.net,
> draft-ietf-homenet-h...@ietf.org, The IESG ,
> home...@ietf.org, terry.mander...@icann.org, rfc-edi...@rfc-editor.org
>
>
> The IESG has approved the following document:
> - 'Home Networking Control Protocol'
>   (draft-ietf-homenet-hncp-10.txt) as Proposed Standard
>
> This document is the product of the Home Networking Working Group.
>
> The IESG contact persons are Brian Haberman and Terry Manderson.
>
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/
>
>
>
>
>
> Technical Summary
>
> This document describes the Home Networking Control Protocol (HNCP),
> an extensible distributed configuration protocol for “unmanaged”
> (e.g., functions that are not configured manually or by a central
> management server of some kind) home network devices. The intent is to
> provide a distributed protocol for flooding of basic configuration
> state essential to IP network functionality.
>
> HNCP is described as a profile of and extension to the Distributed
> Node Consensus Protocol (DNCP).  HNCP enables discovery of network
> topology and borders, automated configuration of addresses (using the
> algorithm defined in draft-ietf-homenet-prefix-assignment-08), name
> resolution, and service discovery.
>
> Working Group Summary
>
> The earliest roots of HNCP are in draft-acee-ospf-ospfv3-autoconfig-00
> (Oct 2011) which was eventually published as Standards Track RFC 7503,
>  with the expectation that other documents would define
> HOMENET-specific TLVs to be carried inside OSPFv3.
>
> Strong resistance from the WG (as well as open source router software
> developers) to this tight coupling between a specific routing protocol
> and network configuration led to the split of HNCP as a standalone
> protocol first defined in draft-stenberg-homenet-hncp-00.
>
> Later, DNCP (generic aspects of HNCP concerning synchronization of
> state among a set of nodes using Trickle[RFC6206]) were split from the
> main HNCP document to allow for modularity and potential reuse. After
> this final split, the HNCP document describes the HOMENET-specific
> TLVs and the DNCP profile used to synchronize them across the home
> network.
>
> Document Quality
>
>   Are there existing implementations of the protocol?
>
> The reference “hnetd” implementation is at
> https://github.com/sbyx/hnetd/ (project homepage at
> http://www.homewrt.org/doku.php).
>
> There is a second (fully independent and interoperable) implementation
> available at https://github.com/jech/shncpd developed entirely from
> the specification documents without referal to the reference
> implementation.
>
> There is a partial third implementation, though not fully independent,
> available here: https://github.com/fingon/pysyma
>
>
>   Have a significant number of vendors indicated their plan to
>   implement the specification?
>
>
> The reference implementation has been a part of routing feed of
> OpenWrt since Barrier Breaker (14.07) release in July, 2014.
>
> Google Nest, Comcast Xfinity, D-Link, Freebox, Technicolor, and Cisco
> have all expressed interest in implementing and/or shipping HNCP. HNCP
> is referenced in version 1.0 of the Thread Specification (Nest,
> Samsung, etc.)
>
> “Homenet” running either the early OSPF version and later HNCP (with
> DNCP) has been demonstrated publicly at 9 IETF BnB events (every BnB
> since BnB began, plus at least one “pre BnB” event), HNCP split off
> from OSPF has been demontrated at the last 5 IETF BnB events. In
> addition to IETF, Homenet 

Re: [OpenWrt-Devel] Fwd: [homenet] Protocol Action: 'Home Networking Control Protocol' to Proposed Standard (draft-ietf-homenet-hncp-10.txt)

[Dave Taht]

On Tue, Dec 8, 2015 at 6:48 PM, L. D. Pinney  wrote:
> Why has this been cross posted to the OpenWrt Development List?
>
> I fail to see any relevance to the usual and prevailing use of this list.

Well, I do keep hoping more folk within openwrt actually try the
hnet-full and babel packages.  and unless someone actually pokes at
the list(s), once in a while, nothing happens. hnet includes a pretty
radical set of changes to how firewalling, ip address assignment and
dns are done...

If there is a better list to poke at, let me know. Sorry to be annoying.

> On Tue, Dec 8, 2015 at 10:52 AM, Dave Taht  wrote:
>>
>> While I'm dreaming of steadier funding for things I care about,
>> ietf homenet wg's work is nearly complete.
>>
>> *most* of the work is already done in openwrt to make all the ietf
>> homenet proposed standards work, and indeed, be the default in
>> openwrt. However nobody is funded anymore to take it further, and it
>> would be nice to see builds taking place and tested automagically - to
>> finally bring the dream of always interoperable, ipv6 capable cpe and
>> home routers, plugged in, every which way - a reality.
>>
>> There are still many details left to make it happen well and be a
>> truly usable set of interoperable standards - I have a huge list of
>> things still not encapsulated or negotiated right within the hncp
>> stack, such as wifi channel selection and uplink bandwidth, and babel
>> is in need of some love, there are some state machine bugs that need
>> squashing.
>>
>> -- Forwarded message --
>> From: The IESG 
>> Date: Tue, Dec 8, 2015 at 3:09 PM
>> Subject: [homenet] Protocol Action: 'Home Networking Control Protocol'
>> to Proposed Standard (draft-ietf-homenet-hncp-10.txt)
>> To: IETF-Announce 
>> Cc: homenet-cha...@ietf.org, m...@townsley.net,
>> draft-ietf-homenet-h...@ietf.org, The IESG ,
>> home...@ietf.org, terry.mander...@icann.org, rfc-edi...@rfc-editor.org
>>
>>
>> The IESG has approved the following document:
>> - 'Home Networking Control Protocol'
>>   (draft-ietf-homenet-hncp-10.txt) as Proposed Standard
>>
>> This document is the product of the Home Networking Working Group.
>>
>> The IESG contact persons are Brian Haberman and Terry Manderson.
>>
>> A URL of this Internet Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-homenet-hncp/
>>
>>
>>
>>
>>
>> Technical Summary
>>
>> This document describes the Home Networking Control Protocol (HNCP),
>> an extensible distributed configuration protocol for “unmanaged”
>> (e.g., functions that are not configured manually or by a central
>> management server of some kind) home network devices. The intent is to
>> provide a distributed protocol for flooding of basic configuration
>> state essential to IP network functionality.
>>
>> HNCP is described as a profile of and extension to the Distributed
>> Node Consensus Protocol (DNCP).  HNCP enables discovery of network
>> topology and borders, automated configuration of addresses (using the
>> algorithm defined in draft-ietf-homenet-prefix-assignment-08), name
>> resolution, and service discovery.
>>
>> Working Group Summary
>>
>> The earliest roots of HNCP are in draft-acee-ospf-ospfv3-autoconfig-00
>> (Oct 2011) which was eventually published as Standards Track RFC 7503,
>>  with the expectation that other documents would define
>> HOMENET-specific TLVs to be carried inside OSPFv3.
>>
>> Strong resistance from the WG (as well as open source router software
>> developers) to this tight coupling between a specific routing protocol
>> and network configuration led to the split of HNCP as a standalone
>> protocol first defined in draft-stenberg-homenet-hncp-00.
>>
>> Later, DNCP (generic aspects of HNCP concerning synchronization of
>> state among a set of nodes using Trickle[RFC6206]) were split from the
>> main HNCP document to allow for modularity and potential reuse. After
>> this final split, the HNCP document describes the HOMENET-specific
>> TLVs and the DNCP profile used to synchronize them across the home
>> network.
>>
>> Document Quality
>>
>>   Are there existing implementations of the protocol?
>>
>> The reference “hnetd” implementation is at
>> https://github.com/sbyx/hnetd/ (project homepage at
>> http://www.homewrt.org/doku.php).
>>
>> There is a second (fully independent and interoperable) implementation
>> available at https://github.com/jech/shncpd developed entirely from
>> the specification documents without referal to the reference
>> implementation.
>>
>> There is a partial third implementation, though not fully independent,
>> available here: https://github.com/fingon/pysyma
>>
>>
>>   Have a significant number of vendors indicated their plan to
>>   implement the specification?
>>
>>
>> The reference implementation has been a part of routing feed of
>> OpenWrt since Barrier Breaker (14.07) release in July, 2014.
>>
>> 

[OpenWrt-Devel] [PATCH] uboot-lantiq: fix build with gcc5

[Mathias Kresin]

Signed-off-by: Mathias Kresin 
---
 .../patches/0045-no_extern_inline.patch| 101 +
 .../uboot-lantiq/patches/0046-no_weak_alias.patch  |  28 ++
 .../patches/0047-add-gcc5-support.patch|  93 +++
 3 files changed, 222 insertions(+)
 create mode 100644 
package/boot/uboot-lantiq/patches/0045-no_extern_inline.patch
 create mode 100644 package/boot/uboot-lantiq/patches/0046-no_weak_alias.patch
 create mode 100644 
package/boot/uboot-lantiq/patches/0047-add-gcc5-support.patch

diff --git a/package/boot/uboot-lantiq/patches/0045-no_extern_inline.patch 
b/package/boot/uboot-lantiq/patches/0045-no_extern_inline.patch
new file mode 100644
index 000..45e8b7d
--- /dev/null
+++ b/package/boot/uboot-lantiq/patches/0045-no_extern_inline.patch
@@ -0,0 +1,101 @@
+From b11c5d1dc29e81326d1215011d19377737082aeb Mon Sep 17 00:00:00 2001
+From: Daniel Schwierzeck 
+Date: Wed, 1 Jul 2015 16:36:43 +0200
+Subject: [PATCH] MIPS: change 'extern inline' to 'static inline'
+
+The kernel changed it a long time ago. Also this is now broken
+on gcc-5.x.
+
+Reported-by: Andy Kennedy 
+Signed-off-by: Daniel Schwierzeck 
+---
+ arch/mips/include/asm/io.h | 12 ++--
+ arch/mips/include/asm/system.h |  6 +++---
+ 2 files changed, 9 insertions(+), 9 deletions(-)
+
+diff --git a/arch/mips/include/asm/io.h b/arch/mips/include/asm/io.h
+index 3fa37f5..a7ab087 100644
+--- a/arch/mips/include/asm/io.h
 b/arch/mips/include/asm/io.h
+@@ -117,7 +117,7 @@ static inline void set_io_port_base(unsigned long base)
+  * Change virtual addresses to physical addresses and vv.
+  * These are trivial on the 1:1 Linux/MIPS mapping
+  */
+-extern inline phys_addr_t virt_to_phys(volatile void * address)
++static inline phys_addr_t virt_to_phys(volatile void * address)
+ {
+ #ifndef CONFIG_64BIT
+   return CPHYSADDR(address);
+@@ -126,7 +126,7 @@ extern inline phys_addr_t virt_to_phys(volatile void * 
address)
+ #endif
+ }
+ 
+-extern inline void * phys_to_virt(unsigned long address)
++static inline void * phys_to_virt(unsigned long address)
+ {
+ #ifndef CONFIG_64BIT
+   return (void *)KSEG0ADDR(address);
+@@ -138,7 +138,7 @@ extern inline void * phys_to_virt(unsigned long address)
+ /*
+  * IO bus memory addresses are also 1:1 with the physical address
+  */
+-extern inline unsigned long virt_to_bus(volatile void * address)
++static inline unsigned long virt_to_bus(volatile void * address)
+ {
+ #ifndef CONFIG_64BIT
+   return CPHYSADDR(address);
+@@ -147,7 +147,7 @@ extern inline unsigned long virt_to_bus(volatile void * 
address)
+ #endif
+ }
+ 
+-extern inline void * bus_to_virt(unsigned long address)
++static inline void * bus_to_virt(unsigned long address)
+ {
+ #ifndef CONFIG_64BIT
+   return (void *)KSEG0ADDR(address);
+@@ -165,12 +165,12 @@ extern unsigned long isa_slot_offset;
+ extern void * __ioremap(unsigned long offset, unsigned long size, unsigned 
long flags);
+ 
+ #if 0
+-extern inline void *ioremap(unsigned long offset, unsigned long size)
++static inline void *ioremap(unsigned long offset, unsigned long size)
+ {
+   return __ioremap(offset, size, _CACHE_UNCACHED);
+ }
+ 
+-extern inline void *ioremap_nocache(unsigned long offset, unsigned long size)
++static inline void *ioremap_nocache(unsigned long offset, unsigned long size)
+ {
+   return __ioremap(offset, size, _CACHE_UNCACHED);
+ }
+diff --git a/arch/mips/include/asm/system.h b/arch/mips/include/asm/system.h
+index 7a28952..d56f73b 100644
+--- a/arch/mips/include/asm/system.h
 b/arch/mips/include/asm/system.h
+@@ -22,7 +22,7 @@
+ #include 
+ #endif
+ 
+-extern __inline__ void
++static __inline__ void
+ __sti(void)
+ {
+   __asm__ __volatile__(
+@@ -46,7 +46,7 @@ __sti(void)
+  * R4000/R4400 need three nops, the R4600 two nops and the R1 needs
+  * no nops at all.
+  */
+-extern __inline__ void
++static __inline__ void
+ __cli(void)
+ {
+   __asm__ __volatile__(
+@@ -207,7 +207,7 @@ do { \
+  * For 32 and 64 bit operands we can take advantage of ll and sc.
+  * FIXME: This doesn't work for R3000 machines.
+  */
+-extern __inline__ unsigned long xchg_u32(volatile int * m, unsigned long val)
++static __inline__ unsigned long xchg_u32(volatile int * m, unsigned long val)
+ {
+ #ifdef CONFIG_CPU_HAS_LLSC
+   unsigned long dummy;
diff --git a/package/boot/uboot-lantiq/patches/0046-no_weak_alias.patch 
b/package/boot/uboot-lantiq/patches/0046-no_weak_alias.patch
new file mode 100644
index 000..4701ab1
--- /dev/null
+++ b/package/boot/uboot-lantiq/patches/0046-no_weak_alias.patch
@@ -0,0 +1,28 @@
+From 3422299dc28fa8257677d03cc1253e3c9bf17e9f Mon Sep 17 00:00:00 2001
+From: Jeroen Hofstee 
+Date: Thu, 26 Jun 2014 20:18:31 +0200
+Subject: [PATCH] common: main.c: make show_boot_progress __weak
+
+This not only looks a bit better it also prevents 

[OpenWrt-Devel] WiFi on RT5350 not performing well

[Luis Soltero]

Hello All,

Working on an RT5350 based system with a generic version of CC 15.05 and the also the latest trunk head I noticed that 
the WiFi performance was very poor.  ssh was very sluggish and file transfers would hang after about 150Kbytes of data 
were transferred.


After some investigation I discovered that be deleting this patch
target/linux/ramips/patches-3.18/0011-MIPS-ralink-add-rt2880-wmac-clock.patch

Full WiFi performance and functionality was restored.  The question is why. The 
patch adds the following

ralink_clk_add("48.wmac", wmac_rate);

to ralink_clk_init()

This looks important.  I am not understanding why RT5350 would balk at this when other similar processors don't.  The 
WiFi for the MT7620 works fine with this patch.


So... is this a bug? is there something I am not understanding here? Is possibly some other code that is missing for the 
initialization of the RT5350 that is present in other SoCs?  For now I have modified the patch as follows


 ralink_clk_add("40.ethernet", cpu_rate / 2);
+#if !defined(CONFIG_RALINK_RT5350)
+ralink_clk_add("48.wmac", wmac_rate);
+#endif
 }


A longer description of symptoms can be found here

https://forum.openwrt.org/viewtopic.php?id=61395

Please comment.

Thanks,

--luis



--


Luis Soltero, Ph.D., MCS
Director of Software Development, CTO
Global Marine Networks, LLC
StarPilot, LLC
Tel: +1.865.379.8723
Fax: +1.865.681.5017
E-Mail: lsolt...@globalmarinenet.net
Web: http://www.globalmarinenet.net
Web: http://www.redportglobal.com
Web: http://www.starpilotllc.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] lantiq: fix led setup after switch to uci-defaults-new.sh

[Mathias Kresin]

The switch to uci-defaults-new.sh revealed a bug in the former used
uci-defaults.sh, which failed to add leds with colons in the led name.

This bug isn't any longer present in uci-defaults-new.sh and therefore
all via DT defined leds will be added to /etc/config/system with their initial
on/off state, regardless whether they are already added by the board specific
led mappings.

This results for a BTHOMEHUBV5A into the following led configuration:

- soc:blue:power is added as led_power with the initial state "switched on"
- soc:blue:power is added as led_soc_blue_power with the initial state 
"switched off"

With the final result of a switched off power led after boot.

The only led that needs to be added is the BTHOMEHUBV5A specific dimmed led.

Signed-off-by: Mathias Kresin 
---

The loop was introduced with r34698 to compact the leds file. The mentioned bug
of uci-defaults.sh can be seen in paste [1].

Based on the commit diff and the current device tree files of the boards that
where removed with r34698 from the leds file, I'm sure the
ucidef_set_led_default calls where used to initially switch off active_low
leds.

Nowdays this isn't needed, as GPIO active_low/active_high is set via DT and
the default state for leds is "switched off".

The "default" leds power, power1, power2 and dsl do not have to be added. They
are hardcoded in the platform specific scripts. I will fix this hardcoding
after this patch is merged.

[1] http://paste.debian.net/hidden/13e5218b/

 target/linux/lantiq/base-files/etc/board.d/01_leds | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/target/linux/lantiq/base-files/etc/board.d/01_leds 
b/target/linux/lantiq/base-files/etc/board.d/01_leds
index 2dc641e..74d74c4 100755
--- a/target/linux/lantiq/base-files/etc/board.d/01_leds
+++ b/target/linux/lantiq/base-files/etc/board.d/01_leds
@@ -27,11 +27,17 @@ BTHOMEHUBV2B)
ucidef_set_led_netdev "internet" "internet" "soc:blue:broadband" 
"pppoa-wan"
ucidef_set_led_usbdev "usb" "usb" "soc:blue:phone" "1-1"
;;
-BTHOMEHUBV3A|BTHOMEHUBV5A)
+BTHOMEHUBV3A)
ucidef_set_led_default "power" "power" "soc:blue:power" "1"
ucidef_set_led_wlan "wifi" "wifi" "soc:blue:wireless" "phy0tpt"
ucidef_set_led_netdev "internet" "internet" "soc:blue:broadband" 
"pppoa-wan"
;;
+BTHOMEHUBV5A)
+   ucidef_set_led_default "power" "power" "soc:blue:power" "1"
+   ucidef_set_led_wlan "wifi" "wifi" "soc:blue:wireless" "phy0tpt"
+   ucidef_set_led_netdev "internet" "internet" "soc:blue:broadband" 
"pppoa-wan"
+   ucidef_set_led_default "dimmed" "dimmed" "dimmed" "0"
+   ;;
 VGV7510KW22)
ucidef_set_led_default "power" "power" "power" "1"
ucidef_set_led_default "power2" "power2" "power2" "0"
@@ -69,11 +75,6 @@ ARV8539PW22)
;;
 esac
 
-for a in `ls /sys/class/leds/`; do
-   grep -q "\[none\]" /sys/class/leds/$a/trigger
-   [ $? -eq 0 ] && ucidef_set_led_default $a $a $a `cat 
/sys/class/leds/$a/brightness`
-done
-
 board_config_flush
 
 exit 0
-- 
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel