I'd be interested in looking at your results, I also came to the same conclusion previously but haven't made any changes yet...
From the documentation for the module it never suggests that the channel halted interrupt can be triggered by a data toggle error though (but this wouldn't be the first time the docs were wrong!)
Data toggle errors can occur at any stage of a USB transaction past the initial packet, IN or OUT where multiple data packets are exchanged. The interrupt handler for this even spits out a debug message to that effect.
In USB terms an error during a BULK or INTERRUPT transfer matters little - resending the current packet in the case of OUT or re-requesting a packet via NAK for an IN will result in re-synchronization.
ISOC transfers don't use data toggles except for high-speed multi-packet ISOC transfers which use an analogue of it to detect but not correct errors.
CONTROL data toggle errors are more serious - if they occur during query/setup phase of a device, you essentially have to redo the transaction from start. In this case you would want to either retry the transaction and the device should restart automatically (as per spec) or the handler should signal to the USB device driver that their control URB failed - which it may decide to retry.
The fact is that the DWC_OTG driver caters for precisely 0 of these conditions - does the underlying silicon handle this? If so, how much given that software intervention is implied to be required in certain cases.
Yay for patch - but I might be a while before considering the bug squashed in my case as I have only seen it once since the NAK holdoff fix...
How does this patch fix the issue? I see only a mod to the top-level IRQ handler to do with a somewhat cryptic reset of the MPHI interrupt every 60 FIQs...