3 ms·
> Perhaps the idea was that you get a fast connection resume This seems unlikely for the reasons you listed. Since USB is a polled bus and has shared bandwidth
by sannee 5y ago
> Perhaps the idea was that you get a fast connection resume
This seems unlikely for the reasons you listed. Since USB is a polled bus and has shared bandwidth, implementing the flow control is likely very beneficial in case the bus can't temporarily handle the full Ethernet speed.
So, a USB-to-Ethernet gizmo just monitors its internal Ethernet-to-USB queue and if it starts to overflow, it attempts to flow control the switch. But, if no USB host is connected, no USB data requests ever arrive, the queue overflows and never gets cleared...
There may also be some WoL/USB remote wakeup stuff at play, which may be why these ICs do not drop the link on USB host disconnect by default. In fact, I wonder if messing with those settings on the host side could remediate the issue...
- oneplane 5y agoI meant fast resume on the ethernet side, not the USB side. While the (often) 8051 cores do work for things like magic packets and ASF, it's often not really exposed to the user or kernel unless some device-specific driver is used. Some devices have windows-specific drivers that come with device manager properties tabs for extra settings, but then they hide it in some unclear magic packet handling and energy saving setting instead of a host-baed link control setting (the ethernet link control usually is still there). The weird thing is that there is a whole lot of cool stuff you can do with the on-chip firmware like mDNS proxy for offline devices, but it's all so hidden and vague that nobody bothers to do a whole lot about it.