fix USB_STORAGE_CYPRESS_ATACB
Subsystems (3)
PATCH 1/1 fix USB_STORAGE_CYPRESS_ATACB
Hi,
64a87b244b9297667ca80264aab849a36f494884 broke USB_STORAGE_CYPRESS_ATACB translation.
Could it be applied to kernel-stable ?
Matthieu
64a87b244b9297667ca80264aab849a36f494884 commit change the scsi_eh_prep_cmnd logic by making it clear the ->cmnd buffer.
But the sat to cypress atacb translation supposed the ->cmnd buffer wasn't modified.
This patch makes it set the ->cmnd buffer after scsi_eh_prep_cmnd call.
drivers/usb/storage/cypress_atacb.c +2 -0
@@ -143,6 +143,8 @@ void cypress_atacb_passthrough(struct scsi_cmnd *srb, struct us_data *us)* the read taskfile bit, for not executing atacb command, * but reading register selected in srb->cmnd[4] */ + srb->cmd_len =16 ; +memcpy (srb->cmnd, ses.cmnd, srb->cmd_len); srb->cmnd[2 ] =1 ;usb_stor_transparent_scsi_command (srb, us);
Boaz, what's your take on this? It "feels" to me like this should be fixed another way, rather than mucking directly with the srb structures.
Matt
Quoted 8 lines · matthieu castet
Hi,
64a87b244b9297667ca80264aab849a36f494884brokeUSB_STORAGE_CYPRESS_ATACBtranslation.Could it be applied to kernel-stable ?
Matthieu
Signature · 6 lines
Matthew Dharm Home: [email protected] Maintainer, Linux USB Mass Storage Driver I think the problem is there's a nut loose on your keyboard. -- Greg to Customer User Friendly, 1/5/1999
Quoted 17 lines · Matthew Dharm
Boaz, what's your take on this? It "feels" to me like this should be fixed another way, rather than mucking directly with the srb structures.
Matt
Quoted 8 lines · matthieu castet
Hi,
64a87b244b9297667ca80264aab849a36f494884brokeUSB_STORAGE_CYPRESS_ATACBtranslation.Could it be applied to kernel-stable ?
Matthieu
You are right there is an easier way.
Sorry to only respond now, we've been moving our office, and were offline. I'll send the proper fix first thing tomorrow ASAP
Thanks
Boaz
PATCH 1/1 fix USB_STORAGE_CYPRESS_ATACB
Hi Matthieu, Matthew
I fixed lots of "mucking directly" with scsi_cmnd and scsi_eh_save internal members but the actual set of srb->cmnd{,_len} is needed still. Though we don't need the copy since we restore the original command right after. If anyone can test this to verify it could be grate.
Sorry for the mishap
Boaz
---
From: Boaz Harrosh <[email protected]>
Subject: [PATCH] fix USB_STORAGE_CYPRESS_ATACB
commit 64a87b24: [SCSI] Let scsi_cmnd->cmnd use request->cmd buffer changed the scsi_eh_prep_cmnd logic by making it clear the ->cmnd buffer. But the sat to cypress atacb translation supposed the ->cmnd buffer wasn't modified.
This patch makes it set the ->cmnd buffer after scsi_eh_prep_cmnd call. The problem and a fix was reported by Matthieu CASTET <[email protected]>
It also removes all the hackery fiddling of scsi_cmnd and scsi_eh_save by requesting from scsi_eh_prep_cmnd to prepare a read into ->sense_buffer, which is much more suitable a buffer for HW transfers, then after the command execution the regs read is copied into regs buffer before actual preparation of sense_buffer.
Also fix an alien comment character to my utf-8 editor.
--- drivers/usb/storage/cypress_atacb.c | 15 +++++++-------- 1 files changed, 7 insertions(+), 8 deletions(-)
drivers/usb/storage/cypress_atacb.c +7 -8
@@ -133,19 +133,18 @@ void cypress_atacb_passthrough(struct scsi_cmnd *srb, struct us_data *us)/* build the command for * reading the ATA registers */ -scsi_eh_prep_cmnd (srb, &ses,NULL ,0 ,0 ); - srb->sdb.length =sizeof (regs); -sg_init_one (&ses.sense_sgl, regs, srb->sdb.length); - srb->sdb.table.sgl = &ses.sense_sgl; - srb->sc_data_direction =DMA_FROM_DEVICE ; - srb->sdb.table.nents =1 ; +scsi_eh_prep_cmnd (srb, &ses,NULL ,0 ,sizeof (regs)); +/* we use the same command as before, but we set * the read taskfile bit, for not executing atacb command, * but reading register selected in srb->cmnd[4] */ + srb->cmd_len =16 ; + srb->cmnd = ses.cmnd; srb->cmnd[2 ] =1 ;usb_stor_transparent_scsi_command (srb, us); +memcpy (regs, srb->sense_buffer,sizeof (regs)); tmp_result = srb->result;scsi_eh_restore_cmnd (srb, &ses);/* we fail to get registers, report invalid command */
@@ -162,8 +161,8 @@ void cypress_atacb_passthrough(struct scsi_cmnd *srb, struct us_data *us)/* XXX we should generate sk, asc, ascq from status and error * regs -* (see 11.1 Error translation � ATA device error to SCSI error map) -* and ata_to_sense_error from libata. +* (see 11.1 Error translation ATA device error to SCSI error +* map, and ata_to_sense_error from libata.) */ /* Sense data is current and format is descriptor. */
Signature · 1 line
1.6.0.1
Hi,
Quoted 8 lines · Boaz Harrosh
Hi Matthieu, Matthew
I fixed lots of "mucking directly" with
scsi_cmndandscsi_eh_saveinternal members but the actual set of srb->cmnd{,_len} is needed still. Though we don't need the copy since we restore the original command right after. If anyone can test this to verify it could be grate.
your patch works for me.
Thanks and happy new year
Matthieu
Hi,
Quoted 11 lines · matthieu castet
Hi,
Quoted 8 lines · Boaz Harrosh
Hi Matthieu, Matthew
I fixed lots of "mucking directly" with
scsi_cmndandscsi_eh_saveinternal members but the actual set of srb->cmnd{,_len} is needed still. Though we don't need the copy since we restore the original command right after. If anyone can test this to verify it could be grate.
Quoted 4 lines
your patch works for me.
Thanks and happy new year
What's the status of that patch ?
I doesn't seem to be in stable nor master.
Matthieu
PATCH RESEND 1/1 fix USB_STORAGE_CYPRESS_ATACB
In reply to Boaz HarroshJames hi.
I'm resending a forgotten patch. See here:
http://lkml.indiana.edu/hypermail/linux/kernel/0812.3/01127.html
I'll need Matthew Dharm ACK or who ever maintains cypress_atacb
---
From: Boaz Harrosh <[email protected]>
Subject: [PATCH] fix USB_STORAGE_CYPRESS_ATACB
commit 64a87b24: [SCSI] Let scsi_cmnd->cmnd use request->cmd buffer changed the scsi_eh_prep_cmnd logic by making it clear the ->cmnd buffer. But the sat to cypress atacb translation supposed the ->cmnd buffer wasn't modified.
This patch makes it set the ->cmnd buffer after scsi_eh_prep_cmnd call. The problem and a fix was reported by Matthieu CASTET <[email protected]>
It also removes all the hackery fiddling of scsi_cmnd and scsi_eh_save by requesting from scsi_eh_prep_cmnd to prepare a read into ->sense_buffer, which is much more suitable a buffer for HW transfers, then after the command execution the regs read is copied into regs buffer before actual preparation of sense_buffer.
Also fix an alien comment character to my utf-8 editor.
--- drivers/usb/storage/cypress_atacb.c | 15 +++++++-------- 1 files changed, 7 insertions(+), 8 deletions(-)
drivers/usb/storage/cypress_atacb.c +7 -8
@@ -133,19 +133,18 @@ void cypress_atacb_passthrough(struct scsi_cmnd *srb, struct us_data *us)/* build the command for * reading the ATA registers */ -scsi_eh_prep_cmnd (srb, &ses,NULL ,0 ,0 ); - srb->sdb.length =sizeof (regs); -sg_init_one (&ses.sense_sgl, regs, srb->sdb.length); - srb->sdb.table.sgl = &ses.sense_sgl; - srb->sc_data_direction =DMA_FROM_DEVICE ; - srb->sdb.table.nents =1 ; +scsi_eh_prep_cmnd (srb, &ses,NULL ,0 ,sizeof (regs)); +/* we use the same command as before, but we set * the read taskfile bit, for not executing atacb command, * but reading register selected in srb->cmnd[4] */ + srb->cmd_len =16 ; + srb->cmnd = ses.cmnd; srb->cmnd[2 ] =1 ;usb_stor_transparent_scsi_command (srb, us); +memcpy (regs, srb->sense_buffer,sizeof (regs)); tmp_result = srb->result;scsi_eh_restore_cmnd (srb, &ses);/* we fail to get registers, report invalid command */
@@ -162,8 +161,8 @@ void cypress_atacb_passthrough(struct scsi_cmnd *srb, struct us_data *us)/* XXX we should generate sk, asc, ascq from status and error * regs -* (see 11.1 Error translation � ATA device error to SCSI error map) -* and ata_to_sense_error from libata. +* (see 11.1 Error translation ATA device error to SCSI error +* map, and ata_to_sense_error from libata.) */ /* Sense data is current and format is descriptor. */
Signature · 6 lines
1.6.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html