Hello.
Phil Sutter wrote:
* rename the offset definition to avoid abiguity with the standard ATA
IO address
* read and write four bytes at once
* use writesl() and readsl() which implicitly iterate over the data
* fix the signature of rb532_pata_data_xfer() to match the function
pointer definition and return the number of bytes consumed
Signed-off-by: Phil Sutter <n0-1@xxxxxxxxxxx>
Acked-by: Sergei Shtyltov <sshtylyov@xxxxxxxxxxxxx>
---
drivers/ata/pata_rb532_cf.c | 21 ++++++++++-----------
1 files changed, 10 insertions(+), 11 deletions(-)
None of this description says _why_ you wish to do this. Also, maybe I
missed the response, what about ATAPI?
Well, Sergei Shtylyov pointed out that the original driver does transfer
data at 4-byte blocks, so I changed it accordingly and tested it.
Hopefully this will provide a performance gain, though I did not do any
performance tests and therefore can't tell if that's really the case.
Might've been worth to put this into separate patch, apart from the
fix for the function prototype.
I had interpreted Sergei's response to my BUG_ON() statement for it to
be unnecessary, which may be wrong.
You misintepreted my response. :-)
I don't know if it's possible to
connect ATAPI devices to the on board CompactFlash slot, maybe you can
I don't think so.
give me some hints on this. OTOH I see that the sector size is hard
coded in the original driver to 0x200, so I guess either ATAPI is not
possible or at least not with the original driver, right?
If ATAPI was indeed possible, BUG() wouldn't have been an option.
I've just remembered about the READ/WRITE LONG commands which might
cause byte count to not be divisible by 4 (although by default ECC is
4-byte entity and CF 1.4 says that this is the ony option).
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
