Re: [LEDE-DEV] [PATCH v2] ar71xx: Add TP-LINK TL-WR841N v12 support.

2017-03-29 Thread Vittorio G (VittGam) 
Hello Piotr,

On 27/03/2017 11:22:05 CEST, Piotr Dymacz wrote:
> Hello Vittorio,
> 
> On 26.03.2017 09:55, Vittorio Gambaletta (VittGam) wrote:
>> This router has the same hardware of TP-LINK TL-WR841N v11 (same
>> FCC ID, same TFTP image name...).
>>
>> The stock firmware web interface does not seem to accept the LEDE
>> factory image, but it can be flashed via the u-boot TFTP recovery
>> by long-pressing the reset button after power on.
> 
> So, I have just made a test (using TL-WR841N v9 "converted" to v12 EU) 
> and factory-eu image works without any problems (Firefox 52).

Ok, perfect, then!

> I'm going to pick up your patch with small change in commit message and 
> subject (please, don't add dot at the end of the subject next time).

Thanks for your suggestion. I knew the exact contrary and in fact I'm
adding dot at end of subject every time... Do you know if there is some
place (that I might have very well missed if it exists...) where this
kind of style rules are written?

Cheers,
Vittorio

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] ar8327: Add workarounds for AR8337 switch.

2017-03-29 Thread Vittorio G (VittGam) 
Hello,

On 29/03/2017 10:44:36 CEST, John Crispin wrote:
> On 26/03/17 10:08, Vittorio Gambaletta (VittGam) wrote:
>> -.phy_fixup = ar8327_phy_fixup,
>> +//.phy_fixup = ar8337_phy_fixup, // not needed at the moment
>>  .set_mirror_regs = ar8327_set_mirror_regs,
>>  .get_arl_entry = ar8327_get_arl_entry,
>>  .sw_hw_apply = ar8327_sw_hw_apply
> Hi,
> 
> why is this not needed ?

Because QCA in their QSDK only execute the AR8327 fixup function
for the AR8327 [0]. Since the fixup function does black magic with
hidden or reserved register bits (some are not even appearing in
the datasheet...), I think that it's better to leave it out
like they do...

Cheers,
Vittorio

[0] 
https://source.codeaurora.org/quic/qsdk/oss/system/openwrt/tree/target/linux/generic/files/drivers/net/phy/ar8216.c?h=aa%2Fbanana#n1324

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ar8327: Add workarounds for AR8337 switch.

2017-03-26 Thread Vittorio G (VittGam) 
Hello,

On 25/03/2017 23:36:03 CET, Mathias Kresin wrote:
> 25.03.2017 18:08, Vittorio Gambaletta (VittGam):
>> Backported from Code Aurora QSDK
>>
>> Signed-off-by: Vittorio Gambaletta 
> 
> Please describe in the commit message what kind of issues need a 
> workaround. Yes, I noticed the comments in the patch, but nevertheless 
> it should go into the commit message.

Ok, I will do it.

> IMHO the changes to the HOL register need an explanation. At least I've 
> no idea what the magic values mean and what kind of issue is fixed by 
> applying them.

They should help in packet flood conditions. In my tests, port 5
stopped freezing when there's a small packets flood after having
applied both the HOL changes and the RGMII RX delay change, and
removed the ar8327 reserved register fixups from ar8337.

By the way, the values are not magic; they set the quantity of buffers
that can be used for ports and relative priorities. The default
for all ports is 0x2A for every port and 0x8 for all queues of every
port. (Values are then multiplied by 8 to get the applied values.)
This means that the patch will slightly reduce buffers per port, and
distribute them for the various available priorities (0-5 for ports
0,5,6 and 0-3 for ports 1,2,3,4).

The HOL_CTRL1 lines instead simply restore the default values.

These changes make sense to me, and they actually solved my problem
with port 5 hanging in flood conditions; that's why I included them
in this patch (after decoding the "magic" unexplained values in the
QSDK commit and mapping them to the right defines).

