perfect business
Hi A multinational corporation is searching for people in the United States to become our representative in the region . Income is $7 /year. No fees, no marketing tricks Interested? Visit our page, to find out more http://hinterfacvqk.prophp.org Have a nice day. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Marvell 6440 SAS/SATA driver
mvsas : Fixed coding problem
Signed-off-by: Ke Wei [EMAIL PROTECTED]
---
drivers/scsi/mvsas.c | 61 +++--
1 files changed, 34 insertions(+), 27 deletions(-)
diff --git a/drivers/scsi/mvsas.c b/drivers/scsi/mvsas.c
index 321be21..3bf009b 100755
--- a/drivers/scsi/mvsas.c
+++ b/drivers/scsi/mvsas.c
@@ -55,11 +55,11 @@
/* offset for D2H FIS in the Received FIS List Structure */
#define SATA_RECEIVED_D2H_FIS(reg_set) \
- (mvi-rx_fis + 0x400 + 0x100 * reg_set + 0x40)
+ ((void *) mvi-rx_fis + 0x400 + 0x100 * reg_set + 0x40)
#define SATA_RECEIVED_PIO_FIS(reg_set) \
- (mvi-rx_fis + 0x400 + 0x100 * reg_set + 0x20)
+ ((void *) mvi-rx_fis + 0x400 + 0x100 * reg_set + 0x20)
#define UNASSOC_D2H_FIS(id) \
- (mvi-rx_fis + 0x100 * id)
+ ((void *) mvi-rx_fis + 0x100 * id)
/* driver compile-time configuration */
enum driver_configuration {
@@ -553,17 +553,16 @@ struct mvs_phy {
struct mvs_port *port;
struct asd_sas_phy sas_phy;
struct sas_identify identify;
- __le32 dev_info;
- __le64 dev_sas_addr;
- __le32 att_dev_info;
- __le64 att_dev_sas_addr;
+ u64 dev_sas_addr;
+ u64 att_dev_sas_addr;
+ u32 att_dev_info;
+ u32 dev_info;
u32 type;
- __le32 phy_status;
- __le32 irq_status;
- u8 wide_port_phymap;
+ u32 phy_status;
+ u32 irq_status;
u32 frame_rcvd_size;
u8 frame_rcvd[32];
-
+ u8 wide_port_phymap;
};
struct mvs_info {
@@ -586,7 +585,7 @@ struct mvs_info {
dma_addr_t rx_dma;
u32 rx_cons;/* RX consumer idx */
- void*rx_fis;/* RX'd FIS area */
+ __le32 *rx_fis;/* RX'd FIS area */
dma_addr_t rx_fis_dma;
struct mvs_cmd_hdr *slot; /* DMA command header slots */
@@ -624,7 +623,6 @@ static void mvs_write_port_vsr_data(struct mvs_info *mvi,
u32 port, u32 val);
static void mvs_write_port_vsr_addr(struct mvs_info *mvi, u32 port, u32 addr);
static u32 mvs_read_port_irq_stat(struct mvs_info *mvi, u32 port);
static void mvs_write_port_irq_stat(struct mvs_info *mvi, u32 port, u32 val);
-static u32 mvs_read_port_irq_mask(struct mvs_info *mvi, u32 port);
static void mvs_write_port_irq_mask(struct mvs_info *mvi, u32 port, u32 val);
static int mvs_scan_finished(struct Scsi_Host *, unsigned long);
@@ -705,8 +703,7 @@ static void mvs_hba_sb_dump(struct mvs_info *mvi, u32 tag,
else
len_ct = MVS_SSP_CMD_SZ;
- offset =
- len_ct + MVS_OAF_SZ +
+ offset = len_ct + MVS_OAF_SZ +
sizeof(struct mvs_prd) * mvi-slot_info[tag].n_elem;
dev_printk(KERN_DEBUG, pdev-dev, +Status buffer :\n);
mvs_hexdump(32, (u8 *) mvi-slot_info[tag].response,
@@ -792,21 +789,27 @@ static void mvs_hba_cq_dump(struct mvs_info *mvi)
#endif
}
-static void mvs_hba_interrupt_enable(struct mvs_info *mvi, int enable)
+#if 0
+static void mvs_hba_interrupt_enable(struct mvs_info *mvi)
{
void __iomem *regs = mvi-regs;
u32 tmp;
- unsigned long flags;
- spin_lock_irqsave(mvi-lock, flags);
tmp = mr32(GBL_CTL);
- if (enable)
- mw32(GBL_CTL, tmp | INT_EN);
- else
- mw32(GBL_CTL, tmp ~INT_EN);
- spin_unlock_irqrestore(mvi-lock, flags);
+ mw32(GBL_CTL, tmp | INT_EN);
+}
+
+static void mvs_hba_interrupt_disable(struct mvs_info *mvi)
+{
+ void __iomem *regs = mvi-regs;
+ u32 tmp;
+
+ tmp = mr32(GBL_CTL);
+
+ mw32(GBL_CTL, tmp ~INT_EN);
}
+#endif
static int mvs_int_rx(struct mvs_info *mvi, bool self_clear);
@@ -1345,6 +1348,7 @@ err_out:
return rc;
}
+#if 0
static void mvs_free_reg_set(struct mvs_info *mvi, struct mvs_port *port)
{
void __iomem *regs = mvi-regs;
@@ -1364,6 +1368,7 @@ static void mvs_free_reg_set(struct mvs_info *mvi, struct
mvs_port *port)
port-taskfileset = MVS_ID_NOT_MAPPED;
}
+#endif
static u8 mvs_assign_reg_set(struct mvs_info *mvi, struct mvs_port *port)
{
@@ -2122,10 +2127,12 @@ static void mvs_write_port_irq_stat(struct mvs_info
*mvi, u32 port, u32 val)
mvs_write_port(mvi, MVS_P0_INT_STAT, MVS_P4_INT_STAT, port, val);
}
+#if 0
static u32 mvs_read_port_irq_mask(struct mvs_info *mvi, u32 port)
{
return mvs_read_port(mvi, MVS_P0_INT_MASK, MVS_P4_INT_MASK, port);
}
+#endif
static void mvs_write_port_irq_mask(struct mvs_info *mvi, u32 port, u32 val)
{
@@ -2258,17 +2265,17 @@ static void __devinit mvs_update_phyinfo(struct
mvs_info *mvi, int i)
{
struct mvs_phy *phy = mvi-phy[i];
u32 tmp;
- __le64
Re: [PATCH] Marvell 6440 SAS/SATA driver
On Sun, 2008-01-27 at 23:27 +0800, Ke Wei wrote: I really don't think you should be doing this. That single ring governs all the potential tag slots for everything in this device. If you do a simple head tail allocation, what can happen is that you get a slow tag (attached to a format command, or a tape command) and then the ring head will hit the slow tag and the entire device will halt. I think you need a bitmap based allocation algorithm to ensure that if you have a free tag anywhere, you'll use it. If you look at the aic94xx index functions in aic94xx_hwi.h you'll see asd_tc_index_get() and asd_tc_index_release() doing exactly what you want with the native linux bitmap functions (the aic also uses a single issue queue with indexes into it). I don't think we need to make use of a bitmap based allocation algorithm. My algorithm is a simple non-blocking scheduling. Some faster tag may be free in advance, so ring will alloc a tag number which has been stored in mvi-tags array instead of waiting to hit the slow tag. Ah, sorry I didn't see you were actually shuffling entries in the tag array ... I think that the bitmap based allocation algorithm try to poll and find the first zero bit. So process may be slow. pls point out anything wrong. I think you'll find a bitmap based algorithm can be much faster. The linux bitmap routines are optimally coded on most architectures (large numbers actually have a find bit in word/long word instruction). Even for a nearly full bitmap, a 512bit array can find the free tag in at most sixteen machine instructions; if the array is sparse, it can do it in about two. Plus a bitmap based scheme has the advantage of tending to allocate hot tags, thus usually keeping reasonable hot cache reuse. A ring based algorithm will effectively do levelling to ensure that every tag is used just about equally, which actually promotes pessimal hot cache reuse. Whether cache locality actually matters to the driver is something I can't actually determine, so I'll leave it up to you to decide. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.24-git3] firewire: fw-sbp2: relax SCSI DMA alignment
Signed-off-by: Stefan Richter [EMAIL PROTECTED] --- Not run-time tested yet. drivers/firewire/fw-sbp2.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) Index: linux-2.6.24-git3/drivers/firewire/fw-sbp2.c === --- linux-2.6.24-git3.orig/drivers/firewire/fw-sbp2.c +++ linux-2.6.24-git3/drivers/firewire/fw-sbp2.c @@ -1309,11 +1309,8 @@ static int sbp2_scsi_slave_alloc(struct sdev-allow_restart = 1; - /* -* Update the dma alignment (minimum alignment requirements for -* start and end of DMA transfers) to be a sector -*/ - blk_queue_update_dma_alignment(sdev-request_queue, 511); + /* SBP-2 requires quadlet alignment of the data buffers. */ + blk_queue_update_dma_alignment(sdev-request_queue, 4 - 1); if (lu-tgt-workarounds SBP2_WORKAROUND_INQUIRY_36) sdev-inquiry_len = 36; -- Stefan Richter -=-==--- ---= ==-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.24-git3] ieee1394: sbp2: relax SCSI DMA alignment
Signed-off-by: Stefan Richter [EMAIL PROTECTED] --- Not run-time tested yet. drivers/ieee1394/sbp2.c |7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) Index: linux-2.6.24-git3/drivers/ieee1394/sbp2.c === --- linux-2.6.24-git3.orig/drivers/ieee1394/sbp2.c +++ linux-2.6.24-git3/drivers/ieee1394/sbp2.c @@ -1966,11 +1966,8 @@ static int sbp2scsi_slave_alloc(struct s lu-sdev = sdev; sdev-allow_restart = 1; - /* -* Update the dma alignment (minimum alignment requirements for -* start and end of DMA transfers) to be a sector -*/ - blk_queue_update_dma_alignment(sdev-request_queue, 511); + /* SBP-2 requires quadlet alignment of the data buffers. */ + blk_queue_update_dma_alignment(sdev-request_queue, 4 - 1); if (lu-workarounds SBP2_WORKAROUND_INQUIRY_36) sdev-inquiry_len = 36; -- Stefan Richter -=-==--- ---= ==-== http://arcgraph.de/sr/ - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] zfcp: fix sense_buffer access bug
On Sun, Jan 27, 2008 at 12:41:50PM +0900, FUJITA Tomonori wrote: The commit de25deb18016f66dcdede165d07654559bb332bc changed scsi_cmnd.sense_buffer from a static array to a dynamically allocated buffer. We can't access to sense_buffer in 'cmd-sense_buffer' way. Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED] --- drivers/s390/scsi/zfcp_fsf.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/s390/scsi/zfcp_fsf.c b/drivers/s390/scsi/zfcp_fsf.c index fe57941..a9a147d 100644 --- a/drivers/s390/scsi/zfcp_fsf.c +++ b/drivers/s390/scsi/zfcp_fsf.c @@ -4224,10 +4224,10 @@ zfcp_fsf_send_fcp_command_task_handler(struct zfcp_fsf_req *fsf_req) ZFCP_LOG_TRACE(%i bytes sense data provided by FCP\n, fcp_rsp_iu-fcp_sns_len); - memcpy(scpnt-sense_buffer, + memcpy(scpnt-sense_buffer, zfcp_get_fcp_sns_info_ptr(fcp_rsp_iu), sns_len); ZFCP_HEX_DUMP(ZFCP_LOG_LEVEL_TRACE, - (void *) scpnt-sense_buffer, sns_len); + (void *)scpnt-sense_buffer, sns_len); } /* check for overrun */ ACK for fixing the access to the sense buffer. We are working internally on cleaning up the zfcp messages. With this change, the 'trace' and 'hex dump' messages will disappear. So, could you simply remove the ZFCP_HEX_DUMP message above, instead of fixing it? Christof - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
