On Fri, Jun 9, 2017 at 12:19 PM, Greg KH <greg@xxxxxxxxx> wrote: > On Fri, Jun 09, 2017 at 11:57:23AM +0530, lingareddy praneethreddy wrote: >> 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. > > 4.1.x or 4.11.x? They are a very different :) > >> 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. > > You have the full source tree, it's easier for you to search for it :) > > Good luck! > > greg k-h Sure Greg, I will locate that. I will suspend this discussion till we reproduce the issue on newer kernel i.e. 4.1.15. Thanks all. -- Thanks&Regards Praneeth Reddy L 8123739792 -- 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
