On Tue, 2009-03-10 at 22:02 -0700, Greg KH wrote: > On Mon, Mar 09, 2009 at 04:15:01PM -0400, Dan Williams wrote: > > > I see what you are trying to solve here, however, you are just pushing > > > the need to create this table from userspace, into the kernel. While > > > this is nice from a userspace point of view, I thought that this is what > > > the modem-id userspace tool was trying to do. What's wrong with that? > > > > The 'modem-probe' tool detects whether the tty supports AT commands. > > But the attributes we're talking about aren't exposed through AT command > > sets or by querying the modem. They are artifacts of firmware or modem > > design in most cases, where only one port returns unsolicited response > > codes. > > Ah, yeah, true. > > > So say you've got an Option Globetrotter; it exposes ttyUSB0 and > > ttyUSB1, and ttyUSB2. USB0 and USB1 accept AT commands, thus the modem > > prober tags them as such. USB2 is a proprietary interface that is not > > supported Linux, and so it's not tagged by the modem prober. > > Qualcom did this right and only asked to expose the single port to > Linux. It uses usbfs and libusb to dump data to the other ports if > needed. Only if Qualcomm provides documentation for their protocols on the other ports. Do we have that? At least AT commands are well understood and fairly easy to handle. I've yet to see anything out of Qualcomm for talking to the proprietary ports on *any* of their other modems, whether OEM-branded or as a chipset in other parts like Sierra or Qualcomm. There's nothing wrong with exposing multiple ports, and I'd argue that actually Sony Ericsson did the right thing with F3507g, with CDC-ACM ports that can *all* do the same things, and a CDC-ETH port that handles the network traffic. 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
