On 06/25/2013 01:29 PM, Greg KH wrote:
Then that library should somehow be unbinding the device from the ttyUSB
port, right? I really don't know how that library works, sorry.
Now that I checked, it does, you're right. The libftdi userspace
library does remove the entries from /dev.
AFAIK mdev gets called by the kernel when there's a hotplug event.
Why didn't the kernel notify mdev to generate the new entries in the
/dev directory ??
Because the devices didn't show back up? Or perhaps, because the
libftdi library unbound the tty ports from the device, which would cause
them to go away in /dev/ because the library is now talking directly to
the device, through the /dev/usb/ device nodes instead of through the
tty device nodes.
But I'm just guessing here...
From the original dmesg entries, the kernel does attach them to other
ports, but right now I'm not so sure if the intrusion of the libftdi
userspace driver has anything to do with identifying new ones. I think
one solution might be to check always if the assigned devnum for the
listed ftdi devices remain the same before reading from them, if they
change ( hope not in a periodic manner ), then reconfigure the two
devices for new ports. It's a bit sloppy but I think it might work.
I'm still a bit worried as of why the reset happened in the first
place. I'm currently with Alan in another thread trying to see if it's
a software or a hardware issue.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
