linux cdc suspend even when opened

[diggit]

Hi,
I am getting device suspend, even when com port is opened on PC. This basically disables device cdc TX flushing.
Kernel: Linux 5.13.10

I don't think this is tinyusb issue, but I also don't know where to ask for help.
Is there some setting on USB device side, which could tell USB host to relax suspending?
Does anybody have similar issue on Linux?

[hathach]

can you provide a bit of background info, which board and which firmware you are running, what have you done in the linux host. Is it selective port suspend (a dmesg log may have some hint) etc ... If it is indeed port suspend, there is no point for flushing, since usb bus is not active.

[diggit]

I am on 0411810, board is custom (ULPY PHY + STM32H730 like in #900), otherwise pretty much dual cdc example with only one CDC enabled.
Board is connected directly to USB port on my PC.
Enumeration works fine. Device Rx (PC->device) works without issues.
Device Tx works for limited time only (until suspend occurs), after any event initiated by host.
So cdc loopback, which is always initiated by host, works fine.
If I try to send data from device spontaneously, after time time since enumeration, no data come to host because device was suspended in the meantime.

dmesg holds enumeration info only, nothing else appears there...

[137581.026857] usb 2-1.8.2.6: new high-speed USB device number 75 using ehci-pci
[137581.125110] usb 2-1.8.2.6: New USB device found, idVendor=cafe, idProduct=4001, bcdDevice= 1.00
[137581.125122] usb 2-1.8.2.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[137581.125126] usb 2-1.8.2.6: Product: test
[137581.125130] usb 2-1.8.2.6: Manufacturer: custom
[137581.125132] usb 2-1.8.2.6: SerialNumber: 123456
[137581.126074] cdc_acm 2-1.8.2.6:1.0: ttyACM0: USB ACM device

[diggit]

oh...
TUD_CONFIG_DESCRIPTOR(1, ITF_NUM_TOTAL, 0, CONFIG_TOTAL_LEN, TUSB_DESC_CONFIG_ATT_REMOTE_WAKEUP, 500),

When I remove attribute TUSB_DESC_CONFIG_ATT_REMOTE_WAKEUP device does not receive suspend requests once I open uart from host.
Two observed issues arise:

• after closing uart, there is not any suspend request anymore
• shouldn't flushing of CDC TX buffer cause remote wake-up to let the host know about data being ready?

[hathach]

• if your application does not support remote wakeup, you should not report it as capacities for the device

shouldn't flushing of CDC TX buffer cause remote wake-up to let the host know about data being ready?

No, when bus is suspended, tinyusb as a stack won't try to communicate with host at that state. It also don't know when to wake the host, remote_wakeup() should always be called explicitly by application.

[diggit]

shouldn't flushing of CDC TX buffer cause remote wake-up to let the host know about data being ready?

Ok, synopsys has a little TODO blocker, I guess...

in dcd_synopsys.c

void dcd_remote_wakeup(uint8_t rhport)
{
  (void) rhport;

  // TODO must manually clear this bit after 1-15 ms
  // USB_OTG_DeviceTypeDef * dev = DEVICE_BASE(rhport);
  // dev->DCTL |= USB_OTG_DCTL_RWUSIG;
}

[hathach]

yeah, seem like remote wakeup is not implemented yet on the synopsys port