On Wed, Jun 7, 2017 at 9:09 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > 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 > Thanks Alan. I understand and agree. It is a legacy platform that we are supporting and I needed to address this issue on 3.10.17. We are in the process of migrating to 4.1.x this coming week to check on this behavior. Until then can you help us with the one thing i.e. can you point me to where in the latest kernel code is the warm reset initiated? Thanks again. Best regards, Praneeth L >> > 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
