Lets get back to the original request/question then. What is the proper
approach to handle such command variation?
When scanning the drive, you need to poke it using scsi_report_opcode() to
determine which write operation is supported. Then sd.c need to be modified to
generate the proper write command if the regular WRITE 10/16/32 are not
supported. You will also need to make sure that this does not break ATA drives
managed with libata, so check libata-scsi translation.
Not saying this can all be accepted though. But that is what is needed.
Thanks Damien.
I went to check the opcode support and it says that Write is supported.
The actual Write execution then fails with "Aborted Command".
It is not making my life easier and the correct way is not going to work.
Then I had a very long and unhelpful discussion on Seagate support chat where
they failed to recognize this combination as a potential bug and a broken
firmware.
I just can not understand they wont accept a bug-report on a custom firmware,
having done all the discoveries for them. Looks like they did not put much of
effort into this and the firmware is a quick hack to get the job done for OEM.
Given the current state of things and thanks to Martin's opinion to not bring
this mess and edge case code into mainline as of now, I will consider getting
these drives to work as a private challenge. If somebody else runs into this,
they will find at least this thread, where the code may appear after I find it
stable enough.
Daniel
