"Li, Aixiong" <aixiong.li@xxxxxxxxx> writes: > The patch format still have some problem since I copied it from the > html mail. I fix it in this mail. :) Since you are obviously going to have to submit this yet again, I'll squeeze in a question or two regarding the approach: Should the remote wakeup control be pushed down to the interface (i.e. function) drivers instead? I assume the point of the per-function remote wakeup feature in USB3 is that you don't necessarily want to enable remote wakeup for the whole composite device. Your patch makes USB3 devices behave similar to USB2 devices, which is of course fine as a quick hack. But I don't see the justification of a quick hack here... I believe per-function remote wakup control can be implemented by simply looking at the struct usb_interface "needs_remote_wakeup" flag. No need to enable it for functions where this flag isn't set. Well, I am probably missing some minor issues here as usual, but at least please explain why it is difficult to do this. And why not just use the "intf_assoc" pointer in the usb_interface struct? Ref /** * struct usb_interface - what usb device drivers talk to .. * @intf_assoc: interface association descriptor Traversing the whole list of IADs for every single interface on every runtime suspend isn't going to win you any efficiency prize... And lastly, the class specific test for intf_class == USB_CLASS_CDC_DATA seems completely redundant and out of place here. It will be handled as part of the IAD lookup, won't it? At least if the overhead of that is removed. Bjørn -- 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
