On Mon, 25 May 2015, Rong Wang wrote: > On Fri, May 22, 2015 at 10:06 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 22 May 2015, Rong Wang wrote: > > > >> Hi, > >> > >> We have one USB 2.0 Controller on an ARM SoC, with internal PHY > >> confirming to UTMI. > >> The PHY would detect unexpected disconnect (amplitude of the > >> differential envelop still < 625 mV) > >> and assert the HostDisconnect signal to the Controller to indicate a > >> disconnection event. > >> When the HostDisconnect signal is asserted, the Controller will first > >> do some internal clean work > >> before it update CCS and CSC in PORTSCx and reports a Port Change > >> Detect interrupt. > >> We want to improve the situation > > > > Why do you want to improve the situation? What's wrong with the way it > > is now? Detecting a disconnect while the differential amplitude is < > > 625 mv is perfectly legal. The USB-2.0 spec requires: "Signals with > > differential amplitudes <= 525 mV must never activate the Disconnection > > Envelope Detector" (section 7.1.7.3). > > > > Our customer oberserved some unexpected disconnections during the > "shaking" test (user scenario simulation). They want the disconnection > detection to be less sensitive (>= 625 mV). Because once the > discoonection is reported, the APP SW will be re-launched and the USB > device will also notify user the disconnection event, which is not > accepted by our customer. It seems that your customer wants to change the hardware, not the software. > > It sounds like you are going to make the situation worse, not improve > > it. > > We are going to filter the intermittent disconnection signal from PHY, > but we must determine a true disconnection by driver with a retry scheme. > I agree that it will make the situation more complicated because there may > be many corner cases that we don't forsee and one of them may even > make this workaround not workable. Sometimes there are hardware problems that can not be solved in software, or are too difficult to solve in software. I think this is one of them. 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
