>> The EHCI controller doesn't properly detect the case when > > "The" EHCI controller? I don't know what EHCI controller you're > talking about, but my controllers don't have any trouble detecting > device removal during suspend. This is similar to other SoC-based controllers that loose state in suspend, like on Samsung's Exynos. Usually we catch that with the FLAG_CF check in ehci_resume(). In the case of RK3288 it unfortunately leaves the CF flag (and other things, like PORTSC[PED] bits) set, although it doesn't react to any events correctly. If the device looses its power session the controller won't notice and then on resume get stuck trying to send resume signals to something that had been reset (or newly plugged in). I think since we can't trust the controller to do anything right, the safest thing is to fall back to the solution of resetting everything (at least we know that works), and since the FLAG_CF check doesn't work we need another solution to mark which controllers are affected. > Isn't this solution too extreme? What if the device was a flash > storage drive and it wasn't unplugged during suspend? This patch would > force it to be removed, messing up any mounted filesystems, when there > was no need. > > Can you find a better way to work around the problem? As Doug said, I think persist is the solution. We have essentially the same case: all we know is that there is now a device connected to the same port that a device had been connected during suspend... but with no guarantees whether it is the same device or in the same state. By forcing people to use persist, we acknowledge that this has the same risks (e.g. data corruption if a mounted mass storage device was swapped out for another one), and we benefit from the same safety checks like comparing the serial number. -- 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
