Fixes and improvements to SCSI request padding
Detail: In order to keep block-based SCSI devices happy, the data transfer length must be a multiple of the block size. Unfortunately the RISC OS SCSI API considers the act of padding requests out to the correct size to be a driver problem rather than a client problem, and the USB SCSI spec doesn't provide a guaranteed way for a host to determine the correct transfer length for a command which has failed. To cope with this SCSISoftUSB contains some code to pad block read/write transfer lengths out to a multiple of the USB packet size. For high-speed USB devices using standard 512 byte sector sizes this works fine, but for low-speed devices or devices with less common block sizes it falls short. To rectify this SCSISoftUSB now listens out for any CAPACITY commands which are sent to the device and peeks at the result to determine the correct block size to use. Except for rare cases where the client takes a random guess at the block size this should allow SCSISoftUSB to get the correct block size itself without having to implement lots of extra logic to deal with devices being slow to initialise, etc. Additionally the padding code has been rewritten to ensure writes are padded with nulls (previously would read off the end of the supplied source data), and excess read bytes are discarded (previously would write off the end of the destination buffer) File changes: c/glue, h/global Admin: Tested on Raspberry Pi USB2 devices forced to run at USB1 speed now behave themselves during non-sector sized filecore ops Version 0.19. Tagged as 'SCSISoftUSB-0_19'
Showing with 131 additions and 71 deletions