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@lists.sourceforge.net/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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
