On 3/27/23 03:05, Oliver Neukum wrote:
On 23.03.23 22:32, Michael Laß wrote:
I am asking because the device says that it is bus powered.
That is, are we putting the device into some sleep state?
This got me thinking. I am observing the behavior on a ZedBoard, a
development board that contains a Xilinx Zynq SoC and the Cypress UART
chip connected to that SoC. I now looked into the schematic of that
board.
Are those devices out in the wild? That is can one buy them or did
you get it through development channels?
https://blockstream.com/jade/
We have a mass produced device Blockstream Jade with USB serial chip
CH9102F 1a86:55d4 misbehaving in the same manner. Tens of thousands of
this device were manufactured and sold worldwide. This board fails to
communicate with Linux cdc-acm unless autosuspend is turned off
(power/control set to 'on'). lsusb -v similarly reports "Bus Powered"
and "Remote Wakeup". [1]
Either of these workarounds allow this device to work by disabling
autosuspend:
* udev rule: ATTRS{idProduct}=="55d4", ATTRS{idVendor}=="1a86",
SUBSYSTEM=="usb", TEST=="power/control" ATTR{power/control}="on"
* usbcore.quirks=1a86:55d4:b
The chip is a CY7C64225-28PVXC and the datasheet has a section on USB
suspend and resume: When suspended, a separate WAKE input pin has to be
set high to issue a remote wake-up. The designers of the ZedBoard have
tied this pin to ground...
That is technically allowed, though disappointing, but then you cannot
advertise
"remote wakeup" in the device descriptor.
So the chip behaves as documented. If any, this is an issue with the
board design. Nothing the kernel could work around. Sorry, I hope I
haven't stolen too much of your time.
The kernel could work around it. We could quirk the device to ignore
the remote wakeup bit from this particular device based on ID.
RESET_RESUME would do that, albeit with side effects.
If such devices are found on sale we need to do something.
Regards
Oliver
https://datasheet.lcsc.com/lcsc/2108181630_WCH-Jiangsu-Qin-Heng-CH9102F_C2858418.pdf
The board contains the CH9102F USB to serial chip which appears in Linux
as /dev/ttyACM#. Prior to 2021 an earlier variant had the CP210x USB to
serial chip.
https://www.cnx-software.com/2021/09/14/ch9102f-a-replacement-for-cp2104-usb-to-uart-bridge/
During the pandemic supply chain constraints led to some switching to
the CH9102F which is described here as *almost* a drop-in replacement.
Unfortunately the pinout differences might have mattered. I am uncertain
if the board design could have been better but that is now in the past.
Too many were mass produced so I am hoping for a USB quirk to stabilize
this going forward.
I have confirmed USB_QUIRK_RESET_RESUME allows this device to function
for the same reason it works for the Cypress. I am uncertain if a
narrower new quirk "ignore the remote wakeup bit" would work here. How
can I test that?
We'd like to send a product sample to a linux-usb maintainer if they
would like to try it. Please e-mail me directly in that case.
Best Regards,
Warren Togami
[1] lsusb -v -d 1a86:55d4
Bus 005 Device 002: ID 1a86:55d4 QinHeng Electronics USB Single Serial
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x1a86 QinHeng Electronics
idProduct 0x55d4
bcdDevice 4.43
iManufacturer 0
iProduct 2 USB Single Serial
iSerial 3 537A009111
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0043
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 134mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands (v.25ter)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC ACM:
bmCapabilities 0x02
line coding and serial state
CDC Union:
bMasterInterface 0
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 CDC Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
