Hi, I am currently looking into a seeming regression in ehci-hub.c where a change triggered by the behaviour of the MAX4967 USB power supply chip has broken the handling of the MPC8349 USB controller at that point. I'd like to come up with a patch solving the issue for both chips and would appreciate any hints towards an acceptable solution. We had experienced problems with the EHCI on an MPC8343E, which after some over-current situations no longer asserts the Connect Change Status Bit in the Port Status and Control Register, leading to the result that USB would be fully functional, but is no longer effectively serviced - see http://www.mail-archive.com/linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx/msg54310.html The behaviour was verified by Freescale and following information provided: > After the power fault condition is removed it is required to perform > following steps: > 1) Clear OCC bit by writing 1 to it. > 2) Disable port power by clearing PORTSC[PP] bit - this effectively moves > the host state machine to disabled state. > 3) Reapply port power by setting PORTSC[PP] back to 1. > At this stage CSC bit correctly reflects connect status change. and implemented in commit 756aa6b3d536afe85e151138cb03a293998887b3 My understanding is that the MAX4967 USB power supply chip used on some boards signals over-current when power is not enabled; once it's enabled, over-current signal returns to normal. That caused an endless stream of "over-current change on port" messages due to the behaviour as described above - see https://lkml.org/lkml/2011/8/5/478 and fixed for the MAX4967 in commit 81463c1d707186adbbe534016cd1249edeab0dac by only disabling port-power in case a currently active over-current situation is detected when handling the over-current change indication. Unfortunately this change removed power-cycling of the affected port after the fault condition is resolved, as required by the MPC8349. Regards, Christian -- 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
