Attention is currently required from: qianfan, Angel Pons.
Nicholas Chin has posted comments on this change. ( https://review.coreboot.org/c/flashrom/+/70529 )
Change subject: Add initial CH347T SPI programmer ......................................................................
Patch Set 3:
(3 comments)
File ch347t_spi.c:
https://review.coreboot.org/c/flashrom/+/70529/comment/74e885a0_6b4fd161 PS3, Line 84: enum spi_nss { : SPI_NSS_SOFT = 0x0200, : SPI_NSS_HARD = 0x0000 : };
I don't know what this means, maybe it is used for spi device. […]
stlinkv3_spi.c also uses NSS, and that code labels it as meaning "Negated Slave Select". After reading about hardware vs software NSS for ST Link devices, it seems like it isn't what I thought it was. This is an article that sort of explains it: https://fastbitlab.com/stm32-spi-hardware-software-slave-managements/
In any case, I could never make those bits change using any settings while calling `CH347SPI_Init` in the vendor driver so it likely doesn't really matter for our purposes.
https://review.coreboot.org/c/flashrom/+/70529/comment/6dbec451_3a50e5b3 PS3, Line 119: SPI_NSS_HARD The vendor drivers set this to 0x0200, which is SPI_NSS_SOFT in the enum. Not that it seems to make any difference in the behavior though
https://review.coreboot.org/c/flashrom/+/70529/comment/63335074_fae88ede PS3, Line 420: 0
Mode 1 uses interface 2, and the programmer currently fails if the vendor kernel driver is loaded.
Rewording what I meant: Mode 1 uses interface 2, so the code currently will not correctly detach the vendor kernel driver attached to interface 2 and not 0, causing flashrom to fail as libusb cannot take control of the chip. It would probably be good to move the interface number into ch347_device (mode 2 uses interface 1)