On Thu, 8 May 2014, Dan Williams wrote: > 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?". As far as I can see, it looks like no special casing is needed. Now, I haven't gone through all the changes introduced by the patch series to make sure, but it seems that all the various port status tests in port_event() will see everything appearing normal, because that's how hub_port_debounce_be_connected() -- or whatever its current name is -- will leave the port. Thus, nothing will happen up until the place in hub_port_connect_change() headed by the "Try to resuscitate an existing device" comment. At that point we will resume the child device. That is, assuming khubd thinks it has any reason for for calling hub_port_connect_change(), which it probably won't. So at first sight, it appears that nothing would need to be changed. I suggest you try it and see. Alan Stern -- 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
