[OpenWrt-Devel] [RFC] [PULL REQUEST] rt2x00 patches from OpenWrt.org

[Daniel Golle]

Hi!

In preparation to be submitted upstream I started to clean up a huge
pile of patches for rt2x00 we have been carrying along for quite a
while (some for more than half a decade!).
Some of them are fixes, most importantly Serge Vasilugin fixed setting
the HT20/HT40 filter which got us much closer to the expected
performance when using HT40 modes.

And also a lot of new added hardware support:
Gabor Juhos wrote code for Rt3883 WiSoC.
Daniel Golle implemented support for Rt3352 by designs with external PA
as well as for boards using a 20MHz crystal instead of the usual 40MHz.
Serge Vasilugin contributed support for the Rt5350 WiSoC.
Michel Stempin, Felix Fietkau and John Crispin have been helping with
cleaning up things and putting away legal doubts.

Please review and comment, so we can get those patches merged!


Cheers


Daniel


The following changes since commit cc75c577806a53893122829d91cb122b51643a2d:

  mwifiex: get rid of global save_adapter and sdio_work (2017-01-12 16:49:18 
+0200)

are available in the git repository at:

  https://github.com/dangowrt/linux.git rt2x00-from-openwrt

for you to fetch changes up to fb8832d1896475059c964c75ab4baaf94199143c:

  rt2x00: fix WARN_ON_ONCE() caused by inbalanced set/clear of beacon enable 
bit (2017-01-13 04:17:57 +0100)


Claudio Mignanti (1):
  rt2x00: rt2x00pci: set PCI MWI only if supported

Daniel Golle (2):
  rt2x00: support for for RT3352 with external PA
  rt2x00: add support for RT3352 with 20MHz crystal

Felix Fietkau (1):
  rt2x00: fix rf id for RT3352

Gabor Juhos (34):
  rt2x00: rt2800lib: move rt2800_drv_data declaration into rt2800lib.h
  rt2x00: rt2800lib: introduce RT2800_HAS_HIGH_SHARED_MEM flag
  rt2x00: rt2800: serialize shared memory access
  rt2x00: rt2800lib: fix beacon generation on RT3593
  rt2x00: rt2800lib: add hw_beacon_count field to struct rt2800_drv_data
  rt2x00: rt2800lib: init additional beacon offset registers
  rt2x00: rt2800lib: fix max supported beacon count for RT3593
  rt2x00: allow to build rt2800soc module for RT3883
  rt2x00: rt2800lib: enable support for RT3883
  rt2x00: rt2800lib: add rf_vals for RF3853
  rt2x00: rt2800lib: enable VCO calibration for RF3853
  rt2x00: rt2800lib: add channel configuration function for RF3853
  rt2x00: rt2800lib: enable RF3853 support
  rt2x00: rt2800lib: add MAC register initialization for RT3883
  rt2x00: rt2800soc: fix rt2800soc_disable_radio for RT3883
  rt2x00: rt2800lib: add BBP register initialization for RT3883
  rt2x00: rt2800lib: add RFCSR initialization for RT3883
  rt2x00: rt2800lib: use the extended EEPROM map for RT3883
  rt2x00: rt2800lib: force rf type to RF3853 on RT3883
  rt2x00: rt2800lib: add channel configuration code for RT3883
  rt2x00: rt2800lib: fix txpower_to_dev function for RT3883
  rt2x00: rt2800lib: use correct txpower calculation function for RT3883
  rt2x00: rt2800lib: hardcode txmixer gain values to zero for RT3883
  rt2x00: rt2800lib: use correct [RT]XWI size for RT3883
  rt2x00: rt2800lib: use correct beacon base for RT3883
  rt2x00: rt2800lib: use correct beacon count for RT3883
  rt2x00: rt2800lib: fix antenna configuration for RT3883
  rt2x00: rt2800lib: fix LNA gain configuration for RT3883
  rt2x00: rt2800lib: fix VGC setup for RT3883
  rt2x00: rt2800lib: fix EEPROM LNA validation for RT3883
  rt2x00: rt2800lib: fix txpower compensation for RT3883
  rt2x00: rt2800lib: enable RT2800_HAS_HIGH_SHARED_MEM for RT3883
  rt2x00: rt2800lib: use high memory for beacons on RT3883
  rt2x00: rt2800mmio: add a workaround for spurious TX_FIFO_STATUS 
interrupts

Michel Stempin (1):
  rt2x00: add support for RT5350 WiSoC

Serge Vasilugin (1):
  rt2x00 correctly set ht20/ht40 filter

evaxige (1):
  rt2x00: fix WARN_ON_ONCE() caused by inbalanced set/clear of beacon 
