[OpenWrt-Devel] [PATCH] ath79: add support for TP-Link TL-MR6400

Fri Jan 17 07:21:51 EST 2020

Hi,

I've just sent an updated patch ("v4") to the list.

Some comments below.

> -----Original Message-----
> From: Filip Moc [mailto:lede at moc6.cz]
> Sent: Donnerstag, 16. Januar 2020 22:27
> To: Adrian Schmutzler <mail at adrianschmutzler.de>
> Cc: 'Enrico Mioso' <mrkiko.rs at gmail.com>; openwrt-devel at lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] ath79: add support for TP-Link TL-MR6400
> 
> Hi,
> 
> > Would you provide a proper Tested-by?
> Sure, you can add "Tested-by: Filip Moc <lede at moc6.cz>" line as needed.
> 
> > We will definitely have to use ucidef_set_led_switch here. Are you sure about
> the port mask?
> Yes I checked.
> 0x2 = LAN1, 0x4 = LAN3, 0x8 = LAN2   so   0x2 | 0x4 | 0x8 = 0xE
> 
> > What about the port order? Can you please verify the assignment of external
> port number vs. internal ports (just stupidly connect a cable and check with
> swconfig which port it is attached to)?
> Matches ordering above.
> switch0 Port 0 = SoC
> switch0 Port 1 = External LAN1
> switch0 Port 2 = External LAN3
> switch0 Port 3 = External LAN2
> switch0 Port 4 = always down

Okay, so my current reassignment for LuCi is correct.

> 
> > Can you provide a detailed explanation of what you observe (what do you use
> for visualization of "link status detection")?
> Simply type "ip link show dev eth0". When there is a link on any port of switch
> it should be UP with carrier (not saying "NO-CARRIER"). When there is no link
> on any external switch port it should say "NO-CARRIER".
> This works fine on ar71xx. On ath79 it never says "NO-CARRIER" on eth0 even
> when there's no cable connected to switch at all.
> Another way to check for carrier is "cat /sys/class/net/eth0/carrier".
> This is always 1 on ath79.
> 
> This causes some problems such as LED not showing link status with netdev
> trigger and device won't behave optimally in many obvious network situations.
> And of course also breaks user scripts relying on eth0 link detection.
> 
> Also when you're remotely troubleshooting some network issues one of first
> things you do after you ssh to the device is usually typing "ip a". It can save
> you a lot of time when you see NO-CARRIER on eth0 when it shouldn't be there.
> This way it's confusingly telling the opposite.

I understand. I added a corresponding remark to known issues. However, I do not consider this a blocker for merging.
This would be something where 981213 could enlighten us, but I think he is short on time at the moment.

> 
> > Do you refer to something specific in the boot process when you say
> "unreliable boot", or is this just backed up by the observation of the non-working
> LTE module? At the moment, this sounds to me like we could just put it in
> "Known issues". Can you provide a short piece of text for that (to be put in the
> commit message)?
> Sometimes after boot LTE module is not working (not visible as USB device at all).
> Relevant lines in dmesg:
> [    5.662821] usb 1-1: new high-speed USB device number 2 using ehci-platform
> [   10.884716] usb 1-1: device descriptor read/64, error -145
> [   16.244841] usb 1-1: device descriptor read/64, error -71
> [   16.574819] usb 1-1: new high-speed USB device number 3 using ehci-platform
> [   21.799081] usb 1-1: device descriptor read/64, error -145
> [   27.174820] usb 1-1: device descriptor read/64, error -71
> [   27.294901] usb usb1-port1: attempt power cycle
> [   28.116145] usb 1-1: new high-speed USB device number 4 using ehci-platform
> [   33.574719] usb 1-1: device not accepting address 4, error -71
> [   33.724710] usb 1-1: new high-speed USB device number 5 using ehci-platform
> [   39.174715] usb 1-1: device not accepting address 5, error -71
> [   39.180824] usb usb1-port1: unable to enumerate USB device
> 
> Possible workaround is to check whether LTE module is available after boot.
> E.g. interface usb0 is present, 'adb devices' shows the device, relevant
> symlinks are present in /sys/bus/usb/devices/.
> When LTE module is not available power-cycle it. E.g by running this command:
> (cd /sys/class/gpio/tp-link\:power\:lte/ && echo 0 > value && sleep 1 && echo 1
> > value)

Same as above: I'm in favor of burying this as known issue for now. I'm not sure yet whether we should include the workaround in the commit message or whether this is too "trivial" ;-).

> 
> > Are there bug report/discussions to link?
> Enrico mentioned it earlier in this thread and also reported it to me few years
> ago (on ar71xx). He also did some research on why it does work on stock
> firmware. Though he didn't seem to find any obvious workaround used by stock
> firmware. Maybe Enrico could post his findings here.
> I don't recall anyone else who reported this but I doubt there won't be anyone
> else affected.
> Since I have this problem only on ath79 and Enrico has this problem also on
> ar71xx it is also possible that there are in fact two different problems.
> 
> > And does the device have a MAC address printed on it? I would assume the
> one from WiFi?
> wlan0 has exact match with mac address printed on the label.
> eth0 is -1 and eth1 is +1 relative to wlan0.

Thanks, I added label-mac-device to the DTS accordingly.

Best

Adrian

