On Thu, May 8, 2014 at 9:09 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 8 May 2014, Dan Williams wrote: > >> > I don't understand this last part. Why do we need to guarantee the >> > child device has recovered from power loss? Why not proceed the same >> > way we do now when the child is suspended? >> >> Two reasons I believe: >> >> 1/ The child may be gone, and usb_port_resume() will mark it for disconnect >> >> 2/ Currently port_event() knows how to handle suspended devices >> (USB_PORT_STAT_C_SUSPEND), but in the case of power loss recovery the >> status and change bits are different. I figure why special case >> port_event()? Just make it so it handles all the same cases that are >> presented when the port does not lose power. > > How much special casing would really be needed? Don't know. Is the forced wakeup really that onerous, vs the risk of touch established code? I've broken the port_event() path enough times through this exercise that I'd want a driving reason beyond "why not?". >> > If you take that stuff out, it seems that there won't be any need to >> > use wakeup_bits or usb_kick_khubd() for this purpose. >> >> See 1/ I think we want to handle disconnects right away, hence the khubd kick. > > If the child has been disconnected, pm_request_resume()'s callback > will determine that fact quickly enough. True. We can now skip the kick, but the runtime_barrier is still needed pending the resolution of the question above. -- 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
