> Who makes those calls, drivers? Any specific ones that you know need to be fixed? Well, the one I'm worried about is the one this patch is fixing, in hub_events(). I have seen this happen when having certain USB3 devices plugged into a host controller that always looses power on suspend-to-ram (dwc3-exynos). Since the host controller resets itself the port no longer has PORT_STAT_ENABLE set and that causes hub_activate() to mark the device as USB_STATE_NOTATTACHED. The next time khubd runs hub_events(), the port may be in Compliance Mode (because the unexpected HC reset can confuse the link state machines on both sides) and the kernel correctly tries to reset it, but doesn't take the fact into account that usb_reset_device() doesn't work on NOTATTACHED devices. > But what can a user do if those messages show up? Nothing. I was just thinking this might help developers follow the kernel decisions better and understand a potential problem faster (e.g. if the user posted his log in a bug report somewhere). > What if the device is in USB_STATE_SUSPENDED? I'm not sure that is possible at that point in hub_events(), I don't know of a way that could lead to this situation. I could still add the check just to be sure if you want it, though. > Not at all. If a device is unplugged, its state changes to NOTATTACHED > before the driver is unbound. During that time, the driver will see > all its URBs failing, so it may very well try to reset the device. > (For example, usbhid behaves like this.) That isn't a bug. Oh, okay, I wasn't quite sure how that plays together. Would you think it's still valuable to print it out (maybe as dev_info() instead of dev_warn()) instead of just silently ignoring the reset request? It would have certainly been useful for me to find this problem faster, but I can take it out again if you think it would result in too much noise. -- 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
