Re: Continuous, infinite warm reset attempts in Chipidea HDRC on multiple connect-disconects

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 7 Jun 2017, lingareddy praneethreddy wrote:

> On Tue, Jun 6, 2017 at 7:38 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> >>On Tue, 6 Jun 2017, lingareddy praneethreddy wrote:
> >>
> >> I am using Chipidea HDRC on imx6sl platform. On connecting USB stick
> >> (sometimes) and Android/ Apple phone (frequent) to ci-hdrc multiple
> >> time it is seen that hub (ehci_hub_control())  reports continuous
> >> USB_PORT_FEAT_C_RESET  (infinitely) before a disconnect-connect caused
> >> USB_PORT_FEAT_C_OVER_CURRENT.
> >
> > Can you post a debugging log?  Do:
> >
> >         echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control
> >
> > before plugging in the device, and then copy the dmesg output.
> Thanks Alan. I have attached the full log. What I see is repeated calls like
> 
> [   42.984214] hub 1-0:1.0: port 1, status 0109, change 0003, 12 Mb/s
> [   43.144120] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms
> status 0x109
> [   43.204151] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002
> [   43.204190] hub 1-0:1.0: port 1, status 0109, change 0003, 12 Mb/s
> [   43.364118] hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms
> status 0x109

All those 0109 and 0108 port status values in the log indicate that the 
port's over-current status bit is turned on.  Nothing will work 
properly until you fix that.

> Let me know if you want working logs. I can attach that as well.
> >
> >> I have two queries:
> >> 1. Can we avoid the continuous warm reset ( USB_PORT_FEAT_C_RESET )
> >> i.e. can we force hub to initialize again and enumerate the device
> >> again?
> >
> > Reset _does_ initialize and enumerate the device again.
> >
> >> 2. Do we need to initialize both controller and hub i.e. we
> >> initialized controller (calling ehci_setup() and ehci_run())  but the
> >> hub continued the resets until the overcurrent bit was set.
> >
> > I don't understand this question.  But remember, the hardware does not
> > decide when to issue a reset.  That decision is made by the driver
> > software in the kernel.
> >
> >
> 
> I meant.. can we stop this continuous warm reset in the driver?

The log shows you are using kernel version 3.10.17.  You wouldn't 
believe how out of date that kernel is.  What happens if you use a 4.11 
kernel?

> I was unable to
> pinpoint in the code where the warm reset is initiated again if the device is
> connected but no valid device is found. Can you help me pinpoint the code
> that reinitiates the warm reset? Thanks.

I can't help unless you use an up-to-date kernel.

Alan Stern

> > Try to disable over current at dts with property 'disable-over-current',
> > if it can't fix your problem, follow Alan's suggestion. If it can fix
> > your problem, try to fix your OC pinmux or polarity.
> >
> >
> 
> Thanks Peter. I tried this, Even if we do disable overcurrent I will still see
> the continuous warm reset. I was hoping to stop the "indefinite" warm
> reset i.e. limit it to maybe 10 retries.  I have attached log.
> 
> 
> Thanks and Regards
> Praneeth Reddy L
> 

--
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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux