Dan Williams <dcbw@xxxxxxxxxx> writes: > On Mon, 2012-01-23 at 19:56 +0100, Bjørn Mork wrote: >> Dan Williams <dcbw@xxxxxxxxxx> writes: >> >> > So the Pantech UML290 has the following layout: >> > >> > 0 (2/2/1): CDC-ACM for AT commands >> > 1 (10/0/0): CDC-DATA for interface 0 >> > 2 (ff/ff/ff): Qualcomm DIAG >> > 3 (ff/fd/ff): NMEA >> > 4 (ff/fe/ff): Pantech WMC >> > 5 (ff/f0/ff): RMNET/QMI port >> >> I assume this is after som modeswitch command? The same as the Windows >> driver uses? And you don't know if there are other options? > > The UML290 does not require modeswitching at all. OK, nice. >> > Interface 5 is obviously the one we want here. And the WDM driver is >> > only looking for certain descriptors. Do we hack CDC-WDM and qmi_wwan >> > up for these types of devices? >> >> >> Interface 5 has three endpoints? Bulk in/out and interrupt in? > > Yes, three endpoints like you describe. > >> OK, this is where the fun begins. I knew there was some reason why I >> was struggling with the interface sharing... I guess we cannot expect >> every vendor to provide a "Linux mode" with two separate interfaces for >> the RMNET/QMI port. >> >> > Second, on Gobi devices, we have four USB interfaces, all FF/FF/FF. >> > Intf 0 and 2 have interrupt endpoints. One of them is a DIAG interface, >> > one is NMEA, and the other two are AT and RMNET/QMI. >> >> What kind of endpoints are on the RMNET/QMI interface? > > see Elly's cleaned up Gobi driver here: http://lwn.net/Articles/439173/ > as it has the logic to set everything up for Gobi devices. I expect > that it would work with the UML290 as well if things were hacked up a > bit. It should be pretty clear here how to talk to them. > > In short we have: > > 0: (ff/ff/ff) (in/out/interrupt) - rmnet/QMI > 1: (ff/ff/ff) (in/out) - DIAG > 2: (ff/ff/ff) (in/out) - AT commands & PPP > 3: (ff/ff/ff) (in/out/interrupt) - NMEA (?) > > lsusb attached for both a Gobi 2K device and the UML290. > >> If you have these devices, then it would be useful to verify that the >> cdc-wdm driver can be used to provide access to QMI without any further >> changes. This should in theory just work if you unload any other >> drivers binding to the RMNET/QMI interface, and bind cdc-wdm to it >> instead. This requires that you have the minimum buffer size patch >> installed, but should not require any other changes. > > I tried that quickly but of course the WDM driver fails with EINVAL > because there are 3 endpoints on the RMNET/QMI interface (bulk > in/out/interrupt) instead of the 1 expected: > > rv = -EINVAL; > iface = intf->cur_altsetting; > if (iface->desc.bNumEndpoints != 1) > goto err; > > I briefly thought about hacking it to find the interrupt endpoing, but > if the cdc-wdm driver apparently only cares about 1 endpoint there's not > much point to handing it an interface with 3 I don't think... Right, forgot about that part. You could hack it so that it was happily ignoring the extra bulk endpoints as long as it found an interrupt endpoint. >> > I think so far the Huawei device is the only one that I've seen that >> > exposes descriptors that are quasi-CDC at all. How should we handle the >> > rest of these? >> >> Good question. Guess I'm going to see if I can make qmi_wwan and >> cdc-wdm share an interface after all. > > Also you may not have seen, but the QUIC codeaurora people pushed a new > rmnet USB driver to their MSM kernel tree: > > https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=commit;h=37c35e4ee5226099374a1a1eda637d0f26fc023d Thanks for the pointer. Will take a look at it. But I guess these are still doing the integrated QMI approach. Which most likely isn't acceptable to anyone here, after you managed to convince me :-) > In the end, if the Huawei device mostly presents itself as WDM, and > other Gobi/MSM8xxx/MSM9xxx devices present themselves like Gobi cards > do, perhaps we should have separate drivers? Does it make sense to keep > hacking up CDC-WDM for devices that are clearly not exposed that way, > even if the internal operation would be similar? Also in the end they > are all just character devices to talk QMI so it doesn't really matter > what driver exposes that interface. It would be nice to share if we > can, but making too many changes to WDM probably isn't the right > approach either. That is for Oliver to decide I guess. But I believe it can make sense to reuse the cdc-wdm driver, even if it needs some small changes to allow other drivers to call it. The actual work it does is pretty standalone: Listen on the interrupt ep, send control messages and do file operations on the char device. Provided the other netdev drivers don't need notifications, then this can all be done without them being involved at all. The only issues are register/deregister instead of probe/disconnect, and doing the mapping to the device specific struct. And having all these devices expose their QMI interface as a /dev/cdc-wdmX should make things look more consistent for users and userspace. 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
