[PATCH 03/33] block: convert to using sg helpers
Convert the main rq mapper (blk_rq_map_sg()) to the sg helper setup.
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
---
block/ll_rw_blk.c | 19 ---
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index ef42bb2..ab71087 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -30,6 +30,7 @@
#include linux/cpu.h
#include linux/blktrace_api.h
#include linux/fault-inject.h
+#include linux/scatterlist.h
/*
* for max sense size
@@ -1307,9 +1308,11 @@ static int blk_hw_contig_segment(request_queue_t *q,
struct bio *bio,
* map a request to scatterlist, return number of sg entries setup. Caller
* must make sure sg can hold rq-nr_phys_segments entries
*/
-int blk_rq_map_sg(request_queue_t *q, struct request *rq, struct scatterlist
*sg)
+int blk_rq_map_sg(request_queue_t *q, struct request *rq,
+ struct scatterlist *sglist)
{
struct bio_vec *bvec, *bvprv;
+ struct scatterlist *next_sg, *sg;
struct bio *bio;
int nsegs, i, cluster;
@@ -1320,6 +1323,7 @@ int blk_rq_map_sg(request_queue_t *q, struct request *rq,
struct scatterlist *sg
* for each bio in rq
*/
bvprv = NULL;
+ sg = next_sg = sglist[0];
rq_for_each_bio(bio, rq) {
/*
* for each segment in bio
@@ -1328,7 +1332,7 @@ int blk_rq_map_sg(request_queue_t *q, struct request *rq,
struct scatterlist *sg
int nbytes = bvec-bv_len;
if (bvprv cluster) {
- if (sg[nsegs - 1].length + nbytes
q-max_segment_size)
+ if (sg-length + nbytes q-max_segment_size)
goto new_segment;
if (!BIOVEC_PHYS_MERGEABLE(bvprv, bvec))
@@ -1336,14 +1340,15 @@ int blk_rq_map_sg(request_queue_t *q, struct request
*rq, struct scatterlist *sg
if (!BIOVEC_SEG_BOUNDARY(q, bvprv, bvec))
goto new_segment;
- sg[nsegs - 1].length += nbytes;
+ sg-length += nbytes;
} else {
new_segment:
- memset(sg[nsegs],0,sizeof(struct scatterlist));
- sg[nsegs].page = bvec-bv_page;
- sg[nsegs].length = nbytes;
- sg[nsegs].offset = bvec-bv_offset;
+ sg = next_sg;
+ next_sg = sg_next(sg);
+ sg-page = bvec-bv_page;
+ sg-length = nbytes;
+ sg-offset = bvec-bv_offset;
nsegs++;
}
bvprv = bvec;
--
1.5.3.rc0.90.gbaa79
-
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 26/33] aha1542: convert to use the data buffer accessors
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
---
drivers/scsi/aha1542.c | 32 +++-
1 files changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/scsi/aha1542.c b/drivers/scsi/aha1542.c
index cbbfbc9..961a188 100644
--- a/drivers/scsi/aha1542.c
+++ b/drivers/scsi/aha1542.c
@@ -61,15 +61,15 @@ static void BAD_DMA(void *address, unsigned int length)
}
static void BAD_SG_DMA(Scsi_Cmnd * SCpnt,
- struct scatterlist *sgpnt,
+ struct scatterlist *sgp,
int nseg,
int badseg)
{
printk(KERN_CRIT sgpnt[%d:%d] page %p/0x%llx length %u\n,
badseg, nseg,
- page_address(sgpnt[badseg].page) + sgpnt[badseg].offset,
- (unsigned long long)SCSI_SG_PA(sgpnt[badseg]),
- sgpnt[badseg].length);
+ page_address(sgp-page) + sgp-offset,
+ (unsigned long long)SCSI_SG_PA(sgp),
+ sgp-length);
/*
* Not safe to continue.
@@ -691,7 +691,7 @@ static int aha1542_queuecommand(Scsi_Cmnd * SCpnt, void
(*done) (Scsi_Cmnd *))
memcpy(ccb[mbo].cdb, cmd, ccb[mbo].cdblen);
if (SCpnt-use_sg) {
- struct scatterlist *sgpnt;
+ struct scatterlist *sg;
struct chain *cptr;
#ifdef DEBUG
unsigned char *ptr;
@@ -699,23 +699,21 @@ static int aha1542_queuecommand(Scsi_Cmnd * SCpnt, void
(*done) (Scsi_Cmnd *))
int i;
ccb[mbo].op = 2;/* SCSI Initiator Command
w/scatter-gather */
SCpnt-host_scribble = kmalloc(512, GFP_KERNEL | GFP_DMA);
- sgpnt = (struct scatterlist *) SCpnt-request_buffer;
cptr = (struct chain *) SCpnt-host_scribble;
if (cptr == NULL) {
/* free the claimed mailbox slot */
HOSTDATA(SCpnt-device-host)-SCint[mbo] = NULL;
return SCSI_MLQUEUE_HOST_BUSY;
}
- for (i = 0; i SCpnt-use_sg; i++) {
- if (sgpnt[i].length == 0 || SCpnt-use_sg 16 ||
- (((int) sgpnt[i].offset) 1) || (sgpnt[i].length
1)) {
+ scsi_for_each_sg(SCpnt, sg, SCpnt-use_sg, i) {
+ if (sg-length == 0 || SCpnt-use_sg 16 ||
+ (((int) sg-offset) 1) || (sg-length 1)) {
unsigned char *ptr;
printk(KERN_CRIT Bad segment list supplied to
aha1542.c (%d, %d)\n, SCpnt-use_sg, i);
- for (i = 0; i SCpnt-use_sg; i++) {
+ scsi_for_each_sg(SCpnt, sg, SCpnt-use_sg, i) {
printk(KERN_CRIT %d: %p %d\n, i,
- (page_address(sgpnt[i].page) +
- sgpnt[i].offset),
- sgpnt[i].length);
+ (page_address(sg-page) +
+ sg-offset), sg-length);
};
printk(KERN_CRIT cptr %x: , (unsigned int)
cptr);
ptr = (unsigned char *) cptr[i];
@@ -723,10 +721,10 @@ static int aha1542_queuecommand(Scsi_Cmnd * SCpnt, void
(*done) (Scsi_Cmnd *))
printk(%02x , ptr[i]);
panic(Fod fight!);
};
- any2scsi(cptr[i].dataptr, SCSI_SG_PA(sgpnt[i]));
- if (SCSI_SG_PA(sgpnt[i]) + sgpnt[i].length - 1
ISA_DMA_THRESHOLD)
- BAD_SG_DMA(SCpnt, sgpnt, SCpnt-use_sg, i);
- any2scsi(cptr[i].datalen, sgpnt[i].length);
+ any2scsi(cptr[i].dataptr, SCSI_SG_PA(sg));
+ if (SCSI_SG_PA(sg) + sg-length - 1 ISA_DMA_THRESHOLD)
+ BAD_SG_DMA(SCpnt, sg, SCpnt-use_sg, i);
+ any2scsi(cptr[i].datalen, sg-length);
};
any2scsi(ccb[mbo].datalen, SCpnt-use_sg * sizeof(struct
chain));
any2scsi(ccb[mbo].dataptr, SCSI_BUF_PA(cptr));
--
1.5.3.rc0.90.gbaa79
-
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 21/33] qla1280: sg chaining support
Interesting hardware setup...
Cc: [EMAIL PROTECTED]
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
---
drivers/scsi/qla1280.c | 66 +++-
1 files changed, 37 insertions(+), 29 deletions(-)
diff --git a/drivers/scsi/qla1280.c b/drivers/scsi/qla1280.c
index 54d8bdf..bd805ec 100644
--- a/drivers/scsi/qla1280.c
+++ b/drivers/scsi/qla1280.c
@@ -2775,7 +2775,7 @@ qla1280_64bit_start_scsi(struct scsi_qla_host *ha, struct
srb * sp)
struct device_reg __iomem *reg = ha-iobase;
struct scsi_cmnd *cmd = sp-cmd;
cmd_a64_entry_t *pkt;
- struct scatterlist *sg = NULL;
+ struct scatterlist *sg = NULL, *s;
__le32 *dword_ptr;
dma_addr_t dma_handle;
int status = 0;
@@ -2889,13 +2889,16 @@ qla1280_64bit_start_scsi(struct scsi_qla_host *ha,
struct srb * sp)
* Load data segments.
*/
if (seg_cnt) { /* If data transfer. */
+ int remseg = seg_cnt;
/* Setup packet address segment pointer. */
dword_ptr = (u32 *)pkt-dseg_0_address;
if (cmd-use_sg) { /* If scatter gather */
/* Load command entry data segments. */
- for (cnt = 0; cnt 2 seg_cnt; cnt++, seg_cnt--) {
- dma_handle = sg_dma_address(sg);
+ for_each_sg(sg, s, seg_cnt, cnt) {
+ if (cnt == 2)
+ break;
+ dma_handle = sg_dma_address(s);
#if defined(CONFIG_IA64_GENERIC) || defined(CONFIG_IA64_SGI_SN2)
if (ha-flags.use_pci_vchannel)
sn_pci_set_vchan(ha-pdev,
@@ -2906,12 +2909,12 @@ qla1280_64bit_start_scsi(struct scsi_qla_host *ha,
struct srb * sp)
cpu_to_le32(pci_dma_lo32(dma_handle));
*dword_ptr++ =
cpu_to_le32(pci_dma_hi32(dma_handle));
- *dword_ptr++ = cpu_to_le32(sg_dma_len(sg));
- sg++;
+ *dword_ptr++ = cpu_to_le32(sg_dma_len(s));
dprintk(3, S/G Segment phys_addr=%x %x,
len=0x%x\n,
cpu_to_le32(pci_dma_hi32(dma_handle)),
cpu_to_le32(pci_dma_lo32(dma_handle)),
- cpu_to_le32(sg_dma_len(sg)));
+ cpu_to_le32(sg_dma_len(sg_next(s;
+ remseg--;
}
dprintk(5, qla1280_64bit_start_scsi: Scatter/gather
command packet data - b %i, t %i, l %i \n,
@@ -2926,7 +2929,9 @@ qla1280_64bit_start_scsi(struct scsi_qla_host *ha, struct
srb * sp)
dprintk(3, S/G Building Continuation...seg_cnt=0x%x
remains\n, seg_cnt);
- while (seg_cnt 0) {
+ while (remseg 0) {
+ /* Update sg start */
+ sg = s;
/* Adjust ring index. */
ha-req_ring_index++;
if (ha-req_ring_index == REQUEST_ENTRY_CNT) {
@@ -2952,9 +2957,10 @@ qla1280_64bit_start_scsi(struct scsi_qla_host *ha,
struct srb * sp)
(u32 *)((struct cont_a64_entry *)
pkt)-dseg_0_address;
/* Load continuation entry data segments. */
- for (cnt = 0; cnt 5 seg_cnt;
-cnt++, seg_cnt--) {
- dma_handle = sg_dma_address(sg);
+ for_each_sg(sg, s, remseg, cnt) {
+ if (cnt == 5)
+ break;
+ dma_handle = sg_dma_address(s);
#if defined(CONFIG_IA64_GENERIC) || defined(CONFIG_IA64_SGI_SN2)
if (ha-flags.use_pci_vchannel)
sn_pci_set_vchan(ha-pdev,
@@ -2966,12 +2972,12 @@ qla1280_64bit_start_scsi(struct scsi_qla_host *ha,
struct srb * sp)
*dword_ptr++ =
cpu_to_le32(pci_dma_hi32(dma_handle));
*dword_ptr++ =
- cpu_to_le32(sg_dma_len(sg));
+ cpu_to_le32(sg_dma_len(s));
dprintk(3, S/G Segment Cont.
phys_addr=%x %x, len=0x%x\n,
Re: [PATCH 13/33] SPARC: sg chaining support
From: Jens Axboe [EMAIL PROTECTED] Date: Mon, 16 Jul 2007 11:47:27 +0200 This updates the sparc iommu/pci dma mappers to sg chaining. Cc: [EMAIL PROTECTED] Signed-off-by: Jens Axboe [EMAIL PROTECTED] Acked-by: David S. Miller [EMAIL PROTECTED] - 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 14/33] SPARC64: sg chaining support
From: Jens Axboe [EMAIL PROTECTED] Date: Mon, 16 Jul 2007 11:47:28 +0200 This updates the sparc64 iommu/pci dma mappers to sg chaining. Cc: [EMAIL PROTECTED] Signed-off-by: Jens Axboe [EMAIL PROTECTED] Acked-by: David S. Miller [EMAIL PROTECTED] - 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 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Fri, 13 Jul 2007, Geert Uytterhoeven wrote:
Ah, that explains it. flush_dcache_page() is used in some drivers.
I'll update my patches. Thanks for the comments!
Does this look OK?
- Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an
interrupt handler, from .request_fn (ps3disk), or from .queuecommand
(ps3rom))
- Add a call to flush_kernel_dcache_page() in routines that write to buffers
If this is OK, I'll fold it into my original patch series and will resend.
Thanks!
---
drivers/block/ps3disk.c |5 +++--
drivers/scsi/ps3rom.c |9 +
2 files changed, 8 insertions(+), 6 deletions(-)
--- a/drivers/block/ps3disk.c
+++ b/drivers/block/ps3disk.c
@@ -109,13 +109,14 @@ static void ps3disk_scatter_gather(struc
bio_sectors(bio), sector);
bio_for_each_segment(bvec, bio, j) {
size = bio_cur_sectors(bio)*KERNEL_SECTOR_SIZE;
- buf = __bio_kmap_atomic(bio, j, KM_USER0);
+ buf = __bio_kmap_atomic(bio, j, KM_IRQ0);
if (gather)
memcpy(dev-bounce_buf+offset, buf, size);
else
memcpy(buf, dev-bounce_buf+offset, size);
offset += size;
- __bio_kunmap_atomic(bio, KM_USER0);
+ flush_kernel_dcache_page(bio_iovec_idx(bio,
j)-bv_page);
+ __bio_kunmap_atomic(bio, KM_IRQ0);
}
sectors += bio_sectors(bio);
i++;
--- a/drivers/scsi/ps3rom.c
+++ b/drivers/scsi/ps3rom.c
@@ -112,7 +112,7 @@ static int fill_from_dev_buffer(struct s
active = 1;
for (k = 0, req_len = 0, act_len = 0; k cmd-use_sg; ++k, ++sgpnt) {
if (active) {
- kaddr = kmap_atomic(sgpnt-page, KM_USER0);
+ kaddr = kmap_atomic(sgpnt-page, KM_IRQ0);
if (!kaddr)
return -1;
len = sgpnt-length;
@@ -121,7 +121,8 @@ static int fill_from_dev_buffer(struct s
len = buflen - req_len;
}
memcpy(kaddr + sgpnt-offset, buf + req_len, len);
- kunmap_atomic(kaddr, KM_USER0);
+ flush_kernel_dcache_page(sgpnt-page);
+ kunmap_atomic(kaddr, KM_IRQ0);
act_len += len;
}
req_len += sgpnt-length;
@@ -149,7 +150,7 @@ static int fetch_to_dev_buffer(struct sc
sgpnt = cmd-request_buffer;
for (k = 0, req_len = 0, fin = 0; k cmd-use_sg; ++k, ++sgpnt) {
- kaddr = kmap_atomic(sgpnt-page, KM_USER0);
+ kaddr = kmap_atomic(sgpnt-page, KM_IRQ0);
if (!kaddr)
return -1;
len = sgpnt-length;
@@ -158,7 +159,7 @@ static int fetch_to_dev_buffer(struct sc
fin = 1;
}
memcpy(buf + req_len, kaddr + sgpnt-offset, len);
- kunmap_atomic(kaddr, KM_USER0);
+ kunmap_atomic(kaddr, KM_IRQ0);
if (fin)
return req_len + len;
req_len += sgpnt-length;
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone:+32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: [EMAIL PROTECTED]
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, 16 Jul 2007, Jens Axboe wrote: On Mon, Jul 16 2007, Geert Uytterhoeven wrote: On Fri, 13 Jul 2007, Geert Uytterhoeven wrote: Ah, that explains it. flush_dcache_page() is used in some drivers. I'll update my patches. Thanks for the comments! Does this look OK? - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an interrupt handler, from .request_fn (ps3disk), or from .queuecommand (ps3rom)) That looks good. - Add a call to flush_kernel_dcache_page() in routines that write to buffers Hmm, I would have thought a flush_dcache_page() would be more appropriate, the backing could be page cache pages. OK, I'll change it to flush_dcache_page(). With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, 16 Jul 2007, Geert Uytterhoeven wrote: On Mon, 16 Jul 2007, Jens Axboe wrote: On Mon, Jul 16 2007, Geert Uytterhoeven wrote: On Fri, 13 Jul 2007, Geert Uytterhoeven wrote: Ah, that explains it. flush_dcache_page() is used in some drivers. I'll update my patches. Thanks for the comments! Does this look OK? - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an interrupt handler, from .request_fn (ps3disk), or from .queuecommand (ps3rom)) That looks good. - Add a call to flush_kernel_dcache_page() in routines that write to buffers Hmm, I would have thought a flush_dcache_page() would be more appropriate, the backing could be page cache pages. OK, I'll change it to flush_dcache_page(). Upon closer look, while flush_kernel_dcache_page() is a no-op on ppc64, flush_dcache_page() isn't. So I'd prefer to not call it if not really needed. And according to James, flush_kernel_dcache_page() should be sufficient... So I'm getting puzzled again... With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: [PATCH 31/33] Fusion: sg chaining support
On Mon, Jul 16 2007, FUJITA Tomonori wrote:
From: Jens Axboe [EMAIL PROTECTED]
Subject: [PATCH 31/33] Fusion: sg chaining support
Date: Mon, 16 Jul 2007 11:47:45 +0200
Cc: [EMAIL PROTECTED]
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
---
drivers/message/fusion/mptscsih.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/message/fusion/mptscsih.c
b/drivers/message/fusion/mptscsih.c
index d356173..f087249 100644
--- a/drivers/message/fusion/mptscsih.c
+++ b/drivers/message/fusion/mptscsih.c
@@ -297,7 +297,7 @@ nextSGEset:
v2 = sg_dma_address(sg);
mptscsih_add_sge(psge, sgflags | thisxfer, v2);
- sg++; /* Get next SG element from the OS */
+ sg = sg_next(sg); /* Get next SG element from the OS */
psge += (sizeof(u32) + sizeof(dma_addr_t));
sgeOffset += (sizeof(u32) + sizeof(dma_addr_t));
sg_done++;
@@ -318,7 +318,7 @@ nextSGEset:
v2 = sg_dma_address(sg);
mptscsih_add_sge(psge, sgflags | thisxfer, v2);
/*
- sg++;
+ sg = sg_next(sg);
psge += (sizeof(u32) + sizeof(dma_addr_t));
*/
sgeOffset += (sizeof(u32) + sizeof(dma_addr_t));
--
We also need this change?
diff --git a/drivers/message/fusion/mptscsih.c
b/drivers/message/fusion/mptscsih.c
index f087249..a3e6170 100644
--- a/drivers/message/fusion/mptscsih.c
+++ b/drivers/message/fusion/mptscsih.c
@@ -289,7 +289,7 @@ nextSGEset:
for (ii=0; ii (numSgeThisFrame-1); ii++) {
thisxfer = sg_dma_len(sg);
if (thisxfer == 0) {
- sg ++; /* Get next SG element from the OS */
+ sg = sg_next(sg); /* Get next SG element from the OS */
sg_done++;
continue;
}
Indeed we do, thanks for spotting that. Applied.
--
Jens Axboe
-
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 29/33] infiniband: sg chaining support
On Mon, Jul 16 2007, FUJITA Tomonori wrote:
From: Jens Axboe [EMAIL PROTECTED]
Subject: [PATCH 29/33] infiniband: sg chaining support
Date: Mon, 16 Jul 2007 11:47:43 +0200
@@ -226,7 +228,8 @@ static int iser_sg_to_page_vec(struct iser_data_buf
*data,
struct iser_page_vec *page_vec,
struct ib_device *ibdev)
{
- struct scatterlist *sg = (struct scatterlist *)data-buf;
+ struct scatterlist *sgl = (struct scatterlist *)data-buf;
+ struct scatterlist *sg;
u64 first_addr, last_addr, page;
int end_aligned;
unsigned int cur_page = 0;
@@ -234,14 +237,14 @@ static int iser_sg_to_page_vec(struct iser_data_buf
*data,
int i;
/* compute the offset of first element */
- page_vec-offset = (u64) sg[0].offset ~MASK_4K;
+ page_vec-offset = (u64) sgl[0].offset ~MASK_4K;
- for (i = 0; i data-dma_nents; i++) {
- unsigned int dma_len = ib_sg_dma_len(ibdev, sg[i]);
+ for_each_sg(sgl, sg, data-dma_nents, i) {
+ unsigned int dma_len = ib_sg_dma_len(ibdev, sg);
total_sz += dma_len;
- first_addr = ib_sg_dma_address(ibdev, sg[i]);
+ first_addr = ib_sg_dma_address(ibdev, sg);
last_addr = first_addr + dma_len;
end_aligned = !(last_addr ~MASK_4K);
@@ -249,9 +252,9 @@ static int iser_sg_to_page_vec(struct iser_data_buf
*data,
/* continue to collect page fragments till aligned or SG ends */
while (!end_aligned (i + 1 data-dma_nents)) {
i++;
Do we need to replace i++ with sg = sg_next(sg) here?
We do, updating the patch. Thanks for your review!
--
Jens Axboe
-
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 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, Jul 16 2007, Geert Uytterhoeven wrote: On Mon, 16 Jul 2007, Geert Uytterhoeven wrote: On Mon, 16 Jul 2007, Jens Axboe wrote: On Mon, Jul 16 2007, Geert Uytterhoeven wrote: On Fri, 13 Jul 2007, Geert Uytterhoeven wrote: Ah, that explains it. flush_dcache_page() is used in some drivers. I'll update my patches. Thanks for the comments! Does this look OK? - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an interrupt handler, from .request_fn (ps3disk), or from .queuecommand (ps3rom)) That looks good. - Add a call to flush_kernel_dcache_page() in routines that write to buffers Hmm, I would have thought a flush_dcache_page() would be more appropriate, the backing could be page cache pages. OK, I'll change it to flush_dcache_page(). Upon closer look, while flush_kernel_dcache_page() is a no-op on ppc64, flush_dcache_page() isn't. So I'd prefer to not call it if not really needed. And according to James, flush_kernel_dcache_page() should be sufficient... So I'm getting puzzled again... I'll let James expand on why he thinks flush_kernel_dcache_page() should be sufficient. If the backing is always user memory from get_user_pages(), then the flush_kernel_dcache_page() looks sufficient. For the normal IO paths, it could be that or page cache pages too for instance. -- Jens Axboe - 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 00/33] SG table chaining support
John == John Stoffel [EMAIL PROTECTED] writes: John Will this help out tape drive performance at all? I looked John through the patches quickly, esp the AIC7xxx stuff since that's John what I use, but nothing jumped out at me... Yes. Most modern tape drives want a block size of 1MB or higher. With the old stack we'd be stuck at 512KB because the sg limitations caused us to come just short of 1MB... -- Martin K. Petersen Oracle Linux Engineering - 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 00/33] SG table chaining support
Jens A repost of this patchset, which adds support forchaining of sg Jens tables. This enables much larger IO commands, since we don't Jens have to allocate large consecutive pieces of memory to represent Jens the sgtable of a huge command. Right now Linux is limited to Jens somewhere between 128 and 256 segments, depending on the Jens architecture. This translates into at most 512k-1mb request Jens sizes. With this patchset, I've successfully pushed 10MiB Jens commands through the IO stack. Will this help out tape drive performance at all? I looked through the patches quickly, esp the AIC7xxx stuff since that's what I use, but nothing jumped out at me... John - 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 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, Jul 16 2007, James Bottomley wrote: On Mon, 2007-07-16 at 14:16 +0200, Jens Axboe wrote: On Mon, Jul 16 2007, Geert Uytterhoeven wrote: On Fri, 13 Jul 2007, Geert Uytterhoeven wrote: Ah, that explains it. flush_dcache_page() is used in some drivers. I'll update my patches. Thanks for the comments! Does this look OK? - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an interrupt handler, from .request_fn (ps3disk), or from .queuecommand (ps3rom)) That looks good. - Add a call to flush_kernel_dcache_page() in routines that write to buffers Hmm, I would have thought a flush_dcache_page() would be more appropriate, the backing could be page cache pages. No ... that was the point of flush_kernel_dcache_page(). The page in question is page cache backed and contains user mappings. However, the block layer has already done a flush_dcache_page() in get_user_pages() and the user shouldn't be touching memory under I/O (unless they want self induced aliasing problems) so we're free to assume all the user cachelines are purged, hence all we have to do is flush the kernel alias to bring the page up to date and make the users see it correctly. Oh indeed, I missed the flush_dcache_page() in get_user_pages(). -- Jens Axboe - 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 00/33] SG table chaining support
On Mon, Jul 16 2007, Martin K. Petersen wrote: John == John Stoffel [EMAIL PROTECTED] writes: John Will this help out tape drive performance at all? I looked John through the patches quickly, esp the AIC7xxx stuff since that's John what I use, but nothing jumped out at me... Yes. Most modern tape drives want a block size of 1MB or higher. With the old stack we'd be stuck at 512KB because the sg limitations caused us to come just short of 1MB... Indeed. John, note that the driver changes aren't related to enabling some hardware feature. Drivers just need to be converted to use the sg walker helpers instead of doing it manually, then they'll also gain larger IO support. The SCSI drivers are currently being transitioned to that seperately, my patchset just contains patches for remaining drivers (which include non-SCSI ones as well). The hardware has to support a big number of segments of course, looking at aic7xxx it seems to be limited at 128. From the comment that looks like it can be increased though, see AHD_NSEG in drivers/scsi/aic7xxx/aic79xx_osm.h: /* * Number of SG segments we require. So long as the S/G segments for * a particular transaction are allocated in a physically contiguous * manner and are allocated below 4GB, the number of S/G segments is * unrestricted. */ #define AHD_NSEG 128 -- Jens Axboe - 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 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, 16 Jul 2007, Jens Axboe wrote: On Mon, Jul 16 2007, James Bottomley wrote: On Mon, 2007-07-16 at 14:16 +0200, Jens Axboe wrote: On Mon, Jul 16 2007, Geert Uytterhoeven wrote: On Fri, 13 Jul 2007, Geert Uytterhoeven wrote: Ah, that explains it. flush_dcache_page() is used in some drivers. I'll update my patches. Thanks for the comments! Does this look OK? - Replaced KM_USER0 by KM_IRQ0 (all routines are either called from an interrupt handler, from .request_fn (ps3disk), or from .queuecommand (ps3rom)) That looks good. - Add a call to flush_kernel_dcache_page() in routines that write to buffers Hmm, I would have thought a flush_dcache_page() would be more appropriate, the backing could be page cache pages. No ... that was the point of flush_kernel_dcache_page(). The page in question is page cache backed and contains user mappings. However, the block layer has already done a flush_dcache_page() in get_user_pages() and the user shouldn't be touching memory under I/O (unless they want self induced aliasing problems) so we're free to assume all the user cachelines are purged, hence all we have to do is flush the kernel alias to bring the page up to date and make the users see it correctly. Oh indeed, I missed the flush_dcache_page() in get_user_pages(). Good, thanks for reaching a consensus, so I can update my patch series. With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
Re: [PATCH 00/33] SG table chaining support
On Mon, 16 Jul 2007, Martin K. Petersen wrote: John == John Stoffel [EMAIL PROTECTED] writes: John Will this help out tape drive performance at all? I looked John through the patches quickly, esp the AIC7xxx stuff since that's John what I use, but nothing jumped out at me... Yes. Most modern tape drives want a block size of 1MB or higher. With the old stack we'd be stuck at 512KB because the sg limitations caused us to come just short of 1MB... Tape block sizes up to 16 MB have been possible for a very long time but this has required tuning of the block/scsi parameters. Very few people seem to have done this and the common (mis)belief seems to be that the tape block size limit has been 512 kB. It is good if this tuning is not needed in future. -- Kai - 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 0/3] PS3 Storage Drivers for 2.6.23, take 5
Hi, These are the remaining patches of the new PS3 storage drivers series: [1] ps3: Disk Storage Driver [2] ps3: BD/DVD/CD-ROM Storage Driver [3] ps3: FLASH ROM Storage Driver They are based on: - the current Linux kernel source tree, - plus the PS3 patches already submitted by Geoff Levand on linuxppc-dev, which are in the for-2.6.23 branch of Paulus' tree, - plus the first 3 patches from the PS3 storage drivers series I submitted before, which are also in the for-2.6.23 branch of Paulus' tree. The only changes compared to the previous submission are the kmap updates, as requested by Jens Axboe and James E.J. Bottomley. I didn't hear anything from the misc device maintainer (for the FLASH ROM Storage Driver). Paulus, please apply. Thanks in advance! With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619 - 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 1/3] ps3: Disk Storage Driver
From: Geert Uytterhoeven [EMAIL PROTECTED]
Add a Disk Storage Driver for the PS3:
- Implemented as a block device driver with a dynamic major
- Disk names (and partitions) are of the format ps3d%c(%u)
- Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor
doesn't support scatter-gather
CC: Geoff Levand [EMAIL PROTECTED]
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
Acked-by: Jens Axboe [EMAIL PROTECTED]
---
v4:
- Replace KM_USER0 by KM_IRQ0 (all kmap routines are either called from an
interrupt handler or from .request_fn())
- Add a call to flush_kernel_dcache_page() before kunmap in routines that
write to buffers
v3:
- Cleanup #includes
- Kill PS3DISK_MAJOR, always use zero to obtain a dynamic major
- Group LV1 API related stuff
- Kill empty ps3disk_open
- Reset ps3disk_priv(dev) to NULL during cleanup
- Move call to put_disk() down
- Pass the interrupt handler to ps3stor_setup(), so it doesn't have to be
overridden later
- Fold ps3disk_read_write_sectors() into ps3disk_submit_request_sg()
- Identify the hard drive capacity and model name during probing
v2:
- Don't use `default y' in Kconfig
- Remove the thread for handling requests
- Set up sysfs links between block device and PS3 system device:
o /sys/block/ps3da/device - ../../devices/ps3_system/sb_02
o /sys/devices/ps3_system/sb_02/block:ps3da - ../../../block/ps3da
- Fix all FIXMEs
- Implement proper barrier support
- Call add_disk_randomness()
- Add a test to verify we are running on a PS3
- Fix error path in ps3disk_init()
- Fix cleanup order in ps3disk_exit()
arch/powerpc/platforms/ps3/Kconfig | 10
drivers/block/Makefile |1
drivers/block/ps3disk.c| 624 +
3 files changed, 635 insertions(+)
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -102,4 +102,14 @@ config PS3_STORAGE
depends on PPC_PS3
tristate
+config PS3_DISK
+ tristate PS3 Disk Storage Driver
+ depends on PPC_PS3 BLOCK
+ select PS3_STORAGE
+ help
+ Include support for the PS3 Disk Storage.
+
+ This support is required to access the PS3 hard disk.
+ In general, all users will say Y or M.
+
endmenu
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -28,3 +28,4 @@ obj-$(CONFIG_VIODASD) += viodasd.o
obj-$(CONFIG_BLK_DEV_SX8) += sx8.o
obj-$(CONFIG_BLK_DEV_UB) += ub.o
+obj-$(CONFIG_PS3_DISK) += ps3disk.o
--- /dev/null
+++ b/drivers/block/ps3disk.c
@@ -0,0 +1,624 @@
+/*
+ * PS3 Disk Storage Driver
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2007 Sony Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include linux/ata.h
+#include linux/blkdev.h
+
+#include asm/lv1call.h
+#include asm/ps3stor.h
+#include asm/firmware.h
+
+
+#define DEVICE_NAMEps3disk
+
+#define BOUNCE_SIZE(64*1024)
+
+#define PS3DISK_MAX_DISKS 16
+#define PS3DISK_MINORS 16
+
+#define KERNEL_SECTOR_SIZE 512
+
+
+#define PS3DISK_NAME ps3d%c
+
+
+struct ps3disk_private {
+ spinlock_t lock;/* Request queue spinlock */
+ struct request_queue *queue;
+ struct gendisk *gendisk;
+ unsigned int blocking_factor;
+ struct request *req;
+ u64 raw_capacity;
+ unsigned char model[ATA_ID_PROD_LEN+1];
+};
+#define ps3disk_priv(dev) ((dev)-sbd.core.driver_data)
+
+
+#define LV1_STORAGE_SEND_ATA_COMMAND (2)
+#define LV1_STORAGE_ATA_HDDOUT (0x23)
+
+struct lv1_ata_cmnd_block {
+ u16 features;
+ u16 sector_count;
+ u16 LBA_low;
+ u16 LBA_mid;
+ u16 LBA_high;
+ u8 device;
+ u8 command;
+ u32 is_ext;
+ u32 proto;
+ u32 in_out;
+ u32 size;
+ u64 buffer;
+ u32 arglen;
+};
+
+enum lv1_ata_proto {
+ NON_DATA_PROTO = 0,
+ PIO_DATA_IN_PROTO = 1,
+ PIO_DATA_OUT_PROTO = 2,
+ DMA_PROTO = 3
+};
+
+enum lv1_ata_in_out {
+ DIR_WRITE = 0, /* memory - device */
+ DIR_READ = 1/* device - memory */
+};
+
+static int ps3disk_major;
+
+
+static struct
[patch 2/3] ps3: BD/DVD/CD-ROM Storage Driver
From: Geert Uytterhoeven [EMAIL PROTECTED]
Add a BD/DVD/CD-ROM Storage Driver for the PS3:
- Implemented as a SCSI device driver
- Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor
doesn't support scatter-gather
CC: Geoff Levand [EMAIL PROTECTED]
Signed-off-by: Geert Uytterhoeven [EMAIL PROTECTED]
---
v4:
- Replace KM_USER0 by KM_IRQ0 (all kmap routines are either called from an
interrupt handler or from .queuecommand())
- Add a call to flush_kernel_dcache_page() before kunmap in routines that
write to buffers
v3:
- Replace dependency on BLK_DEV_SR by SCSI
- Use `BD/DVD/CD-ROM' instead of `ROM' in driver descriptions
- Inform the user to enable SCSI CDROM support
- Cleanup #includes
- Group LV1 API related stuff
- Rename ps3rom_private.cmd to ps3rom_private.curr_cmd
- Use shost_priv() (from scsi-misc)
- Set scsi_device.use_10_for_rw and remove support for {READ,WRITE}_6
- Explain why we prefer to use lv1_storage_{read,write}()
- Pass the interrupt handler to ps3stor_setup(), so it doesn't have to be
overridden later
- Reset ps3rom_priv(dev) to NULL during cleanup
v2:
- Don't use `default y' in Kconfig
- Add missing #include linux/highmem.h
- Remove ps3rom_private.scsi_done, use scsi_cmnd.scsi_done instead
- Use scsi_device.host.hostdata
- Remove empty ps3rom_slave_{alloc,destroy}()
- Kill superfluous test for command in progress
- Move scsi_host_put() last in cleanup sequence
- Remove scsi_command(), use scsi_print_command() for debugging
- scsi_cmnd.use_sg is always 0 these days
- Allocate struct ps3rom_private using scsi_host_alloc()
- Remove the thread for handling requests
- Remove unused position parameter enum
- Remove unused NA_PROTO and DIR_NA
- Derive buffer length, data direction, and transfer protocol from the
struct scsi_command, instead of using a big switch() statement
- Kill superfluous spinlock
- Remove manual request sense, as modern hypervisors always do auto sense
- Pass all SCSI commands to the hypervisor as ATAPI commands, except for
READ_*/WRITE_*
- Don't print errors for SCSI commands that are not allowed for an Other OS
by the hypervisor
- Remove superfluous tests for data directions in
{fill_from,fetch_to}_dev_buffer()
- Handle errors in {fill_from,fetch_to}_dev_buffer()
- Reorder routines
- Manually inline ps3rom_send_atapi_command()
- Fix all FIXMEs
arch/powerpc/platforms/ps3/Kconfig | 11
drivers/scsi/Makefile |1
drivers/scsi/ps3rom.c | 538 +
3 files changed, 550 insertions(+)
--- a/arch/powerpc/platforms/ps3/Kconfig
+++ b/arch/powerpc/platforms/ps3/Kconfig
@@ -112,4 +112,15 @@ config PS3_DISK
This support is required to access the PS3 hard disk.
In general, all users will say Y or M.
+config PS3_ROM
+ tristate PS3 BD/DVD/CD-ROM Storage Driver
+ depends on PPC_PS3 SCSI
+ select PS3_STORAGE
+ help
+ Include support for the PS3 ROM Storage.
+
+ This support is required to access the PS3 BD/DVD/CD-ROM drive.
+ In general, all users will say Y or M.
+ Also make sure to say Y or M to SCSI CDROM support later.
+
endmenu
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -132,6 +132,7 @@ obj-$(CONFIG_SCSI_IBMVSCSI) += ibmvscsi/
obj-$(CONFIG_SCSI_IBMVSCSIS) += ibmvscsi/
obj-$(CONFIG_SCSI_HPTIOP) += hptiop.o
obj-$(CONFIG_SCSI_STEX)+= stex.o
+obj-$(CONFIG_PS3_ROM) += ps3rom.o
obj-$(CONFIG_ARM) += arm/
--- /dev/null
+++ b/drivers/scsi/ps3rom.c
@@ -0,0 +1,538 @@
+/*
+ * PS3 BD/DVD/CD-ROM Storage Driver
+ *
+ * Copyright (C) 2007 Sony Computer Entertainment Inc.
+ * Copyright 2007 Sony Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include linux/cdrom.h
+#include linux/highmem.h
+
+#include scsi/scsi.h
+#include scsi/scsi_cmnd.h
+#include scsi/scsi_dbg.h
+#include scsi/scsi_device.h
+#include scsi/scsi_host.h
+
+#include asm/lv1call.h
+#include asm/ps3stor.h
+
+
+#define DEVICE_NAMEps3rom
+
+#define BOUNCE_SIZE(64*1024)
+
+#define PS3ROM_MAX_SECTORS (BOUNCE_SIZE / CD_FRAMESIZE)
+
+
+struct ps3rom_private {
+ struct ps3_storage_device *dev;
+
Re: [PATCH 00/33] SG table chaining support
On Mon, Jul 16 2007, Kai Makisara wrote: On Mon, 16 Jul 2007, Martin K. Petersen wrote: John == John Stoffel [EMAIL PROTECTED] writes: John Will this help out tape drive performance at all? I looked John through the patches quickly, esp the AIC7xxx stuff since that's John what I use, but nothing jumped out at me... Yes. Most modern tape drives want a block size of 1MB or higher. With the old stack we'd be stuck at 512KB because the sg limitations caused us to come just short of 1MB... Tape block sizes up to 16 MB have been possible for a very long time but this has required tuning of the block/scsi parameters. Very few people seem to have done this and the common (mis)belief seems to be that the tape block size limit has been 512 kB. It is good if this tuning is not needed in future. The main difference is now you get to do it without hacks and in a clean way, so it works through the normal IO path and not some on-the-side thing (or st only). -- Jens Axboe - 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] libsas, aic94xx: fix dma mapping cockups with ATA
This one was noticed by Gilbert Wu of Adaptec:
The libata core actually does the DMA mapping for you, so there has to
be an exception in the device drivers that *don't* do dma mapping for
ATA commands. However, since we've already done this, libsas must now
dma map any ATA commands that it wishes to issue ... and yes, this is a
horrible mess.
Additionally, the test in aic94xx for ATA protocols isn't quite right.
---
James
Index: BUILD-2.6/drivers/scsi/libsas/sas_discover.c
===
--- BUILD-2.6.orig/drivers/scsi/libsas/sas_discover.c 2007-07-16
13:01:19.0 -0500
+++ BUILD-2.6/drivers/scsi/libsas/sas_discover.c2007-07-16
13:39:57.0 -0500
@@ -110,6 +110,13 @@ static int sas_execute_task(struct sas_t
task-total_xfer_len = size;
task-data_dir = pci_dma_dir;
task-task_done = sas_disc_task_done;
+ if (pci_dma_dir != PCI_DMA_NONE
+ sas_protocol_ata(task-task_proto)) {
+ task-num_scatter = pci_map_sg(task-dev-port-ha-pcidev,
+ task-scatter,
+ task-num_scatter,
+ task-data_dir);
+ }
for (retries = 0; retries 5; retries++) {
task-task_state_flags = SAS_TASK_STATE_PENDING;
@@ -192,8 +199,13 @@ static int sas_execute_task(struct sas_t
}
}
ex_err:
- if (pci_dma_dir != PCI_DMA_NONE)
+ if (pci_dma_dir != PCI_DMA_NONE) {
+ if (sas_protocol_ata(task-task_proto))
+ pci_unmap_sg(task-dev-port-ha-pcidev,
+task-scatter, task-num_scatter,
+task-data_dir);
kfree(scatter);
+ }
out:
return res;
}
Index: BUILD-2.6/drivers/scsi/aic94xx/aic94xx_task.c
===
--- BUILD-2.6.orig/drivers/scsi/aic94xx/aic94xx_task.c 2007-07-16
13:37:59.0 -0500
+++ BUILD-2.6/drivers/scsi/aic94xx/aic94xx_task.c 2007-07-16
13:38:46.0 -0500
@@ -76,7 +76,7 @@ static inline int asd_map_scatterlist(st
/* STP tasks come from libata which has already mapped
* the SG list */
- if (task-task_proto == SAS_PROTOCOL_STP)
+ if (sas_protocol_ata(task-task_proto))
num_sg = task-num_scatter;
else
num_sg = pci_map_sg(asd_ha-pcidev, task-scatter,
@@ -125,7 +125,7 @@ static inline int asd_map_scatterlist(st
return 0;
err_unmap:
- if (task-task_proto != SAS_PROTOCOL_STP)
+ if (sas_protocol_ata(task-task_proto))
pci_unmap_sg(asd_ha-pcidev, task-scatter, task-num_scatter,
task-data_dir);
return res;
Index: BUILD-2.6/include/scsi/scsi_transport_sas.h
===
--- BUILD-2.6.orig/include/scsi/scsi_transport_sas.h2007-07-16
13:34:05.0 -0500
+++ BUILD-2.6/include/scsi/scsi_transport_sas.h 2007-07-16 13:35:58.0
-0500
@@ -23,6 +23,12 @@ enum sas_protocol {
SAS_PROTOCOL_SSP= 0x08,
};
+static inline int sas_protocol_ata(enum sas_protocol proto)
+{
+ return ((proto SAS_PROTOCOL_SATA) ||
+ (proto SAS_PROTOCOL_STP))? 1 : 0;
+}
+
enum sas_linkrate {
/* These Values are defined in the SAS standard */
SAS_LINK_RATE_UNKNOWN = 0,
-
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 05/33] Add chained sg support to linux/scatterlist.h
On Monday 16 July 2007, Jens Axboe wrote:
The core of the patch - allow the last sg element in a scatterlist
table to point to the start of a new table. We overload the LSB of
the page pointer to indicate whether this is a valid sg entry, or
merely a link to the next list.
Signed-off-by: Jens Axboe [EMAIL PROTECTED]
---
include/linux/scatterlist.h | 79 +-
1 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index bed5ab4..10f6223 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -20,8 +20,36 @@ static inline void sg_init_one(struct scatterlist *sg,
const void *buf,
sg_set_buf(sg, buf, buflen);
}
-#define sg_next(sg) ((sg) + 1)
-#define sg_last(sg, nents) ((sg[(nents) - 1]))
+/*
+ * We overload the LSB of the page pointer to indicate whether it's
+ * a valid sg entry, or whether it points to the start of a new scatterlist.
+ * Those low bits are there for everyone! (thanks mason :-)
+ */
+#define sg_is_chain(sg) ((unsigned long) (sg)-page 0x01)
+#define sg_chain_ptr(sg) \
+ ((struct scatterlist *) ((unsigned long) (sg)-page ~0x01))
+
+/**
+ * sg_next - return the next scatterlist entry in a list
+ * @sg: The current sg entry
+ *
+ * Usually the next entry will be @sg@ + 1, but if this sg element is part
+ * of a chained scatterlist, it could jump to the start of a new
+ * scatterlist array.
+ *
+ * Note that the caller must ensure that there are further entries after
+ * the current entry, this function will NOT return NULL for an end-of-list.
+ *
+ */
+static inline struct scatterlist *sg_next(struct scatterlist *sg)
+{
+ sg++;
+
+ if (unlikely(sg_is_chain(sg)))
+ sg = sg_chain_ptr(sg);
+
+ return sg;
+}
/*
* Loop over each sg element, following the pointer to a new list if
necessary
@@ -29,4 +57,51 @@ static inline void sg_init_one(struct scatterlist *sg,
const void *buf,
#define for_each_sg(sglist, sg, nr, __i) \
for (__i = 0, sg = (sglist); __i (nr); __i++, sg = sg_next(sg))
+/**
+ * sg_last - return the last scatterlist entry in a list
+ * @sgl: First entry in the scatterlist
+ * @nents: Number of entries in the scatterlist
+ *
+ * Should only be used casually, it (currently) scan the entire list
+ * to get the last entry.
+ *
+ * Note that the @sgl@ pointer passed in need not be the first one,
+ * the important bit is that @nents@ denotes the number of entries that
+ * exist from @[EMAIL PROTECTED]
+ *
+ */
+static inline struct scatterlist *sg_last(struct scatterlist *sgl,
+ unsigned int nents)
+{
+#ifdef ARCH_HAS_SG_CHAIN
Shouldn't this be #ifndef?
+ struct scatterlist *ret = sgl[nents - 1];
+#else
+ struct scatterlist *sg, *ret = NULL;
+ int i;
+
+ for_each_sg(sgl, sg, nents, i)
+ ret = sg;
+
+#endif
+ return ret;
+}
+
+/**
+ * sg_chain - Chain two sglists together
+ * @prv: First scatterlist
+ * @prv_nents: Number of entries in prv
+ * @sgl: Second scatterlist
+ *
+ * Links @prv@ and @sgl@ together, to form a longer scatterlist.
+ *
+ */
+static inline void sg_chain(struct scatterlist *prv, unsigned int prv_nents,
+ struct scatterlist *sgl)
+{
+#ifndef ARCH_HAS_SG_CHAIN
+ BUG();
+#endif
+ prv[prv_nents - 1].page = (struct page *) ((unsigned long) sgl | 0x01);
+}
+
#endif /* _LINUX_SCATTERLIST_H */
-
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] firewire: fw-sbp2: convert to new SCSI data buffer accessors
Signed-off-by: Stefan Richter [EMAIL PROTECTED]
---
Depends on [SCSI] scsi_lib: add scatter/gather data buffer accessors,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=824d7b570b4dec49e868c251d670941b02a1e489
Only compile-tested at the moment.
drivers/firewire/fw-sbp2.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
Index: x/drivers/firewire/fw-sbp2.c
===
--- x.orig/drivers/firewire/fw-sbp2.c
+++ x/drivers/firewire/fw-sbp2.c
@@ -840,7 +840,6 @@ complete_command_orb(struct sbp2_orb *ba
container_of(base_orb, struct sbp2_command_orb, base);
struct fw_unit *unit = orb-unit;
struct fw_device *device = fw_device(unit-device.parent);
- struct scatterlist *sg;
int result;
if (status != NULL) {
@@ -876,11 +875,10 @@ complete_command_orb(struct sbp2_orb *ba
dma_unmap_single(device-card-device, orb-base.request_bus,
sizeof(orb-request), DMA_TO_DEVICE);
- if (orb-cmd-use_sg 0) {
- sg = (struct scatterlist *)orb-cmd-request_buffer;
- dma_unmap_sg(device-card-device, sg, orb-cmd-use_sg,
+ if (scsi_sg_count(orb-cmd) 0)
+ dma_unmap_sg(device-card-device, scsi_sglist(orb-cmd),
+scsi_sg_count(orb-cmd),
orb-cmd-sc_data_direction);
- }
if (orb-page_table_bus != 0)
dma_unmap_single(device-card-device, orb-page_table_bus,
@@ -901,8 +899,8 @@ static int sbp2_command_orb_map_scatterl
int sg_len, l, i, j, count;
dma_addr_t sg_addr;
- sg = (struct scatterlist *)orb-cmd-request_buffer;
- count = dma_map_sg(device-card-device, sg, orb-cmd-use_sg,
+ sg = scsi_sglist(orb-cmd);
+ count = dma_map_sg(device-card-device, sg, scsi_sg_count(orb-cmd),
orb-cmd-sc_data_direction);
if (count == 0)
goto fail;
@@ -971,7 +969,7 @@ static int sbp2_command_orb_map_scatterl
return 0;
fail_page_table:
- dma_unmap_sg(device-card-device, sg, orb-cmd-use_sg,
+ dma_unmap_sg(device-card-device, sg, scsi_sg_count(orb-cmd),
orb-cmd-sc_data_direction);
fail:
return -ENOMEM;
@@ -1031,7 +1029,7 @@ static int sbp2_scsi_queuecommand(struct
orb-request.misc |=
COMMAND_ORB_DIRECTION(SBP2_DIRECTION_TO_MEDIA);
- if (cmd-use_sg sbp2_command_orb_map_scatterlist(orb) 0)
+ if (scsi_sg_count(cmd) sbp2_command_orb_map_scatterlist(orb) 0)
goto fail_mapping;
fw_memcpy_to_be32(orb-request, orb-request, sizeof(orb-request));
--
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 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, 16 Jul 2007 11:47:23 +0200 Jens Axboe [EMAIL PROTECTED] wrote: This prepares x86-64 for sg chaining support. Additional improvements/fixups for pci-gart from Benny Halevy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Jens Axboe [EMAIL PROTECTED] --- arch/x86_64/kernel/pci-calgary.c | 25 -- arch/x86_64/kernel/pci-gart.c| 63 - arch/x86_64/kernel/pci-nommu.c |5 ++- 3 files changed, 51 insertions(+), 42 deletions(-) This causes fairly extensive destruction of 2.6.23 changes which are pending in Andi's tree. I shall drop the block tree until a) Andi has merged the pending Calgary changes and b) the block tree has been fixed up to account for those (and other) changes. Really, this was the perfectly worst time possible to go tromping all over everyone else's trees. - 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 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16 2007, Andrew Morton wrote: On Mon, 16 Jul 2007 11:47:23 +0200 Jens Axboe [EMAIL PROTECTED] wrote: This prepares x86-64 for sg chaining support. Additional improvements/fixups for pci-gart from Benny Halevy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Jens Axboe [EMAIL PROTECTED] --- arch/x86_64/kernel/pci-calgary.c | 25 -- arch/x86_64/kernel/pci-gart.c| 63 - arch/x86_64/kernel/pci-nommu.c |5 ++- 3 files changed, 51 insertions(+), 42 deletions(-) This causes fairly extensive destruction of 2.6.23 changes which are pending in Andi's tree. I shall drop the block tree until a) Andi has merged the pending Calgary changes and b) the block tree has been fixed up to account for those (and other) changes. Really, this was the perfectly worst time possible to go tromping all over everyone else's trees. Well, that's a bit hard for me to know, all I can do is push my stuff to for-akpm so that it gets -mm exposure. If I don't, then you are yelling at me as well :-) I'll keep rebasing sglist and the other branches I pull into for-akpm, so you can just re-enable the for-akpm pull when the a) is true. -- Jens Axboe - 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] libsas, aic94xx: fix dma mapping cockups with ATA
On Mon, 2007-07-16 at 16:19 -0400, Jeff Garzik wrote: James Bottomley wrote: This one was noticed by Gilbert Wu of Adaptec: The libata core actually does the DMA mapping for you, so there has to be an exception in the device drivers that *don't* do dma mapping for ATA commands. However, since we've already done this, libsas must now dma map any ATA commands that it wishes to issue ... and yes, this is a horrible mess. Can you help me understand this logic? libsas must DMA map an ATA command... because libata also DMA maps an ATA command? That does not make sense to me. Why not? ... since the driver must *not* map an ATA command (to prevent double mapping from libata), it can't tell if the command comes from libsas or libata ... so libsas has to map any internal ATA commands it uses. I think you're perhaps thinking libsas must map an ATA command libata has already mapped? If so, no, libsas must only map the commands it is using internally independent of libata. 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
advansys cleanup
I have to run, but here's what I've benn working on today if anyone wants to test: http://git.kernel.org/pub/scm/linux/kernel/git/willy/advansys-2.6.git -- Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - 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 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, 16 Jul 2007 22:10:03 +0200 Jens Axboe [EMAIL PROTECTED] wrote: On Mon, Jul 16 2007, Andrew Morton wrote: On Mon, 16 Jul 2007 11:47:23 +0200 Jens Axboe [EMAIL PROTECTED] wrote: This prepares x86-64 for sg chaining support. Additional improvements/fixups for pci-gart from Benny Halevy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Jens Axboe [EMAIL PROTECTED] --- arch/x86_64/kernel/pci-calgary.c | 25 -- arch/x86_64/kernel/pci-gart.c| 63 - arch/x86_64/kernel/pci-nommu.c |5 ++- 3 files changed, 51 insertions(+), 42 deletions(-) This causes fairly extensive destruction of 2.6.23 changes which are pending in Andi's tree. I shall drop the block tree until a) Andi has merged the pending Calgary changes and b) the block tree has been fixed up to account for those (and other) changes. Really, this was the perfectly worst time possible to go tromping all over everyone else's trees. Well, that's a bit hard for me to know, all I can do is push my stuff to for-akpm so that it gets -mm exposure. If I don't, then you are yelling at me as well :-) It is to be expected that there will be conflicts when making large-scale changes like this while there is 25MB of unmerged diff sitting out in 50 different trees. Doing it around the -rc1 time would be better. Even better would be not doing it at all: add the necessary stuff into the block core and then send the followup work to the relevant maintainers. ie: standard practice. I'll keep rebasing sglist and the other branches I pull into for-akpm, so you can just re-enable the for-akpm pull when the a) is true. Andi's tree is very out of date and is about to be damaged (to what extent I don't yet know) by a xen merge. I don't know if a) is going to happen. Things are more than usually messy this time around. - 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] aacraid: add vpd to inquiry
Report VPD inquiry page 0x80 with an unique array creation serial number (CUID). When an array is created, the metadata stored on the physical drives gets an unique serial number. This serial number remains constant through array morphing or migration to other controllers. This patch is a forward port and modification to survive morphing and migration operations, of a similar piece of (un-attributed author) code added to the SLES10 SP1 aacraid driver. To test the results of the patch, observe that /dev/disk/by-id/ entries will show up for the arrays resulting from the udev rules. Also, as per the udev rules, 'scsi_id -g -x -a -s /block/sd? -d /dev/sd?' will report the ID_SERIAL as constructed from the inquiry data. This attached patch is against current scsi-misc-2.6 ObligatoryDisclaimer: Please accept my condolences regarding Outlook's handling of patch attachments. Signed-off-by: Mark Salyzyn [EMAIL PROTECTED] drivers/scsi/aacraid/aachba.c | 136 + drivers/scsi/aacraid/aacraid.h | 14 2 files changed, 150 insertions(+) Sincerely -- Mark Salyzyn aacraid_vpd.patch Description: aacraid_vpd.patch
Re: [patch 5/6] ps3: BD/DVD/CD-ROM Storage Driver
Upon closer look, while flush_kernel_dcache_page() is a no-op on ppc64, flush_dcache_page() isn't. So I'd prefer to not call it if not really needed. And according to James, flush_kernel_dcache_page() should be sufficient... So I'm getting puzzled again... flush_dcache_page() handles icache vs. dcache coherency by clearing the PG_arch_1 bit in the struct page that indicates that the page is cache clean. You -must- call it if you're going to use any form of CPU access to write to the page (basically dirtying the data cache) and that page can be ever mapped into user space and executed from. I don't know what flush_kernel_dcache_page() does and if it needs a similar treatement, it's a new interface, so maybe Jens and or James can tell me more about it.. Cheers, Ben. - 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 09/33] x86-64: update iommu/dma mapping functions to sg helpers
On Mon, Jul 16, 2007 at 01:34:27PM -0700, Andrew Morton wrote: I'll keep rebasing sglist and the other branches I pull into for-akpm, so you can just re-enable the for-akpm pull when the a) is true. Andi's tree is very out of date and is about to be damaged (to what extent I don't yet know) by a xen merge. I don't know if a) is going to happen. The Xen and Calgary bits are mutually exclusive, so hopefully (a) will not be held up on account of the Xen merge (or for any other reason... CalIOC2 machines which are out there won't boot without it if CONFIG_CALGARY_IOMMU is enabled). Cheers, Muli - 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 5/6] ps3: BD/DVD/CD-ROM Storage Driver
On Mon, 2007-07-16 at 17:03 -0500, James Bottomley wrote: On Tue, 2007-07-17 at 07:49 +1000, Benjamin Herrenschmidt wrote: No ... that was the point of flush_kernel_dcache_page(). The page in question is page cache backed and contains user mappings. However, the block layer has already done a flush_dcache_page() in get_user_pages() and the user shouldn't be touching memory under I/O (unless they want self induced aliasing problems) so we're free to assume all the user cachelines are purged, hence all we have to do is flush the kernel alias to bring the page up to date and make the users see it correctly. The block layer will have done that even in the swap-out path ? (Just asking... I'm not very familiar with the block layer) Er ... not really, this is the I/O path for user initiated I/O. The page out path, by definition, can't have any extant user mappings. For page out, the relevant page is flushed before its mapping is detached, and then it can be paged to the backing store (or for anonymous pages to the swap device) when no mappings remain. Ok, thanks. Ben. - 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
block/bsg.c
A belated review (I've never seen this before and there it is in mainline)
static char bsg_version[] = block layer sg (bsg) 0.4;
`const' would be better. That moves it into a write-protected memory section.
struct bsg_device {
request_queue_t *queue;
spinlock_t lock;
struct list_head busy_list;
struct list_head done_list;
struct hlist_node dev_list;
atomic_t ref_count;
int minor;
int queued_cmds;
int done_cmds;
wait_queue_head_t wq_done;
wait_queue_head_t wq_free;
char name[BUS_ID_SIZE];
int max_queue;
unsigned long flags;
};
Please try to comment your data structures. This is key to allowing others
to understand your code.
#undef BSG_DEBUG
#ifdef BSG_DEBUG
#define dprintk(fmt, args...) printk(KERN_ERR %s: fmt, __FUNCTION__,
##args)
#else
#define dprintk(fmt, args...)
#endif
hm, that seems to be out 187th implementation of dprintk().
#define list_entry_bc(entry) list_entry((entry), struct bsg_command, list)
This makes the code easier to write but harder to read. We should optimise
for readers. Please open-code this at callsites.
Or at least convert it into a (commented) (possibly inlined) C function.
/*
* just for testing
*/
#define BSG_MAJOR (240)
What's this doing in mainline? 240 is a reserved for local use major.
This will cause collisions. This code should be using dynamic major
assignment.
static DEFINE_MUTEX(bsg_mutex);
static int bsg_device_nr, bsg_minor_idx;
#define BSG_LIST_SIZE (8)
afacit this isn't really the size of a list. It has something to do with
the number of minors which are attached to that illegitimate major? A
comment here would help. Perhaps this name is poorly chosen.
#define bsg_list_idx(minor) ((minor) (BSG_LIST_SIZE - 1))
Please prefer to write code in C, not in cpp.
static struct hlist_head bsg_device_list[BSG_LIST_SIZE];
That is an array, not a list.
static struct class *bsg_class;
static LIST_HEAD(bsg_class_list);
static struct kmem_cache *bsg_cmd_cachep;
How many of these items do we expect to be simultaneously allocated? If
that number is small then a custom kmem_cache is probably not warranted.
/*
* our internal command type
*/
struct bsg_command {
struct bsg_device *bd;
struct list_head list;
struct request *rq;
struct bio *bio;
struct bio *bidi_bio;
int err;
struct sg_io_v4 hdr;
struct sg_io_v4 __user *uhdr;
char sense[SCSI_SENSE_BUFFERSIZE];
};
Comments here, please.
static void bsg_free_command(struct bsg_command *bc)
{
struct bsg_device *bd = bc-bd;
unsigned long flags;
kmem_cache_free(bsg_cmd_cachep, bc);
spin_lock_irqsave(bd-lock, flags);
bd-queued_cmds--;
spin_unlock_irqrestore(bd-lock, flags);
wake_up(bd-wq_free);
}
static struct bsg_command *bsg_alloc_command(struct bsg_device *bd)
{
struct bsg_command *bc = ERR_PTR(-EINVAL);
spin_lock_irq(bd-lock);
if (bd-queued_cmds = bd-max_queue)
goto out;
bd-queued_cmds++;
spin_unlock_irq(bd-lock);
bc = kmem_cache_alloc(bsg_cmd_cachep, GFP_USER);
This should be GFP_KERNEL.
if (unlikely(!bc)) {
spin_lock_irq(bd-lock);
bd-queued_cmds--;
bc = ERR_PTR(-ENOMEM);
goto out;
}
memset(bc, 0, sizeof(*bc));
Use kmem_cache_zalloc() above, remove this.
bc-bd = bd;
INIT_LIST_HEAD(bc-list);
dprintk(%s: returning free cmd %p\n, bd-name, bc);
return bc;
out:
spin_unlock_irq(bd-lock);
return bc;
}
static inline void
bsg_del_done_cmd(struct bsg_device *bd, struct bsg_command *bc)
{
bd-done_cmds--;
list_del(bc-list);
}
This only has a single caller. It would be clearer to move this code into
that caller.
static inline void
bsg_add_done_cmd(struct bsg_device *bd, struct bsg_command *bc)
{
bd-done_cmds++;
list_add_tail(bc-list, bd-done_list);
wake_up(bd-wq_done);
}
Ditto. Once this has been moved into the caller, that caller can then use
the neater list_move().
static inline int bsg_io_schedule(struct bsg_device *bd, int state)
This is too large to inline.
{
DEFINE_WAIT(wait);
int ret = 0;
spin_lock_irq(bd-lock);
BUG_ON(bd-done_cmds bd-queued_cmds);
/*
* -ENOSPC or -ENODATA? I'm going for -ENODATA, meaning I have no
* work to do, even though we return -ENOSPC after this same test
* during bsg_write() -- there, it means our buffer can't have more
* bsg_commands added to it, thus has no space left.
*/
if (bd-done_cmds == bd-queued_cmds) {
ret = -ENODATA;
goto unlock;
}
if (!test_bit(BSG_F_BLOCK, bd-flags)) {
ret = -EAGAIN;
goto unlock;
[PATCH 3/4] advansys: Convert to pci_register_driver interface
Add a pci_driver interface for the PCI advansys devices. For
ISA/EISA/VLB devices, we still call advansys_detect and advansys_release.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
---
drivers/scsi/advansys.c | 170 +--
1 files changed, 75 insertions(+), 95 deletions(-)
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index 83fd9c7..35c4a1d 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -4261,12 +4261,12 @@ advansys_proc_info(struct Scsi_Host *shost, char
*buffer, char **start,
static int advansys_board_found(struct scsi_host_template *tpnt, int iop,
struct pci_dev *pdev, int bus_type)
{
-struct Scsi_Host*shp = NULL;
-asc_board_t *boardp = NULL;
+struct Scsi_Host*shp;
+asc_board_t *boardp;
ASC_DVC_VAR *asc_dvc_varp = NULL;
ADV_DVC_VAR *adv_dvc_varp = NULL;
-adv_sgblk_t *sgp = NULL;
-int share_irq = FALSE;
+adv_sgblk_t *sgp;
+int share_irq;
int iolen = 0;
ADV_PADDR pci_memory_address;
int warn_code, err_code;
@@ -4284,6 +4284,8 @@ static int advansys_board_found(struct scsi_host_template
*tpnt, int iop,
/* Save a pointer to the Scsi_Host of each board found. */
asc_host[asc_board_count++] = shp;
+ if (pdev)
+ pci_set_drvdata(pdev, shp);
/* Initialize private per board data */
boardp = ASC_BOARDP(shp);
@@ -5033,9 +5035,8 @@ static int advansys_board_found(struct scsi_host_template
*tpnt, int iop,
sgp = (adv_sgblk_t *)
kmalloc(sizeof(adv_sgblk_t), GFP_ATOMIC);
-if (sgp == NULL) {
+if (sgp == NULL)
break;
-}
sgp-next_sgblkp = boardp-adv_sgblkp;
boardp-adv_sgblkp = sgp;
@@ -5171,24 +5172,6 @@ advansys_detect(struct scsi_host_template *tpnt)
int iop;
int bus;
int ioport = 0;
-#ifdef CONFIG_PCI
-int pci_init_search = 0;
-struct pci_dev *pci_devicep[ASC_NUM_BOARD_SUPPORTED];
-int pci_card_cnt_max = 0;
-int pci_card_cnt = 0;
-struct pci_dev *pci_devp = NULL;
-int pci_device_id_cnt = 0;
-unsigned intpci_device_id[ASC_PCI_DEVICE_ID_CNT] = {
-PCI_DEVICE_ID_ASP_1200A,
-PCI_DEVICE_ID_ASP_ABP940,
-PCI_DEVICE_ID_ASP_ABP940U,
-PCI_DEVICE_ID_ASP_ABP940UW,
-PCI_DEVICE_ID_38C0800_REV1,
-PCI_DEVICE_ID_38C1600_REV1
-};
-#else
-#define pci_devp NULL
-#endif /* CONFIG_PCI */
if (detect_called == ASC_FALSE) {
detect_called = ASC_TRUE;
@@ -5312,70 +5295,6 @@ advansys_detect(struct scsi_host_template *tpnt)
#endif /* CONFIG_ISA */
break;
-case ASC_IS_PCI:
-#ifdef CONFIG_PCI
-if (pci_init_search == 0) {
-int i, j;
-
-pci_init_search = 1;
-
-/* Find all PCI cards. */
-while (pci_device_id_cnt ASC_PCI_DEVICE_ID_CNT) {
-if ((pci_devp = pci_find_device(PCI_VENDOR_ID_ASP,
-pci_device_id[pci_device_id_cnt], pci_devp)) ==
-NULL) {
-pci_device_id_cnt++;
-} else {
-if (pci_enable_device(pci_devp) == 0) {
-pci_devicep[pci_card_cnt_max++] = pci_devp;
-}
-}
-}
-
-/*
- * Sort PCI cards in ascending order by PCI Bus, Slot,
- * and Device Number.
- */
-for (i = 0; i pci_card_cnt_max - 1; i++)
-{
-for (j = i + 1; j pci_card_cnt_max; j++) {
-if ((pci_devicep[j]-bus-number
- pci_devicep[i]-bus-number) ||
-((pci_devicep[j]-bus-number ==
- pci_devicep[i]-bus-number)
- (pci_devicep[j]-devfn
- pci_devicep[i]-devfn))) {
-pci_devp = pci_devicep[i];
-pci_devicep[i] = pci_devicep[j];
-pci_devicep[j] = pci_devp;
-}
-
Re: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
Gabriel C wrote: Hello, sdparm and hdparm are broken for me on git ( abce891a10559343d8ac9f79b46d78afdba63a40 ) ~$ sudo hdparm /dev/sdc /dev/sdc: BLKROGET failed: Inappropriate ioctl for device BLKRAGET failed: Inappropriate ioctl for device BLKGETSIZE failed: Inappropriate ioctl for device ~$ sudo sdparm --all /dev/sdc unable to access /dev/sdc, ATA disk? Well it is bsg , setting BLK_DEV_BSG=n fixed all this errors. Maybe a bit off topic but it depends on EXPERIMENTAL so why the the menu is not telling this ? and why the default is 'y' for it ? IMO everything depends on EXPERIMENTAL should 1) Tell it is EXPERIMENTAL ( visible to the user in menu ) Foo New stuff ( EXPERIMENTAL ) 2) Should not default to 'y' , is up to the users/admins to set EXPERIMENTAL things to Y/M , isn't it ? ( PS: there are even defconfigs with EXPERIMENTAL things set to y but this is really off topic ) Regards, Gabriel C - 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: block/bsg.c
From: Satyam Sharma [EMAIL PROTECTED] Subject: Re: block/bsg.c Date: Tue, 17 Jul 2007 06:22:25 +0530 On 7/17/07, Andrew Morton [EMAIL PROTECTED] wrote: CONFIG_BLK_DEV_BSG=y CONFIG_SCSI=m block/built-in.o: In function `bsg_init': block/bsg.c:1097: undefined reference to `scsi_register_interface' make: *** [.tmp_vmlinux1] Error 1 This should be fixed by the following commit (thanks !): http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=29417b899a77aaba1c060f5e123db4f50006f58a - 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: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
FUJITA Tomonori wrote:
From: Gabriel C [EMAIL PROTECTED]
Subject: Re: Someone ( bsg merge ? ) broke {sd,hd}parm on current git
Date: Tue, 17 Jul 2007 02:44:38 +0200
Gabriel C wrote:
Hello,
sdparm and hdparm are broken for me on git (
abce891a10559343d8ac9f79b46d78afdba63a40 )
~$ sudo hdparm /dev/sdc
/dev/sdc:
BLKROGET failed: Inappropriate ioctl for device
BLKRAGET failed: Inappropriate ioctl for device
BLKGETSIZE failed: Inappropriate ioctl for device
~$ sudo sdparm --all /dev/sdc
unable to access /dev/sdc, ATA disk?
Well it is bsg , setting BLK_DEV_BSG=n fixed all this errors.
Can you check the major number of your /dev/sdc? I've seen that
/dev/sd* is linked to bsg devices somehow.
All my disks are doing this sdc was meant as example.
...
$ ls -la /dev/sd{a,b,c}
brw-r- 1 root disk 8, 0 16. Jul 23:11 /dev/sda
brw-rw 1 root disk 8, 16 16. Jul 23:11 /dev/sdb
brw-r- 1 root disk 8, 32 16. Jul 23:11 /dev/sdc
...
sd{a,b} are SCSI disks and sdc is an ATA disk.
You can get the used config from there :
http://194.231.229.228/2.6.22-gabce891a/config
Gabriel
-
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: block/bsg.c
hrm. uninitialized_var(x) does not silence the warning, on my compiler:
[EMAIL PROTECTED] misc-2.6]$ rpm -q gcc
gcc-4.1.2-13.fc6
@@ -1358,6 +1358,8 @@ udf_load_partition(struct super_block *sb,
kernel_lb_addr
{
kernel_lb_addr ino;
+
uninitialized_var(ino.partitionReferenceNum);
+
if (!UDF_SB_LASTBLOCK(sb))
still yields
fs/udf/super.c: In function ‘udf_fill_super’:
fs/udf/super.c:1359: warning: ‘ino.partitionReferenceNum’ may be used
uninitialized in this function
-
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