enable bit

 drivers/net/wireless/ralink/rt2x00/Kconfig  |2 +-
 drivers/net/wireless/ralink/rt2x00/rt2800.h |   79 +-
 drivers/net/wireless/ralink/rt2x00/rt2800lib.c  | 1006 ++-
 drivers/net/wireless/ralink/rt2x00/rt2800lib.h  |   63 ++
 drivers/net/wireless/ralink/rt2x00/rt2800mmio.c |   98 ++-
 drivers/net/wireless/ralink/rt2x00/rt2800mmio.h |4 +
 drivers/net/wireless/ralink/rt2x00/rt2800pci.c  |   14 +
 drivers/net/wireless/ralink/rt2x00/rt2800soc.c  |   12 +-
 drivers/net/wireless/ralink/rt2x00/rt2800usb.c  |   31 +
 drivers/net/wireless/ralink/rt2x00/rt2x00.h |   10 +
 drivers/net/wireless/ralink/rt2x00/rt2x00dev.c  |7 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00mac.c  |8 +-
 drivers/net/wireless/ralink/rt2x00/rt2x00pci.c  |2 +
 13 files changed, 1254 insertions(+), 82 deletions(-)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org

Re: [OpenWrt-Devel] upstreaming (most) rt2x00 patches

[Daniel Golle]

Hi Tom,

Thank you for reporting that issue.
I reckon that support for the MT7620 family should thus be considered
experimental and is not yet fit for being merged upstream.
I thus removed it from them rt2x00 patch-queue tree on github.

Cheers

Daniel

On Fri, Jan 13, 2017 at 12:16:01AM +0100, Tom Psyborg wrote:
> more info:
> 
> https://forum.openwrt.org/viewtopic.php?id=69042
> 
> https://forum.lede-project.org/t/mt7620a-rx-path-issue/671
> 
> On 13 January 2017 at 00:14, Tom Psyborg  wrote:
> 
> > Hi
> >
> > Any news on MT7620A LNA support? I still don't know if all devices are
> > affected, but few of them are confirmed to have weak reception, possibly
> > eLNA layout devices?
> >
> > On 12 January 2017 at 15:35, Daniel Golle  wrote:
> >
> >> Hi!
> >>
> >> The amount of patches on top of rt2x00 has grown into a huge pile
> >> during the past couple of years. To get things into a shape that allow
> >> discussing and merging them upstream, I created a tree on github based
> >> on wireless-drivers-next.git:
> >>
> >> https://github.com/dangowrt/linux/commits/rt2x00-from-openwrt
> >>
> >> I had to fix up some of Gabor's patches to still apply on the updated
> >> code base, but apart from those small fixes, things still apply cleanly
> >> on that tree.
> >> Imho the patch adding support for MT7620 still needs some more cleaning
> >> (I fixed some white-space and indention issues already), and both
> >> MT7620 and RT5350 still use mdelay and udelay which should be replaced
> >> in the same way done for other codepaths upstream. It'd also be great
> >> not to mess up RF and RT, ie. correctly set the RF value
> >> for RT5350 and MT7620 according to the actual RF IP used on those
> >> chips. Just for clarification, RT6352 was later renamed to MT7620
> >>
> >> I for now didn't add any of the EEPROM-related patches, I a suppose
> >> that only read_eeprom_from_mtd() should go upstream and all file and
> >> firmware-loading mechanics can be considered legacy.
> >> I also didn't add any of the device-tree specific stuff, as that will
> >> need to be documented (Documentation/devicetree/ofbindings/).
> >>
> >> However, all the rest should be fine. Maybe the commit messages could
> >> be nicer...
> >>
> >> The goal is to have a nice and clean tree which we can asked to be
> >> merged into wireless-drivers-next.git instead of submitting the patches
> >> one-by-one via the mailing list.
> >>
> >> Thus I'm asking for your help: Please review the patches, and also
> >> let me know if you had any plans for upstreaming them yourself.
> >>
> >>
> >> Cheers
> >>
> >>
> >> Daniel
> >> ___
> >> 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] Loss of connectivity on ADSL reset

[Hans Dedecker]

