I have run into an issue which seems to call into question the
udev paradigm for USB devices. In my case it has ramifications in
ModemManager and gpsd packages, but I see it as a fundamental
problem with udev which is in all current versions of Fedora.
My USB GPS is a BU-353 which uses a pl2303 USB-Serial Controller
(idVendor=067b, idProduct=2303). However, bugzilla report 878737
indicates this same interface chip is used on other devices such
as RS232-USB adapters.
If the device is a GPS you do not want ModemManager run on it
(bugzilla 1023234) but you do want gpsctl to tell gpsd about it
when it is plugged in. If it is a RS232 adapter the opposite is
true (bugzilla 878737). Note that it is reported that the DU-353
can be bricked if the wrong thing is written to it.
After looking at the lsusb -v output for my BU-353 and the output
for RS232 devices reported on the net, I do not see any way to
distinguish between the two different types of devices that udev
could use to tell them apart.
Unless I am missing something this seems like a fatal flaw in the
udev paradigm.
As the others have said, there's no way to determine what's sitting
behind those serial controllers so it's not a problem with udev but
with the hardware it has to handle. The default udev setting is, or
at least used to be, designed for the most common case, which turns
out wrong for you. No matter what udev does, someone is not going to
get their device auto-configured, so the right choice is to handle
the most common case.
Now, it's possible that modems aren't just used much any more, so
that requiring manual scan would make sense, and udev makes it
possible.
By the way, it seems to me that on a computer with no modems, one
should simply uninistal ModemManager:
yum erase ModemManager