the symptom is that, when uploading code with avrdude, sometimes the result is successful, but not always. I have dozens of Chinese clones of arduino nano with CH340C. uploading fails on about 6 of 10. usually ends up with `expect=0xWHATEVER, resp=0xfc`. during the process, some commands get proper replies, such as `Device signature = 0x1e950f (probably m328p)`, others do not. this seems like a baud rate issue. the Linux kernel driver had a similar issue in the past. but recent kernel does not, which was verified on Fedora 36. avrdude on the Fedora can upload code to all the problematic nano boards. after reading this report on GitHub, i was convinced that the uchcom(4) has issues. https://github.com/nospam2000/ch341-baudrate-calculation when `uchcom_calc_divider_settings()` is replaced with the one in NetBSD, all boards work. Sometimes, I am facing issues when avrdude verifies the flash content, but I am not yet sure what is wrong. could not find common denominators yet. at least, uploading always works with old bootloader (boud rate 57600), and new bootloader (115200).
Created attachment 235574 [details] PoC patch that fixed the issue here is my local patch that fixed the issue.
"always work" is bit too early to say. although success rate is far better than before, i am seeing failures.
checked all the failed boards on Fedora. none worked. it is likely that they are malfunctioning not because of issues in device driver. at least, the patch saved some.
tested other CH340 chips. works fine with CH340G (115200).