Quote:
Originally Posted by igorsk
It's a standard trick - messages are sent to/from the device using a custom SCSI command. See modules/usb_gadget/file_storage.c in the Sony sources (SC_SONY_EXTENDED).
|
Yes, I see that the SC_SONY_EXTENDED triggers functions do_extended_h2d() and do_extended_d2h() in "usbtg_ebook5.c". The extended command reads and writes to a buffer held in the filesystem gadget, "the_fsg". From what I see, the current scsi logical unit (lun/curlun) is only used to report failures, so that the command is really device independent. eg: sending SONY_EXTENDED (0x20) as a SCSI command to any of the Sony reader scsi devices (sdb-sde) on my system, would have the same effect (AFAICT).
The actual extended command appears to be associated with a 4K static buffer (usbtg_ebook5_gfile.h); and there seems to be both proc and device driver interfaces to that buffer; so I presume this is not writing to the root filesystem, but rather this communication buffer is opened by another process as if it were a file.
eg: /proc/usbtg/foo_bar
/dev/usbtg ... or at least ...device w/ major 126, minor 0
Since this is a character device on the Sony, but the SCSI is a block device ... I am not quite sure how to operate the interface; I'll see if I can code a SONY_EXTENDED command to read a 4K block and see what happens....
Side note:
I don't see anything helpful (so far) in calibre with regard to this interface, did I miss something?
..But I did happen to notice earlier in the thread that someone was mentioning peculiarities/problems with subcpu and the USB charging interface for the Sony.
In the source code for the ioctl()'s for usbtg there is the standard "powernego" file operation, but (surprise) also a "usbcharge" file operation. Also in the IOCTL there are USBTG_PD_SET_USBCHARGE and USBTG_GET_USBCHARGE, so perhaps that will help someone find the charging switch they were looking for?
usbtg_ebook5.c: case USBTG_PD_SET_USBCHARGE:
usbtg_ebook5.h:#define USBTG_PD_SET_USBCHARGE _IOW('u', 0x06, unsigned int)