On Mon, 2009-03-09 at 12:49 -0700, Greg KH wrote: > On Mon, Mar 09, 2009 at 02:36:50PM -0400, Dan Williams wrote: > > On Mon, 2009-03-09 at 19:32 +0100, oliver@xxxxxxxxxx wrote: > > > > Following the general example of the 'hso' driver, this patch > > > implements > > > > modem port types using a 'port_type' attribute in the tty's sysfs > > > > directory. Port types for genuine Option NV devices are added by > > > this > > > > patch, but types for other manufacturers devices may follow. I > > > intend > > > > to submit a patch to hso that adds these "standard" port types to > > > that > > > > driver as well. > > > > > > It seems to me most of this belongs into the generic layer. Also, > > > > You mean the generic tty layer? > > The usb-serial layer would be a good first start, but then you need to > also do the same thing for the cdc-acm and cdc-wdm and hso drivers, > right? > > So probably the tty layer. > > 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. 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. But the magic is that only ttyUSB0 will provide the response to ATDT that your program needs, to know that the modem has connected to the network. But that's not exposed anywhere except in an email I got from Option; thus given two "equal" ttys, USB0 and USB1, which is your program supposed to pick? If your program sends ATDT#777 to USB1, it'll sit there and time out because the CONNECT response got emitted on USB0, which your program isn't listening on. In 'hso', port types are provided by the firmware itself for some devices, thus it makes sense to provide the port types through the driver for at least 'hso' devices. In an effort to be consistent, it would be nice to have the same standardized mechanism to get port types for *both* option and hso, and maybe sierra in the future. It seems difficult to achieve a standard interface for port types when some devices need direct firmware communication to figure it out, and others can use a simply lookup table. Suggestions welcome. > Also, I as a kernel developer do not know a lot of this, especially when > users and random developers just email me new device ids. How am I > supposed to get this information from the users/developers as to which > port is which? With this patch, only *known* devices will get the "port_type" attribute in sysfs. Random device IDs would simply not have that attribute, preserving the current situation of confusion about which port to choose. > So I think you are just moving the data down out of hal-device-info, > into the kernel, for no real benifit other than not having to maintain > the tables yourself :) Except that in some cases, only the driver (by talking to the firmware) can figure out the port types. Yes, this is getting pushed from hal down into the drivers, but only when creating a standardized attribute for it requires communicating with the firmware on the device. 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
