Hello, On Sun, 7 Jan 2018 12:48:35 +0000, Vincent Pelletier <plr.vincent@xxxxxxxxx> wrote: > Some update: this patch looks good on DWC3: both unplugging and > unbinding the UDC while AOI transfers are queued works fine. > > What I intended to do is to also test it on DWC2, so I bought a > raspberry pi zero W (ie, with embedded wifi chip on SDIO), but the fail > is strong with me and I just cannot get a custom kernel build to boot > (blocks right after detecting mmc0 & mmc1 and listing MMC partitions), > so I could not extend my tests yet. I'll keep trying, but testers with > a DWC2 or other UDC are very welcome to give that patch a try. I could get around to build a kernel on the raspberry pi zero, rpi-4.16.y as of 6793af87063ddb793c9b40c77a0a70bad09375c7 on https://github.com/raspberrypi/linux with proposed patch applied. My test scenario passed with dwc2 module (dwc_otg, the default off-tree driver on raspberry-pi kernels, is host-only). There are a few caveat though, which I believe are unrelated to this patch: - upon first binding the UDC to the device, there is a WARNING (see the end of this mail) which seems to be a known issue: https://lkml.org/lkml/2017/2/24/723 In ly case, this does not seem to prevent the UDC from working. - upon unplugging USB, the function does not receive an onDisable event. I believe this is because of how the raspberry pi zero board is wired: USB power bus is the board main 5V power bus (shorted to the power-only micro usb plug), so to keep the raspberry pi powered on despite unplugging the fully-wired port, Vbus stays high, so AFAIK the bus is in a state indistinguishable from HSidle. It is only when re-plugging that onDisable fires (because of re-enumeration ?), and the gadget does not seem to recover (no onEnable happen). It is after I unbind the UDC (to do things cleanly), exit the function process, start it again and re-bind the UDC that stuff start working again (so kernel-side can recover without a reboot, there is that). I of course do get an onUnbind if I unbind the UDC while the function implementation is running. No issue when doing this (especially, no AIO-related issue). No issue either when killing function program while bound to UDC and with in-flight AIO requests. While I would like to test this code with more UDCs, I am not sure I can afford to buy development boards (or otherwise linux-friendly boards involving such chips), build linux for each and do comprehensive testing. Should I resubmit my patch ? It applies cleanly on linus master as of f3afe530d644488a074291da04a69a296ab63046 Merge branch 'fixes-v4.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Finally, the WARNING mentioned above, surrounded by UDC binding logs to illustrate the overall sequence: Mar 02 00:57:54 sushi kernel: dwc2 20980000.usb: bound driver configfs-gadget Mar 02 00:57:54 sushi kernel: ------------[ cut here ]------------ Mar 02 00:57:55 sushi kernel: WARNING: CPU: 0 PID: 911 at drivers/usb/dwc2/gadget.c:289 dwc2_hsotg_init_fifo+0xf0/0x1d0 [dwc2] Mar 02 00:57:55 sushi kernel: insufficient fifo memory Mar 02 00:57:55 sushi kernel: Modules linked in: usb_f_fs libcomposite bnep hci_uart btbcm bluetooth ecdh_generic brcmfmac brcmutil sha256_generic cfg80211 snd_bcm2835(C) rfkill snd_pcm snd_timer snd dwc2 udc_core bcm2835_gpiomem uio_pdrv_genirq uio i2c_dev fuse ipv6 Mar 02 00:57:55 sushi kernel: CPU: 0 PID: 911 Comm: bash Tainted: G C 4.16.0-rc3+ #11 Mar 02 00:57:55 sushi kernel: Hardware name: BCM2835 Mar 02 00:57:55 sushi kernel: [<c00172dc>] (unwind_backtrace) from [<c0014904>] (show_stack+0x20/0x24) Mar 02 00:57:55 sushi kernel: [<c0014904>] (show_stack) from [<c068a6dc>] (dump_stack+0x20/0x28) Mar 02 00:57:55 sushi kernel: [<c068a6dc>] (dump_stack) from [<c00243cc>] (__warn+0xe0/0x108) Mar 02 00:57:55 sushi kernel: [<c00243cc>] (__warn) from [<c0024438>] (warn_slowpath_fmt+0x44/0x4c) Mar 02 00:57:55 sushi kernel: [<c0024438>] (warn_slowpath_fmt) from [<bf0f6e8c>] (dwc2_hsotg_init_fifo+0xf0/0x1d0 [dwc2]) Mar 02 00:57:55 sushi kernel: [<bf0f6e8c>] (dwc2_hsotg_init_fifo [dwc2]) from [<bf0f9b94>] (dwc2_hsotg_core_init_disconnected+0x88/0x3e4 [dwc2]) Mar 02 00:57:55 sushi kernel: [<bf0f9b94>] (dwc2_hsotg_core_init_disconnected [dwc2]) from [<bf0faa80>] (dwc2_hsotg_pullup+0x108/0x14c [dwc2]) Mar 02 00:57:55 sushi kernel: [<bf0faa80>] (dwc2_hsotg_pullup [dwc2]) from [<bf0d5478>] (usb_gadget_connect+0x48/0xe0 [udc_core]) Mar 02 00:57:55 sushi kernel: [<bf0d5478>] (usb_gadget_connect [udc_core]) from [<bf0d6140>] (udc_bind_to_driver+0x100/0x108 [udc_core]) Mar 02 00:57:55 sushi kernel: [<bf0d6140>] (udc_bind_to_driver [udc_core]) from [<bf0d6754>] (usb_gadget_probe_driver+0xb0/0x168 [udc_core]) Mar 02 00:57:55 sushi kernel: [<bf0d6754>] (usb_gadget_probe_driver [udc_core]) from [<bf4492a0>] (gadget_dev_desc_UDC_store+0xc0/0xdc [libcomposite]) Mar 02 00:57:55 sushi kernel: [<bf4492a0>] (gadget_dev_desc_UDC_store [libcomposite]) from [<c02019dc>] (configfs_write_file+0xe0/0x170) Mar 02 00:57:55 sushi kernel: [<c02019dc>] (configfs_write_file) from [<c017c940>] (__vfs_write+0x38/0x130) Mar 02 00:57:55 sushi kernel: [<c017c940>] (__vfs_write) from [<c017cbf8>] (vfs_write+0xb0/0x1c0) Mar 02 00:57:55 sushi kernel: [<c017cbf8>] (vfs_write) from [<c017ce38>] (SyS_write+0x4c/0xa0) Mar 02 00:57:55 sushi kernel: [<c017ce38>] (SyS_write) from [<c0009000>] (ret_fast_syscall+0x0/0x28) Mar 02 00:57:55 sushi kernel: Exception stack(0xd973bfa8 to 0xd973bff0) Mar 02 00:57:55 sushi kernel: bfa0: 0000000d 01fe6c08 00000001 01fe6c08 0000000d 00000000 Mar 02 00:57:55 sushi kernel: bfc0: 0000000d 01fe6c08 b6f2fb40 00000004 0000000d 01fe6c08 0000000d 00000000 Mar 02 00:57:55 sushi kernel: bfe0: 00000000 becdc37c b6e5d008 b6eb489c Mar 02 00:57:55 sushi kernel: ---[ end trace c008808c0b965618 ]--- Mar 02 00:57:55 sushi kernel: dwc2 20980000.usb: new device is high-speed Mar 02 00:57:55 sushi kernel: dwc2 20980000.usb: new device is high-speed Mar 02 00:57:55 sushi kernel: dwc2 20980000.usb: new address 64 Mar 02 00:57:55 sushi kernel: configfs-gadget gadget: high-speed config #1: c Regards, -- Vincent Pelletier -- 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
