On Mon, May 25, 2015 at 4:08 PM, Aleksander Wałęski <olewa...@gmail.com> wrote:
>> Maybe you and Aleksander can try this patch again? > > Sure, I'll flash my device with this and let it run for some time to > see if there are any problems. > Ok, I tested your latest patch and everything seems to work but I suggest following build flag changes (which I tested in my build): add --enable-debug-prints=err to ltq-vdsl-app and change enable-debug-prints to err in ltq-vdsl-vr9. Default debug level in api seems to be higher, thats why it caused so much spam in kernel log. "err" seems to be fine. I didn't notice any messages in dmesg during normal operation nor any other side effects to this. And it might provide very useful info if something goes wrong. This is much more important for vdsl_cpe_control app, and that is the reason why I started to mess with compilation flags to begin with. with debug prints disabled it strips all help text in the console which makes playing with it somewhat frustrating. Here is an example of output of the same command with debug-prints=off on ltq-vdsl-app: DSL_CPE#>acos nReturn=-1 (wrong number of parameters/help not available) and with debug-prints=err DSL_CPE#>acos Long Form: AutobootConfigOptionSet Short Form: acos Input Parameter - DSL_boolean_t bWaitBeforeConfigWrite false = 0 true = 1 - DSL_boolean_t bWaitBeforeLinkActivation false = 0 true = 1 - DSL_boolean_t bWaitBeforeRestart false = 0 true = 1 - DSL_boolean_t bAutoContinueWaitBeforeConfigWrite (dsl_cpe_control) false = 0 true = 1 - DSL_boolean_t bAutoContinueWaitBeforeLinkActivation (dsl_cpe_control) false = 0 true = 1 - DSL_boolean_t bAutoContinueWaitBeforeRestart (dsl_cpe_control) false = 0 true = 1 Output Parameter - DSL_Error_t nReturn Additionally, I added --disable-dsl-ceoc to ltq-vdsl-app since CEOC is disabled in API by default anyway. Again, can someone with ADSL line test what parameters vdsl_cpe_control actually needs to operate with newest driver and firmware version (from W9980)? I accidentally compiled driver with high debbuging level at one point and got this in kernel log: ========== Port Mode Control (default) =========== [ 438.848000] [ 438.848000] Dual Port Lock : UNLOCKED xDSL Mode Lock : UNLOCKED [ 438.848000] [ 438.848000] Preferred Port Mode : SINGLE Preferred xDSL Mode : VDSL [ 438.848000] [ 438.848000] Current Port Mode : NONE Current xDSL Mode : NONE [ 438.848000] [ 438.848000] ================================================== [ 438.848000] ========== Port Mode Control (current) =========== [ 438.848000] [ 438.848000] Dual Port Lock : LOCKED xDSL Mode Lock : LOCKED [ 438.848000] [ 438.848000] Preferred Port Mode : SINGLE Preferred xDSL Mode : VDSL [ 438.848000] [ 438.848000] Current Port Mode : SINGLE Current xDSL Mode : VDSL [ 438.848000] [ 438.848000] ================================================== This makes me wonder if maybe TP-LINK firmware is just prepared to support VDSL by default, but needs a startup parameter to support ADSL. I still don't think it needs "low level config" though. It makes sense not to require end user to know annex/tone group connection requires. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