> 
> 
> Filip
> 
> 
> On Thu, Jan 16, 2020 at 12:25:58PM +0100, Adrian Schmutzler wrote:
> > Hi,
> >
> > thanks for your feedback.
> >
> > I currently consider merging this (considering your reply on my questions
> below) and would include the few minor remaining issues as "Known issues" in
> the commit message.
> >
> > Would you provide a proper Tested-by?
> >
> > > -----Original Message-----
> > > From: Filip Moc [mailto:lede at moc6.cz]
> > > Sent: Donnerstag, 16. Januar 2020 09:31
> > > To: mail at adrianschmutzler.de
> > > Cc: 'Enrico Mioso' <mrkiko.rs at gmail.com>; openwrt-devel at lists.openwrt.org
> > > Subject: Re: [OpenWrt-Devel] [PATCH] ath79: add support for TP-Link TL-
> MR6400
> > >
> > > Hi Adrian,
> > >
> > > thanks a lot for patch.
> > >
> > > I tested it on current trunk (bda6b6144d) and I can confirm that:
> > > 1. Works as expected, LTE can be turned off/on and value works as expected
> > > (0=off,1=on).
> > > 2. Works as expected. LTE module's httpd is started after boot and LTE
> module's
> > > web interface is available.
> > > 3. Seems to be working just fine. eth0 is still connected to switch (ports LAN1
> to
> > > LAN3) while eth1 is connected to LAN4/WAN.
> >
> > What about the port order? Can you please verify the assignment of external
> port number vs. internal ports (just stupidly connect a cable and check with
> swconfig which port it is attached to)?
> >
> > > 4. Interfaces are working just fine. Except for obvious problem with eth0
> which
> > > has no link status detection.
> >
> > Can you provide a detailed explanation of what you observe (what do you use
> for visualization of "link status detection")?
> >
> > > 5. Seems to be working just right. Even LAN LED turns off when I manually set
> > > eth0 interface down from shell.
> > >
> > > I also tested buttons which still work fine.
> > >
> > > Problem with link detection on eth0 which always reports interface as UP with
> > > carrier even when there's nothing connected to switch remains unresolved.
> > > I'd be willing to help with link detection but there already seems to be some
> > > specific solution expected and I don't know what exactly is the expected way
> to
> > > solve it.
> > > So far ucidef_set_led_switch with port mask 0x0E can at least be used as a
> > > workaround to make LAN LED show link detection on LAN ports (though this
> also
> > > has negative impact on link activity visualisation).
> >
> > We will definitely have to use ucidef_set_led_switch here. Are you sure about
> the port mask?
> >
> > I will update my staging tree with the current value.
> >
> > >
> > > Also the problem with unreliable boot causing LTE module to not always work
> > > after boot is still present. This can be workarounded by turning LTE module
> off
> > > and on again. I don't have this problem on ar71xx where LTE module always
> > > realiably works just fine after boot. Though Enrico reported that he has this
> > > problem even on ar71xx.
> >
> > Do you refer to something specific in the boot process when you say
> "unreliable boot", or is this just backed up by the observation of the non-working
> LTE module? At the moment, this sounds to me like we could just put it in
> "Known issues". Can you provide a short piece of text for that (to be put in the
> commit message)? Are there bug report/discussions to link?
> >
> > Best
> >
> > Adrian
> >
> > >
> > > Anyway good progress, thanks for your work.
> > >
> > > Filip
> > >
> > >
> > > On Mon, Jan 06, 2020 at 01:23:22AM +0100, mail at adrianschmutzler.de wrote:
> > > > Hi Enrico,
> > > >
> > > > > -----Original Message-----
> > > > > From: Enrico Mioso [mailto:mrkiko.rs at gmail.com]
> > > > > Sent: Dienstag, 17. September 2019 19:59
> > > > > To: mail at adrianschmutzler.de
> > > > > Cc: Filip Moc <lede at moc6.cz>; openwrt-devel at lists.openwrt.org
> > > > > Subject: RE: [OpenWrt-Devel] [PATCH] ath79: add support for TP-Link TL-
> > > > > MR6400
> > > > >
> > > > > Thanks! I'll take a look now.
> > > > > Still, something should be interestingly wrong here:
> > > > >
> > > > > root at OpenWrt:/# swconfig dev switch0 show|grep -i link
> > > > >          link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
> > > > >          link: port:1 link:up speed:100baseT full-duplex auto
> > > > >          link: port:2 link:down
> > > > >          link: port:3 link:down
> > > > >          link: port:4 link:down
> > > > > root at OpenWrt:/#
> > > >
> > > > I've just unearthed this topic in my mailbox and tried a port myself based on
> > > your V2 patch.
> > > >
> > > > You will find the updated version in a branch of my staging repo here:
> > > >
> > >
> https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads
> > > /mr6400
> > > >
> > > > (Most recent patch there.)
> > > >
> > > > Despite several minor issues (sorting, rebase, etc.) I've also addressed the
> > > following major issues:
> > > > 1. Use gpio-export again instead of gpio-hog, so LTE can be switched on/off
> > > > 2. Added adb-enablemodem
> > > > 3. Removed the phy-swap in DTS. This is not present in the mach-file for
> > > mr6400, only in the one for the fritzbox 4020 you took as blueprint.
> > > > 4. Adjusted ports 2 vs. 3 in 02_network based on your assessment. This will
> > > most probably be wrong again now, as this might be influenced by the phy-
> swap.
> > > > 5. LAN/WAN LEDs still won't work properly, as at least one will need to be
> > > changed to ucidef_set_led_switch, and I cannot check that without the
> device.
> > > >
> > > > Best
> > > >
> > > > Adrian
> > >
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200117/15f978e9/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel