Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
everything after the usb1 (all the 1-1* sections) are dynamically allocated at the time the device is plugged in.
if you only ever plug one device into a port, then you can name things this way, but if there is a hub or multi-function device involved, it depends on the order that they are identified.
nowdays a lot of monitors and keyboards have hubs in them.
User-friendly disk names
Posted Jun 24, 2011 23:48 UTC (Fri) by mikov (subscriber, #33179)
You are saying that there is no theoretical way to identify the port in an USB hub where a device is inserted. So my scheme kind'a works only because it correctly identifies separate buses, and because already plugged devices in the same bus are enumerated in the same order. But if I start unplugging and plugging devices attached directly to a hub, I am screwed.
If I only could get my hands on the idiots who designed USB :-) Starting from the asymmetric connector and now down to this.
All that said, my complaint about the PCI device identification in the device model is still valid.
Posted Jun 25, 2011 0:44 UTC (Sat) by dlang (✭ supporter ✭, #313)
the thing you need to remember about USB is that is was initially designed for cheap, low-end, low speed devices like keyboards. Electrically it is a _very_ simple design.
you have four wires
the signaling over the data and clock wires is also pretty primitive (it's basically the i2c bus with a little more definition over the data standard)
all that a non-powered USB hub consists of is multiple sockets wired together (NO active electronics at all)
a powered hub is only required to add a power supply to this.
(now frequently hubs do add a bit more logic so that they can respond to queries from devices to answer how much power they can provide, but that's not a requirement of the USB 1.0 spec)
as for the funny connector, it was designed primarily to be cheap, then to be durable. it was copied from one of the popular console game systems that used it for the joysticks. They then made the ends of the cable different to make it impossible to plug things in incorrectly (and then people didn't like the size of the connector, so they made a different one, and a different one,.....)
over time things have gotten faster (by a factor of 100 or so), but everything is still backwards compatible so that you can take the oldest USB device and plug it into the newest system and things will work (everything on the bus will slow down to the speed of the slowest device on the bus, but it will function). USB was designed to be _extremely_ forgiving for slow or extremely low capability devices
device identification on USB is supposed by be done by a unique identifier in each device, but as USB interfaces have gotten cheaper (and moved from needing several chips, including separate rom/ram chips to being a tiny section of built-in logic 'thrown in' on a $5 chip in addition to the main functionality) the process and capability to give each device a unique serial number has fallen by the wayside (and/or cheap, short-sighted manufacturers have opted to shave pennies off their costs by not bothering to program the serial numbers on the devices) and the result is that sometimes there is no theoretical way to tell two devices apart once you are talking to them (you have to depend on what bus are they plugged into, which falls apart with hubs, at which point the only thing you can do is to depend on what order they were plugged in)
USB today is doing things never imagined by the designers, and in fact doing things that if you had asked the designers, they would have told you were explicitly _not_ in the world of things they designed USB for (due to the cost of implementing the interface with the technology of the time). For a lot of things that USB is being used for today, their answer would have been "use FireWire, it's designed for that sort of performance"
Posted Jun 25, 2011 1:22 UTC (Sat) by mikov (subscriber, #33179)
In our case, we are using several USB to serial converters plugged into a couple of hubs. They are supposed to be the same, so it is not the manufacturers fault that they are indistinguishable by anything other than their physical connection. Unfortunately there is no reasonably priced alternative to USB,
A single multi-port USB to serial converter would address this nicely, but
we have evaluated about a dozen of them, and while all they work perfectly in Windows, they are either unsupported in Linux at all, or horribly broken (like dropping a byte every couple of hours). It is an embarrassing shame. I wish our company had the resources to sponsor somebody to fix that.
The only multi-port converter that worked well (other than not having its "non-free" firmware in Debian), and was reasonably cheap and available in the USA, was an old Keyspan 4-port model, which is no longer manufactured...
Posted Jun 25, 2011 3:44 UTC (Sat) by dlang (✭ supporter ✭, #313)
Posted Jun 26, 2011 1:37 UTC (Sun) by mikov (subscriber, #33179)
However I see how a hybrid solution could work. Our current approach with PHYSDEVPATH does work if all devices are plugged in, so knowing that this the case we could use it to automatically generate a one time mapping from a USB serial number to location. It is still a pain because the mapping will have to be re-generated if a converter is replaced (and they do fail out in the field, being the cheap pieces of garbage that they are), but it is a conceptually robust solution.
Sigh, I do miss the olden days of ISA, i2c and even PCI. Now PCIE has been relegated to being a "server technology" in practice.
Posted Jun 26, 2011 3:02 UTC (Sun) by dlang (✭ supporter ✭, #313)
as for other technologies,
i2c has the exact same problem as USB, the only identity possible is what's reported by the device.
PCI has a slot number ID, but I've seen different versions of the kernel detect the multiple PCI buses in a different order
ISA didn't have any slot identifier, everything was based on the configuration of the individual board.
depending on how many of these serial adapters you need, your best bet may be to buy them from a more upstream provider, you could probably get someone to program a bunch of them with a set of identifiers (i.e. if you need 5 serial ports, get a bunch of them labeled and electronicly identified as #1, a bunch as #2, etc), then your udev rules could map them properly and your only limitation would be that you only replace a #1 with a #1
Posted Jun 27, 2011 3:17 UTC (Mon) by mikov (subscriber, #33179)
About PCI: you don't use the bus number at all. The sequence of PCI device:function id-s starting from the root bridge through all downstream bridges and ending at the device gives you a guaranteed unique mapping for that hardware regardless of BIOS, kernel, etc. You only need to define a mapping once for a motherboard/CompactPCI chassis and you get a reliable physical slot identification. That is how it is supposed to work and incidentally that is how Windows identifies its PCI devices.
udev and sysfs provide the same information, so it is technically possible to get the same functionality in Linux.
In a previous life I had to do stuff like hack an embedded PC BIOS and Windows bus driver to support huge numbers of PCI devices. The BIOS code was so bad it was scary (to this day I am impressed that PCs can boot at all), but the PCI bus itself at the logical level was a joy.
So purely as a user of USB, I naively believed that it was similar to PCI.
And I am surprised you commented on i2c. It is fundamentally different from USB - the device ids are fixed, or you can choose a bit at most (in hardware). There is no plug and play. Often you can't even have two devices of the same kind on the same bus. It takes half an hour to implement I2C from scratch via bit banging :-)
And ISA. Oh, ISA... It didn't have slot id-s, but it did have jumpers :-) Not to mention you could actually build an ISA board from scratch and do the decoding manually with wires... Good times.
Posted Jun 27, 2011 3:33 UTC (Mon) by dlang (✭ supporter ✭, #313)
as for USB vs i2c, if you look at the low-level over-the-wire protocol, i believe that USB is really a superset of i2c. you can bit-bang a USB interface as well, (although not very efficiently), USB adds an additional layer of software and standard definitions over the raw wire protocol.
I could be mistake, but when I first learned about USB I was looking very closely at i2c for other things and I remembering that they were extremely similar at the hardware/signaling level
Posted Jun 27, 2011 4:12 UTC (Mon) by mikov (subscriber, #33179)
I think my point, to the extent that I even have a point beyond just being nostalgic about times when there was more direct control over hardware, is that in I2C there is no discovery. The device type is the device address. The devices and their ids are by definition fixed and known in advance. So, the question of identifying the physical location of a I2C device doesn't even exist. I2C is good for what it does.
With USB by contrast, you are identifying devices that look externally the same by a hidden magic serial number. There is a fundamental usability problem.
If I have two USB mouses which are _exactly_ the same, why do they need appear as separate devices to the computer? That makes no sense at all. If I plug them in the same PC at the same time, the only thing that really differentiates them is the USB connector.
Imagine a hypothetical product where users can interact with multiple virtual machines running on the same PC, using multiple video cards, mice and keyboards. It is pure idiocy to have to associate the keyboards and mice to the virtual machines by their unique USB serial number rather than the USB connector where they are plugged.
In other words, ideally USB hubs should have been designed to function like PCI-PCI bridges. Oh well, that is not a Linux problem :-)
Posted Nov 8, 2011 20:13 UTC (Tue) by jo42 (subscriber, #59640)
Where can I find this serial number? I've the same problem.
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 009: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 003 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 003 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 003 Device 006: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303]
Bus 003 Device 005: ID 0557:2008 ATEN International Co., Ltd UC-232A Serial Port [pl2303]
Bus 003 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 003 Device 003: ID 058f:9254 Alcor Micro Corp. Hub
Bus 003 Device 002: ID 058f:9254 Alcor Micro Corp. Hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
# diff <(lsusb -vvv -s 3:9) <(lsusb -vvv -s 3:8)
--- /proc/self/fd/11 2011-11-08 21:09:05.183873823 +0100
+++ /proc/self/fd/12 2011-11-08 21:09:05.183873823 +0100
@@ -1,5 +1,5 @@
-Bus 003 Device 009: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
+Bus 003 Device 008: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Posted Nov 8, 2011 22:14 UTC (Tue) by jimparis (subscriber, #38647)
USB Serial port woes
Posted Jun 26, 2011 16:31 UTC (Sun) by speedster1 (subscriber, #8143)
Do they _really_ work perfectly in Windows? In my experience, cheap serial converters are prone to dropping a byte now and then, and when I searched online it turned out that it was hardware not drivers -- Windows users would experience the same problem given the same level of usage and attention to detail (it just happens a lot less often, because there are more of us Linux developers making heavy use of serial ports).
Sorry I can't find an actual reference explaining the hardware issue on a common PLX usb-serial chip; there is no sufficient replacement yet for the recently-discontinued Google Linux search :`-(
I agree that keyspan did not have these problems, but they were significantly more expensive and seem to have lost out to the even cheaper but somewhat flaky adapters...
If there are current multi-port adapters that really do have higher quality chips in them (i.e. like keyspan rather than PLX) but lack Linux drivers, then somebody should get in touch with the Linux Driver Project and donate such an adapter!
Posted Jun 27, 2011 3:34 UTC (Mon) by mikov (subscriber, #33179)
There is one additional piece of information however, which can explain at least part of what I saw:
Most of the multiport USB-to-serial adapters are in fact a USB hub with ordinary single-port adapters hanging from it. The problem is that the hub is USB 2.0 while the serial adapters themselves are USB 1.0. Linux kernels at least up to 2.6.26 had a bug where USB 1.0 devices did not work reliably behind a USB 2.0 bridge.
I have complained about this problem before on LWN and I got advice to try other config settings, which I did, but saw no improvement.
I am not 100% sure the problems were caused by this and it is also possible that it has been fixed in later kernel versions.
Posted Jun 27, 2011 16:35 UTC (Mon) by speedster1 (subscriber, #8143)
If your problem is instead a more generic 2.0 hub driver problem, could you post a link discussing it? With details, I might be able to go check commit messages to see if it has supposedly been fixed.
Posted Jun 28, 2011 4:29 UTC (Tue) by mikov (subscriber, #33179)
BTW, we have been using PL2303 USB-to-serial adapters and we haven't had any issues with them, as long as (important!) USB 2.0 is disabled.
Posted Nov 3, 2011 8:46 UTC (Thu) by gebi (subscriber, #59940)
Posted Nov 13, 2011 14:29 UTC (Sun) by Baylink (subscriber, #755)
It's TCP instead of USB, but do you really care? :-)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds