Re: [LEDE-DEV] enhanced 3G support

[Giuseppe Lippolis]

Hi Bjørn,

> No, no, the cdc_ether driver is definitely the correct one.  NCM or MBIM
> won't work unless you can make the device morph into another mode. But
> since you know how to manage it in cdc_ether mode, and that is the native
> mode, I see no reason to mess with it.

You are right. The only working driver (at least in the default status) for the 
2 data interface is the cdc_ether.

> I don't think it is relevant for you, though.  You should continue your 
> initial
> idea, creating a "proto" supporting the AT managed cdc_ether based
> modem.

The actual wwan script with the simple modification of the 2001-7d04 data file 
from the (2001-7d03) call the 3g.sh script.
But this script establish the connection using the ppp over the ttyUSB and do 
not use the cdc_ether.
So I'm going to update the wwan script to support the cdc_ether.

As soon as (I'm a LEDE hobbyist, I cannot work full time) I have some results I 
will ask you for some advice.

Thanks,
Bye.


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

Re: [LEDE-DEV] [BUG] Kernel crashes with ath10k radio and Nexus 5X clients

[Timo Sigurdsson]

Hi Mohammed,

sorry for the late reply, but I was on a business trip last week.

The log I had attached is all I got from this crash. I have no experience
with kernel debugging, but I assume some info might be missing because the
kernel was not compiled with debug information. So, I will have to provoke
another crash with a different firmware image that has more debugging
options enabled. It might take a few days, until the error occurs again,
but I'll try to gather more information and post it.

Regards,

Timo


Mohammed Shafi Shajakhan schrieb am 21.11.2016 13:47:

> Hi Timo,
> 
> sorry had I missed the exact kernel crash call trace ?
> I could see only the warnings, can you please post the call
> trace of the kernel crash please ?
> 
> regards,
> shafi
> 
> On Sun, Nov 20, 2016 at 02:35:27AM +0100, Timo Sigurdsson wrote:
>> Hi Adrian,
>> 
>> sure - here's the bug report on kernel.org:
>> https://bugzilla.kernel.org/show_bug.cgi?id=188201
>> 
>> Regards,
>> 
>> Timo
>> 
>> 
>> Adrian Chadd schrieb am 18.11.2016 22:22:
>> 
>> > hiya!
>> > 
>> > Can you file a kernel.org bug mentioning this?
>> > 
>> > thanks!
>> > 
>> > 
>> > -a
>> > 
>> > 
>> > On 18 November 2016 at 01:30, Timo Sigurdsson
>> >  wrote:
>> >> Hi again,
>> >>
>> >> in the meantime, I have some more information to add to the issue 
>> >> mentioned
>> in
>> >> my email quoted further down below.
>> >>
>> >> Ben Greear approached me off-list and suggested to try the Candela Tech
>> ath10k
>> >> driver and firmware and see if the issue occurs with that as well. So, for
>> the
>> >> last 3 weeks I've been testing the CT driver and firmware and I can 
>> >> happily
>> >> report that the issue with the driver crashing after a while when a Nexus
>> 5X
>> >> device is connected is not occuring with the current BETA 18
>> >> firmware-2-ct-full-community.bin. So, this really seems like a regression
>> in
>> >> the official API level 5 ath10k firmware blobs.
>> >>
>> >> The CT firmware is not perfect either, since it seems to suffer from a
>> >> different
>> >> bug that has been resolved in the official firmwares, and that is that
>> after a
>> >> reboot of my TP-Link Archer C7 v2, the ath10k driver won't load. Only 
>> >> after
>> a
>> >> hard reset or "cold boot" it will come up. That's an issue I had with 
>> >> older
>> >> official firmwares as well, but it has been resolved with the recent API
>> level
>> >> 5 firmwares.
>> >>
>> >> Nevertheless, for the time being, I will stick to the CT firmware because 
>> >> I
>> >> can
>> >> work around the reboot issue and having the 5GHz wifi working for my Nexus
>> 5X
>> >> clients is more important.
>> >>
>> >> Over the next weeks, I will test different combinations of ath10k(-ct)
>> driver
>> >> and firmware to see if there's a combination that resolves all issues. 
>> >> This
>> >> morning I flashed a LEDE build with the official ath10k driver and the CT
>> >> firmware binary.
>> >>
>> >> But of course, if someone has more suggestions on what I could try or what
>> >> information I could collect to help resolve the issue related to the Nexus
>> 5X
>> >> clients in the official firmware binaries, I think that would be 
>> >> beneficial
>> >> for a larger audience.
>> >>
>> >> Regards,
>> >>
>> >> Timo
>> >>
>> >> P.S.: Please include my email address in any reply, since I'm not
>> subscribed
>> >> to the mailing list. Thank you.
>> >>
>> >>
>> >> Timo Sigurdsson schrieb am 29.10.2016 22:19:
>> >>
>> >>> Hi everybody,
>> >>>
>> >>> I have a TP-Link Archer C7 v2 running a fairly recent build of LEDE
>> (r1952,
>> >>> Linux 4.4.26, compat-wireless-2016-10-08). It all works well except for
>> the
>> >>> fact that when I connect a Nexus 5X device to the 5GHz radio, the kernel
>> or
>> >>> ath10k driver will crash after a while. 5Ghz wifi will be dead after that
>> >>> until I reboot the system.
>> >>>
>> >>> This issue has been reported before [1] and it also has been declared as
>> >>> solved with newer firmwares [2] (but reopened by other users). However,
>> even
>> >>> with the latest firmware 10.2.4.70.58 from Kalle Valo's Github repository
>> the
>> >>> issue is far from resolved. I have tried many different firmware 
>> >>> revisions
>> >>> over the time (more recently 10.2.4.70.56 and 10.2.4.70.54), and I can
>> could
>> >>> only find that the issue sometimes takes longer to trigger with some
>> >>> firmwares
>> >>> (which might just be random), but it would always occur at some point 
>> >>> with
>> >>> API
>> >>> level 5 firmwares. With API level 2 firmwares (which I testesd when I was
>> >>> still using OpenWrt 15.05) I never saw these crashes, but the Nexus 5X 
>> >>> had
>> >>> other connectivity issues with these older firmwares that made this
>> >>> combination no fun to use either. But this shows that the firmware itself
>> >>> makes the difference here.
>> >>>
>> >>> I actually have two Nexus 5X on my network (my wife's and my own). I can
>> >>> trigger the 

Re: [LEDE-DEV] [PATCH] ath9k: Add airtime fairness scheduler

[Weedy]

On Sun, Nov 27, 2016 at 11:01 AM, Toke Høiland-Jørgensen  wrote:
> Weedy  writes:
>
>> On Fri, Nov 25, 2016 at 5:16 AM, Toke Høiland-Jørgensen  wrote:
>>> This adds a patch that introduces airtime fairness scheduling to ath9k,
>>> which can significantly improve network efficiency in mixed-rate
>>> environments.
>> ...
>>> ++  astats = >airtime_stats;
>>> ++
>>> ++  len += scnprintf(buf + len, size - len, "RX: %u us\n", 
>>> astats->rx_airtime);
>>> ++  len += scnprintf(buf + len, size - len, "TX: %u us\n", 
>>> astats->tx_airtime);
>>> ++  len += scnprintf(buf + len, size - len, "Deficit: ");
>>> ++  for (i = 0; i < 4; i++)
>>> ++  len += scnprintf(buf+len, size - len, "%s: %lld us ", 
>>> qname[i], an->airtime_deficit[i]);
>>> ++  if (len < size)
>>> ++  buf[len++] = '\n';
>>> ++
>>> ++  retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
>>> ++  kfree(buf);
>>> ++
>>> ++  return retval;
>>> ++}
>>
>> I'm supposed to have a
>> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/something/airtime
>> right?
>
> Yeah, you should. Do you have
> /sys/kernel/debug/ieee80211/phy0/ath9k/airtime_flags ?

Yes I do. It's set to 7

>> Should I have done anything else besides:
>> # curl https://patchwork.ozlabs.org/patch/699159/raw/ | git apply -v
>> # make V=s package/mac80211/{clean,install}
>
> [..]
>
> No, don't think so. Did you reload the right kernel modules after
> installing the updated kmod package? You'll need to reload at least the
> 'ath' and 'ath9k' modules...
>
> -Toke

I flashed the resulting image, so full reboot.

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

Re: [LEDE-DEV] enhanced 3G support

[Bjørn Mork]

"Giuseppe Lippolis"  writes:

> Dear Bjørn,
>
>> Nice.  The "M-MBIM" is a bit confusing, though.  This doesn't seem to have
>> anything to do with MBIM?
>> 
> I'm just recompiled an image with mbim, ncm support.
>
> But I don't know if it is the right driver.
> If I send the cmd 
> echo '2001 7d04'> /sys/bus/usb/drivers/cdc_ncm/new_id
>
> I get:
> [ 1984.505162] cdc_ncm 1-1:1.1: no of_node; not parsing pinctrl DT
> [ 1984.505366] cdc_ncm 1-1:1.2: no of_node; not parsing pinctrl DT
> [ 1984.505480] cdc_ncm 1-1:1.3: no of_node; not parsing pinctrl DT
> [ 1984.505592] cdc_ncm 1-1:1.4: no of_node; not parsing pinctrl DT
> [ 1984.505704] cdc_ncm 1-1:1.5: no of_node; not parsing pinctrl DT
> [ 1984.505816] cdc_ncm 1-1:1.6: no of_node; not parsing pinctrl DT

No, no, the cdc_ether driver is definitely the correct one.  NCM or MBIM
won't work unless you can make the device morph into another mode. But
since you know how to manage it in cdc_ether mode, and that is the
native mode, I see no reason to mess with it.
>
>> See e.g the 'directip' or 'ncm' protocols implemented in the comgt package.
>> They are very similar, using AT commands to manage a network interface. It
>> should be possible to use the same tricks as in
>> proto_directip_setup() to map between serial device and network device for
>> example.
>> 
> I'm going to recompile also the directip.
>
> By the way in the package/network/utils/wwan/files/data dir  I found the
> 2001-7d03
>
> I'm currently using this as base file for my 2001-7d04 data file.
> I guess that if the 7d03 is supported the 7d04 will be the same (99%).

Not necessarily. The firmware base could be the same, but the modem
layout depends on which firmware features they decided to make
available.

I actually have one the D-Link dongles with a similar ID. It's an
DWM-156A7 I got from Mediatek as an early example of their MBIM
implementation.  It is a mode switching dongle which turns into MBIM (of
course) + serial:

P:  Vendor=2001 ProdID=7d01 Rev= 3.00
S:  Manufacturer=D-Link,Inc  
S:  Product=D-Link DWM-156
C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim
E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=125us
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=500us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms


I don't think it is relevant for you, though.  You should continue your
initial idea, creating a "proto" supporting the AT managed cdc_ether
based modem.




Bjørn

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

Re: [LEDE-DEV] QCA Dakota support

[Alexis Green]

Hi Christian,

Could you post .config for your build? I cloned your repo and
successfully built and installed an image, but I'm seeing some rather
weird behavior.

I get kernel oops (null derefrence) in bridge code when I connect a
client to WPA2 AP that is bridged. The oops is gone after I removed
the following patches (I'm sure it's just one of them, but I have not
had a chance  to figure out which one exactly it is).
target/linux/generic/patches-4.8/120-bridge_allow_receiption_on_disabled_port.patch
target/linux/generic/patches-4.8/640-bridge_no_eap_forward.patch
target/linux/generic/patches-4.8/641-bridge_always_accept_eap.patch

I'm also seeing rather fast memory leak/wastage when wireless devices
are up - takes 10-15 min to run out of memory. I tried using kmemleak,
but it doesn't report any suspected leaks. I guess I'll try some
tracing next.

Best regards,

Alexis

On Wed, Nov 23, 2016 at 3:45 PM, Christian Lamparter
 wrote:
> Hi Christian,
>
> On Wednesday, November 23, 2016 10:13:45 PM CET Christian Mehlis wrote:
>> your current staging tree works for me, it generates an itb and a trx
>> file!
>> I added some files to support the Compex board I own:
>> https://github.com/mehlis/source/commits/compex-wpj428
>>
>> Feel free to include some bits in your tree. I had to add dk04-c5
>> support, perhaps you know some other way?
>> My commit is compile tested only.
> I looked at it. But you need to consider what I previously wrote (in the
> second to last mail?):
>
> "the kernel devicetree maintainers frown upon "catch-all" compatible strings 
> [0]."
>
> This means that you have to replace all the generic "qcom,*ipq40xx*" with
> "qcom,*ipq4028*" in your dts and dtsi. Next, you have to add the bindings
> to the kernel platform and driver code, so the device-tree will find the
> driver for hardware definitions in your dtb. (Alternatively, you can
> add the appropriate "qcom,*ipq4019*" binding)
>
>> Please be more precise on the flashing steps. I would like to flash from
>> uboot. I never had a board running ubifs. QCA provides a img file, so
>> I'm a bit lost here.
> I added an entry on how to boot the initramfs on the ASUS. And since that's
> the only IPQ40XX device I have, I can only give "precise informations" for
> it.
>
> For the Asus RT-AC58U, it's very simple. During boot, you have this 1-2 Second
> window to select the following option:
>
> Please choose the operation:
>1: Load System code to SDRAM via TFTP.
>2: Load System code then write to Flash via TFTP.
>3: Boot System code via Flash (default).
>4: Entr boot command line interface.
>7: Load Boot Loader code then write to Flash via Serial.
>9: Load Boot Loader code then write to Flash via TFTP.
>
> And for the initramfs image. you just hit (1). It then continues to ask
> about the IP, tftp server ip and tftp image name (obviously that's the
> lede-ipq40xx-RT-AC58U-initramfs-fit-uImage.itb file in the tftp's server
> directory). and that's it: it automatically boots.
>
> Note: Currently, a working flash image is not implemented. But, you don't
> need to flash the image in order to test it. The initramfs image is simply
> loaded into the SDRAM and it boots from there. (The rootfs is part
> of the initramfs image). Using initramfs is much better for development,
> since you don't need to wait it to flash (The SPINAND is very slow and
> also you'll burn through the NAND quite quickly)
>
> Regards,
> Christian
>
> [0] 
>
> BTW: If you have any questions, you can also find me on google hangouts
> (with the same gmail). Note: If you have an "unusual mail/nick"* there,
> just let me know beforehand via email as I tend to ignore unknown
> requests :-) )
>
> * not something that resembles your name.
>
> ___
> 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] enhanced 3G support

