On Mon, Jun 01, 2020 at 10:05:05AM +1000, Finn Thain wrote:
BTW, how does the issue being fixed manifest itself? That's not clear to me from the patch description.The bugs in the iop driver were found by inspection, in the course of debugging adb-iop driver failures that Stan encountered. It's possible that the adb-iop driver is not badly affected by these bugs (I don't know). It's possible that the iop driver bugs are among the reasons why the swim_iop driver was never stabilized. That driver was removed in b21a323710e7 ("[PATCH] remove the broken BLK_DEV_SWIM_IOP driver").
The swim_iop driver was never completed. As far as I know, the data transfer code was never written. I remember testing the driver, and all it could do was detect the drives and do eject. Read and write were not working. I looked into it at the time, but it's a little messy and is much more complicated than the ADB driver. For ADB, the data is small enough that it's packed in the IOP message. That's not possible for SWIM, so it has a more complex data handling method. If you look at the code of that driver and the messages, it looks like the IOP can do DMA but it can't. The SWIM IOP message includes a buffer pointer, but the IOP chip isn't connected in a way that it can just access it (and it's getting passed a virtual address anyway). Based on some of the other information I was given, there's a separate message protocol on channel 0 (on each IOP) for bulk data transfer. At the time, I had a diff to fix some bugs in the detection and handle the status update messages. However, it hardly seemed worth submitting that as a fix since the driver still wasn't useful without the bulk data transfer working. I can pass my diff along if you intend to make an attempt at a working swim_iop driver. Brad Boyer flar@xxxxxxxxxxxxx
