Hi, > > I have a network adapter which uses the aforementioned driver and while > > checking for the link state via ethtool reports the correct state, many > > networking userspace utilities seem to have no clue about it (NM 0.8.1 starts > > dhclient BEFORE any cable is plugged) - and more importantly, don't notice when > > the cable is (dis)connected. Since there's not even a kernel message when > > (dis)connecting the cable, I suspect the driver does not implement Link state > > change detection at all. Is this accurate? Ah, perhaps that is why as long as network-mangler is running, my .resume_reset() handler improvements (managing to keep an active interface even directly after resume) actually do _not_ work (since it seems it simply down:s the iface and that's it). I know that there is link info functionality in other drivers yet not as much in mcs7830. Note that the mcs7830 driver still has a rather stubby appearance (many more "advanced" features are either weak or not available at all). I've got a patch series sitting here to improve several parts (and waiting to cook a bit more), but I hadn't even identified the link issue. It appears that this would need fixing, presto. > > LSCD works in Windows, where it's apparently implemented through periodic > > polling (judging by virtualbox's blinking USB icon). > > How is this situation normally handled? Is it kernel's job to do the polling? > > Or are userspace utilities expected to do this? I'm afraid a painful solution would be to activate the .status callback for periodic USB status descriptor polling. I've got a half-implementation of that, however it's very painful in terms of obscene amounts of CPU wakeups. There _has_ to be a better solution... Thank you for your (the OP's) report (and for my extra notification!), this seems very helpful! (I am determined to post related useful patches soon, especially since this card is in active use here) Andreas Mohr -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html