On Fri, 2013-11-08 at 15:29 -0600, Dan Williams wrote: > On Fri, 2013-11-08 at 21:44 +0100, Bjørn Mork wrote: > > Dan Williams <dcbw@xxxxxxxxxx> writes: > > > On Mon, 2013-11-04 at 14:27 -0600, Dan Williams wrote: > > >> On Fri, 2013-11-01 at 13:53 +0100, Bjørn Mork wrote: > > >> > This reverts commit 7b0c5f21f348a66de495868b8df0284e8dfd6bbf. > > >> > > > >> > It's not easy to create a driver for all the various firmware > > >> > bugs out there. > > >> > > > >> > This change caused regressions for a number of devices, which > > >> > started to fail link detection and therefore became completely > > >> > non-functional. The exact reason is yet unknown, it looks like > > >> > the affected firmwares might actually need all or some of the > > >> > additional SYNC messages the patch got rid of. > > >> > > > >> > Reverting is not optimal, as it will re-introduce the original > > >> > problem, but it is currently the only alternative known to fix > > >> > this issue. > > >> > > >> Instead, how does the following patch work for you? > > > > > > Bjorn, did you have a chance to try this patch out on your devices? > > > > The only DirectIP device I have is the MC7710, which never had any of > > the firmware issues you are trying to fix. I only tried to forward Johns > > issue. > > > > When this patch worked for John, then I am pretty confident that you > > have solved the problem here. > > Well, "solved", since I still have no idea why the original patch would > cause the device behavior based on what I know and have read about the > expected firmware/host handshaking sequence. But the patch there > appears to fix the problem *and* not blindly send tons of SYNCs forever. > > So I'll go ahead and submit a proper version of it. Actually, is "[PATCH] usbnet: fix status interrupt urb handling" the real fix for this problem? John, any chance you could revert my RFC patch and try Felix's patch in that mail? Dan -- 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
