>From the article, it sounds like " udevadm info -a -p
/sys/bus/usb-serial/devices/ttyUSB0/" might be interesting (if it
returns the relevant info)?

Did some digging on FreeBSD, seems it's possible to find the associated
TTY from sysctl:

sysctl -a|grep "^dev\.uftdi"
dev.uftdi.2.%desc: FT232R USB UART
dev.uftdi.2.%driver: uftdi
dev.uftdi.2.%location: bus=2 hubaddr=2 port=1 devaddr=3 interface=0
dev.uftdi.2.%pnpinfo: vendor=0x0403 product=0x6001 devclass=0x00
devsubclass=0x00 sernum="AAAAAAxXXXX" release=0x0600 mode=host
intclass=0xff intsubclass=0xff intprotocol=0xff  ttyname=U0 ttyports=1
dev.uftdi.2.%parent: uhub3
dev.uftdi.2.ttyname: U0
dev.uftdi.2.ttyports: 1

This is present as /dev/cuaU0 (ttyname). It's pretty trivial to iterate
the sysctl MIB tree using sysctl() calls, so looking for the dev.uftdi
devices (or others, if other lowlevel special impls are written) should
be doable.

On 24/09/14 02:53, David Torrey wrote:
> Does this help?  Seems to be a lot more complicated than it should be,
> but at least it's fairly deterministic.
>
> http://askubuntu.com/questions/184526/how-to-get-bus-and-device-relationship-for-a-dev-ttyusb
>
> Dave
>
> On Sep 23, 2014, at 7:58 PM, Paul Alfille <paul.alfi...@gmail.com
> <mailto:paul.alfi...@gmail.com>> wrote:
>
>> Ok, I'm perplexed!
>>
>> I need help mapping device name (e.g. /dev/ttyUSB0) to USB bus:devnum
>> that I get in libusb.
>>
>> I can probably do it by parsing 'dmesg' but that's rather inelegant.
>> Perhaps the data is somewhere in /sys or /proc?
>>
>> The problem is that after searching (and perhaps tuning) USB devices,
>> I then need to use them as a serial device.
>> I need to go in both directions -- both to not open use a bus master
>> twice and to check device names.
>>
>> Paul
>>
>> On Tue, Sep 23, 2014 at 5:37 PM, Dirk Opfer <d...@do13.de
>> <mailto:d...@do13.de>> wrote:
>>
>>     Hi Paul,
>>
>>     I have another one:
>>
>>     Elabnet (PBM01)  -- 0403:6015 -- with UNIQUE product and
>>     manufacture ID
>>
>>     Sorry for the delay. I'm still negotiating a sample for your.
>>
>>     Thanks
>>     Dirk
>>
>>     Am 23.09.2014 um 23:27 schrieb Paul Alfille:
>>>     Ok, I did some testing of various USB 1-wire bus masters:
>>>
>>>     LinkUSB -- 0403:6001 -- FTDI but no identifying charcteristics
>>>     (Except serial number, but that's probably not consecutive)
>>>     TAI603B -- 10c4:ea60 -- CP210x Unclear if it's generic or not
>>>     USB9097 --1a86:7523 -- HL-340 Seems generic
>>>     ECLO -- 0403:ea90 -- FTDI with UNIQUE product ID
>>>     MasterHub -- 04d8:f897 -- MTI with UNIQUE product ID
>>>     DS9490R -- 04fa:2490 -- Maxim with UNIQUE ID
>>>
>>>     So it looks like only  ECLO, the new Hobby Boards MasterHub, and
>>>     the DS9490R can be auto-detected by USB scanning. I had high
>>>     hopes for the LinkUSB, but perhaps I have an early version and
>>>     the internal fields have changed.
>>>
>>>     Paul Alfille
>>>
>>>
>>>
>>>
>>>     On Tue, Sep 23, 2014 at 3:40 PM, Johan Ström <jo...@stromnet.se
>>>     <mailto:jo...@stromnet.se>> wrote:
>>>
>>>         I'm all for auto-detection, when it is possible to do so
>>>         reliably. As you mentioned in the other reply, randomly
>>>         poking at stuff is neither reliable or safe..
>>>         So, the question is what we can do to make it as smooth for
>>>         the user as possible..
>>>
>>>         A possibly a new approach, with OS-specific resolving you
>>>         mentioned:
>>>
>>>         If user specifies --link /dev/ttyS0, -d /dev/ttyS0 or other,
>>>         we could try OS-specific lookups to find what serial
>>>         hardware it is using. For example, if we can find out that
>>>         it is a FTDI based device, we could try to use ft_ftdi
>>>         instead of ft_serial. If we cannot find out, we just fall
>>>         back to regular TTY access.
>>>
>>>         If user specifies --link 2:3, -d 3:4, --link usb:NNSERIAL or
>>>         such,  we look for that specific USB device. If it is a FTDI
>>>         device, we use ft_ftdi. Else, we can either fail, or for
>>>         device-types which are serial, we could try to
>>>         reverse-lookup TTY using OS-specific approach.
>>>
>>>         Note: on FreeBSD there are separate /dev permissions for
>>>         accessing the TTY and the USB device. Not sure if Linux has
>>>         the same.
>>>
>>>         Or, a more intrusive approach, clean up all parameters and
>>>         go a generic device-option: --device <type>[ <port-or-address>].
>>>         Examples:
>>>         --device link /dev/ttyS0 (would also possibly try to use OS
>>>         specific resolving)
>>>         --device link usb:3:4
>>>         --device link usb:NNSERIAL
>>>         --device ds9097 /dev/ttyS0
>>>         --device ds9097 usb:3:4
>>>         --device ds9097 usb:NNSERIAL
>>>         --device ds9097u /dev/ttyS0
>>>         --device i2c /dev/i2c-0
>>>         --device masterhub /dev/ttyS0
>>>         --device usb                   (this would search for
>>>         DS9490R or PuceBaboon or any other USb which we can
>>>         *reliably* identify)
>>>
>>>         What would your optimal owfs usage model look like?
>>>
>>>
>>>         For the record, here are the usbconfig --dump_device_desc
>>>         data for my two FTDI devices:
>>>
>>>         ugen1.3: <FT232R USB UART FTDI> at usbus1, cfg=0 md=HOST
>>>         spd=FULL (12Mbps) pwr=ON (90mA)
>>>           bLength = 0x0012
>>>           bDescriptorType = 0x0001
>>>           bcdUSB = 0x0200
>>>           bDeviceClass = 0x0000
>>>           bDeviceSubClass = 0x0000
>>>           bDeviceProtocol = 0x0000
>>>           bMaxPacketSize0 = 0x0008
>>>           idVendor = 0x0403
>>>           idProduct = 0x6001
>>>           bcdDevice = 0x0600
>>>           iManufacturer = 0x0001  <FTDI>
>>>           iProduct = 0x0002  <FT232R USB UART>
>>>           iSerialNumber = 0x0003  <A9xxxxxD>
>>>           bNumConfigurations = 0x0001
>>>
>>>         ugen2.3: <USB FAST SERIAL ADAPTER FTDI> at usbus2, cfg=0
>>>         md=HOST spd=FULL (12Mbps) pwr=ON (44mA)
>>>           bcdUSB = 0x0110
>>>           bcdDevice = 0x0400
>>>           iManufacturer = 0x0001  <FTDI>
>>>           iProduct = 0x0002  <USB FAST SERIAL ADAPTER>
>>>           iSerialNumber = 0x0003  <FTCDXXX>
>>>         (skipped all other attributes which are identical)
>>>
>>>
>>>
>>>         Johan
>>>
>>>
>>>         On 9/22/14 18:23 , Paul Alfille wrote:
>>>>         I notice in recent Linux (Fedora specifically) that USB
>>>>         devices get pretty consistently listed by a reasonably
>>>>         consistent and recognizable name in /dev/serial/by_id. 
>>>>
>>>>         I haven't looked to closely at all the USB fields yet, but
>>>>         some devices have unique identifiers rather than the
>>>>         generic USB/serial. I was hoping to scan for known
>>>>         patterns, apply any optimizations, and then connect. The
>>>>         upcoming USB HobbyBoards hub will have that.
>>>>
>>>>         My dream is that owfs will be as "automatic" as possible.
>>>>         Currently we can automatically scan for:
>>>>         i2c
>>>>         DS9490R
>>>>         HA7Net
>>>>         OWSERVER-ENET
>>>>         w1
>>>>
>>>>         Hardware serial will always be a problem, but some
>>>>         USB-serial might be possible.
>>>>
>>>>         Paul
>>>>
>>>>         On Mon, Sep 22, 2014 at 2:59 AM, Johan Ström
>>>>         <jo...@stromnet.se <mailto:jo...@stromnet.se>> wrote:
>>>>
>>>>
>>>>             On 22/09/14 00:21, Robin Gilks wrote:
>>>>             >> 1. Trying to resolve a serial port TTY name (i.e.
>>>>             /dev/cuaU1 on FreeBSD)
>>>>             >> to a potential USB device is probably doable, but
>>>>             not without a lot of
>>>>             >> effort and OS specific code.
>>>>             >> I don't think it's worth trying to go down that road.
>>>>             >>
>>>>             > How about using udev on Linux (is there an equivalent on
>>>>             other OSes?) that
>>>>             > creates a symlink to a device node with a unique name
>>>>             from the type (FTDI)
>>>>             > and bus number and OWFS looks for that specific
>>>>             device name.
>>>>             >
>>>>             > Just an idea (had to do that years ago with serial
>>>>             devices to sort out a
>>>>             > connection to a weather station and an IR blaster,
>>>>             never sure what device
>>>>             > names each would come up with!).
>>>>             >
>>>>             >
>>>>
>>>>             I have a similar setup myself, using FreeBSD's devd. It
>>>>             uses my known,
>>>>             hard-coded USB serials to set up a symlink from
>>>>             /dev/cua-linkusb to
>>>>             /dev/cuaXXX when device is detected, to easier find
>>>>             which tty device I
>>>>             should be using for what (I think I have ~4 serial
>>>>             ports on my box)
>>>>
>>>>             However, this doesn't solve the auto-deteciton problem,
>>>>             the user still
>>>>             needs to manually tell which USB device to be used, by
>>>>             serial-no or
>>>>             otherwise. And if that has to be done, it could just as
>>>>             well be done
>>>>             directly in owfs.
>>>>
>>>>             
>>>> ------------------------------------------------------------------------------
>>>>             Meet PCI DSS 3.0 Compliance Requirements with EventLog
>>>>             Analyzer
>>>>             Achieve PCI DSS 3.0 Compliant Status with
>>>>             Out-of-the-box PCI DSS Reports
>>>>             Are you Audit-Ready for PCI DSS 3.0 Compliance?
>>>>             Download White paper
>>>>             Comply to PCI DSS 3.0 Requirement 10 and 11.5 with
>>>>             EventLog Analyzer
>>>>             
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>>>             _______________________________________________
>>>>             Owfs-developers mailing list
>>>>             Owfs-developers@lists.sourceforge.net
>>>>             <mailto:Owfs-developers@lists.sourceforge.net>
>>>>             https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>> ------------------------------------------------------------------------------
>>>>         Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>>>         Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS 
>>>> Reports
>>>>         Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White 
>>>> paper
>>>>         Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog 
>>>> Analyzer
>>>>         
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>>>
>>>>
>>>>         _______________________________________________
>>>>         Owfs-developers mailing list
>>>>         Owfs-developers@lists.sourceforge.net 
>>>> <mailto:Owfs-developers@lists.sourceforge.net>
>>>>         https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>
>>>
>>>         
>>> ------------------------------------------------------------------------------
>>>         Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>>         Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI
>>>         DSS Reports
>>>         Are you Audit-Ready for PCI DSS 3.0 Compliance? Download
>>>         White paper
>>>         Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog
>>>         Analyzer
>>>         
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>>         _______________________________________________
>>>         Owfs-developers mailing list
>>>         Owfs-developers@lists.sourceforge.net
>>>         <mailto:Owfs-developers@lists.sourceforge.net>
>>>         https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>>
>>>
>>>
>>>
>>>     
>>> ------------------------------------------------------------------------------
>>>     Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>>     Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>>>     Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>>     Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>>     
>>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>>
>>>
>>>     _______________________________________________
>>>     Owfs-developers mailing list
>>>     Owfs-developers@lists.sourceforge.net 
>>> <mailto:Owfs-developers@lists.sourceforge.net>
>>>     https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>>     
>> ------------------------------------------------------------------------------
>>     Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>>     Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS
>>     Reports
>>     Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>>     Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>>     
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>>     _______________________________________________
>>     Owfs-developers mailing list
>>     Owfs-developers@lists.sourceforge.net
>>     <mailto:Owfs-developers@lists.sourceforge.net>
>>     https://lists.sourceforge.net/lists/listinfo/owfs-developers
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________
>> Owfs-developers mailing list
>> Owfs-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Reply via email to