[Giuseppe Lippolis]

Dear All,
I currently add supprt for the dwr-512 device on LEDE.
This device have a 3G modem embedded.
The current available configuration uses the usb-option to establish the 3G
connection over ppp.
Nevertheless the modem offer one cdc-ether interface with better
performance.

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=2001 ProdID=7d04 Rev= 3.00
S:  Manufacturer=D-Link,Inc
S:  Product=D-Link DWM-158
C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
A:  FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=cdc_ether
E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=125us
I:  If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option
E:  Ad=87(I) Atr=03(Int.) MxPS=  64 Ivl=125us
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

It seems to me that currently this kind of "protocol" is not supported in
LEDE.
In particular I'm unable to found an interface type in the
/etc/config/network to setup this kind of connection.

Currently I'm able to establish a connection setting the interface in
"manual" mode.

To do this I setup an usb interface

config interface 'wan3g'
option ifname 'usb0'
option proto 'dhcp'

then I need to send manually the following command to the /dev/ttyUSB0 to
establish the 3G connection:

AT+CFUN=1
AT+CPIN=""
AT+CREG?
> +CREG: 2,1,"1CE3","0BCA3360",6 (6=UTRAN w/HSDPA and HSUPA)
AT+CGDCONT=1,"IP","",0,0
AT+CGACT=1,1
AT+CGACT?
AT+CGPADDR=1
>> +CGPADDR: 1, "109.42.15.170"
AT+CGPRCO?
>> +CGPRCO: 1, "139.7.30.126", "139.7.30.125", "", ""
AT+CGDATA="M-MBIM",1,1