Cheers,
Vittorio

> Mathias
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ar71xx: Add TP-LINK TL-WR841N v12 support.

2017-03-26 Thread Vittorio G (VittGam) 
Hello Piotr,

On 25/03/2017 23:12:58 CET, Piotr Dymacz wrote:
> Hello Vittorio,
> 
> On 25.03.2017 18:08, Vittorio Gambaletta (VittGam) wrote:
>> This router has the same hardware of TP-LINK TL-WR841N v11 (same
>> FCC ID, same TFTP image name...).
>>
>> The stock firmware web interface does not seem to accept the LEDE
>> factory image, but it can be flashed via the u-boot TFTP recovery
>> by long-pressing the reset button after power on.
> 
> Did you try factory image but with changed filename (sometimes TP-Link 
> web gui doesn't accept files with long name)?

Yes, I remembered about this problem with late versions of the 703n,
so I tried both short name (x.bin) and same name of factory image.
But it didn't work in either case.

Fortunately the TFTP client integrated in the factory u-boot accepts
the image, so opening the router to access the serial is not required.

> What kind of error are you getting with LEDE factory image?

If I remember well it was 18005, wrong filename...

> BTW. It seems that TP-Link already released v13 version of this device 
> in Europe but this time it's (surprise!) MediaTek (MT7628?) based.

Yes. But here in Italy, a big online retailer just started selling v12
(with new TP-LINK logo) instead of v11, so who knows when v13 will
arrive...

(I hope v13 will not have problems, since the 841 v9/v11/v12 today is a
very stable and reliable (and really cheap...) platform.)

>> The TFTP image name is wr841nv11_tp_recovery.bin (yes, v11, not v12).
>>
>> Signed-off-by: Vittorio Gambaletta 
>> ---
>>  target/linux/ar71xx/image/tp-link.mk |   13 -
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/target/linux/ar71xx/image/tp-link.mk 
>> b/target/linux/ar71xx/image/tp-link.mk
>> index cf2e5e7..705e400 100644
>> --- a/target/linux/ar71xx/image/tp-link.mk
>> +++ b/target/linux/ar71xx/image/tp-link.mk
>> @@ -736,6 +736,17 @@ define Device/tl-wr841-v11
>>IMAGE/factory-eu.bin := append-rootfs | mktplinkfw factory -C EU
>>  endef
>>
>> +define Device/tl-wr841-v12
>> +  $(Device/tplink-4mlzma)
> 
> Can you use here $(Device/tl-wr841-v11) instead and then overwrite only 
> two variables which are different: DEVICE_TITLE and TPLINK_HWID?

Ok, I will send a PATCH v2 with this change.

Cheers,
Vittorio

> --
> Best regards,
> Piotr Dymacz
> 
>> +  DEVICE_TITLE := TP-LINK TL-WR841N/ND v12
>> +  BOARDNAME := TL-WR841N-v11
>> +  DEVICE_PROFILE := TLWR841
>> +  TPLINK_HWID := 0x08410012
>> +  IMAGES += factory-us.bin factory-eu.bin
>> +  IMAGE/factory-us.bin := append-rootfs | mktplinkfw factory -C US
>> +  IMAGE/factory-eu.bin := append-rootfs | mktplinkfw factory -C EU
>> +endef
>> +
>>  define Device/tl-wr842n-v1
>>$(Device/tplink-8m)
>>DEVICE_TITLE := TP-LINK TL-WR842N/ND v1
>> @@ -778,7 +789,7 @@ define Device/tl-wr847n-v8
>>DEVICE_PROFILE := TLWR841
>>TPLINK_HWID := 0x08470008
>>  endef
>> -TARGET_DEVICES += tl-wr840n-v2 tl-wr840n-v3 tl-wr841-v1.5 tl-wr841-v3 
>> tl-wr841-v5 tl-wr841-v7 tl-wr841-v8 tl-wr841-v9 tl-wr841-v10 tl-wr841-v11 
>> tl-wr842n-v1 tl-wr842n-v2 tl-wr842n-v3 tl-wr843nd-v1 tl-wr847n-v8
>> +TARGET_DEVICES += tl-wr840n-v2 tl-wr840n-v3 tl-wr841-v1.5 tl-wr841-v3 
>> tl-wr841-v5 tl-wr841-v7 tl-wr841-v8 tl-wr841-v9 tl-wr841-v10 tl-wr841-v11 
>> tl-wr841-v12 tl-wr842n-v1 tl-wr842n-v2 tl-wr842n-v3 tl-wr843nd-v1 
>> tl-wr847n-v8
>>
>>  define Device/tl-wr941nd-v2
>>$(Device/tplink-4m)
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>>
> 
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] mac80211: Fix race condition leading to wifi interfaces not coming up at boot sometimes.

