axge: fix spurious link down from MII, frozen TX

[rkitover_gmail.com]

Summary

A race condition in the MII layer causes spurious link down events, see:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252165

. In statchg, on link down, check if the PHY reports the link as
actually down using the BMSR register, if not, force the status of the
link to back up and restart TX. Do the same in a MII linkchg handler.

On actual link up, restart TX in case it went idle and down.

I have tested this patch with two of my USB-C hubs with this Ethernet
interface, and it gives me a stable permanent connection with no
interruptions to my internet connections.

Signed-off-by: Rafael Kitover <[e-mail]>

[rkitover_gmail.com]

Add Differential Review URL

Add Differential Review URL to commit message.

[rkitover_gmail.com]

Started as pull request here:

https://github.com/freebsd/freebsd-src/pull/2037

[rkitover_gmail.com]

Update for style(9)

[rkitover_gmail.com]

Update for style(9)

[pouria]

style.9

sys/dev/usb/net/if_axge.c

334

use bool for new_link and old_link

392–394

Up to your judgement, but try to not break strings as much as possible.

476

style: Do not test without a comparison, or with unary ! (except for booleans).

[rkitover_gmail.com]

Update for style(9)

[rkitover_gmail.com]

I think I can remove the frozen TX fix given that the link doesn't go down, I'll do that and test it out, then update this patch.

pouria, I still want your ure logs, with and without the patch, I need to figure out why it didn't work for you as intended.

[rkitover_gmail.com]

Remove frozen TX handling, unneeded if link up

[rkitover_gmail.com]

I have confirmation from someone in the bug thread that the patch works:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267514#c17

[rkitover_gmail.com]

Another style(9) update

[pouria]

LGTM

[adrian]

this is good work! i would like to figure out how to describe the "why" this extra stuff is necessary though, so lemme noodle on that a bit first.

(and yeah some if "be correct" and some is "usb stack race conditions sigh")

[rkitover_gmail.com]

Hi Adrian,

thanks for getting back to this. I'm fine with removing these changes once MII is fixed, although they don't really hurt anything.

So ure, just merged, is the other common Ethernet dongle chipset, I'm also doing axe, an older 100Mbps interface, I will link it here.

That will cover the common set of dongle chips.

That leaves some pi models which use MII for Ethernet, but that would be hard to test, so I won't do those now.

The goal here is for a user to be able to use an Ethernet dongle with their laptop with an unsupported wifi chip.

I'm going to look at a couple of wifi chips too later, maybe more.

[rkitover_gmail.com]

I posted the axe patch:

https://reviews.freebsd.org/D55925

[rkitover_gmail.com]

Add lock to serialize MII bus operations

[sanpei]

I have tested the updated if_axge driver with several devices.
In my environments, the issues with link flaps have been resolved(even added changing axge_miibus_statchg, there is "no" spurious link down message. Same as axe I don't know why??) .

Test Environments:
ASIX Elec. Corp. AX88179(ELECOM EDC-GUC3L-W)

• Raspberry Pi 4 (16-CURRENT/arm64)
• Raspberry Pi Zero 2W and Pine64 (15.0-RELEASE/arm64)

I would appreciate it if these changes could be merged into -CURRENT, stable/15, and stable/14.
(I haven't tested this with 14.4-RELEASE yet, but I can do so if needed.)

[rkitover_gmail.com]

Hi sanpei,

as far as USB Ethernet goes, the commonly available chipsets for dongles are axge, ure and axe.

Those are the ones I could buy dongles to teset for and we're dealing with those.

Do you know of other drivers that would benefit from this patch that you have access to hardware for?

I'm trying to get the C revision chip for ure so I can add support for it too.

[bms]

I was able to obtain an axge(4) compatible USB3 adapter for ~6GBP from Amazon.

It may be able to support IEEE 1588 receive timestamping, if someone ports the required M_TSTMP support from ASIX's own out-of-tree source-available driver for Linux.

Due to work commitments, it appears @kevlo can't commit to it.

I'll send it at cost to someone who commits to doing this.

[rkitover_gmail.com]

Hi bms,

I'll do it if you need this feature, I have a hub with this chip.