at this point the IF is UP and working:
usb0  Link encap:Ethernet  HWaddr 02:00:FF:AA:AA:AA
  inet addr:109.42.15.170  Bcast:109.42.15.171  Mask:255.255.255.252
  inet6 addr: fe80:::feaa:/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:314 errors:0 dropped:0 overruns:0 frame:0
  TX packets:360 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:29855 (29.1 KiB)  TX bytes:33129 (32.3 KiB)

  
Can someoune help me in introduce the handling of this "protocol" in LEDE?

Thanks,
Bye.


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

Re: [LEDE-DEV] [PATCH] ath9k: Add airtime fairness scheduler

[Weedy]

On Fri, Nov 25, 2016 at 5:16 AM, Toke Høiland-Jørgensen  wrote:
> This adds a patch that introduces airtime fairness scheduling to ath9k,
> which can significantly improve network efficiency in mixed-rate
> environments.
...
> ++  astats = >airtime_stats;
> ++
> ++  len += scnprintf(buf + len, size - len, "RX: %u us\n", 
> astats->rx_airtime);
> ++  len += scnprintf(buf + len, size - len, "TX: %u us\n", 
> astats->tx_airtime);
> ++  len += scnprintf(buf + len, size - len, "Deficit: ");
> ++  for (i = 0; i < 4; i++)
> ++  len += scnprintf(buf+len, size - len, "%s: %lld us ", 
> qname[i], an->airtime_deficit[i]);
> ++  if (len < size)
> ++  buf[len++] = '\n';
> ++
> ++  retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
> ++  kfree(buf);
> ++
> ++  return retval;
> ++}

I'm supposed to have a
/sys/kernel/debug/ieee80211/phy0/netdev\:wlan0/stations/something/airtime
right?
Should I have done anything else besides:
# curl https://patchwork.ozlabs.org/patch/699159/raw/ | git apply -v
# make V=s package/mac80211/{clean,install}
Applying ./patches/326-ath9k-Introduce-airtime-fairness-scheduling.patch
using plaintext:
patching file drivers/net/wireless/ath/ath9k/ath9k.h
patching file drivers/net/wireless/ath/ath9k/channel.c
patching file drivers/net/wireless/ath/ath9k/debug.c
patching file drivers/net/wireless/ath/ath9k/debug.h
patching file drivers/net/wireless/ath/ath9k/debug_sta.c
patching file drivers/net/wireless/ath/ath9k/init.c
patching file drivers/net/wireless/ath/ath9k/main.c
patching file drivers/net/wireless/ath/ath9k/recv.c
patching file drivers/net/wireless/ath/ath9k/xmit.c

# 

Sat Nov 26 16:39:31 2016 kern.warn kernel: [   11.595812] PCI:
Enabling device :00:11.0 ( -> 0002)
Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.606388] ath: phy0:
Ignoring endianness difference in EEPROM magic bytes.
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614943] ath: EEPROM
regdomain: 0x0
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614952] ath: EEPROM
indicates default country code should be used
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614960] ath: doing
EEPROM country->regdmn map search
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614975] ath:
country maps to regdmn code: 0x3a
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614985] ath:
Country alpha2 being used: US
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.614993] ath:
Regpair used: 0x3a
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.628327] ieee80211
phy0: Selected rate control algorithm 'minstrel_ht'
Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.632241] ieee80211
phy0: Atheros AR9280 Rev:2 mem=0xb000, irq=40
Sat Nov 26 16:39:31 2016 kern.warn kernel: [   11.697119] PCI:
Enabling device :00:12.0 ( -> 0002)
Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.707690] ath: phy1:
Ignoring endianness difference in EEPROM magic bytes.
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716278] ath: EEPROM
regdomain: 0x0
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716289] ath: EEPROM
indicates default country code should be used
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716297] ath: doing
EEPROM country->regdmn map search
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716313] ath:
country maps to regdmn code: 0x3a
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716322] ath:
Country alpha2 being used: US
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.716330] ath:
Regpair used: 0x3a
Sat Nov 26 16:39:31 2016 kern.debug kernel: [   11.731825] ieee80211
phy1: Selected rate control algorithm 'minstrel_ht'
Sat Nov 26 16:39:31 2016 kern.info kernel: [   11.735844] ieee80211
phy1: Atheros AR9280 Rev:2 mem=0xb001, irq=41