2017-03-14 Thread Vittorio G (VittGam) 
If you're wondering where the -ENFILE error comes from...

At first I thought it was obviously related to fs.file-max that
defaults to "just" 8192.

But it was not. It took me a while to figure out that the error
came from here instead...

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/core/dev.c?id=13baa00ad01bb3a9f893e3a08cbc2d072fc0c15d#n1070

In fact, -ENFILE is returned every time one tries to add a wireless
virtual interface with the same name as another existing one.
(Maybe the error code should be changed to -EEXIST when an explicit
interface name is requested and it turns out to be already taken,
like in this case... Time for a kernel patch, maybe!)

This issue was also very time-sensitive; when I added some debug
prints to iw, it disappeared...

On 14/03/2017 06:19:44 CET, Vittorio Gambaletta (VittGam) wrote:
> In the drv_mac80211_setup function, mac80211_interface_cleanup
> is called to ask the kernel to delete all existing interfaces
> for the phy that is being configured via netlink.
> 
> Later in the first function, mac80211_prepare_vif is called to
> set up the new interfaces as required.
> 
> But sometimes, when mac80211_prepare_vif (and so the relevant
> `iw phy x interface add y` command) runs, the kernel might still
> be cleaning up the old interface with the same ifname. It usually
> takes very few time to do that; possibly a few milliseconds of
> sleep in the script after detecting this error condition could be
> enough, but the busybox sh does not support sub-second sleep
> intervals.
> 
> When this happens, iw obviously fails to create the new interface;
> and the following message is printed in the system log, followed by
> subsequent failure messages from hostapd in case this would have been
> an AP interface.
> 
> Tue Mar 14 04:21:57 2017 daemon.notice netifd: radio1 (2767): command failed: 
> Too many open files in system (-23)
> 
> This was a long-standing issue existing since at least OpenWrt Backfire,
> and today I finally managed to debug and (hopefully) solve it.
> It was happening very few times on most devices; but it was happening
> a lot more frequently on fast platforms with multiple radios, such as
> the powerpc-based dual-ath9k-radio tl-wdr4900-v1.
> 
> Signed-off-by: Vittorio Gambaletta 
> 
> ---
>  .../mac80211/files/lib/netifd/wireless/mac80211.sh |   35 
> +---
>  1 file changed, 30 insertions(+), 5 deletions(-)
> 
> diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
> b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> index baa023e..5058b01 100644
> --- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> +++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
> @@ -411,6 +411,31 @@ mac80211_check_ap() {
>   has_ap=1
>  }
>  
> +mac80211_iw_interface_add() {
> + local phy="$1"
> + local ifname="$2"
> + local type="$3"
> + local wdsflag="$4"
> +
> + iw phy "$phy" interface add "$ifname" type "$type" $wdsflag
> + ret="$?"
> +
> + [ "$ret" = 233 ] && {
> + # Device might have just been deleted, give the kernel some 
> time to finish cleaning it up
> + sleep 1
> +
> + iw phy "$phy" interface add "$ifname" type "$type" $wdsflag
> + ret="$?"
> + }
> +
> + [ "$ret" != 0 ] && {
> + wireless_setup_failed INTERFACE_CREATION_FAILED
> + return 1
> + }
> +
> + return 0
> +}
> +
>  mac80211_prepare_vif() {
>   json_select config
>  
> @@ -437,7 +462,7 @@ mac80211_prepare_vif() {
>   # It is far easier to delete and create the desired interface
>   case "$mode" in
>   adhoc)
> - iw phy "$phy" interface add "$ifname" type adhoc
> + mac80211_iw_interface_add "$phy" "$ifname" adhoc || 
> return
>   ;;
>   ap)
>   # Hostapd will handle recreating the interface and
> @@ -451,21 +476,21 @@ mac80211_prepare_vif() {
>   mac80211_hostapd_setup_bss "$phy" "$ifname" "$macaddr" 
> "$type" || return
>  
>   [ -n "$hostapd_ctrl" ] || {
> - iw phy "$phy" interface add "$ifname" type __ap
> + mac80211_iw_interface_add "$phy" "$ifname" __ap 
> || return
>   
> hostapd_ctrl="${hostapd_ctrl:-/var/run/hostapd/$ifname}"
>   }
>   ;;
>   mesh)
> - iw phy "$phy" interface add "$ifname" type mp
> + mac80211_iw_interface_add "$phy" "$ifname" mp || return
>   ;;
>   monitor)
> - iw phy "$phy" interface add "$ifname" type monitor
> + mac80211_iw_interface_add "$phy" "$ifname" monitor || 
> return
>   ;;
>   sta)
>   local wdsflag=
>

