Sarah: Improving the bandwidth management in ehci-hcd will require a lot of changes, and some difficult issues have come up. Maybe you can suggest a good way to approach them. The first problem is that when a Set-Interface request fails, the HCD needs to revert to the previous schedule settings. Now even though the badnwidth mutex gets held throughout the entire procedure, there's no guarantee that the old settings can be restored unless they are saved somewhere for reuse. This suggests that bandwidth allocation changes should be carried in multiple steps. Initially usbcore tells the HCD which endpoints are to be disabled and enabled, and then later usbcore tells the HCD either to accept the changes or to revert them. The second problem is that periodic schedule changes can be rather invasive, causing service intervals to be missed for endpoints on devices other than the one being changed if rebalancing is needed. For this reason I would like to avoid rebalancing whenever possible. One example is when reverting an altsetting change, the other is when a Set-Config request fails. In that case we disable all the device's endpoints (other than ep0), which means there's no need to rebalance the schedule for all the other devices. Again, to recognize when this situation occurs, the HCD has to be told not to accept the previous changes (installing the new config) but to carry out different changes instead (disabling the entire device). What do you think? Does this seem feasible? 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
