Re: USB serial device naming
On Tuesday 07 September 2010 21:13:25 Nick Hibma wrote: Maybe you can make PR on the issue and assign it to USB. Currently there is no way of knowing which /dev/cuaUXXX belongs to which USB device. Probably we can add the USB bus and address number as a part of the device coordinates. So that /dev/ugen1.1 only creates /dev/cuaU1.1.xxx entries. And then we can also remove the current unit number allocation structure I guess, if we use: /dev/cuaU1.1.iface_number.optional_sub_modem_unit The only problem is: Will we break any existing applications? Well, yes, to some extent :) Problem with this naming convention is name changes with every port change - that is, if you pull USB cable out and plug it in another port. There was already some older thread about naming on freebsd-usb list (end of April 2009). But if devd receives all necessary informations in attach event, then it is possible to rewrite config files or create symlink in /dev directory or something like this to handle this situation. I think better way is use device connection path in name. User know to which port of hub they attach device, so name like /dev/cuaU.h0p1.h2p3 (root hub 0, port 1, hub 2, port 3 ) have all information user need and this name not changing between reboot`s. May by we have way make naming more simple, but we really need path somewhere in device name. Two things are needed: 1) path to the device so you can distinguish two identical devices. 2) map u3gN to cuaUX.Y My problem is the latter: Processing event '+u3g0 vendor=0x0af0 product=0x7601 devclass=0xff devsubclass=0xff sernum= release=0x intclass=0xff intsubclass=0xff at port=2 interface=0 vendor=0x0af0 product=0x7601 devclass=0xff devsubclass=0xff sernum= release=0x intclass=0xff intsubclass=0xff on uhub1' Pushing table setting device-name=u3g0 setting vendor=0x0af0 setting product=0x7601 setting devclass=0xff setting devsubclass=0xff setting sernum= setting release=0x setting intclass=0xff setting intsubclass=0xff Processing attach event Hi, How do I get to the cuaU10.0 device here? As far as I can see there is no way to do this. I think we should use the following format: cuaUbus.addr.iface[.sub_unit] Then you can match by ugenX.Y unit. Possibly we could add this information to the processing event. I would like to avoid having too much information in the device name, which is not really needed. Then we can also remove the unit allocator in usb/serial/usb_serial.c . The main problem is the strange way the minor number is assigned to the cuaU device. But having the major and minor numbers for the cuaU device per u3g instance would be sufficient. Through a sysctl for example, or as extra information in the attach. You mean in the device name, not in the inode? If no one objects I will submit a patch to resolve problem 2). Please send a patch for review. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
Two things are needed: 1) path to the device so you can distinguish two identical devices. 2) map u3gN to cuaUX.Y My problem is the latter: Processing event '+u3g0 vendor=0x0af0 product=0x7601 devclass=0xff devsubclass=0xff sernum= release=0x intclass=0xff intsubclass=0xff at port=2 interface=0 vendor=0x0af0 product=0x7601 devclass=0xff devsubclass=0xff sernum= release=0x intclass=0xff intsubclass=0xff on uhub1' Pushing table Hi, How do I get to the cuaU10.0 device here? As far as I can see there is no way to do this. I think we should use the following format: cuaUbus.addr.iface[.sub_unit] Then you can match by ugenX.Y unit. Possibly we could add this information to the processing event. Yes. We need a mapping from vendor/product/rev - /dev/ entry and from location - /dev/ entry. Adding this cuaUbus.addr.iface string (not the absence of the sub_unit) to the event would resolve both issues 1) and 2). /me starts handing out paint and pencils for the bike shed painting to come... The main problem is the strange way the minor number is assigned to the cuaU device. But having the major and minor numbers for the cuaU device per u3g instance would be sufficient. Through a sysctl for example, or as extra information in the attach. You mean in the device name, not in the inode? Device name, right. The mknod stuff is too old to be wrong... Please send a patch for review. Will do in the next two weeks. Nick___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
On Wed, Sep 08, 2010 at 09:00:46AM +0200, Hans Petter Selasky wrote: On Tuesday 07 September 2010 21:13:25 Nick Hibma wrote: Maybe you can make PR on the issue and assign it to USB. Currently there is no way of knowing which /dev/cuaUXXX belongs to which USB device. Probably we can add the USB bus and address number as a part of the device coordinates. So that /dev/ugen1.1 only creates /dev/cuaU1.1.xxx entries. And then we can also remove the current unit number allocation structure I guess, if we use: /dev/cuaU1.1.iface_number.optional_sub_modem_unit The only problem is: Will we break any existing applications? Well, yes, to some extent :) Problem with this naming convention is name changes with every port change - that is, if you pull USB cable out and plug it in another port. There was already some older thread about naming on freebsd-usb list (end of April 2009). But if devd receives all necessary informations in attach event, then it is possible to rewrite config files or create symlink in /dev directory or something like this to handle this situation. I think better way is use device connection path in name. User know to which port of hub they attach device, so name like /dev/cuaU.h0p1.h2p3 (root hub 0, port 1, hub 2, port 3 ) have all information user need and this name not changing between reboot`s. May by we have way make naming more simple, but we really need path somewhere in device name. Two things are needed: 1) path to the device so you can distinguish two identical devices. 2) map u3gN to cuaUX.Y My problem is the latter: Processing event '+u3g0 vendor=0x0af0 product=0x7601 devclass=0xff devsubclass=0xff sernum= release=0x intclass=0xff intsubclass=0xff at port=2 interface=0 vendor=0x0af0 product=0x7601 devclass=0xff devsubclass=0xff sernum= release=0x intclass=0xff intsubclass=0xff on uhub1' Pushing table setting device-name=u3g0 setting vendor=0x0af0 setting product=0x7601 setting devclass=0xff setting devsubclass=0xff setting sernum= setting release=0x setting intclass=0xff setting intsubclass=0xff Processing attach event Hi, How do I get to the cuaU10.0 device here? As far as I can see there is no way to do this. I think we should use the following format: cuaUbus.addr.iface[.sub_unit] I come back later to your suggestion. Then you can match by ugenX.Y unit. Possibly we could add this information to the processing event. I would like to avoid having too much information in the device name, which is not really needed. Then we can also remove the unit allocator in usb/serial/usb_serial.c . What I missed most with the USB serial concept is that there is not easy way to get from the driver instance to the ucom instance. For other devices it is easy to have devd setup softlinks depending on e.g. serial numbers. devd gets bus addresses, so it is possible to easily setup softlinks for your suggested device naming without knowin the ucom instance. But it breaks another feature. We ship /etc/remote prefilled with ucom[012] entries. umass devices have a similar problem - you don't know the da* nodes you'll get. In many cases like harddisks, picturecards, ... you can get away with labels, but if you regularily need to partion brand new flash cards you need to be very carefull about devicenames to not overwrite the wrong media. The main problem is the strange way the minor number is assigned to the cuaU device. But having the major and minor numbers for the cuaU device per u3g instance would be sufficient. Through a sysctl for example, or as extra information in the attach. There is no single set per device. ucom already has /dev/ttyU* and /dev/cuaU* in different variants with and without .init and .lock extensions. You mean in the device name, not in the inode? You better know the ucom instance number via devinfo - then devd can setup all required softlinks because with the instance number you also know all nodenames. The path - as suggested in the original post - is also interesting. Knowing the nodes allows you to setup softlinks, but you need to know the device as well and not everyone has a serial number, but usually is conneted using the same hub/port chain. The bus address is useless here, because it is dynamic. devinfo already contains informations about the uplink port, but requires to travel the chain yourself and in single-user-mode (when devd gets the bootmessages) you don't have many tools for scripting available. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
Maybe you can make PR on the issue and assign it to USB. Currently there is no way of knowing which /dev/cuaUXXX belongs to which USB device. Probably we can add the USB bus and address number as a part of the device coordinates. So that /dev/ugen1.1 only creates /dev/cuaU1.1.xxx entries. And then we can also remove the current unit number allocation structure I guess, if we use: /dev/cuaU1.1.iface_number.optional_sub_modem_unit The only problem is: Will we break any existing applications? Well, yes, to some extent :) Problem with this naming convention is name changes with every port change - that is, if you pull USB cable out and plug it in another port. There was already some older thread about naming on freebsd-usb list (end of April 2009). But if devd receives all necessary informations in attach event, then it is possible to rewrite config files or create symlink in /dev directory or something like this to handle this situation. I think better way is use device connection path in name. User know to which port of hub they attach device, so name like /dev/cuaU.h0p1.h2p3 (root hub 0, port 1, hub 2, port 3 ) have all information user need and this name not changing between reboot`s. May by we have way make naming more simple, but we really need path somewhere in device name. Two things are needed: 1) path to the device so you can distinguish two identical devices. 2) map u3gN to cuaUX.Y My problem is the latter: Processing event '+u3g0 vendor=0x0af0 product=0x7601 devclass=0xff devsubclass=0xff sernum= release=0x intclass=0xff intsubclass=0xff at port=2 interface=0 vendor=0x0af0 product=0x7601 devclass=0xff devsubclass=0xff sernum= release=0x intclass=0xff intsubclass=0xff on uhub1' Pushing table setting device-name=u3g0 setting vendor=0x0af0 setting product=0x7601 setting devclass=0xff setting devsubclass=0xff setting sernum= setting release=0x setting intclass=0xff setting intsubclass=0xff Processing attach event How do I get to the cuaU10.0 device here? As far as I can see there is no way to do this. The main problem is the strange way the minor number is assigned to the cuaU device. But having the major and minor numbers for the cuaU device per u3g instance would be sufficient. Through a sysctl for example, or as extra information in the attach. If no one objects I will submit a patch to resolve problem 2). Nick___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
On Thursday 06 May 2010 11:07:00 Alexandr Rybalko wrote: On Wed, 5 May 2010 21:57:20 +0200 Hans Petter Selasky hsela...@c2i.net wrote: Hi, Thanks for all good ideas. Can you give some feedback on the following solution: http://p4web.freebsd.org/@@19?ac=10 Looks interest, can You send to me patch to svn head. (So more difference in p4, without access to p4 difficult to test it) Me too... I have no experience with p4, now I even could not access it for some reason... Think uhub_child_location_string output must be added to attach event, so devd can make unique link for device. Milan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
On Wed, 5 May 2010 21:57:20 +0200 Hans Petter Selasky hsela...@c2i.net wrote: Hi, Thanks for all good ideas. Can you give some feedback on the following solution: http://p4web.freebsd.org/@@19?ac=10 Looks interest, can You send to me patch to svn head. (So more difference in p4, without access to p4 difficult to test it) Think uhub_child_location_string output must be added to attach event, so devd can make unique link for device. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org -- Alexandr Rybalko r...@dlink.ua aka Alex RAY r...@ddteam.net ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
Hi, Maybe you can make PR on the issue and assign it to USB. Currently there is no way of knowing which /dev/cuaUXXX belongs to which USB device. Probably we can add the USB bus and address number as a part of the device coordinates. So that /dev/ugen1.1 only creates /dev/cuaU1.1.xxx entries. And then we can also remove the current unit number allocation structure I guess, if we use: /dev/cuaU1.1.iface_number.optional_sub_modem_unit The only problem is: Will we break any existing applications? The second problem was that the USB attach event was generated before the modem was probed and the umodem and other modem drivers do not provide any information about their USB address in the pnpinfo. This can be fixed. Old pnpinfo: dev.ums.0.%pnpinfo: vendor=0x0 product=0x0 devclass=0x00 devsubclass=0x00 sernum= release=0x0200 intclass=0x03 intsubclass=0x01 Suggested new pnpinfo (which is available from devd.conf I guess) dev.ums.0.%pnpinfo: vendor=0x0 product=0x0 devclass=0x00 devsubclass=0x00 sernum= release=0x0200 intclass=0x03 intsubclass=0x01 bus=1 addr=2 ifaceidx=0 What do you think? --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
On Wednesday 05 May 2010 09:52:15 Hans Petter Selasky wrote: Hi, Maybe you can make PR on the issue and assign it to USB. Currently there is no way of knowing which /dev/cuaUXXX belongs to which USB device. Probably we can add the USB bus and address number as a part of the device coordinates. So that /dev/ugen1.1 only creates /dev/cuaU1.1.xxx entries. And then we can also remove the current unit number allocation structure I guess, if we use: /dev/cuaU1.1.iface_number.optional_sub_modem_unit The only problem is: Will we break any existing applications? Well, yes, to some extent :) Problem with this naming convention is name changes with every port change - that is, if you pull USB cable out and plug it in another port. There was already some older thread about naming on freebsd-usb list (end of April 2009). But if devd receives all necessary informations in attach event, then it is possible to rewrite config files or create symlink in /dev directory or something like this to handle this situation. The second problem was that the USB attach event was generated before the modem was probed and the umodem and other modem drivers do not provide any information about their USB address in the pnpinfo. This can be fixed. Old pnpinfo: dev.ums.0.%pnpinfo: vendor=0x0 product=0x0 devclass=0x00 devsubclass=0x00 sernum= release=0x0200 intclass=0x03 intsubclass=0x01 Suggested new pnpinfo (which is available from devd.conf I guess) dev.ums.0.%pnpinfo: vendor=0x0 product=0x0 devclass=0x00 devsubclass=0x00 sernum= release=0x0200 intclass=0x03 intsubclass=0x01 bus=1 addr=2 ifaceidx=0 This would be good thing to do I think. Just a typo spot here - ums means USB mouse driver, I think, but this idea is worth evaluating. My sole concern is use somehow stable names for situations when more than one serial port (serial USB cable, u3g modem etc) is attached so each device is properly used in correct program. Regards, Milan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
Hi, On Wed, 5 May 2010 10:46:30 +0200 Milan Obuch freebsd-...@dino.sk wrote: On Wednesday 05 May 2010 09:52:15 Hans Petter Selasky wrote: Hi, Maybe you can make PR on the issue and assign it to USB. Currently there is no way of knowing which /dev/cuaUXXX belongs to which USB device. Probably we can add the USB bus and address number as a part of the device coordinates. So that /dev/ugen1.1 only creates /dev/cuaU1.1.xxx entries. And then we can also remove the current unit number allocation structure I guess, if we use: /dev/cuaU1.1.iface_number.optional_sub_modem_unit The only problem is: Will we break any existing applications? Well, yes, to some extent :) Problem with this naming convention is name changes with every port change - that is, if you pull USB cable out and plug it in another port. There was already some older thread about naming on freebsd-usb list (end of April 2009). But if devd receives all necessary informations in attach event, then it is possible to rewrite config files or create symlink in /dev directory or something like this to handle this situation. I think better way is use device connection path in name. User know to which port of hub they attach device, so name like /dev/cuaU.h0p1.h2p3 (root hub 0, port 1, hub 2, port 3 ) have all information user need and this name not changing between reboot`s. May by we have way make naming more simple, but we really need path somewhere in device name. The second problem was that the USB attach event was generated before the modem was probed and the umodem and other modem drivers do not provide any information about their USB address in the pnpinfo. This can be fixed. Old pnpinfo: dev.ums.0.%pnpinfo: vendor=0x0 product=0x0 devclass=0x00 devsubclass=0x00 sernum= release=0x0200 intclass=0x03 intsubclass=0x01 Suggested new pnpinfo (which is available from devd.conf I guess) dev.ums.0.%pnpinfo: vendor=0x0 product=0x0 devclass=0x00 devsubclass=0x00 sernum= release=0x0200 intclass=0x03 intsubclass=0x01 bus=1 addr=2 ifaceidx=0 This would be good thing to do I think. Just a typo spot here - ums means USB mouse driver, I think, but this idea is worth evaluating. My sole concern is use somehow stable names for situations when more than one serial port (serial USB cable, u3g modem etc) is attached so each device is properly used in correct program. Regards, Milan ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org -- Alexandr Rybalko r...@dlink.ua aka Alex RAY r...@ddteam.net ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
Hi, Thanks for all good ideas. Can you give some feedback on the following solution: http://p4web.freebsd.org/@@19?ac=10 --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
At 04:48 AM 12/14/2009, Hans Petter Selasky wrote: On Monday 14 December 2009 08:42:04 Ed Schouten wrote: Hello Trevor, * Trevor Blackwell t...@tlb.org wrote: I can't seem to find a way to match USB serial ports tty names. I have two serial USB devices, which I can distinguish easily from usbconfig show_ifdrv snip and they result in two ttys: /dev/cuaU0 /dev/cuaU1 Be sure to keep in mind: the `real' TTY devices are ttyU0 and ttyU1. The cua* devices are callout devices, which unlike the tty* devices don't wait for a carrier detect signal during open(). My opinion is that the USB serial driver shouldn't use a bitmask to keep track of which unit number are available, because we've got a nice KPI for that: http://www.freebsd.org/cgi/man.cgi?query=new_unrhdr Unfortunately I cannot answer your question. Hopefully Hans can. ;-) That's OK, but the real problem is that TTY is not a visible child of UPLCOM for example. I would suggest adding a new IOCTL or maybe you have a better idea, where we can pass the device_get_nameunit() string, and then TTY can store it and pass it to userland. Also TTY should have a printout in dmesg, which unit is create if this string is specified. I think I am running into a similar problem in this old thread. But in my case, I am trying to identify the umodem type device. I have a few firewalls in the field that have a USB dialup modem and various u3g type devices that are attached. With the u3g devices in particular, they can sometimes show up as /dev/cuaU#.# or just /dev/cuaU# where as the modem shows up as /dev/cuaU#. I have to fire up different copies of ppp based on the device and modem they attach to. The problem I have is there seems to be no way of knowing which physical device corresponds to which /dev/cuaU#.# file interface. eg What is the safest way to find out that /dev/cuaU1 is the ZTE stick in this case ? Another model of ZTE shows up as /dev/cuaU2.0 which nothing on /dev/cuaU1 oddly enough. # usbconfig show_ifdrv ugen0.1: OHCI root HUB AMD at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen0.1.0: uhub0: AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 ugen1.1: EHCI root HUB AMD at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.1.0: uhub1: AMD EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 ugen1.2: USB Modem U.S.Robotics at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.2.0: umodem0: AltIf0 ugen0.2: Back-UPS ES 650 FW:825.B1.D USB FW:B1 APC at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen1.3: ZTE CDMA Technologies MSM ZTE, Incorporated at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.3.0: u3g0: ZTE, Incorporated ZTE CDMA Technologies MSM, class 0/0, rev 2.00/0.00, addr 3 ugen1.3.2: umass0: ZTE, Incorporated ZTE CDMA Technologies MSM, class 0/0, rev 2.00/0.00, addr 3 # ls -l /dev/cuaU* crw-rw 1 uucp dialer - 0, 78 May 4 16:10 /dev/cuaU0 crw-rw 1 uucp dialer - 0, 79 May 4 09:19 /dev/cuaU0.init crw-rw 1 uucp dialer - 0, 80 May 4 09:19 /dev/cuaU0.lock crw-rw 1 uucp dialer - 0, 104 May 4 16:10 /dev/cuaU1 crw-rw 1 uucp dialer - 0, 105 May 4 09:19 /dev/cuaU1.init crw-rw 1 uucp dialer - 0, 106 May 4 09:19 /dev/cuaU1.lock nothing in sysctl unfortunately dev.umodem.0.%desc: AltIf0 dev.umodem.0.%driver: umodem dev.umodem.0.%location: port=2 interface=0 dev.umodem.0.%pnpinfo: vendor=0x0baf product=0x0303 devclass=0x02 devsubclass=0x00 sernum=002 release=0x0200 intclass=0x02 intsubclass=0x02 dev.umodem.0.%parent: uhub1 dev.u3g.0.%desc: ZTE, Incorporated ZTE CDMA Technologies MSM, class 0/0, rev 2.00/0.00, addr 3 dev.u3g.0.%driver: u3g dev.u3g.0.%location: port=1 interface=0 dev.u3g.0.%pnpinfo: vendor=0x19d2 product=0x0031 devclass=0x00 devsubclass=0x00 sernum=1234567890ABCDEF release=0x intclass=0xff intsubclass=0xff it would be great if there were something like dev.u3g.0.%fileinterface=/dev/cuaU1 or perhaps somewhere in devinfo ? umodem0 pnpinfo vendor=0x0baf product=0x0303 devclass=0x02 devsubclass=0x00 sernum=002 release=0x0200 intclass=0x02 intsubclass=0x02 at port=2 interface=0 u3g0 pnpinfo vendor=0x19d2 product=0x0031 devclass=0x00 devsubclass=0x00 sernum=1234567890ABCDEF release=0x intclass=0xff intsubclass= at port=1 interface=0 ugen1.2: USB Modem U.S.Robotics at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0043 bNumInterfaces = 0x0002 bConfigurationValue = 0x0002 iConfiguration = 0x no string bmAttributes = 0x0080 bMaxPower = 0x00b4 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0001 bInterfaceClass = 0x0002 bInterfaceSubClass = 0x0002 bInterfaceProtocol = 0x0001
Re: USB serial device naming
On Sunday 13 December 2009 23:45:07 Trevor Blackwell wrote: I can't figure out how to map the USB devices to tty names. I think this is not possible at the moment. And there is no TTY API to pass this information. Please provide a patch. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
* Hans Petter Selasky hsela...@c2i.net wrote: Also TTY should have a printout in dmesg, which unit is create if this string is specified. Just patch your ucom driver to print that information. It doesn't belong in the TTY layer. Can't you just extend usbconfig to also dump that information? -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpXyZt3QQRcf.pgp Description: PGP signature
Re: USB serial device naming
On Monday 14 December 2009 09:53:51 Ed Schouten wrote: * Hans Petter Selasky hsela...@c2i.net wrote: Also TTY should have a printout in dmesg, which unit is create if this string is specified. Just patch your ucom driver to print that information. It doesn't belong in the TTY layer. Can't you just extend usbconfig to also dump that information? Hi, A printout in USB is OK for the user, but what about applications? Probably I could extend with an USB IOCTL for the TTY device to do what I want, in addition to a printout. USB_IOCTL_GET_PARENT_NAME --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
USB_IOCTL_GET_PARENT_NAME That seems like the right approach. Is there only ever one associated parent driver? Are there cases where it should report both a serial network interface? -- Trevor Blackwell650 776 7870t...@tlb.org ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
On Monday 14 December 2009 18:44:01 Trevor Blackwell wrote: USB_IOCTL_GET_PARENT_NAME That seems like the right approach. Is there only ever one associated parent driver? Are there cases where it should report both a serial network interface? That's a good question how to best standardise this. Probably the IOCTL is useful for other busses too. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
I can't seem to find a way to match USB serial ports tty names. I have two serial USB devices, which I can distinguish easily from usbconfig show_ifdrv ugen2.2: URG-Series USB Driver Hokuyo Data Flex for USB at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.2.0: umodem0: Hokuyo Data Flex for USB URG-Series USB Driver, class 2/0, rev 2.00/1.00, addr 2 ugen2.3: USB-Serial Controller Prolific Technology Inc. at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.3.0: uplcom0: Prolific Technology Inc. USB-Serial Controller, class 0/0, rev 1.10/3.00, addr 3 and they result in two ttys: /dev/cuaU0 /dev/cuaU1 but I can't figure out how to map the USB devices to tty names. It depends on what order they come up in. They're assigned sequentially by a bitmap system in usb_serial.c How can my code figure this out? I think what I want is some sort of ioctl on the raw USB device or usbconfig option to tell me what tty it appears as. -- Trevor Blackwell650 776 7870t...@tlb.org ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
Re: USB serial device naming
Hello Trevor, * Trevor Blackwell t...@tlb.org wrote: I can't seem to find a way to match USB serial ports tty names. I have two serial USB devices, which I can distinguish easily from usbconfig show_ifdrv snip and they result in two ttys: /dev/cuaU0 /dev/cuaU1 Be sure to keep in mind: the `real' TTY devices are ttyU0 and ttyU1. The cua* devices are callout devices, which unlike the tty* devices don't wait for a carrier detect signal during open(). My opinion is that the USB serial driver shouldn't use a bitmask to keep track of which unit number are available, because we've got a nice KPI for that: http://www.freebsd.org/cgi/man.cgi?query=new_unrhdr Unfortunately I cannot answer your question. Hopefully Hans can. ;-) Cheers, -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpJwaqLvdK3u.pgp Description: PGP signature
USB serial device naming
I cannot seem to find a way to identify serial ports. I have two
serial USB devices, which I can distinguish easily from usbconfig:
ugen2.3: URG-Series USB Driver Hokuyo Data Flex for USB at usbus2,
cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
ugen0.2: USB-Serial Controller Prolific Technology Inc. at usbus0,
cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON
and they result in two ttys:
/dev/cuaU0
/dev/cuaU1
but I can't figure out how to map the USB devices to tty names.
They're assigned sequentially by a bitmap system in usb_serial.c
Currently, no devices seem to be using this mechanism:
sys/dev/usb/serial/usb_serial.c:
/* Check if the client has a custom TTY name */
if (sc-sc_callback-ucom_tty_name) {
sc-sc_callback-ucom_tty_name(sc, buf,
sizeof(buf), sc-sc_local_unit);
}
is that the right way? Or, what I really want is some sort of ioctl on
the raw USB device or usbconfig option to tell me what serial port it
appears as.
--
Trevor Blackwell650 776 7870t...@tlb.org
___
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to freebsd-usb-unsubscr...@freebsd.org
