Skip to content

[RFC] ipq40xx: fix port 1 status for IPQ40xx switches #3491

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

DavideFioravanti
Copy link
Contributor

Currently in ar40xx_phy_read_status and ar40xx_phy_config_aneg
functions there is a check which, presumably, should fail if the port
doesn't exists.

However in the current implementation, this check seems to be pointless
and moreover prevents the port 1 of the switch to be correctly enabled
if polling is required.

This commit fixes the last issue.

Even if these changes are more or less acked by other developers in this thread and should be even safe to completely remove the ar40xx_phy_read_status and ar40xx_phy_config_aneg functions, I can't be 100% sure that won't negatively impact other ipq40xx devices. Because of this I am marking this PR with RFC.

This commit fixes the "wan port" problem for this device.

Signed-off-by: Davide Fioravanti pantanastyle@gmail.com

Currently in ar40xx_phy_read_status and ar40xx_phy_config_aneg
functions there is a check which, presumably, should fail if the port
doesn't exists.

However in the current implementation, this check seems to be pointless
and moreover prevents the port 1 of the switch to be correctly enabled
if polling is required.

This commit fixes the last issue.

Signed-off-by: Davide Fioravanti <pantanastyle@gmail.com>
@robimarko
Copy link
Contributor

robimarko commented Oct 7, 2020

This is a good catch, but by accident, I have an even better solution.
I have been writing a proper PHY driver for QCA8072 and QCA8075, its really close to being fully finished.
It should be upstreamable and supports advanced features that PHY has, like setting/getting tuneables, cable testing(Kernel 5.7 and later only), using interrupts, and proper GPIO handling per PHY so that all devices that are using PHY-s for non-default LED-s can be ported.
It even polls data from PHY specific registers that all Atheros/Qualcomm PHY-s have that tell actual speeds, duplex, MDI crossover, etc.
I will also add fiber support as that definitively does not work in AR40xx, but since I don't have anything with SFP its gotta have to wait.

So far, I have only one bug and that is that EDMA does not use read_status callback at all so after the PHY is configured and AR40xx does calibration EDMA won't recognize a link-up but ethernet will work fine.
Simple generic PHY soft reset causes EDMA to recognize it and to populate PHY stats correctly, so I made a workaround to soft reset the PHY before calling phy_start in EDMA.

So, this driver would be ideal for DSA where the driver won't mess with PHY as EDMA does.

I need to backport and test this under OpenWrt, as I only tested this under kernel 5.9.
If it works, I will try to get it merged to drop the whole PHY handling from AR40xx until DSA is ready.

@robimarko
Copy link
Contributor

@DavideFioravanti This PR should resolve your issues:#3498

@hauke hauke added the target/ipq40xx pull request/issue for ipq40xx target label Oct 9, 2020
@DavideFioravanti
Copy link
Contributor Author

Thank you very much @robimarko. Hopefully your PR will be merged soon, so I can close this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
target/ipq40xx pull request/issue for ipq40xx target
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants