On Fri, 29 Mar 2013, Christian Engelmayer wrote: > 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. To sum up, on some systems (the MPC8343E) it is necessary to cycle the port power whenever an over-current change occurs, whereas on other systems (those with the MAX4967) it is necessary _not_ to cycle the port power when an over-current change occurs. The right way to deal with this is to add a quirk flag. If this flag gets set on the MPC systems then it could essentially revert the behavior added by the 81463c1d7071 commit. Can you write a patch adding such a flag? 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