On Thursday, 12 January 2017 10:24:45 CET Tim Coote wrote:
> Hullo
> 
> I’ve tried this request to openwrt-users and got no response, so I’m trying
> the developer community in the hope that you’ve got a deeper understanding
> of how openwrt should work.
> 
> I keep losing my openwrt router’s IPv4 configuration when my ISP bounces the
> link to my home.
> 
> I’m using commit 1a7b132013 (Jan 9 2016)
> 
> My ISP link is over ADSL. I have a dsl modem attached to the phone line and
> a WRT1200 attached to that, which connects with pppoe. I’m trying to run
> homenet, so I’d like to have the WAN interface controlled by homenet
> (hence, I’m avoiding interfaces called ‘wan’ or ‘lan’ to avoid them being
> treated as ’special'). Based on advice that I cannot immediately put my
> finger on, I’m using these stanzas to set up the WAN links:
> 
> config interface 'e0'
>   option ifname 'eth0'
>   option proto 'pppoe'
>   option username ‘'
>   option password ‘'
> 
> config interface 'e0ext'
>   option ifname 'pppoe-e0'
You need to configure the ifname as an aliased interface of interface e0; eg 
option ifname @e0

Hans
>   option proto 'hnet'
>   option mode 'external'
>   option _orig_ifname 'pppoe-e0’ # I think that this line is redundant.
> 
> 
> The idea is that e0ext is ‘stacked’ on pppoe-e0 (the interface name from
> e0).
> 
> The configuration works most of the time. Until the link bounces. What seems
> to happen is that pppoe is torn down when the link is reset, and then
> rebuilt correctly. However, the interface e0ext does not seem to receive
> any notification of the link coming back up (I’m assuming that’s how things
> are supposed to work).  Hnet is designed to keep the ipv6 links up in the
> event of loss of internet, so I’m assuming that this doesn’t require
> notification of link restoration.
> 
> I’m guessing that the events on the links/interfaces should be propagated
> through ubus (?)
> 
> If I use ubus to take down e0, e0ext is disabled, but on sending up to e0,
> e0ext stays down. An explicit up to e0ext creates this error (from ubus
> call network.interface.e0ext status):
> 
> root@OpenWrt:~# ubus call network.interface.e0ext status
> {
>   "up": false,
>   "pending": false,
>   "available": false,
>   "autostart": true,
>   "dynamic": false,
>   "proto": "hnet",
>   "data": {
> 
>   },
>   "errors": [
>   {
>   "subsystem": "interface",
>   "code": "NO_DEVICE"
>   }
>   ]
> }
> 
> 
> 
> Am I missing something from the configuration, have I stumbled upon a bug,
> or do I have to live with rebooting the router ~once per week?  (and am I
> posting to the right group?)
> 
> cheers
> Tim
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [Babel-users] Babeld now has procd support on OpenWRT/LEDE

[Dave Taht]

On Thu, Jan 12, 2017 at 1:01 PM, Baptiste Jonglez
 wrote:
> Hi,
>
> Here is yet another OpenWRT-related change for babeld: I just merged procd
> support for babeld [2], after more than two years of lingering [1].
>
> The only user-visible changes should be:
>
> - babeld now logs to the system log (visible with "logread") instead of a
>   file in /var/log.  This is nice for embedded devices, where you don't
>   want to write too much to the filesystem.  It is still possible to
>   explicitly configure babeld to use a log file;
>
> - babeld is now restarted automatically whenever it crashes;
>
> - the usual procd niceties: calling "/etc/init.d/babeld reload" will
>   restart babeld only if the configuration has changed.
>
>
> Please test babeld 1.8.0-2 and report any resulting breakage.  I would
> like this change (and the other compatibility change) to make it into the
> upcoming LEDE release, which is due to happen quite soon.

Groovy.

lede can dynamically insert/delete routes into tables from netifd
babeld can pull routes from "protos" but not tables.

I spoke with hedecker (? can't remember his email) about somehow
having a field to export routes into kernel protos in the lede network
file, he indicated he'd look at it in a few weeks.

(I wanted to get away from ever having to revise the conf file
dynamically, but it looks like not this release. Not having to restart
babeld as per the above is a nice improvement though and I'll get on
testing it this weekend. At the moment I'm going through some mild
hell with dhcpv6-pd on comcast and adding "sonic" fiber (with a HE
ipv6 tunnel. Will hopefully have 4 source specific gateways to play
with here)

In other other news the "rabeld" backport of the gentler route switch
change loses kernel routes on the vyatta (3.10 based) OS in the
edgerouter. :(. That said, haven't tested mainline babeld there yet.
It seems to work on debian.

For those fiddling with edgerouter's default 1.9.x OS, backports of
cake, iproute, and rabeld are presently here:
https://build.lochnair.net/

> Baptiste
>
> [1] https://github.com/openwrt-routing/packages/pull/55
> [2] https://github.com/openwrt-routing/packages/pull/250
>
> ___
> Babel-users mailing list
> babel-us...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Babeld now has procd support on OpenWRT/LEDE

[Baptiste Jonglez]

Hi,

Here is yet another OpenWRT-related change for babeld: I just merged procd
support for babeld [2], after more than two years of lingering [1].

The only user-visible changes should be:

- babeld now logs to the system log (visible with "logread") instead of a
  file in /var/log.  This is nice for embedded devices, where you don't
  want to write too much to the filesystem.  It is still possible to
  explicitly configure babeld to use a log file;

- babeld is now restarted automatically whenever it crashes;

- the usual procd niceties: calling "/etc/init.d/babeld reload" will
  restart babeld only if the configuration has changed.


Please test babeld 1.8.0-2 and report any resulting breakage.  I would
like this change (and the other compatibility change) to make it into the
upcoming LEDE release, which is due to happen quite soon.

Baptiste

[1] https://github.com/openwrt-routing/packages/pull/55
[2] https://github.com/openwrt-routing/packages/pull/250


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

[OpenWrt-Devel] python ctypes.util.find_library cannot find libc

[Andrew McConachie]

Hi OpenWRT Devs,

I'm building an OpenWRT package for python-iptables for a project I'm 
working on and getting this error message when attempting to use it.


import iptc
  File "/usr/lib/python2.7/site-packages/iptc/__init__.py", line 10, in 

from ip4tc import (is_table_available, Table, Chain, Rule, Match, 
Target,
  File "/usr/lib/python2.7/site-packages/iptc/ip4tc.py", line 13, in 


from xtables import (XT_INV_PROTO, NFPROTO_IPV4, XTablesError, xtables,
  File "/usr/lib/python2.7/site-packages/iptc/xtables.py", line 677, in 


_optind = ct.c_long.in_dll(_libc, "optind")
AttributeError: 'NoneType' object has no attribute '_handle'

You can view xtables.py here if you're curious.
https://github.com/ldx/python-iptables/blob/master/iptc/xtables.py

The problem is that my python-iptables package cannot find libc 
functions using ctypes.util.find_library(). I've tried building OpenWRT 
using both musl and eglibc but neither work. I've also tried building 
OpenWRT with objdump and ldconfig. When I include ldconfig via 'make 
menuconfig' it doesn't actually populate my OpenWRT image with an 
ldconfig binary. Maybe this is the problem?


This bug report looks similar to my problem, but it's about MIPS and 
marked as closed.

https://dev.openwrt.org/ticket/20123

Any help or pointers would be much appreciated.

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

[OpenWrt-Devel] upstreaming (most) rt2x00 patches

[Daniel Golle]

Hi!

The amount of patches on top of rt2x00 has grown into a huge pile
during the past couple of years. To get things into a shape that allow
discussing and merging them upstream, I created a tree on github based
on wireless-drivers-next.git:

https://github.com/dangowrt/linux/commits/rt2x00-from-openwrt

I had to fix up some of Gabor's patches to still apply on the updated
code base, but apart from those small fixes, things still apply cleanly
on that tree.
Imho the patch adding support for MT7620 still needs some more cleaning
(I fixed some white-space and indention issues already), and both
MT7620 and RT5350 still use mdelay and udelay which should be replaced
in the same way done for other codepaths upstream. It'd also be great
not to mess up RF and RT, ie. correctly set the RF value
for RT5350 and MT7620 according to the actual RF IP used on those
chips. Just for clarification, RT6352 was later renamed to MT7620

I for now didn't add any of the EEPROM-related patches, I a suppose
that only read_eeprom_from_mtd() should go upstream and all file and
firmware-loading mechanics can be considered legacy.
I also didn't add any of the device-tree specific stuff, as that will
need to be documented (Documentation/devicetree/ofbindings/).

However, all the rest should be fine. Maybe the commit messages could
be nicer...

The goal is to have a nice and clean tree which we can asked to be
merged into wireless-drivers-next.git instead of submitting the patches
one-by-one via the mailing list.

Thus I'm asking for your help: Please review the patches, and also
let me know if you had any plans for upstreaming them yourself.


Cheers


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

[OpenWrt-Devel] Loss of connectivity on ADSL reset

[Tim Coote]

Hullo

I’ve tried this request to openwrt-users and got no response, so I’m trying the 
developer community in the hope that you’ve got a deeper understanding of how 
openwrt should work.

I keep losing my openwrt router’s IPv4 configuration when my ISP bounces the 
link to my home.

I’m using commit 1a7b132013 (Jan 9 2016)

My ISP link is over ADSL. I have a dsl modem attached to the phone line and a 
WRT1200 attached to that, which connects with pppoe. I’m trying to run homenet, 
so I’d like to have the WAN interface controlled by homenet (hence, I’m 
avoiding interfaces called ‘wan’ or ‘lan’ to avoid them being treated as 
’special'). Based on advice that I cannot immediately put my finger on, I’m 
using these stanzas to set up the WAN links:

config interface 'e0'
option ifname 'eth0'
option proto 'pppoe'
option username ‘'
option password ‘'

config interface 'e0ext'
option ifname 'pppoe-e0'
option proto 'hnet'
option mode 'external'
option _orig_ifname 'pppoe-e0’ # I think that this line is redundant.


The idea is that e0ext is ‘stacked’ on pppoe-e0 (the interface name from e0).

The configuration works most of the time. Until the link bounces. What seems to 
happen is that pppoe is torn down when the link is reset, and then rebuilt 
correctly. However, the interface e0ext does not seem to receive any 
notification of the link coming back up (I’m assuming that’s how things are 
supposed to work).  Hnet is designed to keep the ipv6 links up in the event of 
loss of internet, so I’m assuming that this doesn’t require notification of 
link restoration.

I’m guessing that the events on the links/interfaces should be propagated 
through ubus (?)

If I use ubus to take down e0, e0ext is disabled, but on sending up to e0, 
e0ext stays down. An explicit up to e0ext creates this error (from ubus call 
network.interface.e0ext status):

root@OpenWrt:~# ubus call network.interface.e0ext status
{
"up": false,
"pending": false,
"available": false,
"autostart": true,
"dynamic": false,
"proto": "hnet",
"data": {

},
"errors": [
{
"subsystem": "interface",
"code": "NO_DEVICE"
}
]
}



Am I missing something from the configuration, have I stumbled upon a bug, or 
do I have to live with rebooting the router ~once per week?  (and am I posting 
to the right group?)

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

Re: [OpenWrt-Devel] [RFC][netifd]: Support for 802154 devices

[Xue Liu]

Hi Anatoliy,

Actually I am working on it. Now I am writing a program which is similar 
with iwinfo. Later I will make some scripts like mac80211.sh and binding 
with netifd.


ci40 has already some work on it. You could have a look.

Xue Liu

On 12.01.2017 01:02, Anatoliy Atanasov wrote:

Hey Folks,

I saw that netifd isn't able to fully manage 802154 devices. At the 
moment it lacks the understanding of wpan settings and definition. If 
it would be in a separate file it would look like:

/etc/config/wpan

config wpan-device radio0
option type 'mac80215'
option channel '11'
option disabled '0' / '1'

config wpan-iface
option device 'radio0'
option pan_id '0xbeef'

I figured two ways to implement this.
The approach #1 is to follow the logic in wireless.h/c which wraps 
calls to the kernel driver in mac80211.sh & netifd-wireless.sh.
The approach #2 is to replicate the wpan-tools code which would add a 
dependency to libnl.


I'm wondering which approach to follow in doing this task?

Regards, Anatoliy




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


--
M.Sci.

Embedded Software Entwicklung

DKS Dienstleistungsgesellschaft
für Kommunikationsanlagen des
Stadt- und Regionalverkehrs mbH

Robert-Perthel-Str. 79
D-50739 Köln

Fon: +49 221 954442-43
Fax: +49 221 954442-23
E-Mail: xue@dks-koeln.de
Web: www.dks-koeln.de

Geschäftsführung: Christian Döring, Ralf Kochs

Aufsichtsratsvorsitzender: Jörn Schwarze

Sitz der Gesellschaft: Köln

Registergericht: Köln, HRB 4521

UST-IDNr: DE154089761

Wichtiger Hinweis: Diese E-Mail und etwaige Anlagen können Betriebs- oder 
Geschäftsgeheimnisse, dem Anwaltsgeheimnis unterliegende oder sonstige 
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich 
erhalten haben, ist Ihnen der Status dieser E-Mail bekannt. Bitte 
benachrichtigen Sie uns in diesem Fall sofort durch Antwort-Mail und löschen 
Sie diese E-Mail nebst etwaigen Anlagen von Ihrem System. Ebenso dürfen Sie 
diese E-Mail oder ihre Anlagen nicht kopieren oder an Dritte weitergeben. 
Vielen Dank!

Important note: This e-mail and any attachment are confidential and may contain 
trade secrets and may well also be legally privileged or otherwise protected 
from disclosure. If you have received it in error, you are on notice of its 
status. Please notify us immediately by reply e-mail and then delete this 
e-mail and any attachment from your system. If you are not the intended 
recipient please understand that you must not copy this e-mail or any 
attachment or disclose the contents to any other person. Thank you for your 
cooperation.

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