Dan Williams <dcbw@xxxxxxxxxx> writes: > did you say that the char device was protocol agnostic? What other > protocols might it speak here? Don't really know. Just observed the fact there's nothing preventing some other chipset vendor from putting their protocol in there. And guessing that if one vendor already did, then it's very likely that others will follow. But regarding the device naming, I agree that /dev/qmiX has a nicer look and feel. I could easily be convinced to change that. We can always use the "for historical reasons" argument when explaining this later. >> But I soon found out that this was too restrictive for protocol debug >> usage, so of you open the device read-only then you will get all >> packets. Including those sent by other clients, which again includes >> the internal one managing the wwanX network interface. > > I don't think that's a problem. So I made the driver copy all packets, both sent and received, to all clients. That simplified things quite a bit. Still haven't had a chance to look at a better buffering solution, and given the time on my hands I've concluded that I won't do that. The code I've got now is working, so let's just use it. Instead I looked at getting better response when the net device isn't running, and getting rid of the stupid read loops. The thing is that usbnet already handles status interrupts most of the time, but kills the status URB when it thinks it doesn't need it. So I steal the URB and submit it whenever it suits me. Hackish, but I don't know what else to do given that I do not want to copy all the usbnet code to make a few minor changes... Anyway, the new reading code is both simpler and much more responsive than before. As expected. The loops were never a great idea. While struggling with this I've also come over a few new firmware behavioural surprises. Like: Reconnecting immediately after an unwanted disconnect works fine, but IP packets are not forwarded until the address configuration is requested again either via DHCP or via QMI. OK, so I don't know how to trigger a DHCP RENEW from a driver (well, I do but you don't want to see that :-). So I send a QMI get runtime settings requests. Works fine, making disconnects barely noticable. But enter whacky firmware: If I send the QMI get runtime command immediately after the *first* connect, before the DHCP client has requested an address, then I end up receiving raw IP packets with no ethernet header. Ugh. So I now send the QMI command only on reconnects. Seems to do the job. But I expect there are other weird issues like this... Which makes me think that I'd better not touch this anymore as long as it is working. I've therefore sent an updated version of the driver to linux-usb and netdev, as you might already have noticed. I'm guessing that the character device driver will have a hard time being accepted on netdev, but I haven't got any other suggestions at the moment. It *is* really part of a CDC networking driver... sort of. Bjørn -- 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
