Alan, > Other people know more about this than I do. Isn't there a specific > request you send the device to cause the CPU to reset? > Yes, the 0x01 bit in CPUC_REGS on the fx2 is toggled with control calls. > > You're likely to run into trouble, because the reenumeration will cause > the device's descriptors to change and that will cause the kernel to > unbind the existing driver. Thus the open call will end up associated > with a defunct device instance. > > Normally firmware is sent while probe() runs and the device's CPU is > reset right away. The driver gets unbound and rebound, and the second > time through the probe() routine recognizes that the firmware has > already been installed. > Good advice, I've done this in probe now, but still the behaviour is not what I expect. Shouldn't the driver disconnect and then re-probe when the chip renumerates? I don't have trouble keeping track of that two pass approach in probe. I'm expecting the unbinding to happen automatically when I reset the CPU on the USB chip. Is this an incorrect assumption? Should I manually bind/unbind? I'm not even trying to download the firmware. Just trying to verify renumeration with the fx2 loader firmware. regards, John -- 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