Re: [LEDE-DEV] Regarding switching "everything" to 24kc

2016-08-22 Thread Vittorio G (VittGam) 

Hi,

As an opposite example, ar71xx 74Kc CPUs such as Atheros AR934x currently
run 34Kc (so 24Kc) code. Would a separate 74Kc subtarget make sense there?

On 22/08/2016 11:03:54 CEST, Jonas Gorski wrote:

But of course if benchmarks show that 74k won't reduce performance on
24k/34k/1004k, we can consider switching to eliminate one more package
feed target.


It would be interesting to run such benchmarks, but which ones exactly?

Cheers,
Vittorio

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: Future of Chaos Calmer

2016-05-05 Thread Vittorio G (VittGam) 

On 05/05/2016 21:30:56 CEST, David Lang wrote:

On Thu, 5 May 2016, Vittorio G (VittGam) wrote:


Hello,

I'd like to know if there are any plans for Chaos Calmer?

Will it become mantained by LEDE?


almost certinly not. But LEDE will create their own release to replace it.


Okay, it would be great to have a LEDE release derived by the CC codebase, too.


remember that part of maintaining a release is making updates to it available.

OpenWRT updates against *openwrt.org servers, so LEDE is not going to be able 
to do anything there.

David Lang


Trunk introduces important changes, for example the switch from uClibc to
musl, so until everything's polished and ready for release I'd rather not
use trunk on "production" devices, like the main home modem/router or all
the antennas of a wireless community that are mounted on the roofs...


shrug, you need to do testing anyway. I ran 120 APs from Trunk at the Scale 
conference in January and they worked well.


Well, of course I would never flash deployed antennas with trunk without
testing; but sometimes trunk reserves strange surprises that may not be
caught even while testing... As an extreme example, some years ago I had
some APs flashed with a supposedly "stable" revision of AA (when it still
was the trunk). After some time, when trying to update to BB, I saw that
some of the routers were rebooting in the middle of flashing, because the
watchdog process wasn't terminated properly, so the hardware watchdog
remained active and triggered in the middle of the upgrade.

Cheers,
Vittorio

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [PATCH] style: use sans-serif font

2016-05-04 Thread Vittorio G (VittGam) 

Are you really thanking yourself for your patch here? ;)

Cheers,
Vittorio

On 04/05/2016 13:12:37 CEST, Rafał Miłecki wrote:

Applied, thanks Rafal.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev