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