On Mon, 2012-01-23 at 21:31 +0100, Bjørn Mork wrote: > 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. Ok, I'll try that. I'll just do a loop to find the interrupt endpoint and see if I can talk QMI to the devices. > > >> > 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 :-) Yeah, its the integrated approach. Obviously not quite what we care about but just used as a reference. > > 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. Agreed. 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
