Quantcast

USB serial device naming

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

USB serial device naming

Trevor Blackwell

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 Blackwell 650 776 7870 [hidden email]





_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Hans Petter Selasky
There is:

usbconfig show_ifdrv

Maybe it helps?

Else send an e-mail to:

Ed Schouten

--HPS

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Trevor Blackwell

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 Blackwell 650 776 7870 [hidden email]




_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Ed Schouten-3
Hello Trevor,

* Trevor Blackwell <[hidden email]> 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 <[hidden email]>
 WWW: http://80386.nl/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Hans Petter Selasky
In reply to this post by Trevor Blackwell
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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Hans Petter Selasky
In reply to this post by Ed Schouten-3
On Monday 14 December 2009 08:42:04 Ed Schouten wrote:

> Hello Trevor,
>
> * Trevor Blackwell <[hidden email]> 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.

--HPS

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Ed Schouten-3
* Hans Petter Selasky <[hidden email]> 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 <[hidden email]>
 WWW: http://80386.nl/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Hans Petter Selasky
On Monday 14 December 2009 09:53:51 Ed Schouten wrote:
> * Hans Petter Selasky <[hidden email]> 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

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Trevor Blackwell

> 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 Blackwell 650 776 7870 [hidden email]

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Hans Petter Selasky
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

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

mdtancsa
In reply to this post by Hans Petter Selasky
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 <[hidden email]> 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="0000002" 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=0x0000
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="0000002" release=0x0200
intclass=0x02 intsubclass=0x02 at port=2 interface=0
               u3g0 pnpinfo vendor=0x19d2 product=0x0031
devclass=0x00 devsubclass=0x00 sernum="1234567890ABCDEF"
release=0x0000 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 = 0x0000  <no string>
     bmAttributes = 0x0080
     bMaxPower = 0x00b4

     Interface 0
       bLength = 0x0009
       bDescriptorType = 0x0004
       bInterfaceNumber = 0x0000
       bAlternateSetting = 0x0000
       bNumEndpoints = 0x0001
       bInterfaceClass = 0x0002
       bInterfaceSubClass = 0x0002
       bInterfaceProtocol = 0x0001
       iInterface = 0x0005  <AltIf0>

       Additional Descriptor

       bLength = 0x05
       bDescriptorType = 0x24
       bDescriptorSubType = 0x00
        RAW dump:
        0x00 | 0x05, 0x24, 0x00, 0x01, 0x10


       Additional Descriptor

       bLength = 0x05
       bDescriptorType = 0x24



>--HPS
>
>_______________________________________________
>[hidden email] mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-usb
>To unsubscribe, send any mail to "[hidden email]"

--------------------------------------------------------------------
Mike Tancsa,                                      tel +1 519 651 3400
Sentex Communications,                            [hidden email]
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada                         www.sentex.net/mike

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Hans Petter Selasky
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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Milan Obuch-29
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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Aleksandr Rybalko
Hi,

On Wed, 5 May 2010 10:46:30 +0200
Milan Obuch <[hidden email]> 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
>> _______________________________________________
>> [hidden email] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-usb
>> To unsubscribe, send any mail to "[hidden email]"


--
Alexandr Rybalko <[hidden email]>
aka Alex RAY <[hidden email]>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Hans Petter Selasky
In reply to this post by Milan Obuch-29
Hi,

Thanks for all good ideas. Can you give some feedback on the following
solution:

http://p4web.freebsd.org/@@177779?ac=10

--HPS
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Aleksandr Rybalko
On Wed, 5 May 2010 21:57:20 +0200
Hans Petter Selasky <[hidden email]> wrote:

>> Hi,
>>
>> Thanks for all good ideas. Can you give some feedback on the following
>> solution:
>>
>> http://p4web.freebsd.org/@@177779?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
>> _______________________________________________
>> [hidden email] mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-usb
>> To unsubscribe, send any mail to "[hidden email]"


--
Alexandr Rybalko <[hidden email]>
aka Alex RAY <[hidden email]>
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Milan Obuch-29
On Thursday 06 May 2010 11:07:00 Alexandr Rybalko wrote:

> On Wed, 5 May 2010 21:57:20 +0200
>
> Hans Petter Selasky <[hidden email]> wrote:
> >> Hi,
> >>
> >> Thanks for all good ideas. Can you give some feedback on the following
> >> solution:
> >>
> >> http://p4web.freebsd.org/@@177779?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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Nick Hibma-4
In reply to this post by Aleksandr Rybalko
>>>> 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=0x0000 intclass=0xff intsubclass=0xff at port=2 interface=0 vendor=0x0af0 product=0x7601 devclass=0xff devsubclass=0xff sernum="" release=0x0000 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=0x0000
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_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Hans Petter Selasky
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=0x0000 intclass=0xff intsubclass=0xff
> at port=2 interface=0 vendor=0x0af0 product=0x7601 devclass=0xff
> devsubclass=0xff sernum="" release=0x0000 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=0x0000
> 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:

cuaU<bus>.<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
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: USB serial device naming

Nick Hibma-4
>> 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=0x0000 intclass=0xff intsubclass=0xff
>> at port=2 interface=0 vendor=0x0af0 product=0x7601 devclass=0xff
>> devsubclass=0xff sernum="" release=0x0000 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:
>
> cuaU<bus>.<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 cuaU<bus>.<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_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[hidden email]"
12
Loading...