On 02/27/2019 12:13 PM, Martin Pieuchot wrote: > On 26/02/19(Tue) 00:49, James Hastings wrote: >> On 02/25/2019 02:22 PM, Martin Pieuchot wrote: >>> On 18/02/19(Mon) 03:31, James Hastings wrote: >>>> On 17/02/19(Sun) 15:07, Martin Pieuchot wrote: >>>>> On 15/02/19(Fri) 01:47, James Hastings wrote: >>>>>> I settled on a patch providing an additional 250ms powerdelay in >>>> uhub(4). >>>>>> mue(4) reliably attaches now, but hotplugging devices in the left two >>>>>> ports is still an issue. >>>>> >>>>> Interesting. Could you build a kernel with UHUB_DEBUG enable and >>>>> compare the status of the ports? I'm wondering if your increased delay >>>>> will change the value returned by usbd_get_port_status() line 376. >>>> >>>> Before: >>>> uhub2: port 1 status=0x0100 change=0x0000 >>>> >>>> With delay: >>>> uhub2: port 1 status=0x0101 change=0x0001 >>>> uhub2: port 1 status=0x0503 change=0x0000 >>> >>> Did you look at the bit which is set with delay? What does it mean? >> >> The status bit set with delay is UPS_CURRENT_CONNECT_STATUS. change bit >> is UPS_C_CONNECT_STATUS. >> >>> You said that hotplugging is not working with your diff, right? Did you >>> capture the output w/ UHUB_DEBUG when hot-plugging a device? What did >>> you see? Was this bit also absent? >> >> Yes I checked that too, hotplugging a device at uhub2 produces zero >> debug output to console. > > But do you see different port status when using lsusb(1)? > lsusb(1) port status bits from uhub2: before: Port 2: 0000.0100 power
inserted: Port 2: 0001.0101 C_CONNECT power connect removed: Port 2: 0001.0100 C_CONNECT power > You could also enable DWC_DEBUG and see if adding/removing a device > generates interrupts? > I attempted this with a GENERIC kernel and debug output would run for days without stopping because the root disk is on usb. I am starting a make build and make release to get a ramdisk kernel with DWC_DEBUG enabled.