I can't seem to tell if I have the patched driver loaded. Unless
rc_stats counts?
  best   rate__
statisticslast___
__sum-of
mode guard #  rate  [name   idx airtime  max_tp]  [avg(tp) avg(prob)
sd(prob)]  [prob.|retry|suc|att]  [#success | #attempts]

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

Re: [LEDE-DEV] [PATCH v5 2/3] ipq806x: Add support for new device: tew827dru

[Mathias Kresin]

27.11.2016 06:28, J Mo:

diff --git a/target/linux/ipq806x/image/Makefile 
b/target/linux/ipq806x/image/Makefile
index 3cc48bb..01bcbc7 100644
--- a/target/linux/ipq806x/image/Makefile
+++ b/target/linux/ipq806x/image/Makefile
@@ -103,6 +103,49 @@ define Device/ZyXELImage
IMAGE/mmcblk0p4-kernel.bin := append-kernel
 endef

+define Build/mkfit-TEW827DRU
+   $(TOPDIR)/scripts/its-maker.sh \
+   --device $(DEVICE_NAME) \
+   -O $@.its \
+   --img-name 0 script \
+   --img-descr 0 "u-boot-HTTP firmware update script" \
+   --img-file 0 
$(TOPDIR)/target/linux/ipq806x/image/tew827dru-flash.scr \
+   --img-type 0 script --img-arch 0 $(ARCH) \
+   --img-compression 0 none \
+   --img-hashes 0 crc32 \
+   --img-name 1 ubi-image \
+   --img-descr 1 "UBI rootfs image" \
+   --img-file 1 $@ \
+   --img-type 1 firmware \
+   --img-arch 1 $(ARCH) \
+   --img-compression 1 none \
+   --img-hashes 1 crc32 \
+   --img-name 2 bootconfig \
+   --img-descr 2 "BOOTCONFIG: boot from APPSBL and rootfs" \
+   --img-file 2 
$(TOPDIR)/target/linux/ipq806x/image/tew827dru-bootconfig.bin \
+   --img-type 2 firmware \
+   --img-arch 2 $(ARCH) \
+   --img-compression 2 none \
+   --img-hashes 2 crc32
+   PATH=$(LINUX_DIR)/scripts/dtc:$(PATH) mkimage -f $@.its $@.fit
+   @rm $@.its
+   @mv $@.fit $@
+endef
+
+define Build/cameo-sig
+   { \
+   cameo_sig=$(word 1, $(1)) ;\
+   align=$(if $(2),$(2),64) ;\
+   oldsize=$$(stat -c %s $@) ;\
+   sigsize=$$(echo -n $$cameo_sig | wc -c) ;\
+   padsize=$$(( ( ( ( ( ( $$oldsize + $$sigsize ) / $$align ) + 1 
) * $$align ) - $$oldsize ) - $$sigsize )) ;\
+   newsize=$$(( $$oldsize + $$padsize )) ;\
+   dd if=$@ of=$@.new bs=$$newsize count=1 conv=sync ;\
+   echo -n "$$cameo_sig" >> $@.new ; \
+   }
+   @mv $@.new $@
+endef


I asked you three (!) times to _explain_ what this code should do 
[0][1][2]. Now I see the very same code again without having ever seen 
the requested explanation.


This still looks like the hackish image code that was required with the 
old image build system. I guess most of the stuff can be done with the 
existing build helpers.


To say it with easy understandable words: This patch will not be merged 
till I get an understandable answer what this code should do. I do not 
even consider doing a review before I get this answer.


Mathias

[0] http://lists.infradead.org/pipermail/lede-dev/2016-September/002677.html
[1] http://lists.infradead.org/pipermail/lede-dev/2016-September/002681.html
[2] http://lists.infradead.org/pipermail/lede-dev/2016-September/002744.html

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