On Fri, 2 Nov 2012, Sarah Sharp wrote: > > I don't like that idea. It would be much simpler to put the port back > > into a useful state. For example, disable the port, then put it into > > RxDetect, then clear any change bits, and set the port's bit in > > hub->removed_bits. > > > > (hub->removed_bits was meant to help implement Windows' "Safely remove > > hardware" feature. When a port's bit is set, khubd will ignore any > > device attached to that port until it sees a connect-change.) > > Oh, interesting! I didn't know that. I think putting the device into > disabled, then RxDetect and ignoring it is a good solution, however... > > What exactly does khubd do when it ignores the device? Does it still > clear the change bits, but not take any action on them? Or does it > ignore the change bits entirely? The other way around -- it pays attention to the port-change bits and treats them normally. The important part is in hub_port_connect_change(); if there hasn't been a connect-change or a disconnect then it won't try to enumerate a device plugged into the port. > If khubd completely ignores the port status change bits, I think we have > an issue with xHCI. The xHC only generates a port event when all port > change bits were previously cleared (see section 4.19.2). So if a port > change bit gets set and the port status change event is completely > ignored by khubd, the xHC won't generate a port status change event on > the disconnect. A port will seem "dead" after a safely remove, if an > event like an overcurrent or link state change occurs. > > Ignoring one port shouldn't have any affect on port status change event > generation for other ports, so I think we're ok there. I'll just have > to take a look at how khubd deals with the hub->removed_bits. It's pretty straightforward. You can play around with it by writing to /sys/bus/usb/devices/.../remove. The usb_remove_store() routine calls usb_remove_device(). 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
