On Thu, Jun 03, 2021 at 02:48:44PM -0700, David Frey wrote: > Hi Johan, > > I have added linux-usb@xxxxxxxxxxxxxxx to the CC as requested. > > > I just verified with a CP2102N here and everything appears to work as > > expected as it also does with some of your boards. Could the CP2102N in > > the board in question be configured differently in EEPROM? > I would be surprised if the EEPROM of the failing devices were > customized, but I'm not sure how to prove that there weren't modified. > The CP2102N seems to identify with the default VID/PID, so that's > evidence supporting the theory that it's not been modified. It could be some other setting. I guess we could read out the entire configuration blob and compare it to that of a working CP2102N just to be sure. > Now I upgraded to kernel 5.12.8 (after the bug) and when I plug in the > device I get: > 5.12.8: Before trying to flash the ESP32 using the CP2102N: > $ stty -F /dev/ttyUSB0 -a > speed 9600 baud; rows 0; columns 0; line = 0; > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; > eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; > rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; > -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts > -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl > ixon -ixoff -iuclc -ixany -imaxbel -iutf8 > opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 > isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop > -echoprt echoctl echoke -flusho -extproc > > 5.12.8: Debug logs as a result of above stty command: > [ 507.773433] cp210x ttyUSB0: cp210x_change_speed - setting baud rate to 9600 > [ 507.774216] cp210x ttyUSB0: cp210x_set_flow_control - ctrl = 0x00, > flow = 0x01 > [ 507.774450] cp210x ttyUSB0: cp210x_tiocmset_port - control = 0x0303 > [ 507.774673] cp210x ttyUSB0: failed set request 0x7 status: -32 > [ 507.775273] cp210x ttyUSB0: cp210x_tiocmset_port - control = 0x0300 > [ 507.775454] cp210x ttyUSB0: failed set request 0x7 status: -32 > > 5.12.8: Debugs logs as a result of FAILED programming of ESP32: > [ 1385.733008] cp210x ttyUSB0: cp210x_change_speed - setting baud rate to 9600 > [ 1385.733899] cp210x ttyUSB0: cp210x_set_flow_control - ctrl = 0x00, > flow = 0x01 > [ 1385.734165] cp210x ttyUSB0: cp210x_tiocmset_port - control = 0x0303 > [ 1385.734391] cp210x ttyUSB0: failed set request 0x7 status: -32 > [ 1385.735014] cp210x ttyUSB0: cp210x_set_flow_control - ctrl = 0x01, > flow = 0x40 > [ 1385.735187] cp210x ttyUSB0: cp210x_tiocmset_port - control = 0x0101 > [ 1385.735316] cp210x ttyUSB0: cp210x_tiocmset_port - control = 0x0202 > [ 1385.735558] cp210x ttyUSB0: failed set request 0x7 status: -32 > [ 1385.735817] cp210x ttyUSB0: cp210x_tiocmset_port - control = 0x0300 > [ 1385.736082] cp210x ttyUSB0: failed set request 0x7 status: -32 Thanks a lot for testing this. You seem to have the same issue as the one reported by Alex here a fews days after you: https://lore.kernel.org/r/465ef3ac-4291-6392-e52b-26cc0c34dd7c@xxxxxxxxxxxxx let's keep discussing in that thread. I added you on CC. > 5.12.8: After failed programming: > $ stty -F /dev/ttyUSB0 -a > speed 9600 baud; rows 0; columns 0; line = 0; > intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; > eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; > rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 0; time = 0; > -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts > -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl > -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 > -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 > bs0 vt0 ff0 > -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase > -tostop -echoprt -echoctl -echoke -flusho -extproc > > > It appears that in the 5.12.8 kernel, there is a failure every time > cp210x_tiocmset_port is called resulting from this: > ret = cp210x_write_u16_reg(port, CP210X_SET_MHS, control); Indeed. Alex bisected it down to a commit setting the default IXOFF thresholds. Not sure why that would cause the device to misbehave yet, but we may need to stick with the default settings for CP2102N if we can't figure it out. Johan
