QCA9531 network

[zhangsd20]

Describe the bug

openwrt22.03 I have two etherports (eth0 and eth1) on my router, and eth0 always shows a connection when I don't have a network cable

root@OpenWrt:/# cat /sys/class/net/eth0/carrier 1 root@OpenWrt:/# cat /sys/class/net/eth1/carrier 0

With or without a network cable, eth0 always displays 1( cat /sys/class/net/eth0/carrier)

Is this normal? If this is a bug how it should be fixed?(openwrt19.07 is ok)

OpenWrt version

22.03

OpenWrt target/subtarget

ath79

Device

e600g

Image kind

Self-built image

Steps to reproduce

No response

Actual behaviour

No response

Expected behaviour

No response

Additional info

No response

Diffconfig

No response

Terms

• [X] I am reporting an issue for OpenWrt, not an unsupported fork.

[DragonBluep]

This problem seems caused by dc power supply current leaks to the poe port.

[brada4]

SoC contains 5-port switch. That port can be always up. Could you specify exact router model?

[zhangsd20]

But, I tested on openwrt 19.07 and 18.06 without this issue

[zhangsd20]

Testing on openwrt 22.03 only the eth0 port had this issue. I think it might be an issue inside ath79.

[brada4]

You have to provide more hardware detail. Basic function of PoE is 'leaking DC' to a client device. SoC you mention does not include PoE injector.

[zhangsd20]

https://openwrt.org/toh/qxwlan/e600g

This is the device information I tested this time. If it's a device issue, then why isn't there this issue on 19.07 and 18.06?

[DragonBluep]

I am 100% certain that this issue is related to the PoE port, as I also have a similar board. During the switch from ar71xx to ath79, some features of the phy driver seem to have been lost.

[zhangsd20]

Thanks. Is there a solution to this problem? From hardware or software?

[DragonBluep]

Thanks. Is there a solution to this problem? From hardware or software?

Adding some phy connection detection code into the driver should solve the problem. Although I don't know exactly how to do it.

[DragonBluep]

You have to provide more hardware detail. Basic function of PoE is 'leaking DC' to a client device. SoC you mention does not include PoE injector.

These devices have two power supplies. What I mean is that the current leaks from the usual DC port to the PoE. This mistakenly triggered RJ45 connection detection.

[DragonBluep]

If you follow what you say, it should be a hardware problem, not a software problem. However, there is no problem on 19.07 and 18.06. It's just that the software version is different.

Firstly, this is a hardware issue, but it can be solved on software side. And then, if my hypothesis is correct, paralleling a resistor to the PoE port should also solve the problem.

[brada4]

Or to pjnpoint issue if there is separate PoE DC in[ut pin - disconnect thatband see if port is still unnecesarily up.

[tmn505]

Check if this PR https://github.com/openwrt/openwrt/pull/9971 solves Your issue.

[zhangsd20]

https://github.com/openwrt/openwrt/commit/74c976f5b21fec54bafc436993f692d8530ca099

&eth1 { status = "okay"; + phy-handle = <&swphy0>;

nvmem-cells = <&macaddr_board_data_66>;
nvmem-cell-names = "mac-address";

+ /delete-node/ fixed-link; gmac-config { device = <&gmac>; switch-phy-swap = <0>; } }

I tested and found that adding code on the patch solved this problem. Since this problem was discovered, why didn't anyone solve it and merge it into OpenWRT?

[tmn505]

I tested and found that adding code on the patch solved this problem. Since this problem was discovered, why didn't anyone solve it and merge it into OpenWRT?

Not enough testers and reports it works, and apparently does not solve the issue for some Mikrotik board (they usually do some funky stuff with their design). Nonetheless please report Your test result in the mentioned PR.

[zhangsd20]

Ok, thanks!

Do I need to create a pr to add code on my device?

在2023年06月02 @.***>写道：

I tested and found that adding code on the patch solved this problem. Since this problem was discovered, why didn't anyone solve it and merge it into OpenWRT? Not enough testers and reports it works, and apparently does not solve the issue for some Mikrotik board (they usually do some funky stuff with their design). Nonetheless please report Your test result in the mentioned PR. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[tmn505]

Do I need to create a pr to add code on my device?

You could make PR for it and mentioning it depends on 9971 PR, that way it'll trigger committers to again evaluate the stale PR.

[mrkiko]

I encountered this problem when porting the TP-Link MR6400 V1 to ath79: while in ar71xx all worked correctly, in ath79 I got problems with cable detection. So I'm pretty convinced this is a driver/problem issue.