On Tue, Jun 05, 2012 at 12:48:14AM -0700, Stanislaw Ledwon wrote: > > On 06/04/2012 09:34 PM, Stanislaw Ledwon wrote: > >>> On 06/04/2012 04:46 PM, Stanislaw Ledwon wrote: > >> The CAS bit is defined only on XHCI port status so I thought that this > >> is > >> better to not propagate this bit to core/hub. When the bogus bit is > >> defined in the reserved area of the port status then some conflicts are > >> possible on future USB products. > >> I think that this bogus bit should not be associated only with CAS but > >> should be used as general port reset request form controller specific > >> layer. > >> The reset on Compliance Modes should be supported as well - based on > >> USB3.0 HUB state diagram this is only possible way to return from this > >> state. > > > > OK. Since we don't have a well-defined link state for when the CAS bit is set, I think it's better to fake the compliance mode in the xhci hub code. I also really would like to avoid adding fake port status bits to the USB core. I know that's what was done for USB 2.0, but it causes confusion for new developers (including myself), and as Staszek pointed out, it may break any future xHCI extensions. So I think that Staszek should stick with faking compliance mode in order to force the USB core to issue a warm reset. Sarah Sharp -- 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
