Hi, On Thu, Mar 14, 2013 at 7:58 AM, Thomas Abraham <thomas.abraham@xxxxxxxxxx> wrote: >> I can see your point, but as I mentioned earlier there seems to be some timing issue here. By simply doing the reset a few ms earlier (in the first probe, before the driver detects that it needs to defer probing), I already can't find the hub on the bus later. >> >> So I'm assuming that the same thing would also happen if I put it even earlier in machine init. > > True, I missed that point. The usb hub connected over hsic interface, > after power-on-reset, might have initiated the 'connect' state on > seeing the idle condition on the bus and since the host/phy controller > is not ready yet, the connect might have failed. > > So the correct sequence would be, after the usb host controller and > the phy controllers are initialized, the 'reset' pin on the on-board > usb hub should be asserted. Upon releasing that reset, the usb hub > would initiate the 'connect' state on the HSIC bus. I think we ran into similar issues on one of our boards that had a hub attached to the HSIC port. We had to make our fix in a version of the code that's nowhere near what landed upstream (so our change is not relevant), but we're definitely interested in whatever solution you come up with. :) -Doug -- 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
