On Sun, 2012-01-15 at 08:07 +0100, Bjørn Mork wrote: > 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 The answer here is you don't try to do anything with DHCP. That's a total layer violation and needs to be left to userspace. At some point you're not going to be able to keep putting this stuff in the kernel because it really doesn't belong there :) It's really something stuff in userspace should be doing. You're going to eventually have to run a modem manager daemon anyway. Besides, the userspace daemon is the only thing that can actually make the correct policy decision about unwanted disconnects; if you make the driver reconnect automatically, that's a policy decision that shouldn't be made in the kernel. A userspace daemon should be figuring out the reason for the disconnect and either indicating that to the user, or attempting to reconnect. If you're getting disconnected because, say, you've run over your traffic quotas for the month, the driver shouldn't be continuously reconnecting, but the userspace daemon might well have more information about that because it can track data usage. The Intel WiMAX stack also wants a DHCP renew indication for when the device comes out of idle mode. So it makes sense to do this generically. About all I can think of (besides abusing IFF_DORMANT which doesn't seem quite right) is a new netlink indication that clients (including dhcp clients) could watch for and then perform the renew. > 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. Try setting the data format then to make sure it's in 802.3 mode. See the CTL/Set Data Format command: 26 00 09 00 01 01 00 00 10 02 00 01 00 Cmd: 0x0026 (SET_DATA_FORMAT) Size: 0x0009 TLV: 0x01 (Format) Size: 0x0001 Data: 0x00 (0 = no QoS Header, 1 = include QoS header) TLV: 0x10 (Protocol) Size: 0x0002 Data[0]: 0x01 (1 = 802.3, 2 = raw IP mode) Data[1]: 0x00 > 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... Try the data format thing. I don't think that's a firmware bug really, but simply that you didn't set the format first. The UML290 sends this command to ensure the data format is always [ no QoS, raw IP ]. > 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. Yeah, we'll see, but we really, really do need a way of handling this sort of thing and if it's all using the same endpoints as the CDC ether driver (which it is) and since they are both intimately related it's hard to see how they really should be separated. Unfortunately that's the mechanism Qualcomm chose instead of a separate USB interface for the QMI stuff :(. 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
