Re: [PATCH 3/4] [SCSI] ips: PCI API cleanups
Jeff Garzik wrote:
> * pass Scsi_Host to ips_remove_device() via pci_set_drvdata(),
> allowing us to eliminate the ips_ha[] search loop and call
> ips_release() directly.
>
> * call pci_{request,release}_regions() and eliminate individual
> request/release_[mem_]region() calls
>
> * call pci_disable_device(), paired with pci_enable_device()
>
> * s/0/NULL/ in a few places
>
> * check ioremap() return value
> @@ -7036,32 +7042,17 @@ ips_init_phase1(struct pci_dev *pci_dev, int
> *indexPtr) uint32_t base;
> uint32_t offs;
>
> - if (!request_mem_region(mem_addr, mem_len, "ips")) {
> - IPS_PRINTK(KERN_WARNING, pci_dev,
> -"Couldn't allocate IO Memory space %x len
> %d.\n",
> -mem_addr, mem_len);
> - return -1;
> - }
> -
> base = mem_addr & PAGE_MASK;
> offs = mem_addr - base;
> ioremap_ptr = ioremap(base, PAGE_SIZE);
This looks odd. What are we actually doing here?
It seems that we want to map that PCI BAR. Since we're playing with PAGE_MASK
I assume the BAR always has a length
signature.asc
Description: This is a digitally signed message part.
Re: Subject: [PATCH] tgt: use KMEM_CACHE
On Wed, 24 Oct 2007 21:25:24 -0600
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 24, 2007 at 07:57:55PM -0700, Arjan van de Ven wrote:
> > On Thu, 25 Oct 2007 01:21:29 +0900
> > FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > > - scsi_tgt_cmd_cache = kmem_cache_create("scsi_tgt_cmd",
> > > -sizeof(struct
> > > scsi_tgt_cmd),
> > > -0, 0, NULL);
> > > + scsi_tgt_cmd_cache = KMEM_CACHE(scsi_tgt_cmd, 0);
> >
> > I have a question that is not described in your change log: why would
> > you want to do this change? kmem_cache_create() is THE linux API to
> > achieve this why would you not want to use it?? I'm sure you have a
> > good reason for this change, but I can't figure out what that is from
> > the changelog of your patch.
>
> Looks like the preferred API was changed in May by clameter; see
> commit 0a31bd5f2bbb6473ef9d24f0063ca91cfa678b64
Yeah, I just thought that it would be better use new KMEM_CACHE macro.
Here's a bit better changelog.
-
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: [PATCH] tgt: use KMEM_CACHE macro
This uses new KMEM_CACHE() macro instead of kmem_cache_create directly
to simplify slab cache creation.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_tgt_lib.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/scsi_tgt_lib.c b/drivers/scsi/scsi_tgt_lib.c
index a91761c..d67ca14 100644
--- a/drivers/scsi/scsi_tgt_lib.c
+++ b/drivers/scsi/scsi_tgt_lib.c
@@ -640,9 +640,7 @@ static int __init scsi_tgt_init(void)
{
int err;
- scsi_tgt_cmd_cache = kmem_cache_create("scsi_tgt_cmd",
- sizeof(struct scsi_tgt_cmd),
- 0, 0, NULL);
+ scsi_tgt_cmd_cache = KMEM_CACHE(scsi_tgt_cmd, 0);
if (!scsi_tgt_cmd_cache)
return -ENOMEM;
--
1.5.2.4
-
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 4/4] aic7xxx: Enable 16-bit CDBs
James Bottomley wrote: > On Mon, 2007-10-22 at 13:57 +0200, Hannes Reinecke wrote: >> Matthew Wilcox wrote: >>> On Mon, Oct 22, 2007 at 08:50:45AM +0200, Hannes Reinecke wrote: That's what I thought, too. Hence the patch. But if we set the default to 16 byte cdbs you can of course ignore the patch. >>> I think the comment in hosts.c explains why we shouldn't do that ... >>> >> _I_ certainly wouldn't. But if the maintainer says so :-) > > Actually, I misremembered. I thought I did a commit a few years ago > that automatically raised the cutoff to 16 byte cdbs and forced drivers > who couldn't do that to lower the limit, but apparently it was never > merged. > > So, just pick either 16 or 32 for both drivers and add that as the max > cdb size. > Hmm. But aic7xxx actually supports 32-byte cdbs (for whatever reason); cf drivers/scsi/aic7xxx/aic7xxx.h:478. And aic79xx only supports 16 byte cdbs; the clever 'use pointer for cdb if it's longer than the 12 bytes' routine sadly isn't implemented for aic79xx. It somehow feels wrong to arbitrarily cut the limit to 16 bytes for aic7xxx, hence the two different limits. But again, you're the maintainer, you get to decide. If you feel it's reasonable to limit both to 16 byte so be it. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - 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 1/4] [SCSI] ips: remove ips_ha members that duplicate struct pci_dev members
Andrew Morton wrote:
On Wed, 24 Oct 2007 19:48:26 -0400 (EDT) Jeff Garzik <[EMAIL PROTECTED]> wrote:
drivers/scsi/ips.c | 178
this driver seems a bit of a basket case :(
What's going on here?
scb->dcdb.cmd_attribute =
ips_command_direction[scb->scsi_cmd->cmnd[0]];
/* Allow a WRITE BUFFER Command to Have no Data */
/* This is Used by Tape Flash Utilites */
if ((scb->scsi_cmd->cmnd[0] == WRITE_BUFFER) && (scb->data_len == 0))
scb->dcdb.cmd_attribute = 0;
if (!(scb->dcdb.cmd_attribute & 0x3))
scb->dcdb.transfer_length = 0;
if (scb->data_len >= IPS_MAX_XFER) {
I hope that's just busted indentation and not a missing {} block.
The driver is one of the grotty drivers people are afraid to touch,
therefore it bitrots even faster, in a vicious cycle. You don't have to
look hard at all to find checkpatch pukeage, very real bugs, and
Pythonesque silliness.
Not having hardware I went only for changes that are provable and
obvious, really...
Jeff
-
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 1/4] [SCSI] ips: remove ips_ha members that duplicate struct pci_dev members
On Wed, 24 Oct 2007 19:48:26 -0400 (EDT) Jeff Garzik <[EMAIL PROTECTED]> wrote:
> drivers/scsi/ips.c | 178
>
this driver seems a bit of a basket case :(
What's going on here?
scb->dcdb.cmd_attribute =
ips_command_direction[scb->scsi_cmd->cmnd[0]];
/* Allow a WRITE BUFFER Command to Have no Data */
/* This is Used by Tape Flash Utilites */
if ((scb->scsi_cmd->cmnd[0] == WRITE_BUFFER) && (scb->data_len == 0))
scb->dcdb.cmd_attribute = 0;
if (!(scb->dcdb.cmd_attribute & 0x3))
scb->dcdb.transfer_length = 0;
if (scb->data_len >= IPS_MAX_XFER) {
I hope that's just busted indentation and not a missing {} block.
-
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: Subject: [PATCH] tgt: use KMEM_CACHE
On Wed, Oct 24, 2007 at 07:57:55PM -0700, Arjan van de Ven wrote:
> On Thu, 25 Oct 2007 01:21:29 +0900
> FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > - scsi_tgt_cmd_cache = kmem_cache_create("scsi_tgt_cmd",
> > - sizeof(struct
> > scsi_tgt_cmd),
> > - 0, 0, NULL);
> > + scsi_tgt_cmd_cache = KMEM_CACHE(scsi_tgt_cmd, 0);
>
> I have a question that is not described in your change log: why would
> you want to do this change? kmem_cache_create() is THE linux API to
> achieve this why would you not want to use it?? I'm sure you have a
> good reason for this change, but I can't figure out what that is from
> the changelog of your patch.
Looks like the preferred API was changed in May by clameter; see
commit 0a31bd5f2bbb6473ef9d24f0063ca91cfa678b64
--
Intel are signing my paycheques ... these opinions are still mine
"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: Subject: [PATCH] tgt: use KMEM_CACHE
On Thu, 25 Oct 2007 01:21:29 +0900
FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> ---
> drivers/scsi/scsi_tgt_lib.c |4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/scsi_tgt_lib.c b/drivers/scsi/scsi_tgt_lib.c
> index deea3cd..7abef1a 100644
> --- a/drivers/scsi/scsi_tgt_lib.c
> +++ b/drivers/scsi/scsi_tgt_lib.c
> @@ -641,9 +641,7 @@ static int __init scsi_tgt_init(void)
> {
> int err;
>
> - scsi_tgt_cmd_cache = kmem_cache_create("scsi_tgt_cmd",
> -sizeof(struct
> scsi_tgt_cmd),
> -0, 0, NULL);
> + scsi_tgt_cmd_cache = KMEM_CACHE(scsi_tgt_cmd, 0);
Hi,
I have a question that is not described in your change log: why would
you want to do this change? kmem_cache_create() is THE linux API to
achieve this why would you not want to use it?? I'm sure you have a
good reason for this change, but I can't figure out what that is from
the changelog of your patch.
Greetings,
Arjan van de Ven
-
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
slow after upgrade to CentOS 5 (RHEL5)
Hi All, If you all would not mind a post from the general public Linux user, after doing a complete disk wipe of CentOS 4 and installing CentOS5, my system is preceived to be 3 times slower. To troubleshooting this, I made a post on CentOS's bugzilla: http://bugs.centos.org/view.php?id=2382 Would some of the experts on this group mind looking at the bug to evaluate the possibility that it is being caused by the underlying scsi driver? The post contains a dmesg from "Computer C". (Yes, I am getting a bit desperate.) Do I automatically get a response from the list, or do I need to sign up for it? Many thanks, -T - 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 4/4] [SCSI] ips: handle scsi_add_host() failure, and other err cleanups
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/scsi/ips.c | 18 +-
1 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index fb90b6c..b8e2f5a 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -6836,13 +6836,10 @@ ips_register_scsi(int index)
if (request_irq(ha->pcidev->irq, do_ipsintr, IRQF_SHARED, ips_name,
ha)) {
IPS_PRINTK(KERN_WARNING, ha->pcidev,
"Unable to install interrupt handler\n");
- scsi_host_put(sh);
- return -1;
+ goto err_out_sh;
}
kfree(oldha);
- ips_sh[index] = sh;
- ips_ha[index] = ha;
/* Store away needed values for later use */
sh->unique_id = (ha->io_addr) ? ha->io_addr : ha->mem_addr;
@@ -6858,10 +6855,21 @@ ips_register_scsi(int index)
sh->max_channel = ha->nbus - 1;
sh->can_queue = ha->max_cmds - 1;
- scsi_add_host(sh, NULL);
+ if (scsi_add_host(sh, &ha->pcidev->dev))
+ goto err_out;
+
+ ips_sh[index] = sh;
+ ips_ha[index] = ha;
+
scsi_scan_host(sh);
return 0;
+
+err_out:
+ free_irq(ha->pcidev->irq, ha);
+err_out_sh:
+ scsi_host_put(sh);
+ return -1;
}
/*---*/
--
1.5.2.4
-
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/4] [SCSI] ips: trim trailing whitespace
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/scsi/ips.c | 44 ++--
drivers/scsi/ips.h | 12 ++--
2 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index 595a91a..c9f3e1f 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -389,17 +389,17 @@ static struct pci_device_id ips_pci_table[] = {
MODULE_DEVICE_TABLE( pci, ips_pci_table );
static char ips_hot_plug_name[] = "ips";
-
+
static int __devinit ips_insert_device(struct pci_dev *pci_dev, const struct
pci_device_id *ent);
static void __devexit ips_remove_device(struct pci_dev *pci_dev);
-
+
static struct pci_driver ips_pci_driver = {
.name = ips_hot_plug_name,
.id_table = ips_pci_table,
.probe = ips_insert_device,
.remove = __devexit_p(ips_remove_device),
};
-
+
/*
* Necessary forward function protoypes
@@ -587,7 +587,7 @@ static void
ips_setup_funclist(ips_ha_t * ha)
{
- /*
+ /*
* Setup Functions
*/
if (IPS_IS_MORPHEUS(ha) || IPS_IS_MARCO(ha)) {
@@ -2081,7 +2081,7 @@ ips_host_info(ips_ha_t * ha, char *ptr, off_t offset, int
len)
/* That keeps everything happy for "text" operations on the proc file.
*/
if (le32_to_cpu(ha->nvram->signature) == IPS_NVRAM_P5_SIG) {
-if (ha->nvram->bios_low[3] == 0) {
+if (ha->nvram->bios_low[3] == 0) {
copy_info(&info,
"\tBIOS Version :
%c%c%c%c%c%c%c\n",
ha->nvram->bios_high[0],
ha->nvram->bios_high[1],
@@ -2782,8 +2782,8 @@ ips_next(ips_ha_t * ha, int intr)
/* Allow a WRITE BUFFER Command to Have no Data */
/* This is Used by Tape Flash Utilites */
-if ((scb->scsi_cmd->cmnd[0] == WRITE_BUFFER) && (scb->data_len == 0))
-scb->dcdb.cmd_attribute = 0;
+if ((scb->scsi_cmd->cmnd[0] == WRITE_BUFFER) && (scb->data_len == 0))
+scb->dcdb.cmd_attribute = 0;
if (!(scb->dcdb.cmd_attribute & 0x3))
scb->dcdb.transfer_length = 0;
@@ -3404,7 +3404,7 @@ ips_map_status(ips_ha_t * ha, ips_scb_t * scb, ips_stat_t
* sp)
/* Restrict access to physical DASD */
if (scb->scsi_cmd->cmnd[0] == INQUIRY) {
- ips_scmd_buf_read(scb->scsi_cmd,
+ ips_scmd_buf_read(scb->scsi_cmd,
&inquiryData, sizeof (inquiryData));
if ((inquiryData.DeviceType & 0x1f) ==
TYPE_DISK) {
errcode = DID_TIME_OUT;
@@ -4090,10 +4090,10 @@ ips_chkstatus(ips_ha_t * ha, IPS_STATUS * pstatus)
scb->scsi_cmd->result = errcode << 16;
} else {/* bus == 0 */
/* restrict access to physical drives */
- if (scb->scsi_cmd->cmnd[0] == INQUIRY) {
- ips_scmd_buf_read(scb->scsi_cmd,
+ if (scb->scsi_cmd->cmnd[0] == INQUIRY) {
+ ips_scmd_buf_read(scb->scsi_cmd,
&inquiryData, sizeof (inquiryData));
- if ((inquiryData.DeviceType & 0x1f) == TYPE_DISK)
+ if ((inquiryData.DeviceType & 0x1f) == TYPE_DISK)
scb->scsi_cmd->result = DID_TIME_OUT << 16;
}
} /* else */
@@ -4661,8 +4661,8 @@ ips_isinit_morpheus(ips_ha_t * ha)
uint32_t bits;
METHOD_TRACE("ips_is_init_morpheus", 1);
-
- if (ips_isintr_morpheus(ha))
+
+ if (ips_isintr_morpheus(ha))
ips_flush_and_reset(ha);
post = readl(ha->mem_ptr + IPS_REG_I960_MSG0);
@@ -4686,7 +4686,7 @@ ips_isinit_morpheus(ips_ha_t * ha)
/* state ( was trying to INIT and an interrupt was already pending ) ... */
/* */
//
-static void
+static void
ips_flush_and_reset(ips_ha_t *ha)
{
ips_scb_t *scb;
@@ -4718,9 +4718,9 @@ ips_flush_and_reset(ips_ha_t *ha)
if (ret == IPS_SUCCESS) {
time = 60 * IPS_ONE_SEC; /* Max Wait time
is 60 seconds */
done = 0;
-
+
while ((time > 0) && (!done)) {
- done = ips_poll_for_flush_complete(ha);
+ done = ips_poll_for_flush_complete(ha);
/* This may look evil, but it's only done during extremely
rare start-up condi
[PATCH 3/4] [SCSI] ips: PCI API cleanups
* pass Scsi_Host to ips_remove_device() via pci_set_drvdata(),
allowing us to eliminate the ips_ha[] search loop and call
ips_release() directly.
* call pci_{request,release}_regions() and eliminate individual
request/release_[mem_]region() calls
* call pci_disable_device(), paired with pci_enable_device()
* s/0/NULL/ in a few places
* check ioremap() return value
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/scsi/ips.c | 72 ++-
1 files changed, 31 insertions(+), 41 deletions(-)
diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index c9f3e1f..fb90b6c 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -702,10 +702,6 @@ ips_release(struct Scsi_Host *sh)
/* free extra memory */
ips_free(ha);
- /* Free I/O Region */
- if (ha->io_addr)
- release_region(ha->io_addr, ha->io_len);
-
/* free IRQ */
free_irq(ha->pcidev->irq, ha);
@@ -4393,8 +4389,6 @@ ips_free(ips_ha_t * ha)
ha->mem_ptr = NULL;
}
- if (ha->mem_addr)
- release_mem_region(ha->mem_addr, ha->mem_len);
ha->mem_addr = 0;
}
@@ -6879,20 +6873,14 @@ ips_register_scsi(int index)
static void __devexit
ips_remove_device(struct pci_dev *pci_dev)
{
- int i;
- struct Scsi_Host *sh;
- ips_ha_t *ha;
+ struct Scsi_Host *sh = pci_get_drvdata(pci_dev);
- for (i = 0; i < IPS_MAX_ADAPTERS; i++) {
- ha = ips_ha[i];
- if (ha) {
- if ((pci_dev->bus->number == ha->pcidev->bus->number) &&
- (pci_dev->devfn == ha->pcidev->devfn)) {
- sh = ips_sh[i];
- ips_release(sh);
- }
- }
- }
+ pci_set_drvdata(pci_dev, NULL);
+
+ ips_release(sh);
+
+ pci_release_regions(pci_dev);
+ pci_disable_device(pci_dev);
}
//
@@ -6946,12 +6934,17 @@ module_exit(ips_module_exit);
static int __devinit
ips_insert_device(struct pci_dev *pci_dev, const struct pci_device_id *ent)
{
- int uninitialized_var(index);
+ int index = -1;
int rc;
METHOD_TRACE("ips_insert_device", 1);
- if (pci_enable_device(pci_dev))
- return -1;
+ rc = pci_enable_device(pci_dev);
+ if (rc)
+ return rc;
+
+ rc = pci_request_regions(pci_dev, "ips");
+ if (rc)
+ goto err_out;
rc = ips_init_phase1(pci_dev, &index);
if (rc == SUCCESS)
@@ -6967,6 +6960,19 @@ ips_insert_device(struct pci_dev *pci_dev, const struct
pci_device_id *ent)
ips_num_controllers++;
ips_next_controller = ips_num_controllers;
+
+ if (rc < 0) {
+ rc = -ENODEV;
+ goto err_out_regions;
+ }
+
+ pci_set_drvdata(pci_dev, ips_sh[index]);
+ return 0;
+
+err_out_regions:
+ pci_release_regions(pci_dev);
+err_out:
+ pci_disable_device(pci_dev);
return rc;
}
@@ -6999,7 +7005,7 @@ ips_init_phase1(struct pci_dev *pci_dev, int *indexPtr)
METHOD_TRACE("ips_init_phase1", 1);
index = IPS_MAX_ADAPTERS;
for (j = 0; j < IPS_MAX_ADAPTERS; j++) {
- if (ips_ha[j] == 0) {
+ if (ips_ha[j] == NULL) {
index = j;
break;
}
@@ -7036,32 +7042,17 @@ ips_init_phase1(struct pci_dev *pci_dev, int *indexPtr)
uint32_t base;
uint32_t offs;
- if (!request_mem_region(mem_addr, mem_len, "ips")) {
- IPS_PRINTK(KERN_WARNING, pci_dev,
- "Couldn't allocate IO Memory space %x len
%d.\n",
- mem_addr, mem_len);
- return -1;
- }
-
base = mem_addr & PAGE_MASK;
offs = mem_addr - base;
ioremap_ptr = ioremap(base, PAGE_SIZE);
+ if (!ioremap_ptr)
+ return -1;
mem_ptr = ioremap_ptr + offs;
} else {
ioremap_ptr = NULL;
mem_ptr = NULL;
}
- /* setup I/O mapped area (if applicable) */
- if (io_addr) {
- if (!request_region(io_addr, io_len, "ips")) {
- IPS_PRINTK(KERN_WARNING, pci_dev,
- "Couldn't allocate IO space %x len %d.\n",
- io_addr, io_len);
- return -1;
- }
- }
-
/* found a controller */
ha = kzalloc(sizeof (ips_ha_t), GFP_KERNEL);
if (ha == NULL) {
@@ -7070,7 +7061,6 @@ ips_init_phase1(struct pci_dev *pci_dev, int *indexPtr)
[PATCH 1/4] [SCSI] ips: remove ips_ha members that duplicate struct pci_dev members
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
---
drivers/scsi/ips.c | 178
drivers/scsi/ips.h | 20 +++
2 files changed, 91 insertions(+), 107 deletions(-)
diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index 5c5a9b2..595a91a 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -707,7 +707,7 @@ ips_release(struct Scsi_Host *sh)
release_region(ha->io_addr, ha->io_len);
/* free IRQ */
- free_irq(ha->irq, ha);
+ free_irq(ha->pcidev->irq, ha);
scsi_host_put(sh);
@@ -1637,7 +1637,7 @@ ips_make_passthru(ips_ha_t *ha, struct scsi_cmnd *SC,
ips_scb_t *scb, int intr)
return (IPS_FAILURE);
}
- if (ha->device_id == IPS_DEVICEID_COPPERHEAD &&
+ if (ha->pcidev->device == IPS_DEVICEID_COPPERHEAD &&
pt->CoppCP.cmd.flashfw.op_code ==
IPS_CMD_RW_BIOSFW) {
ret = ips_flash_copperhead(ha, pt, scb);
@@ -2021,7 +2021,7 @@ ips_cleanup_passthru(ips_ha_t * ha, ips_scb_t * scb)
pt->ExtendedStatus = scb->extended_status;
pt->AdapterType = ha->ad_type;
- if (ha->device_id == IPS_DEVICEID_COPPERHEAD &&
+ if (ha->pcidev->device == IPS_DEVICEID_COPPERHEAD &&
(scb->cmd.flashfw.op_code == IPS_CMD_DOWNLOAD ||
scb->cmd.flashfw.op_code == IPS_CMD_RW_BIOSFW))
ips_free_flash_copperhead(ha);
@@ -2075,7 +2075,7 @@ ips_host_info(ips_ha_t * ha, char *ptr, off_t offset, int
len)
ha->mem_ptr);
}
- copy_info(&info, "\tIRQ number: %d\n", ha->irq);
+ copy_info(&info, "\tIRQ number: %d\n",
ha->pcidev->irq);
/* For the Next 3 lines Check for Binary 0 at the end and don't include it
if it's there. */
/* That keeps everything happy for "text" operations on the proc file.
*/
@@ -2232,31 +2232,31 @@ ips_identify_controller(ips_ha_t * ha)
{
METHOD_TRACE("ips_identify_controller", 1);
- switch (ha->device_id) {
+ switch (ha->pcidev->device) {
case IPS_DEVICEID_COPPERHEAD:
- if (ha->revision_id <= IPS_REVID_SERVERAID) {
+ if (ha->pcidev->revision <= IPS_REVID_SERVERAID) {
ha->ad_type = IPS_ADTYPE_SERVERAID;
- } else if (ha->revision_id == IPS_REVID_SERVERAID2) {
+ } else if (ha->pcidev->revision == IPS_REVID_SERVERAID2) {
ha->ad_type = IPS_ADTYPE_SERVERAID2;
- } else if (ha->revision_id == IPS_REVID_NAVAJO) {
+ } else if (ha->pcidev->revision == IPS_REVID_NAVAJO) {
ha->ad_type = IPS_ADTYPE_NAVAJO;
- } else if ((ha->revision_id == IPS_REVID_SERVERAID2)
+ } else if ((ha->pcidev->revision == IPS_REVID_SERVERAID2)
&& (ha->slot_num == 0)) {
ha->ad_type = IPS_ADTYPE_KIOWA;
- } else if ((ha->revision_id >= IPS_REVID_CLARINETP1) &&
- (ha->revision_id <= IPS_REVID_CLARINETP3)) {
+ } else if ((ha->pcidev->revision >= IPS_REVID_CLARINETP1) &&
+ (ha->pcidev->revision <= IPS_REVID_CLARINETP3)) {
if (ha->enq->ucMaxPhysicalDevices == 15)
ha->ad_type = IPS_ADTYPE_SERVERAID3L;
else
ha->ad_type = IPS_ADTYPE_SERVERAID3;
- } else if ((ha->revision_id >= IPS_REVID_TROMBONE32) &&
- (ha->revision_id <= IPS_REVID_TROMBONE64)) {
+ } else if ((ha->pcidev->revision >= IPS_REVID_TROMBONE32) &&
+ (ha->pcidev->revision <= IPS_REVID_TROMBONE64)) {
ha->ad_type = IPS_ADTYPE_SERVERAID4H;
}
break;
case IPS_DEVICEID_MORPHEUS:
- switch (ha->subdevice_id) {
+ switch (ha->pcidev->subsystem_device) {
case IPS_SUBDEVICEID_4L:
ha->ad_type = IPS_ADTYPE_SERVERAID4L;
break;
@@ -2285,7 +2285,7 @@ ips_identify_controller(ips_ha_t * ha)
break;
case IPS_DEVICEID_MARCO:
- switch (ha->subdevice_id) {
+ switch (ha->pcidev->subsystem_device) {
case IPS_SUBDEVICEID_6M:
ha->ad_type = IPS_ADTYPE_SERVERAID6M;
break;
@@ -2332,20 +2332,20 @@ ips_get_bios_version(ips_ha_t * ha, int intr)
strncpy(ha->bios_version, " ?", 8);
- if (ha->device_id == IPS_DEVICEID_COPPERHEAD) {
+ if (ha->pcidev->device == IPS_DEVICEID_COPPERHEAD) {
if (IPS_USE_MEMIO(ha)) {
[CFP] 2008 Linux Storage and Filesystem Workshop
We are organizing another filesystem and storage workshop in San Jose next Feb 25 and 26. You can find some great writeups of last year's conference on LWN: http://lwn.net/Articles/226351/ This year we're trying to concentrate on more problem solving sessions, short term projects and joint sessions. You can find all the details on the conference webpages: http://www.usenix.org/events/lsf08/ Soon there will be a link for submitting your position statement, which is basically a note to the organizers that you are interested in attending and which topics you think should be covered. We're also looking for people to lead the discussion around the major topics, so please let us know if you're interested in that. The discussion leaders will have input into the people that get invited and the format of the discussion. Please let [EMAIL PROTECTED] know if there are any questions about the workshop. 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
Re: stex driver panic in kernel 2.6.23
On Wed, 2007-10-24 at 12:17 -0700, Andrew Morton wrote: > On Wed, 24 Oct 2007 11:59:30 -0700 "Ed Lin" <[EMAIL PROTECTED]> wrote: > > > The shared tag issue was not fixed yet. Kernel panic > > happened while running I/O test in kernel 2.6.23 > > (information attached). After applying the patch I posted > > (or the version James modified), panic disappeared. > > Switch back to standard kernel, panic again. > > Did either of those patches get merged in 2.6.24-rc1? No ... Jens did one instead (commit f3da54ba140c6427fa4a32913e1bf406f41b5dda), which now looks like it might not have fixed the issue. 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
Re: stex driver panic in kernel 2.6.23
On Wed, 2007-10-24 at 15:16 -0400, James Bottomley wrote: > On Wed, 2007-10-24 at 11:59 -0700, Ed Lin wrote: > > The shared tag issue was not fixed yet. Kernel panic > > happened while running I/O test in kernel 2.6.23 > > (information attached). After applying the patch I posted > > (or the version James modified), panic disappeared. > > Switch back to standard kernel, panic again. > > Just so we're on the same page, do you have a pointer to the patch? > > I thought the issue was fixed by this patch > > http://marc.info/?l=linux-scsi&m=118968649513338 > > Which Linus said he modified and then committed here: > > http://marc.info/?l=linux-kernel&m=118969824104600 > > However, I have to confess I can't find this patch in the current > kernel. Found it; it's commit f3da54ba140c6427fa4a32913e1bf406f41b5dda. So we still have some problem, even with this patch. 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
Re: stex driver panic in kernel 2.6.23
On Wed, 24 Oct 2007 11:59:30 -0700 "Ed Lin" <[EMAIL PROTECTED]> wrote: > The shared tag issue was not fixed yet. Kernel panic > happened while running I/O test in kernel 2.6.23 > (information attached). After applying the patch I posted > (or the version James modified), panic disappeared. > Switch back to standard kernel, panic again. Did either of those patches get merged in 2.6.24-rc1? - 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: stex driver panic in kernel 2.6.23
On Wed, 2007-10-24 at 11:59 -0700, Ed Lin wrote: > The shared tag issue was not fixed yet. Kernel panic > happened while running I/O test in kernel 2.6.23 > (information attached). After applying the patch I posted > (or the version James modified), panic disappeared. > Switch back to standard kernel, panic again. Just so we're on the same page, do you have a pointer to the patch? I thought the issue was fixed by this patch http://marc.info/?l=linux-scsi&m=118968649513338 Which Linus said he modified and then committed here: http://marc.info/?l=linux-kernel&m=118969824104600 However, I have to confess I can't find this patch in the current kernel. 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
Re: [GIT PATCH] final SCSI pieces for the merge window
On Wed, 24 Oct 2007 08:35:21 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > On Wed, 24 Oct 2007, James Bottomley wrote: > > > > OK, so it's no secret that I'm the last of the subsystem maintainers > > whose day job isn't working on the linux kernel. If you want a full > > time person, who did you have in mind? > > Quite frankly, at least for me personally, what I would rather have (in > general: this is really not at all SCSI-specific in any way, shape, or > form, and not directed at James!) is a less rigid maintainership > structure. > > Let's face it, we are *all* likely to be overworked at different times, > and even when not overworked, it's just the fact that people need to take > a breather etc. And there is seldom - if ever - a very strong argument for > having one person per subsystem. Am OK with all of that, but with a rider. It would make my life even more miserable if there was a (say) git-scsi-tweedledee and a git-scsi-tweedledum. We already have too much out-of-scope code turning up in the git trees and having two trees explicitly modifying the same subsystem would hurt. It's also bad from an engineering POV: there's a decent chance that when combined, they just won't work. So Tweedledee and Tweedledum should both commit to the same tree, please. - 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: [RFC: 2.6 patch] nsp32_restart_autoscsi(): remove error check
On Wed, Oct 24, 2007 at 12:41:12PM -0400, James Bottomley wrote: > On Wed, 2007-10-24 at 18:25 +0200, Adrian Bunk wrote: > > The Coverity checker noted that we'll anyway Oops later when we ran into > > this condition - and the error check didn't prevent that. > > > > Considering that the error condition shouldn't be possible, and we are > > not able to handle it easily, this patch simply removes the pointless > > error check. > > This is the one where I said I don't like the fact that you're removing > the explanatory message that's printed before we crash. if you want to > shut coverity up and stop sending the patch, I'm happy adding a BUG(); > after the nsp32_msg(). Sorry, I missed your answer when resending since it was in a different thread. I'm still not convinced we really need the nsp32_msg() here but you are the maintainer and it's not a big deal anyway A BUG() would IMHO be similarly pointless as the nsp32_msg() at this point and there's no value in changing code only for the sake of the Coverity checker. > James cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [RFC: 2.6 patch] nsp32_restart_autoscsi(): remove error check
On Wed, 2007-10-24 at 18:25 +0200, Adrian Bunk wrote: > The Coverity checker noted that we'll anyway Oops later when we ran into > this condition - and the error check didn't prevent that. > > Considering that the error condition shouldn't be possible, and we are > not able to handle it easily, this patch simply removes the pointless > error check. This is the one where I said I don't like the fact that you're removing the explanatory message that's printed before we crash. if you want to shut coverity up and stop sending the patch, I'm happy adding a BUG(); after the nsp32_msg(). 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
[2.6 patch] 53c7xx removal fallout
This patch does some additional cleanups after the 53c7xx removal. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- Documentation/dontdiff|2 Documentation/m68k/kernel-options.txt | 60 -- Documentation/scsi/00-INDEX |2 Documentation/scsi/ncr53c7xx.txt | 40 - drivers/scsi/.gitignore |2 5 files changed, 106 deletions(-) cc96ec601a55800f9a6bce6e208c7ff1e2f618fd diff --git a/Documentation/dontdiff b/Documentation/dontdiff index f2d658a..c09a96b 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -46,8 +46,6 @@ .mailmap .mm 53c700_d.h -53c7xx_d.h -53c7xx_u.h 53c8xx_d.h* BitKeeper COPYING diff --git a/Documentation/m68k/kernel-options.txt b/Documentation/m68k/kernel-options.txt index 248589e..c93bed6 100644 --- a/Documentation/m68k/kernel-options.txt +++ b/Documentation/m68k/kernel-options.txt @@ -867,66 +867,6 @@ controller and should be autodetected by the driver. An example is the 24 bit region which is specified by a mask of 0x00fe. -5.5) 53c7xx= - - -Syntax: 53c7xx= - -These options affect the A4000T, A4091, WarpEngine, Blizzard 603e+, -and GForce 040/060 SCSI controllers on the Amiga, as well as the -builtin MVME 16x SCSI controller. - -The is a comma-separated list of the sub-options listed -below. - -5.5.1) nosync -- - -Syntax: nosync:0 - - Disables sync negotiation for all devices. Any value after the - colon is acceptable (and has the same effect). - -5.5.2) noasync --- - -[OBSOLETE, REMOVED] - -5.5.3) nodisconnect - -Syntax: nodisconnect:0 - - Disables SCSI disconnects. Any value after the colon is acceptable - (and has the same effect). - -5.5.4) validids - -Syntax: validids:0xNN - - Specify which SCSI ids the driver should pay attention to. This is - a bitmask (i.e. to only pay attention to ID#4, you'd use 0x10). - Default is 0x7f (devices 0-6). - -5.5.5) opthi -5.5.6) optlo - - -Syntax: opthi:M,optlo:N - - Specify options for "hostdata->options". The acceptable definitions - are listed in drivers/scsi/53c7xx.h; the 32 high bits should be in - opthi and the 32 low bits in optlo. They must be specified in the - order opthi=M,optlo=N. - -5.5.7) next - - No argument. Used to separate blocks of keywords when there's more - than one 53c7xx host adapter in the system. - - /* Local Variables: */ /* mode: text */ /* End: */ diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX index aa1f7e9..c2e18e1 100644 --- a/Documentation/scsi/00-INDEX +++ b/Documentation/scsi/00-INDEX @@ -64,8 +64,6 @@ lpfc.txt - LPFC driver release notes megaraid.txt - Common Management Module, shared code handling ioctls for LSI drivers -ncr53c7xx.txt - - info on driver for NCR53c7xx based adapters ncr53c8xx.txt - info on driver for NCR53c8xx based adapters osst.txt diff --git a/Documentation/scsi/ncr53c7xx.txt b/Documentation/scsi/ncr53c7xx.txt deleted file mode 100644 index 91e9552..000 --- a/Documentation/scsi/ncr53c7xx.txt +++ /dev/null @@ -1,40 +0,0 @@ -README for WarpEngine/A4000T/A4091 SCSI kernels. - -Use the following options to disable options in the SCSI driver. - -Using amiboot for example. - -To disable Synchronous Negotiation - - amiboot -k kernel 53c7xx=nosync:0 - -To disable Disconnection - - amiboot -k kernel 53c7xx=nodisconnect:0 - -To disable certain SCSI devices... - - amiboot -k kernel 53c7xx=validids:0x3F - - this allows only device ID's 0,1,2,3,4 and 5 for linux to handle. - (this is a bitmasked field - i.e. each bit represents a SCSI ID) - -These commands work on a per controller basis and use the option 'next' to -move to the next controller in the system. - -e.g. - amiboot -k kernel 53c7xx=nodisconnect:0,next,nosync:0 - - this uses No Disconnection on the first controller and Asynchronous - SCSI on the second controller. - -Known Issues: - -Two devices are known not to function with the default settings of using -synchronous SCSI. These are the Archive Viper 150 Tape Drive and the -SyQuest SQ555 removeable hard drive. When using these devices on a controller -use the 'nosync:0' option. - -Please try these options and post any problems/successes to me. - -Alan Hourihane <[EMAIL PROTECTED]> diff --git a/drivers/scsi/.gitignore b/drivers/scsi/.gitignore index b385af3..c89ae9a 100644 --- a/drivers/scsi/.gitignore +++ b/drivers/scsi/.gitignore @@ -1,3 +1 @@ 53c700_d.h -53c7xx_d.h -53c7xx_u.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
RE: [PATCH -mm 11/11] aacraid: use pci_set_dma_max_seg_size
Not requesting you to test (aacraid), just scoping any effort. The cards in question are the (old) Dell PERC variety that would trigger the need. I will notify our Dell liaison to see what they can do. Sincerely -- Mark Salyzyn > -Original Message- > From: FUJITA Tomonori [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 24, 2007 12:22 PM > To: Salyzyn, Mark > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; > [EMAIL PROTECTED]; AACRAID; [EMAIL PROTECTED] > Subject: RE: [PATCH -mm 11/11] aacraid: use pci_set_dma_max_seg_size > > On Wed, 24 Oct 2007 09:34:23 -0400 > "Salyzyn, Mark" <[EMAIL PROTECTED]> wrote: > > > ACK > > Thanks. > > > Based on the presence of the call. 2.6.22, for instance, > does not have > > this capability... > > > > I did not test this change, just accepting on the > principals. How much > > testing of the change did you do Fujita? > > Unfortunately, I tested only the main component (device and pci > changes) with ppc64 IOMMU. I don't have the other IOMMUs. > > I didn't test the aacraid patch but I guess that I have aacraid in the > workplace so I can test the patch (without the IOMMU chages). > - 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
[2.6 patch] cleanup after APUS removal
After the APUS removal, some code can be removed.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
arch/m68k/amiga/chipram.c |2
drivers/ide/ide-probe.c |8 +--
drivers/isdn/hisax/avm_pci.c|8 ---
drivers/scsi/a2091.c|3 -
drivers/scsi/a3000.c|3 -
drivers/scsi/gvp11.c|3 -
drivers/scsi/oktagon_esp.c |2
drivers/scsi/oktagon_io.S | 72
drivers/video/console/fbcon.c |2
drivers/video/console/fonts.c |4 -
include/asm-m68k/pgtable.h |2
sound/oss/dmasound/Kconfig |2
sound/oss/dmasound/dmasound_paula.c |4 -
13 files changed, 12 insertions(+), 103 deletions(-)
557134975b5c1098cd42a6295670723ecfb35b57
diff --git a/arch/m68k/amiga/chipram.c b/arch/m68k/amiga/chipram.c
index fa015d8..75d4626 100644
--- a/arch/m68k/amiga/chipram.c
+++ b/arch/m68k/amiga/chipram.c
@@ -29,12 +29,10 @@ void __init amiga_chip_init(void)
if (!AMIGAHW_PRESENT(CHIP_RAM))
return;
-#ifndef CONFIG_APUS_FAST_EXCEPT
/*
* Remove the first 4 pages where PPC exception handlers will be located
*/
amiga_chip_size -= 0x4000;
-#endif
chipram_res.end = amiga_chip_size-1;
request_resource(&iomem_resource, &chipram_res);
diff --git a/drivers/ide/ide-probe.c b/drivers/ide/ide-probe.c
index 6a6f2e0..1664e2d 100644
--- a/drivers/ide/ide-probe.c
+++ b/drivers/ide/ide-probe.c
@@ -1062,9 +1062,9 @@ static int init_irq (ide_hwif_t *hwif)
*/
if (!match || match->irq != hwif->irq) {
int sa = IRQF_DISABLED;
-#if defined(__mc68000__) || defined(CONFIG_APUS)
+#if defined(__mc68000__)
sa = IRQF_SHARED;
-#endif /* __mc68000__ || CONFIG_APUS */
+#endif /* __mc68000__ */
if (IDE_CHIPSET_IS_PCI(hwif->chipset)) {
sa = IRQF_SHARED;
@@ -1107,7 +1107,7 @@ static int init_irq (ide_hwif_t *hwif)
spin_unlock_irq(&ide_lock);
}
-#if !defined(__mc68000__) && !defined(CONFIG_APUS)
+#if !defined(__mc68000__)
printk("%s at 0x%03lx-0x%03lx,0x%03lx on irq %d", hwif->name,
hwif->io_ports[IDE_DATA_OFFSET],
hwif->io_ports[IDE_DATA_OFFSET]+7,
@@ -1115,7 +1115,7 @@ static int init_irq (ide_hwif_t *hwif)
#else
printk("%s at 0x%08lx on irq %d", hwif->name,
hwif->io_ports[IDE_DATA_OFFSET], hwif->irq);
-#endif /* __mc68000__ && CONFIG_APUS */
+#endif /* __mc68000__ */
if (match)
printk(" (%sed with %s)",
hwif->sharing_irq ? "shar" : "serializ", match->name);
diff --git a/drivers/isdn/hisax/avm_pci.c b/drivers/isdn/hisax/avm_pci.c
index f8b7978..be55a26 100644
--- a/drivers/isdn/hisax/avm_pci.c
+++ b/drivers/isdn/hisax/avm_pci.c
@@ -263,11 +263,7 @@ hdlc_empty_fifo(struct BCState *bcs, int count)
outl(idx, cs->hw.avm.cfg_reg + 4);
while (cnt < count) {
#ifdef __powerpc__
-#ifdef CONFIG_APUS
- *ptr++ = in_le32((unsigned *)(cs->hw.avm.isac
+_IO_BASE));
-#else
*ptr++ = in_be32((unsigned *)(cs->hw.avm.isac
+_IO_BASE));
-#endif /* CONFIG_APUS */
#else
*ptr++ = inl(cs->hw.avm.isac);
#endif /* __powerpc__ */
@@ -328,11 +324,7 @@ hdlc_fill_fifo(struct BCState *bcs)
if (cs->subtyp == AVM_FRITZ_PCI) {
while (cnthw.avm.isac +_IO_BASE),
*ptr++);
-#else
out_be32((unsigned *)(cs->hw.avm.isac +_IO_BASE),
*ptr++);
-#endif /* CONFIG_APUS */
#else
outl(*ptr++, cs->hw.avm.isac);
#endif /* __powerpc__ */
diff --git a/drivers/scsi/a2091.c b/drivers/scsi/a2091.c
index b7c5385..0d4c593 100644
--- a/drivers/scsi/a2091.c
+++ b/drivers/scsi/a2091.c
@@ -46,8 +46,7 @@ static int dma_setup(struct scsi_cmnd *cmd, int dir_in)
struct Scsi_Host *instance = cmd->device->host;
/* don't allow DMA if the physical address is bad */
-if (addr & A2091_XFER_MASK ||
- (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
+if (addr & A2091_XFER_MASK)
{
HDATA(instance)->dma_bounce_len = (cmd->SCp.this_residual + 511)
& ~0x1ff;
diff --git a/drivers/scsi/a3000.c b/drivers/scsi/a3000.c
index 796f1c4..b3a6c58 100644
--- a/drivers/scsi/a3000.c
+++ b/drivers/scsi/a3000.c
@@ -54,8 +54,7 @@ static int dma_setup(struct scsi_cmnd *cmd, int dir_in)
* end of a physical memory chunk, then allocate a bounce
* buffer
*/
-if (addr & A3000_XFER_MASK ||
- (!dir_in && mm_end_of_chunk (addr, cmd->SCp.this_residual)))
+if (addr & A3000_XFER_MASK)
{
HDATA(a3000_host)->dma_bounce_len = (cmd->SCp.this_residual + 511)
& ~0x1ff;
diff --git a/drivers/scsi/gvp11.c b/drivers/scsi/gvp11.c
index 37741e9..91f8522 100644
--- a/drivers/scsi/gvp11.c
+++ b/drivers/scsi/gvp11.c
@@ -54,8 +54
[PATCH] tgt: convert to use the data buffer accessors
This converts tgt to use the data buffer accessors to reduce the size
of the scsi_data_buffer patch for tgt, which will be merged later.
-
Subject: [PATCH] tgt: convert to use the data buffer accessors
- convert to use the new accessors for the sg lists and the
parameters.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/ibmvscsi/ibmvstgt.c |2 +-
drivers/scsi/libsrp.c| 23 ---
drivers/scsi/scsi_tgt_if.c |2 +-
drivers/scsi/scsi_tgt_lib.c | 11 ++-
4 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvstgt.c b/drivers/scsi/ibmvscsi/ibmvstgt.c
index 82bcab6..d63f11e 100644
--- a/drivers/scsi/ibmvscsi/ibmvstgt.c
+++ b/drivers/scsi/ibmvscsi/ibmvstgt.c
@@ -292,7 +292,7 @@ static int ibmvstgt_cmd_done(struct scsi_cmnd *sc,
dprintk("%p %p %x %u\n", iue, target, vio_iu(iue)->srp.cmd.cdb[0],
cmd->usg_sg);
- if (sc->use_sg)
+ if (scsi_sg_count(sc))
err = srp_transfer_data(sc, &vio_iu(iue)->srp.cmd,
ibmvstgt_rdma, 1, 1);
spin_lock_irqsave(&target->lock, flags);
diff --git a/drivers/scsi/libsrp.c b/drivers/scsi/libsrp.c
index 2ad0a27..5cff020 100644
--- a/drivers/scsi/libsrp.c
+++ b/drivers/scsi/libsrp.c
@@ -192,18 +192,18 @@ static int srp_direct_data(struct scsi_cmnd *sc, struct
srp_direct_buf *md,
if (dma_map) {
iue = (struct iu_entry *) sc->SCp.ptr;
- sg = sc->request_buffer;
+ sg = scsi_sglist(sc);
- dprintk("%p %u %u %d\n", iue, sc->request_bufflen,
- md->len, sc->use_sg);
+ dprintk("%p %u %u %d\n", iue, scsi_bufflen(sc),
+ md->len, scsi_sg_count(sc));
- nsg = dma_map_sg(iue->target->dev, sg, sc->use_sg,
+ nsg = dma_map_sg(iue->target->dev, sg, scsi_sg_count(sc),
DMA_BIDIRECTIONAL);
if (!nsg) {
- printk("fail to map %p %d\n", iue, sc->use_sg);
+ printk("fail to map %p %d\n", iue, scsi_sg_count(sc));
return 0;
}
- len = min(sc->request_bufflen, md->len);
+ len = min(scsi_bufflen(sc), md->len);
} else
len = md->len;
@@ -229,10 +229,10 @@ static int srp_indirect_data(struct scsi_cmnd *sc, struct
srp_cmd *cmd,
if (dma_map || ext_desc) {
iue = (struct iu_entry *) sc->SCp.ptr;
- sg = sc->request_buffer;
+ sg = scsi_sglist(sc);
dprintk("%p %u %u %d %d\n",
- iue, sc->request_bufflen, id->len,
+ iue, scsi_bufflen(sc), id->len,
cmd->data_in_desc_cnt, cmd->data_out_desc_cnt);
}
@@ -268,13 +268,14 @@ static int srp_indirect_data(struct scsi_cmnd *sc, struct
srp_cmd *cmd,
rdma:
if (dma_map) {
- nsg = dma_map_sg(iue->target->dev, sg, sc->use_sg,
DMA_BIDIRECTIONAL);
+ nsg = dma_map_sg(iue->target->dev, sg, scsi_sg_count(sc),
+DMA_BIDIRECTIONAL);
if (!nsg) {
- eprintk("fail to map %p %d\n", iue, sc->use_sg);
+ eprintk("fail to map %p %d\n", iue, scsi_sg_count(sc));
err = -EIO;
goto free_mem;
}
- len = min(sc->request_bufflen, id->len);
+ len = min(scsi_bufflen(sc), id->len);
} else
len = id->len;
diff --git a/drivers/scsi/scsi_tgt_if.c b/drivers/scsi/scsi_tgt_if.c
index 9815a1a..d2557db 100644
--- a/drivers/scsi/scsi_tgt_if.c
+++ b/drivers/scsi/scsi_tgt_if.c
@@ -112,7 +112,7 @@ int scsi_tgt_uspace_send_cmd(struct scsi_cmnd *cmd, u64
itn_id,
memset(&ev, 0, sizeof(ev));
ev.p.cmd_req.host_no = shost->host_no;
ev.p.cmd_req.itn_id = itn_id;
- ev.p.cmd_req.data_len = cmd->request_bufflen;
+ ev.p.cmd_req.data_len = scsi_bufflen(cmd);
memcpy(ev.p.cmd_req.scb, cmd->cmnd, sizeof(ev.p.cmd_req.scb));
memcpy(ev.p.cmd_req.lun, lun, sizeof(ev.p.cmd_req.lun));
ev.p.cmd_req.attribute = cmd->tag;
diff --git a/drivers/scsi/scsi_tgt_lib.c b/drivers/scsi/scsi_tgt_lib.c
index d67ca14..7abef1a 100644
--- a/drivers/scsi/scsi_tgt_lib.c
+++ b/drivers/scsi/scsi_tgt_lib.c
@@ -331,7 +331,7 @@ static void scsi_tgt_cmd_done(struct scsi_cmnd *cmd)
scsi_tgt_uspace_send_status(cmd, tcmd->itn_id, tcmd->tag);
- if (cmd->request_buffer)
+ if (scsi_sglist(cmd))
scsi_free_sgtable(cmd);
queue_work(scsi_tgtd, &tcmd->work);
@@ -365,14 +365,15 @@ static int scsi_tgt_init_cmd(struct scsi_cmnd *cmd, gfp_t
gfp_mask)
cmd->request_bufflen = rq->data_len;
- dprintk("cmd %p cnt %d %lu\n", cmd, cmd->use_sg, rq_data_dir(rq));
-
[RFC: 2.6 patch] nsp32_restart_autoscsi(): remove error check
The Coverity checker noted that we'll anyway Oops later when we ran into
this condition - and the error check didn't prevent that.
Considering that the error condition shouldn't be possible, and we are
not able to handle it easily, this patch simply removes the pointless
error check.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch has been sent on:
- 23 Jul 2007
drivers/scsi/nsp32.c |4
1 file changed, 4 deletions(-)
--- linux-2.6.22-rc6-mm1/drivers/scsi/nsp32.c.old 2007-07-23
19:38:58.0 +0200
+++ linux-2.6.22-rc6-mm1/drivers/scsi/nsp32.c 2007-07-23 20:17:14.0
+0200
@@ -1888,44 +1888,40 @@ static void nsp32_msgout_occur(struct sc
data->msgout_len = 0;
nsp32_dbg(NSP32_DEBUG_MSGOUTOCCUR, "exit");
}
/*
* Restart AutoSCSI
*
* Note: Restarting AutoSCSI needs set:
* SYNC_REG, ACK_WIDTH, SGT_ADR, TRANSFER_CONTROL
*/
static void nsp32_restart_autoscsi(struct scsi_cmnd *SCpnt, unsigned short
command)
{
nsp32_hw_data *data = (nsp32_hw_data *)SCpnt->device->host->hostdata;
unsigned int base = data->BaseAddress;
unsigned short transfer = 0;
nsp32_dbg(NSP32_DEBUG_RESTART, "enter");
- if (data->cur_target == NULL || data->cur_lunt == NULL) {
- nsp32_msg(KERN_ERR, "Target or Lun is invalid");
- }
-
/*
* set SYNC_REG
* Don't set BM_START_ADR before setting this register.
*/
nsp32_write1(base, SYNC_REG, data->cur_target->syncreg);
/*
* set ACKWIDTH
*/
nsp32_write1(base, ACK_WIDTH, data->cur_target->ackwidth);
/*
* set SREQ hazard killer sampling rate
*/
nsp32_write1(base, SREQ_SMPL_RATE, data->cur_target->sample_reg);
/*
* set SGT ADDR (physical address)
*/
nsp32_write4(base, SGT_ADR, data->cur_lunt->sglun_paddr);
-
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
[2.6 patch] scsi/advansys.c: make 3 functions static
This patch makes three needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
ad7c16573cd33555f4136c50fa35d1fb2c3669ca
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index 9dd3952..e316ff2 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -12261,7 +12261,7 @@ static ushort __devinit AdvReadEEPWord(AdvPortAddr
iop_base, int eep_word_addr)
/*
* Write the EEPROM from 'cfg_buf'.
*/
-void __devinit
+static void __devinit
AdvSet3550EEPConfig(AdvPortAddr iop_base, ADVEEP_3550_CONFIG *cfg_buf)
{
ushort *wbuf;
@@ -12328,7 +12328,7 @@ AdvSet3550EEPConfig(AdvPortAddr iop_base,
ADVEEP_3550_CONFIG *cfg_buf)
/*
* Write the EEPROM from 'cfg_buf'.
*/
-void __devinit
+static void __devinit
AdvSet38C0800EEPConfig(AdvPortAddr iop_base, ADVEEP_38C0800_CONFIG *cfg_buf)
{
ushort *wbuf;
@@ -12395,7 +12395,7 @@ AdvSet38C0800EEPConfig(AdvPortAddr iop_base,
ADVEEP_38C0800_CONFIG *cfg_buf)
/*
* Write the EEPROM from 'cfg_buf'.
*/
-void __devinit
+static void __devinit
AdvSet38C1600EEPConfig(AdvPortAddr iop_base, ADVEEP_38C1600_CONFIG *cfg_buf)
{
ushort *wbuf;
-
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
Subject: [PATCH] tgt: use KMEM_CACHE
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_tgt_lib.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/scsi_tgt_lib.c b/drivers/scsi/scsi_tgt_lib.c
index deea3cd..7abef1a 100644
--- a/drivers/scsi/scsi_tgt_lib.c
+++ b/drivers/scsi/scsi_tgt_lib.c
@@ -641,9 +641,7 @@ static int __init scsi_tgt_init(void)
{
int err;
- scsi_tgt_cmd_cache = kmem_cache_create("scsi_tgt_cmd",
- sizeof(struct scsi_tgt_cmd),
- 0, 0, NULL);
+ scsi_tgt_cmd_cache = KMEM_CACHE(scsi_tgt_cmd, 0);
if (!scsi_tgt_cmd_cache)
return -ENOMEM;
--
1.5.2.4
-
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 -mm 11/11] aacraid: use pci_set_dma_max_seg_size
On Wed, 24 Oct 2007 09:34:23 -0400 "Salyzyn, Mark" <[EMAIL PROTECTED]> wrote: > ACK Thanks. > Based on the presence of the call. 2.6.22, for instance, does not have > this capability... > > I did not test this change, just accepting on the principals. How much > testing of the change did you do Fujita? Unfortunately, I tested only the main component (device and pci changes) with ppc64 IOMMU. I don't have the other IOMMUs. I didn't test the aacraid patch but I guess that I have aacraid in the workplace so I can test the patch (without the IOMMU chages). - 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: [GIT PATCH] final SCSI pieces for the merge window
On Wed, 24 Oct 2007, James Bottomley wrote: > > OK, so it's no secret that I'm the last of the subsystem maintainers > whose day job isn't working on the linux kernel. If you want a full > time person, who did you have in mind? Quite frankly, at least for me personally, what I would rather have (in general: this is really not at all SCSI-specific in any way, shape, or form, and not directed at James!) is a less rigid maintainership structure. Let's face it, we are *all* likely to be overworked at different times, and even when not overworked, it's just the fact that people need to take a breather etc. And there is seldom - if ever - a very strong argument for having one person per subsystem. I think git is excellent for trying to spreading the "joy" of maintainership, but even without something like that, I think it's much better to try to find people you can trust, rather than strict maintainership boundaries. For example, Andrew certainly seems to be very productive as a kernel maintainer, and it has nothing to do with git, and everything to do with trust. So I'd rather have less recriminations about "xyz is holding up abc", and have people more open to just trying to help out even across strict borders. And I don't mean that in a "two fighting people" kind of way where there are two or more people who maintain things _despite_ each other, but more in a "Hey we know each other, and we trust each other, and no, we won't guarantee that we always agree, but we can work on things, and if it turns out that one person merged somethign that the other person _really_ doesn't like, we'll revert it and/or work it out some other way". I've personally always been against _strict_ maintainer lines, so I've always taken stuff "past" the maintainer anyway (and sometimes maintainers have complained, because they feel like they "own" their subsystem, and I either tell them to stuff it, or say "my bad", depending on whether they had a valid _technical_ complaint or not). So rather than getting into a pissing match of "ok, who would be the best maintainer", I'd much *much* prefer to take this as another "we really don't need or even _want_ to have strict maintainer rules" opportunity. Now, the most important part here is the trust part. I need to be able to trust maintainers, but when you have multiple people in the same "box", those people need to trust each other even more than usual, because you *are* going to get disagreements. And the only way it can work is if you acknowledge that disagreements will happen, and that any situation is not a "my way or the highway" kind of thing - the trust also implies a certain give and take. And this really *is* an issue that cuts across subsystem boundaries. Anybody who thinks that SCSI is "unique" in this kind of issues is sadly mistaken. We've had the exact same thing come up in every single subsystem over time, and at every single level of maintainership (from individual drivers all the way right up to me) over time. So I *really* don't want to throw any stones in a glass house here. Quite the reverse. I'd like to get rid of some of the glass, and replace it with padding. Because you all know we'd all fit better in a padded room than a glass house.. Are there any such people that think there s a sufficient mutual trust with James that you think a blurring of maintainership lines could work out? Or in any other subsystem, for that matter? Hmm? Linus - 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: [GIT PATCH] final SCSI pieces for the merge window
On Wed, 24 Oct 2007 09:28:10 -0400 James Bottomley <[EMAIL PROTECTED]> wrote: > OK, so it's no secret that I'm the last of the subsystem maintainers > whose day job isn't working on the linux kernel. For the record, lots of subsystem maintainers are privateers. I am not aware that these guys: Mauro Chehab, Dmitry Torokhov, Sam Ravnborg, Pierre Ossman, Mark Hoffman, Thomas Gleixner, David Airlie, Richard Purdie, Peter Anvin, Kyle McMartin, Francois Romieu, Artem Bityutskiy, Erez Zadok, Josef Sipek, Anton Altaparmakov, Eric Van Hensbergen, Latchesar Ionkov, Wim Van Sebroeck, Antonino Daplas. do it with any compensation. - 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 -mm 09/11] call blk_queue_segment_boundary in __scsi_alloc_queue
On Wed, 24 Oct 2007 16:28:11 +0200
Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 24 2007, FUJITA Tomonori wrote:
> > On Wed, 24 Oct 2007 07:39:16 -0400
> > Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> > > FUJITA Tomonori wrote:
> > > > request_queue and device struct must have the same value of a segment
> > > > size limit. This patch adds blk_queue_segment_boundary in
> > > > __scsi_alloc_queue so LLDs don't need to call both
> > > > blk_queue_segment_boundary and set_dma_max_seg_size. A LLD can change
> > > > the default value (64KB) can call device_dma_parameters accessors like
> > > > pci_set_dma_max_seg_size when allocating scsi_host.
> > > >
> > > > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> > > > ---
> > > > drivers/scsi/scsi_lib.c |3 +++
> > > > 1 files changed, 3 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > > > index 61fdaf0..23a30ab 100644
> > > > --- a/drivers/scsi/scsi_lib.c
> > > > +++ b/drivers/scsi/scsi_lib.c
> > > > @@ -1645,6 +1645,7 @@ struct request_queue *__scsi_alloc_queue(struct
> > > > Scsi_Host *shost,
> > > > request_fn_proc *request_fn)
> > > > {
> > > > struct request_queue *q;
> > > > + struct device *dev = shost->shost_gendev.parent;
> > > >
> > > > q = blk_init_queue(request_fn, NULL);
> > > > if (!q)
> > > > @@ -1673,6 +1674,8 @@ struct request_queue *__scsi_alloc_queue(struct
> > > > Scsi_Host *shost,
> > > > blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
> > > > blk_queue_segment_boundary(q, shost->dma_boundary);
> > > >
> > > > + blk_queue_max_segment_size(q, dma_get_max_seg_size(dev));
> > > > +
> > >
> > > it would be nice to have something more general that's useable in
> > > drivers/block/sx8.c (for example), something like
> > >
> > > static inline void
> > > dev_blk_associate(struct device *dev, request_queue *q)
> > > {
> > > blk_queue_max_segment_size(q,
> > > dma_get_max_seg_size(dev));
> > > }
> > >
> > > still, I will ACK the above patch (#9) in case you wish that to become a
> > > future cleanup, or others dislike this suggestion
> >
> > Yeah, I thought about something like that. But I can't find many
> > non-scsi drivers (ide, sx8, mmc/card/, anymore?) doing dma and having
> > the restrictions so I just call blk_queue_max_segment_size here.
> >
> > Either is ok with me. I'll modify the patch if Jens prefers such
> > function. Jens?
>
> If there's a use for it, sure.
Ok, I'll update the patch and add some patches for non-scsi drivers.
-
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 -mm 09/11] call blk_queue_segment_boundary in __scsi_alloc_queue
FUJITA Tomonori wrote:
On Wed, 24 Oct 2007 07:39:16 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
FUJITA Tomonori wrote:
request_queue and device struct must have the same value of a segment
size limit. This patch adds blk_queue_segment_boundary in
__scsi_alloc_queue so LLDs don't need to call both
blk_queue_segment_boundary and set_dma_max_seg_size. A LLD can change
the default value (64KB) can call device_dma_parameters accessors like
pci_set_dma_max_seg_size when allocating scsi_host.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_lib.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 61fdaf0..23a30ab 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1645,6 +1645,7 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
request_fn_proc *request_fn)
{
struct request_queue *q;
+ struct device *dev = shost->shost_gendev.parent;
q = blk_init_queue(request_fn, NULL);
if (!q)
@@ -1673,6 +1674,8 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
blk_queue_segment_boundary(q, shost->dma_boundary);
+ blk_queue_max_segment_size(q, dma_get_max_seg_size(dev));
+
it would be nice to have something more general that's useable in
drivers/block/sx8.c (for example), something like
static inline void
dev_blk_associate(struct device *dev, request_queue *q)
{
blk_queue_max_segment_size(q,
dma_get_max_seg_size(dev));
}
still, I will ACK the above patch (#9) in case you wish that to become a
future cleanup, or others dislike this suggestion
Yeah, I thought about something like that. But I can't find many
non-scsi drivers (ide, sx8, mmc/card/, anymore?) doing dma and having
the restrictions so I just call blk_queue_max_segment_size here.
My main idea was that request_queue will eventually want to know struct
device details directly, if it can.
Either is ok with me. I'll modify the patch if Jens prefers such
function. Jens?
I have no strong opinion... it was just a thought.
Jeff
-
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 -mm 0/11] fix iommu sg merging problem
On Wed, 24 Oct 2007 07:40:50 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > FUJITA Tomonori wrote: > > IOMMUs merges scatter/gather segments without considering a low level > > driver's restrictions. The problem is that IOMMUs can't access to the > > limitations because they are in request_queue. > > > > This patchset introduces a new structure, device_dma_parameters, > > including dma information. A pointer to device_dma_parameters is added > > to struct device. The bus specific structures (like pci_dev) includes > > device_dma_parameters. Low level drivers can use dma_set_max_seg_size > > to tell IOMMUs about the restrictions. > > > > We can move more dma stuff in struct device (like dma_mask) to struct > > device_dma_parameters later (needs some cleanups before that). > > > > This includes patches for all the IOMMUs that could merge sg (x86_64, > > ppc, IA64, alpha, sparc64, and parisc) though only the ppc patch was > > tested. The patches for other IOMMUs are only compile tested. > > > > Thanks to everyone for the comments on the previous submission > > to linux-scsi. > > > > This is against 2.6.24-rc1. The same patchset is also available: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git > > iommu-sg-fixes > > Are you interested in collecting patches to libata that eliminate the > hand-rolled S/G splitting? e.g. now ata_fill_sg() and mv_fill_sg() can > be made much more efficient. Yeah, but ATA has the segment boundary limit too. It's much more tricky than the segment size limit. It makes the IOMMU free space managemet complicated. > Again, thanks for doing this! It's been needed for a long time. My pleasure. - 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: [GIT PATCH] final SCSI pieces for the merge window
Douglas Gilbert wrote: Jeff Garzik wrote: James Bottomley wrote: On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote: James Bottomley wrote: This should be the final SCSI updates; it's mainly just a few accessor completion updates and two driver merges (sym2 and qla2xxx) we also secured DaveM's agreement to remove fcal/fc4, which explains the high removal line count. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git I guess I have the go-ahead to merge the end-CDROM-polling async notification work you've been repeatedly ignoring? I haven't been ignoring it ... it just needs quite a bit of work; the best way to accelerate it seems to be simply to do it (add the supported/trigger event bitmasks and expand the infrastructure). I just haven't had the time within the merge window. James, things cannot get bottlenecked like this. You have had MONTHS to say something like this. The code was ready BEFORE the merge window. I really think you have the knowledge to be SCSI maintainer, but not the time. Jeff, If only I had a dollar (Canadian unit please) for each day some of my libata patches were queued up to you before you accepted them. Remember MODE SELECT ... You're darned right, I've screwed up in the past. Sat on stuff "until I get time to rewrite it" and that sort of thing. My colleagues give me lumps for it too :) We talked about this issue at the Kernel Summit -- collectively we need to stop holding on to useful, working stuff for months on end. It serves nobody. We have to rediscover our roots: "release early, release often" Jeff - 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: [GIT PATCH] final SCSI pieces for the merge window
James Bottomley wrote: On Tue, 2007-10-23 at 18:06 -0400, Jeff Garzik wrote: James Bottomley wrote: On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote: James Bottomley wrote: This should be the final SCSI updates; it's mainly just a few accessor completion updates and two driver merges (sym2 and qla2xxx) we also secured DaveM's agreement to remove fcal/fc4, which explains the high removal line count. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git I guess I have the go-ahead to merge the end-CDROM-polling async notification work you've been repeatedly ignoring? I haven't been ignoring it ... it just needs quite a bit of work; the best way to accelerate it seems to be simply to do it (add the supported/trigger event bitmasks and expand the infrastructure). I just haven't had the time within the merge window. James, things cannot get bottlenecked like this. You have had MONTHS to say something like this. The code was ready BEFORE the merge window. The patch in question is an interface to user space. The problem with those is that you can't put them in and refine them because the user visible interface changes when you do that. Post August, this user space interface patch has received (a) silence or (b) this vague general worry about changing user space interfaces. All the while it is working and was revised according to comment at the time. At some point you gotta stop waiting for perfection or that mythical "when I get a round tuit" and actually DO something. When I see the new patch to end CD-ROM polling grow moldy for two months while rewrites to ancient SCSI drivers go in, I throw up my hands in wonderment. Poor Andrew is constantly resending -mm patches to you -- some stick, some vanish into the ether without comment. For months. I really think you have the knowledge to be SCSI maintainer, but not the time. The pot is calling the kettle black here, since libata was supposed to have moved out of SCSI about three years ago by helping us move the shared elements up to block. As far as I can tell, the only progress we've made in this area is me adding the odd API shift. You're talking about long term directions, I'm talking about actually getting day-to-day work accomplished. Jeff - 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 -mm 09/11] call blk_queue_segment_boundary in __scsi_alloc_queue
On Wed, Oct 24 2007, FUJITA Tomonori wrote:
> On Wed, 24 Oct 2007 07:39:16 -0400
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > FUJITA Tomonori wrote:
> > > request_queue and device struct must have the same value of a segment
> > > size limit. This patch adds blk_queue_segment_boundary in
> > > __scsi_alloc_queue so LLDs don't need to call both
> > > blk_queue_segment_boundary and set_dma_max_seg_size. A LLD can change
> > > the default value (64KB) can call device_dma_parameters accessors like
> > > pci_set_dma_max_seg_size when allocating scsi_host.
> > >
> > > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> > > ---
> > > drivers/scsi/scsi_lib.c |3 +++
> > > 1 files changed, 3 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > > index 61fdaf0..23a30ab 100644
> > > --- a/drivers/scsi/scsi_lib.c
> > > +++ b/drivers/scsi/scsi_lib.c
> > > @@ -1645,6 +1645,7 @@ struct request_queue *__scsi_alloc_queue(struct
> > > Scsi_Host *shost,
> > >request_fn_proc *request_fn)
> > > {
> > > struct request_queue *q;
> > > + struct device *dev = shost->shost_gendev.parent;
> > >
> > > q = blk_init_queue(request_fn, NULL);
> > > if (!q)
> > > @@ -1673,6 +1674,8 @@ struct request_queue *__scsi_alloc_queue(struct
> > > Scsi_Host *shost,
> > > blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
> > > blk_queue_segment_boundary(q, shost->dma_boundary);
> > >
> > > + blk_queue_max_segment_size(q, dma_get_max_seg_size(dev));
> > > +
> >
> > it would be nice to have something more general that's useable in
> > drivers/block/sx8.c (for example), something like
> >
> > static inline void
> > dev_blk_associate(struct device *dev, request_queue *q)
> > {
> > blk_queue_max_segment_size(q,
> > dma_get_max_seg_size(dev));
> > }
> >
> > still, I will ACK the above patch (#9) in case you wish that to become a
> > future cleanup, or others dislike this suggestion
>
> Yeah, I thought about something like that. But I can't find many
> non-scsi drivers (ide, sx8, mmc/card/, anymore?) doing dma and having
> the restrictions so I just call blk_queue_max_segment_size here.
>
> Either is ok with me. I'll modify the patch if Jens prefers such
> function. Jens?
If there's a use for it, sure.
--
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: [GIT PATCH] final SCSI pieces for the merge window
On Wed, Oct 24, 2007 at 09:28:10AM -0400, James Bottomley wrote: > OK, so it's no secret that I'm the last of the subsystem maintainers > whose day job isn't working on the linux kernel. If you want a full > time person, who did you have in mind? I'm willing to take on the role of scsi git-monkey. Alternatively, we could split the scsi maintainer role the same way that Dave and Jeff do for net where Dave handles the core and Jeff handles the drivers. Or we can negotiate some other arrangement. -- Intel are signing my paycheques ... these opinions are still mine "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 -mm 09/11] call blk_queue_segment_boundary in __scsi_alloc_queue
On Wed, 24 Oct 2007 07:39:16 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> FUJITA Tomonori wrote:
> > request_queue and device struct must have the same value of a segment
> > size limit. This patch adds blk_queue_segment_boundary in
> > __scsi_alloc_queue so LLDs don't need to call both
> > blk_queue_segment_boundary and set_dma_max_seg_size. A LLD can change
> > the default value (64KB) can call device_dma_parameters accessors like
> > pci_set_dma_max_seg_size when allocating scsi_host.
> >
> > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> > ---
> > drivers/scsi/scsi_lib.c |3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> > index 61fdaf0..23a30ab 100644
> > --- a/drivers/scsi/scsi_lib.c
> > +++ b/drivers/scsi/scsi_lib.c
> > @@ -1645,6 +1645,7 @@ struct request_queue *__scsi_alloc_queue(struct
> > Scsi_Host *shost,
> > request_fn_proc *request_fn)
> > {
> > struct request_queue *q;
> > + struct device *dev = shost->shost_gendev.parent;
> >
> > q = blk_init_queue(request_fn, NULL);
> > if (!q)
> > @@ -1673,6 +1674,8 @@ struct request_queue *__scsi_alloc_queue(struct
> > Scsi_Host *shost,
> > blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
> > blk_queue_segment_boundary(q, shost->dma_boundary);
> >
> > + blk_queue_max_segment_size(q, dma_get_max_seg_size(dev));
> > +
>
> it would be nice to have something more general that's useable in
> drivers/block/sx8.c (for example), something like
>
> static inline void
> dev_blk_associate(struct device *dev, request_queue *q)
> {
> blk_queue_max_segment_size(q,
> dma_get_max_seg_size(dev));
> }
>
> still, I will ACK the above patch (#9) in case you wish that to become a
> future cleanup, or others dislike this suggestion
Yeah, I thought about something like that. But I can't find many
non-scsi drivers (ide, sx8, mmc/card/, anymore?) doing dma and having
the restrictions so I just call blk_queue_max_segment_size here.
Either is ok with me. I'll modify the patch if Jens prefers such
function. Jens?
-
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 3/3] faster workaround
On Tue, 2007-10-23 at 17:08 +0900, Tejun Heo wrote: > Jeff Garzik wrote: > > Alan Cox wrote: > >>> 2) Once we identified, over time, the set of drives affected by this > >>> 3112 quirk (aka drives that didn't fully comply to SATA spec), the > >>> debugging of corruption cases largely shifted to the standard > >>> routine: update the BIOS, replace the > >>> cables/RAM/power/mainboard/slot/etc. to be certain of problem location. > >> > >> Except for the continued series of later SI + Nvidia chipset (mostly) > >> pattern which seems unanswered but also being later chips I assume > >> unrelated to this problem. > > > > The SIL_FLAG_MOD15WRITE flag is set in sil_port_info[] is set according > > to the best info we have from SiI, which indicates that 3114 and 3512 do > > not have the same problem as the 3112. > > I don't think this data corruption problem w/ sil3114 is related to > m15w. m15w workaround slows down things quite a bit and is likely to > hide problems on PCI bus side. There are reports of data corruption > with 3114 on nvidia (most common), via and now amd chipsets. There's > one on intel too but IIRC wasn't too definite. err wait, the motherboard I am having is also via based. however the m15w workaround just slowed down everything but the problem still appeared. also to be sure that it is really some problem related to the particular seagate drive vs. sil3114 I created a 200G file of zeros on one of the known to work seagates. and indeed it was all zeros... > According to a user, freebsd didn't have data corruption problem on the > same hardware. I copied PCI FIFO setup code (ours is broken BTW) but it > didn't fix the problem. > > I'll try to reproduce the problem locally and hunt it down. Thanks in advance... Soeren - 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 -mm 02/11] PCI: add device_dma_parameters support
On Wed, 24 Oct 2007 07:34:07 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > FUJITA Tomonori wrote: > > index 463a5a9..54edea2 100644 > > --- a/drivers/pci/probe.c > > +++ b/drivers/pci/probe.c > > @@ -985,8 +985,11 @@ void pci_device_add(struct pci_dev *dev, struct > > pci_bus *bus) > > > > set_dev_node(&dev->dev, pcibus_to_node(bus)); > > dev->dev.dma_mask = &dev->dma_mask; > > + dev->dev.dma_parms = &dev->dma_parms; > > dev->dev.coherent_dma_mask = 0xull; > > > > + pci_set_dma_max_seg_size(dev, 65536); > > this should check the return value of pci_set_dma_max_seg_size(), and do > something useful. > > ACK everything else Thanks. I wasn't sure about what to do. Should pci_device_add fail in case of pci_set_dma_max_seg_size failure or just should we print warning? - 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: Target mode support for qlogic chipsets isp2422/2432/5422/5432
Matthew Jacob wrote: > Hey- this is great stuff. This means I can finally give up on my stuff > for linux now that there's some better and more integral stuff in > place. Woo Hoo! Thanks for the comment. Hopefully, you haven't gone too far with this. I will post the progress, soon. Thank you, Seokmann - 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 -mm 11/11] aacraid: use pci_set_dma_max_seg_size
Jeff Garzik [mailto:[EMAIL PROTECTED] writes: > is this needed, given that the default is already 65536? Apparently so, as we had to add it in the past, mainly because the feature to limit was not part of the SCSI layer when the original limit code was added. At that time it replaced a complicated sg breakup algorithm. Does your statement guarantee that the default will not change to a large value? If not, then we need to enforce it in perpetuity... Sincerely -- Mark Salyzyn - 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 -mm 11/11] aacraid: use pci_set_dma_max_seg_size
ACK
Based on the presence of the call. 2.6.22, for instance, does not have
this capability...
I did not test this change, just accepting on the principals. How much
testing of the change did you do Fujita?
Sincerely -- Mark Salyzyn
> -Original Message-
> From: FUJITA Tomonori [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, October 24, 2007 6:49 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org;
> [EMAIL PROTECTED]; AACRAID; [EMAIL PROTECTED]
> Subject: [PATCH -mm 11/11] aacraid: use pci_set_dma_max_seg_size
>
> This sets the segment size limit properly via pci_set_dma_max_seg_size
> and remove blk_queue_max_segment_size because scsi-ml calls it.
>
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> ---
> drivers/scsi/aacraid/linit.c |9 ++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/aacraid/linit.c
> b/drivers/scsi/aacraid/linit.c
> index 038980b..04d6a65 100644
> --- a/drivers/scsi/aacraid/linit.c
> +++ b/drivers/scsi/aacraid/linit.c
> @@ -435,9 +435,6 @@ static int aac_slave_configure(struct
> scsi_device *sdev)
> else if (depth < 2)
> depth = 2;
> scsi_adjust_queue_depth(sdev, MSG_ORDERED_TAG, depth);
> - if (!(((struct aac_dev
> *)host->hostdata)->adapter_info.options &
> - AAC_OPT_NEW_COMM))
> -
> blk_queue_max_segment_size(sdev->request_queue, 65536);
> } else
> scsi_adjust_queue_depth(sdev, 0, 1);
>
> @@ -1045,6 +1042,12 @@ static int __devinit
> aac_probe_one(struct pci_dev *pdev,
> if (error < 0)
> goto out_deinit;
>
> + if (!(aac->adapter_info.options & AAC_OPT_NEW_COMM)) {
> + error = pci_set_dma_max_seg_size(pdev, 65536);
> + if (error)
> + goto out_deinit;
> + }
> +
> /*
>* Lets override negotiations and drop the maximum SG
> limit to 34
>*/
> --
> 1.5.2.4
>
-
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: [GIT PATCH] final SCSI pieces for the merge window
On Tue, 2007-10-23 at 15:36 -0700, David Miller wrote: > From: Jeff Garzik <[EMAIL PROTECTED]> > Date: Tue, 23 Oct 2007 18:06:51 -0400 > > > James Bottomley wrote: > > > On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote: > > >> James Bottomley wrote: > > >>> This should be the final SCSI updates; it's mainly just a few accessor > > >>> completion updates and two driver merges (sym2 and qla2xxx) we also > > >>> secured DaveM's agreement to remove fcal/fc4, which explains the high > > >>> removal line count. > > >>> > > >>> The patch is available here: > > >>> > > >>> master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git > > >> I guess I have the go-ahead to merge the end-CDROM-polling async > > >> notification work you've been repeatedly ignoring? > > > > > > I haven't been ignoring it ... it just needs quite a bit of work; the > > > best way to accelerate it seems to be simply to do it (add the > > > supported/trigger event bitmasks and expand the infrastructure). I just > > > haven't had the time within the merge window. > > > > James, things cannot get bottlenecked like this. You have had MONTHS to > > say something like this. The code was ready BEFORE the merge window. > > > > I really think you have the knowledge to be SCSI maintainer, but not the > > time. > > Unfortunately, I think this is an important point. > > Developers depend strongly upon a subsystem maintainer to > "make time" for these things so that work integration does > not get delayed past the merge window if at all possible. > > Not being able to "make time" to do these things is a great > way to lose contributers. > > James, whilst there is no doubt in my mind that skill-wise > you are probably the most capable scsi maintainer, your "lack > of time" is sounding like a broken record and harming the > development process. OK, so it's no secret that I'm the last of the subsystem maintainers whose day job isn't working on the linux kernel. If you want a full time person, who did you have in mind? 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
Re: [PATCH -mm 0/11] fix iommu sg merging problem
On Wed, Oct 24 2007, FUJITA Tomonori wrote: > IOMMUs merges scatter/gather segments without considering a low level > driver's restrictions. The problem is that IOMMUs can't access to the > limitations because they are in request_queue. > > This patchset introduces a new structure, device_dma_parameters, > including dma information. A pointer to device_dma_parameters is added > to struct device. The bus specific structures (like pci_dev) includes > device_dma_parameters. Low level drivers can use dma_set_max_seg_size > to tell IOMMUs about the restrictions. > > We can move more dma stuff in struct device (like dma_mask) to struct > device_dma_parameters later (needs some cleanups before that). > > This includes patches for all the IOMMUs that could merge sg (x86_64, > ppc, IA64, alpha, sparc64, and parisc) though only the ppc patch was > tested. The patches for other IOMMUs are only compile tested. > > Thanks to everyone for the comments on the previous submission > to linux-scsi. > > This is against 2.6.24-rc1. The same patchset is also available: Looks good to me, I think we should get this included sooner rather than later. -- 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: [GIT PATCH] final SCSI pieces for the merge window
On Tue, 2007-10-23 at 18:06 -0400, Jeff Garzik wrote: > James Bottomley wrote: > > On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote: > >> James Bottomley wrote: > >>> This should be the final SCSI updates; it's mainly just a few accessor > >>> completion updates and two driver merges (sym2 and qla2xxx) we also > >>> secured DaveM's agreement to remove fcal/fc4, which explains the high > >>> removal line count. > >>> > >>> The patch is available here: > >>> > >>> master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git > >> I guess I have the go-ahead to merge the end-CDROM-polling async > >> notification work you've been repeatedly ignoring? > > > > I haven't been ignoring it ... it just needs quite a bit of work; the > > best way to accelerate it seems to be simply to do it (add the > > supported/trigger event bitmasks and expand the infrastructure). I just > > haven't had the time within the merge window. > > James, things cannot get bottlenecked like this. You have had MONTHS to > say something like this. The code was ready BEFORE the merge window. The patch in question is an interface to user space. The problem with those is that you can't put them in and refine them because the user visible interface changes when you do that. > I really think you have the knowledge to be SCSI maintainer, but not the > time. The pot is calling the kettle black here, since libata was supposed to have moved out of SCSI about three years ago by helping us move the shared elements up to block. As far as I can tell, the only progress we've made in this area is me adding the odd API shift. 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
Re: [PATCH] scsi/sym53c8xx: Fix a warning in sym_eh_handler
On Wed, 24 Oct 2007 05:25:43 -0600, Matthew Wilcox wrote: > On Wed, Oct 24, 2007 at 11:59:20AM +0200, Jean Delvare wrote: > > In 2.6.24-rc1 I see the following warning: > > drivers/scsi/sym53c8xx_2/sym_glue.c: In function "sym_eh_handler": > > drivers/scsi/sym53c8xx_2/sym_glue.c:612: warning: "io_reset" may be used > > uninitialized in this function > > > > Although gcc is wrong and the code is actually correct, it can easily > > be made more obvious to keep the compiler quiet. > > Which compiler version? I don't see this with 4.2.1. gcc version 4.1.2. -- Jean Delvare - 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 -mm 0/11] fix iommu sg merging problem
FUJITA Tomonori wrote: IOMMUs merges scatter/gather segments without considering a low level driver's restrictions. The problem is that IOMMUs can't access to the limitations because they are in request_queue. This patchset introduces a new structure, device_dma_parameters, including dma information. A pointer to device_dma_parameters is added to struct device. The bus specific structures (like pci_dev) includes device_dma_parameters. Low level drivers can use dma_set_max_seg_size to tell IOMMUs about the restrictions. We can move more dma stuff in struct device (like dma_mask) to struct device_dma_parameters later (needs some cleanups before that). This includes patches for all the IOMMUs that could merge sg (x86_64, ppc, IA64, alpha, sparc64, and parisc) though only the ppc patch was tested. The patches for other IOMMUs are only compile tested. Thanks to everyone for the comments on the previous submission to linux-scsi. This is against 2.6.24-rc1. The same patchset is also available: git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git iommu-sg-fixes Are you interested in collecting patches to libata that eliminate the hand-rolled S/G splitting? e.g. now ata_fill_sg() and mv_fill_sg() can be made much more efficient. Again, thanks for doing this! It's been needed for a long time. Jeff - 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 -mm 10/11] sata_inic162x: use pci_set_dma_max_seg_size
FUJITA Tomonori wrote: This sets the segment size limit properly via pci_set_dma_max_seg_size and remove blk_queue_max_segment_size because scsi-ml calls it. Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> --- drivers/ata/sata_inic162x.c | 25 + 1 files changed, 13 insertions(+), 12 deletions(-) ACK - 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 -mm 09/11] call blk_queue_segment_boundary in __scsi_alloc_queue
FUJITA Tomonori wrote:
request_queue and device struct must have the same value of a segment
size limit. This patch adds blk_queue_segment_boundary in
__scsi_alloc_queue so LLDs don't need to call both
blk_queue_segment_boundary and set_dma_max_seg_size. A LLD can change
the default value (64KB) can call device_dma_parameters accessors like
pci_set_dma_max_seg_size when allocating scsi_host.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_lib.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 61fdaf0..23a30ab 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1645,6 +1645,7 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
request_fn_proc *request_fn)
{
struct request_queue *q;
+ struct device *dev = shost->shost_gendev.parent;
q = blk_init_queue(request_fn, NULL);
if (!q)
@@ -1673,6 +1674,8 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
blk_queue_segment_boundary(q, shost->dma_boundary);
+ blk_queue_max_segment_size(q, dma_get_max_seg_size(dev));
+
it would be nice to have something more general that's useable in
drivers/block/sx8.c (for example), something like
static inline void
dev_blk_associate(struct device *dev, request_queue *q)
{
blk_queue_max_segment_size(q,
dma_get_max_seg_size(dev));
}
still, I will ACK the above patch (#9) in case you wish that to become a
future cleanup, or others dislike this suggestion
-
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 -mm 11/11] aacraid: use pci_set_dma_max_seg_size
On Wed, 24 Oct 2007 07:31:30 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> FUJITA Tomonori wrote:
> > This sets the segment size limit properly via pci_set_dma_max_seg_size
> > and remove blk_queue_max_segment_size because scsi-ml calls it.
> >
> > Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> > ---
> > drivers/scsi/aacraid/linit.c |9 ++---
> > 1 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
> > index 038980b..04d6a65 100644
> > --- a/drivers/scsi/aacraid/linit.c
> > +++ b/drivers/scsi/aacraid/linit.c
> > @@ -435,9 +435,6 @@ static int aac_slave_configure(struct scsi_device *sdev)
> > else if (depth < 2)
> > depth = 2;
> > scsi_adjust_queue_depth(sdev, MSG_ORDERED_TAG, depth);
> > - if (!(((struct aac_dev *)host->hostdata)->adapter_info.options &
> > - AAC_OPT_NEW_COMM))
> > - blk_queue_max_segment_size(sdev->request_queue, 65536);
> > } else
> > scsi_adjust_queue_depth(sdev, 0, 1);
> >
> > @@ -1045,6 +1042,12 @@ static int __devinit aac_probe_one(struct pci_dev
> > *pdev,
> > if (error < 0)
> > goto out_deinit;
> >
> > + if (!(aac->adapter_info.options & AAC_OPT_NEW_COMM)) {
> > + error = pci_set_dma_max_seg_size(pdev, 65536);
> > + if (error)
> > + goto out_deinit;
> > + }
>
>
> is this needed, given that the default is already 65536?
Yeah, but I thought that it would be better to set it explicitly
because 'aac->adapter_info.options & AAC_OPT_NEW_COMM' HBAs looks to
be able to handle larger segments.
-
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 -mm 08/11] parisc: make iommu respect the segment size limits
FUJITA Tomonori wrote: This patch makes iommu respect segment size limits when merging sg lists. Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> --- drivers/parisc/ccio-dma.c |2 +- drivers/parisc/iommu-helpers.h |7 ++- drivers/parisc/sba_iommu.c |2 +- 3 files changed, 8 insertions(+), 3 deletions(-) patches 3-8 look OK - 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 -mm 02/11] PCI: add device_dma_parameters support
FUJITA Tomonori wrote: index 463a5a9..54edea2 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -985,8 +985,11 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus) set_dev_node(&dev->dev, pcibus_to_node(bus)); dev->dev.dma_mask = &dev->dma_mask; + dev->dev.dma_parms = &dev->dma_parms; dev->dev.coherent_dma_mask = 0xull; + pci_set_dma_max_seg_size(dev, 65536); this should check the return value of pci_set_dma_max_seg_size(), and do something useful. ACK everything else - 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 -mm 01/11] add device_dma_parameters structure
FUJITA Tomonori wrote: iommu code merges scatter/gather segments without considering a low level driver's restrictions. The problem is that iommu code can't access to the limitations because they are in request_queue. This patch adds a new structure, device_dma_parameters, including dma information. A pointer to device_dma_parameters is added to struct device. - there are only max_segment_size and segment_boundary_mask there but we'll move more dma stuff in struct device (like dma_mask) to struct device_dma_parameters later. segment_boundary_mask is not supported yet. - new accessors for the dma parameters are added. So we can easily change where to place struct device_dma_parameters in the future. - dma_get_max_seg_size returns 64K if dma_parms in struct device isn't set up properly. 64K is the default max_segment_size in the block layer. Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]> --- include/linux/device.h | 11 +++ include/linux/dma-mapping.h | 15 +++ 2 files changed, 26 insertions(+), 0 deletions(-) ACK - 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 -mm 11/11] aacraid: use pci_set_dma_max_seg_size
FUJITA Tomonori wrote:
This sets the segment size limit properly via pci_set_dma_max_seg_size
and remove blk_queue_max_segment_size because scsi-ml calls it.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/aacraid/linit.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index 038980b..04d6a65 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -435,9 +435,6 @@ static int aac_slave_configure(struct scsi_device *sdev)
else if (depth < 2)
depth = 2;
scsi_adjust_queue_depth(sdev, MSG_ORDERED_TAG, depth);
- if (!(((struct aac_dev *)host->hostdata)->adapter_info.options &
- AAC_OPT_NEW_COMM))
- blk_queue_max_segment_size(sdev->request_queue, 65536);
} else
scsi_adjust_queue_depth(sdev, 0, 1);
@@ -1045,6 +1042,12 @@ static int __devinit aac_probe_one(struct pci_dev *pdev,
if (error < 0)
goto out_deinit;
+ if (!(aac->adapter_info.options & AAC_OPT_NEW_COMM)) {
+ error = pci_set_dma_max_seg_size(pdev, 65536);
+ if (error)
+ goto out_deinit;
+ }
is this needed, given that the default is already 65536?
Jeff
-
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] scsi/sym53c8xx: Fix a warning in sym_eh_handler
On Wed, Oct 24, 2007 at 11:59:20AM +0200, Jean Delvare wrote: > In 2.6.24-rc1 I see the following warning: > drivers/scsi/sym53c8xx_2/sym_glue.c: In function "sym_eh_handler": > drivers/scsi/sym53c8xx_2/sym_glue.c:612: warning: "io_reset" may be used > uninitialized in this function > > Although gcc is wrong and the code is actually correct, it can easily > be made more obvious to keep the compiler quiet. Which compiler version? I don't see this with 4.2.1. -- Intel are signing my paycheques ... these opinions are still mine "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
[PATCH -mm 02/11] PCI: add device_dma_parameters support
This adds struct device_dma_parameters in struct pci_dev and properly
sets up a pointer in struct device.
The default max_segment_size is set to 64K, same to the block layer's
default value.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/pci/pci.c |8
drivers/pci/probe.c |3 +++
include/linux/pci.h |4
3 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 71d561f..de97c2b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1397,6 +1397,14 @@ pci_set_consistent_dma_mask(struct pci_dev *dev, u64
mask)
}
#endif
+#ifndef HAVE_ARCH_PCI_SET_DMA_MAX_SEGMENT_SIZE
+int pci_set_dma_max_seg_size(struct pci_dev *dev, unsigned int size)
+{
+ return dma_set_max_seg_size(&dev->dev, size);
+}
+EXPORT_SYMBOL(pci_set_dma_max_seg_size);
+#endif
+
/**
* pcix_get_max_mmrbc - get PCI-X maximum designed memory read byte count
* @dev: PCI device to query
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 463a5a9..54edea2 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -985,8 +985,11 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus
*bus)
set_dev_node(&dev->dev, pcibus_to_node(bus));
dev->dev.dma_mask = &dev->dma_mask;
+ dev->dev.dma_parms = &dev->dma_parms;
dev->dev.coherent_dma_mask = 0xull;
+ pci_set_dma_max_seg_size(dev, 65536);
+
/* Fix up broken headers */
pci_fixup_device(pci_fixup_header, dev);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 5d2281f..f8cba3b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -152,6 +152,8 @@ struct pci_dev {
this if your device has broken DMA
or supports 64-bit transfers. */
+ struct device_dma_parameters dma_parms;
+
pci_power_t current_state; /* Current operating state. In
ACPI-speak,
this is D0-D3, D0 being fully
functional,
and D3 being off. */
@@ -556,6 +558,7 @@ void pci_intx(struct pci_dev *dev, int enable);
void pci_msi_off(struct pci_dev *dev);
int pci_set_dma_mask(struct pci_dev *dev, u64 mask);
int pci_set_consistent_dma_mask(struct pci_dev *dev, u64 mask);
+int pci_set_dma_max_seg_size(struct pci_dev *dev, unsigned int size);
int pcix_get_max_mmrbc(struct pci_dev *dev);
int pcix_get_mmrbc(struct pci_dev *dev);
int pcix_set_mmrbc(struct pci_dev *dev, int mmrbc);
@@ -744,6 +747,7 @@ static inline void pci_set_master(struct pci_dev *dev) { }
static inline int pci_enable_device(struct pci_dev *dev) { return -EIO; }
static inline void pci_disable_device(struct pci_dev *dev) { }
static inline int pci_set_dma_mask(struct pci_dev *dev, u64 mask) { return
-EIO; }
+static inline int pci_set_dma_max_seg_size(struct pci_dev *dev, unsigned int
size) { return -EIO; }
static inline int pci_assign_resource(struct pci_dev *dev, int i) { return
-EBUSY;}
static inline int __pci_register_driver(struct pci_driver *drv, struct module
*owner) { return 0;}
static inline int pci_register_driver(struct pci_driver *drv) { return 0;}
--
1.5.2.4
-
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 -mm 01/11] add device_dma_parameters structure
iommu code merges scatter/gather segments without considering a low
level driver's restrictions. The problem is that iommu code can't
access to the limitations because they are in request_queue.
This patch adds a new structure, device_dma_parameters, including dma
information. A pointer to device_dma_parameters is added to struct
device.
- there are only max_segment_size and segment_boundary_mask there but
we'll move more dma stuff in struct device (like dma_mask) to struct
device_dma_parameters later. segment_boundary_mask is not supported
yet.
- new accessors for the dma parameters are added. So we can easily
change where to place struct device_dma_parameters in the future.
- dma_get_max_seg_size returns 64K if dma_parms in struct device isn't
set up properly. 64K is the default max_segment_size in the block
layer.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
include/linux/device.h | 11 +++
include/linux/dma-mapping.h | 15 +++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index 2e15822..9eb883f 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -397,6 +397,15 @@ extern int devres_release_group(struct device *dev, void
*id);
extern void *devm_kzalloc(struct device *dev, size_t size, gfp_t gfp);
extern void devm_kfree(struct device *dev, void *p);
+struct device_dma_parameters {
+ /*
+* a low level driver may set these to teach IOMMU code about
+* sg limitations.
+*/
+ unsigned int max_segment_size;
+ unsigned long segment_boundary_mask;
+};
+
struct device {
struct klistklist_children;
struct klist_node knode_parent; /* node in sibling list
*/
@@ -432,6 +441,8 @@ struct device {
64 bit addresses for consistent
allocations such descriptors. */
+ struct device_dma_parameters *dma_parms;
+
struct list_headdma_pools; /* dma pools (if dma'ble) */
struct dma_coherent_mem *dma_mem; /* internal for coherent mem
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 101a2d4..71972ca 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -60,6 +60,21 @@ static inline int is_device_dma_capable(struct device *dev)
extern u64 dma_get_required_mask(struct device *dev);
+static inline unsigned int dma_get_max_seg_size(struct device *dev)
+{
+ return dev->dma_parms ? dev->dma_parms->max_segment_size : 65536;
+}
+
+static inline unsigned int dma_set_max_seg_size(struct device *dev,
+ unsigned int size)
+{
+ if (dev->dma_parms) {
+ dev->dma_parms->max_segment_size = size;
+ return 0;
+ } else
+ return -EIO;
+}
+
/* flags for the coherent memory api */
#defineDMA_MEMORY_MAP 0x01
#define DMA_MEMORY_IO 0x02
--
1.5.2.4
-
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 -mm 04/11] ppc: make iommu respect the segment size limits
This patch makes iommu respect segment size limits when merging sg
lists.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/dma_64.c |2 +-
arch/powerpc/kernel/iommu.c |8 ++--
include/asm-powerpc/iommu.h |2 +-
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
index 14206e3..1806d96 100644
--- a/arch/powerpc/kernel/dma_64.c
+++ b/arch/powerpc/kernel/dma_64.c
@@ -68,7 +68,7 @@ static void dma_iommu_unmap_single(struct device *dev,
dma_addr_t dma_handle,
static int dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
int nelems, enum dma_data_direction direction)
{
- return iommu_map_sg(dev->archdata.dma_data, sglist, nelems,
+ return iommu_map_sg(dev, sglist, nelems,
device_to_mask(dev), direction);
}
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 2d0c9ef..7a5d247 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -270,15 +270,17 @@ static void iommu_free(struct iommu_table *tbl,
dma_addr_t dma_addr,
spin_unlock_irqrestore(&(tbl->it_lock), flags);
}
-int iommu_map_sg(struct iommu_table *tbl, struct scatterlist *sglist,
+int iommu_map_sg(struct device *dev, struct scatterlist *sglist,
int nelems, unsigned long mask,
enum dma_data_direction direction)
{
+ struct iommu_table *tbl = dev->archdata.dma_data;
dma_addr_t dma_next = 0, dma_addr;
unsigned long flags;
struct scatterlist *s, *outs, *segstart;
int outcount, incount, i;
unsigned long handle;
+ unsigned int max_seg_size;
BUG_ON(direction == DMA_NONE);
@@ -297,6 +299,7 @@ int iommu_map_sg(struct iommu_table *tbl, struct
scatterlist *sglist,
spin_lock_irqsave(&(tbl->it_lock), flags);
+ max_seg_size = dma_get_max_seg_size(dev);
for_each_sg(sglist, s, nelems, i) {
unsigned long vaddr, npages, entry, slen;
@@ -338,7 +341,8 @@ int iommu_map_sg(struct iommu_table *tbl, struct
scatterlist *sglist,
/* We cannot merge if:
* - allocated dma_addr isn't contiguous to previous
allocation
*/
- if (novmerge || (dma_addr != dma_next)) {
+ if (novmerge || (dma_addr != dma_next) ||
+ (outs->dma_length + s->length > max_seg_size)) {
/* Can't merge: create a new segment */
segstart = s;
outcount++;
diff --git a/include/asm-powerpc/iommu.h b/include/asm-powerpc/iommu.h
index 4a82fdc..5225f05 100644
--- a/include/asm-powerpc/iommu.h
+++ b/include/asm-powerpc/iommu.h
@@ -80,7 +80,7 @@ extern void iommu_free_table(struct device_node *dn);
extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
int nid);
-extern int iommu_map_sg(struct iommu_table *tbl, struct scatterlist *sglist,
+extern int iommu_map_sg(struct device *dev, struct scatterlist *sglist,
int nelems, unsigned long mask,
enum dma_data_direction direction);
extern void iommu_unmap_sg(struct iommu_table *tbl, struct scatterlist *sglist,
--
1.5.2.4
-
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 -mm 03/11] x86: make pci-gart iommu respect the segment size limits
This patch makes pci-gart iommu respect segment size limits when
merging sg lists.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
arch/x86/kernel/pci-gart_64.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
index c56e9ee..dfe3828 100644
--- a/arch/x86/kernel/pci-gart_64.c
+++ b/arch/x86/kernel/pci-gart_64.c
@@ -384,6 +384,8 @@ static int gart_map_sg(struct device *dev, struct
scatterlist *sg, int nents,
int start;
unsigned long pages = 0;
int need = 0, nextneed;
+ unsigned int seg_size;
+ unsigned int max_seg_size;
struct scatterlist *s, *ps, *start_sg, *sgmap;
if (nents == 0)
@@ -395,6 +397,8 @@ static int gart_map_sg(struct device *dev, struct
scatterlist *sg, int nents,
out = 0;
start = 0;
start_sg = sgmap = sg;
+ seg_size = 0;
+ max_seg_size = dma_get_max_seg_size(dev);
ps = NULL; /* shut up gcc */
for_each_sg(sg, s, nents, i) {
dma_addr_t addr = sg_phys(s);
@@ -408,11 +412,13 @@ static int gart_map_sg(struct device *dev, struct
scatterlist *sg, int nents,
/* Can only merge when the last chunk ends on a page
boundary and the new one doesn't have an offset. */
if (!iommu_merge || !nextneed || !need || s->offset ||
+ (s->length + seg_size > max_seg_size) ||
(ps->offset + ps->length) % PAGE_SIZE) {
if (dma_map_cont(start_sg, i - start, sgmap,
pages, need) < 0)
goto error;
out++;
+ seg_size = 0;
sgmap = sg_next(sgmap);
pages = 0;
start = i;
@@ -420,6 +426,7 @@ static int gart_map_sg(struct device *dev, struct
scatterlist *sg, int nents,
}
}
+ seg_size += s->length;
need = nextneed;
pages += to_pages(s->offset, s->length);
ps = s;
--
1.5.2.4
-
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 -mm 11/11] aacraid: use pci_set_dma_max_seg_size
This sets the segment size limit properly via pci_set_dma_max_seg_size
and remove blk_queue_max_segment_size because scsi-ml calls it.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/aacraid/linit.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/aacraid/linit.c b/drivers/scsi/aacraid/linit.c
index 038980b..04d6a65 100644
--- a/drivers/scsi/aacraid/linit.c
+++ b/drivers/scsi/aacraid/linit.c
@@ -435,9 +435,6 @@ static int aac_slave_configure(struct scsi_device *sdev)
else if (depth < 2)
depth = 2;
scsi_adjust_queue_depth(sdev, MSG_ORDERED_TAG, depth);
- if (!(((struct aac_dev *)host->hostdata)->adapter_info.options &
- AAC_OPT_NEW_COMM))
- blk_queue_max_segment_size(sdev->request_queue, 65536);
} else
scsi_adjust_queue_depth(sdev, 0, 1);
@@ -1045,6 +1042,12 @@ static int __devinit aac_probe_one(struct pci_dev *pdev,
if (error < 0)
goto out_deinit;
+ if (!(aac->adapter_info.options & AAC_OPT_NEW_COMM)) {
+ error = pci_set_dma_max_seg_size(pdev, 65536);
+ if (error)
+ goto out_deinit;
+ }
+
/*
* Lets override negotiations and drop the maximum SG limit to 34
*/
--
1.5.2.4
-
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 -mm 06/11] alpha: make pci_iommu respect the segment size limits
This patch makes pci_iommu respect segment size limits when merging sg
lists.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
arch/alpha/kernel/pci_iommu.c | 24 ++--
include/asm-alpha/pci.h |1 +
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
index 2d00a08..26d3789 100644
--- a/arch/alpha/kernel/pci_iommu.c
+++ b/arch/alpha/kernel/pci_iommu.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -470,22 +471,29 @@ EXPORT_SYMBOL(pci_free_consistent);
#define SG_ENT_PHYS_ADDRESS(SG) __pa(SG_ENT_VIRT_ADDRESS(SG))
static void
-sg_classify(struct scatterlist *sg, struct scatterlist *end, int virt_ok)
+sg_classify(struct device *dev, struct scatterlist *sg, struct scatterlist
*end,
+ int virt_ok)
{
unsigned long next_paddr;
struct scatterlist *leader;
long leader_flag, leader_length;
+ unsigned int max_seg_size;
leader = sg;
leader_flag = 0;
leader_length = leader->length;
next_paddr = SG_ENT_PHYS_ADDRESS(leader) + leader_length;
+ /* we will not marge sg without device. */
+ max_seg_size = dev ? dma_get_max_seg_size(dev) : 0;
for (++sg; sg < end; ++sg) {
unsigned long addr, len;
addr = SG_ENT_PHYS_ADDRESS(sg);
len = sg->length;
+ if (leader_length + len > max_seg_size)
+ goto new_segment;
+
if (next_paddr == addr) {
sg->dma_address = -1;
leader_length += len;
@@ -494,6 +502,7 @@ sg_classify(struct scatterlist *sg, struct scatterlist
*end, int virt_ok)
leader_flag = 1;
leader_length += len;
} else {
+new_segment:
leader->dma_address = leader_flag;
leader->dma_length = leader_length;
leader = sg;
@@ -512,7 +521,7 @@ sg_classify(struct scatterlist *sg, struct scatterlist
*end, int virt_ok)
in the blanks. */
static int
-sg_fill(struct scatterlist *leader, struct scatterlist *end,
+sg_fill(struct device *dev, struct scatterlist *leader, struct scatterlist
*end,
struct scatterlist *out, struct pci_iommu_arena *arena,
dma_addr_t max_dma, int dac_allowed)
{
@@ -562,8 +571,8 @@ sg_fill(struct scatterlist *leader, struct scatterlist *end,
/* Otherwise, break up the remaining virtually contiguous
hunks into individual direct maps and retry. */
- sg_classify(leader, end, 0);
- return sg_fill(leader, end, out, arena, max_dma, dac_allowed);
+ sg_classify(dev, leader, end, 0);
+ return sg_fill(dev, leader, end, out, arena, max_dma,
dac_allowed);
}
out->dma_address = arena->dma_base + dma_ofs*PAGE_SIZE + paddr;
@@ -619,12 +628,15 @@ pci_map_sg(struct pci_dev *pdev, struct scatterlist *sg,
int nents,
struct pci_iommu_arena *arena;
dma_addr_t max_dma;
int dac_allowed;
+ struct device *dev;
if (direction == PCI_DMA_NONE)
BUG();
dac_allowed = pdev ? pci_dac_dma_supported(pdev, pdev->dma_mask) : 0;
+ dev = pdev ? &pdev->dev : NULL;
+
/* Fast path single entry scatterlists. */
if (nents == 1) {
sg->dma_length = sg->length;
@@ -638,7 +650,7 @@ pci_map_sg(struct pci_dev *pdev, struct scatterlist *sg,
int nents,
end = sg + nents;
/* First, prepare information about the entries. */
- sg_classify(sg, end, alpha_mv.mv_pci_tbi != 0);
+ sg_classify(dev, sg, end, alpha_mv.mv_pci_tbi != 0);
/* Second, figure out where we're going to map things. */
if (alpha_mv.mv_pci_tbi) {
@@ -658,7 +670,7 @@ pci_map_sg(struct pci_dev *pdev, struct scatterlist *sg,
int nents,
for (out = sg; sg < end; ++sg) {
if ((int) sg->dma_address < 0)
continue;
- if (sg_fill(sg, end, out, arena, max_dma, dac_allowed) < 0)
+ if (sg_fill(dev, sg, end, out, arena, max_dma, dac_allowed) < 0)
goto error;
out++;
}
diff --git a/include/asm-alpha/pci.h b/include/asm-alpha/pci.h
index 30ee766..d5b10ef 100644
--- a/include/asm-alpha/pci.h
+++ b/include/asm-alpha/pci.h
@@ -4,6 +4,7 @@
#ifdef __KERNEL__
#include
+#include
#include
#include
--
1.5.2.4
-
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 -mm 0/11] fix iommu sg merging problem
IOMMUs merges scatter/gather segments without considering a low level driver's restrictions. The problem is that IOMMUs can't access to the limitations because they are in request_queue. This patchset introduces a new structure, device_dma_parameters, including dma information. A pointer to device_dma_parameters is added to struct device. The bus specific structures (like pci_dev) includes device_dma_parameters. Low level drivers can use dma_set_max_seg_size to tell IOMMUs about the restrictions. We can move more dma stuff in struct device (like dma_mask) to struct device_dma_parameters later (needs some cleanups before that). This includes patches for all the IOMMUs that could merge sg (x86_64, ppc, IA64, alpha, sparc64, and parisc) though only the ppc patch was tested. The patches for other IOMMUs are only compile tested. Thanks to everyone for the comments on the previous submission to linux-scsi. This is against 2.6.24-rc1. The same patchset is also available: git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git iommu-sg-fixes - 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 -mm 08/11] parisc: make iommu respect the segment size limits
This patch makes iommu respect segment size limits when merging sg
lists.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/parisc/ccio-dma.c |2 +-
drivers/parisc/iommu-helpers.h |7 ++-
drivers/parisc/sba_iommu.c |2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/parisc/ccio-dma.c b/drivers/parisc/ccio-dma.c
index 7c60cbd..2ec7db1 100644
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -941,7 +941,7 @@ ccio_map_sg(struct device *dev, struct scatterlist *sglist,
int nents,
** w/o this association, we wouldn't have coherent DMA!
** Access to the virtual address is what forces a two pass algorithm.
*/
- coalesced = iommu_coalesce_chunks(ioc, sglist, nents, ccio_alloc_range);
+ coalesced = iommu_coalesce_chunks(ioc, dev, sglist, nents,
ccio_alloc_range);
/*
** Program the I/O Pdir
diff --git a/drivers/parisc/iommu-helpers.h b/drivers/parisc/iommu-helpers.h
index 0a1f99a..97ba828 100644
--- a/drivers/parisc/iommu-helpers.h
+++ b/drivers/parisc/iommu-helpers.h
@@ -95,12 +95,14 @@ iommu_fill_pdir(struct ioc *ioc, struct scatterlist
*startsg, int nents,
*/
static inline unsigned int
-iommu_coalesce_chunks(struct ioc *ioc, struct scatterlist *startsg, int nents,
+iommu_coalesce_chunks(struct ioc *ioc, struct device *dev,
+ struct scatterlist *startsg, int nents,
int (*iommu_alloc_range)(struct ioc *, size_t))
{
struct scatterlist *contig_sg; /* contig chunk head */
unsigned long dma_offset, dma_len; /* start/len of DMA stream */
unsigned int n_mappings = 0;
+ unsigned int max_seg_size = dma_get_max_seg_size(dev);
while (nents > 0) {
@@ -142,6 +144,9 @@ iommu_coalesce_chunks(struct ioc *ioc, struct scatterlist
*startsg, int nents,
IOVP_SIZE) > DMA_CHUNK_SIZE))
break;
+ if (startsg->length + dma_len > max_seg_size)
+ break;
+
/*
** Next see if we can append the next chunk (i.e.
** it must end on one page and begin on another
diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c
index e527a0e..d06627c 100644
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -946,7 +946,7 @@ sba_map_sg(struct device *dev, struct scatterlist *sglist,
int nents,
** w/o this association, we wouldn't have coherent DMA!
** Access to the virtual address is what forces a two pass algorithm.
*/
- coalesced = iommu_coalesce_chunks(ioc, sglist, nents, sba_alloc_range);
+ coalesced = iommu_coalesce_chunks(ioc, dev, sglist, nents,
sba_alloc_range);
/*
** Program the I/O Pdir
--
1.5.2.4
-
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 -mm 10/11] sata_inic162x: use pci_set_dma_max_seg_size
This sets the segment size limit properly via pci_set_dma_max_seg_size
and remove blk_queue_max_segment_size because scsi-ml calls it.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/ata/sata_inic162x.c | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/ata/sata_inic162x.c b/drivers/ata/sata_inic162x.c
index 08595f3..4f3ba83 100644
--- a/drivers/ata/sata_inic162x.c
+++ b/drivers/ata/sata_inic162x.c
@@ -108,17 +108,6 @@ struct inic_port_priv {
u8 cached_pirq_mask;
};
-static int inic_slave_config(struct scsi_device *sdev)
-{
- /* This controller is braindamaged. dma_boundary is 0x
-* like others but it will lock up the whole machine HARD if
-* 65536 byte PRD entry is fed. Reduce maximum segment size.
-*/
- blk_queue_max_segment_size(sdev->request_queue, 65536 - 512);
-
- return ata_scsi_slave_config(sdev);
-}
-
static struct scsi_host_template inic_sht = {
.module = THIS_MODULE,
.name = DRV_NAME,
@@ -132,7 +121,7 @@ static struct scsi_host_template inic_sht = {
.use_clustering = ATA_SHT_USE_CLUSTERING,
.proc_name = DRV_NAME,
.dma_boundary = ATA_DMA_BOUNDARY,
- .slave_configure= inic_slave_config,
+ .slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
};
@@ -730,6 +719,18 @@ static int inic_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
return rc;
}
+ /*
+* This controller is braindamaged. dma_boundary is 0x
+* like others but it will lock up the whole machine HARD if
+* 65536 byte PRD entry is fed. Reduce maximum segment size.
+*/
+ rc = pci_set_dma_max_seg_size(pdev, 65536 - 512);
+ if (rc) {
+ dev_printk(KERN_ERR, &pdev->dev,
+ "failed to set the maximum segment size.\n");
+ return rc;
+ }
+
rc = init_controller(iomap[MMIO_BAR], hpriv->cached_hctl);
if (rc) {
dev_printk(KERN_ERR, &pdev->dev,
--
1.5.2.4
-
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 -mm 07/11] sparc64: make iommu respect the segment size limits
This patch makes iommu respect segment size limits when merging sg
lists.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
arch/sparc64/kernel/iommu.c|2 +-
arch/sparc64/kernel/iommu_common.c |8 ++--
arch/sparc64/kernel/iommu_common.h |3 ++-
arch/sparc64/kernel/pci_sun4v.c|2 +-
4 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/sparc64/kernel/iommu.c b/arch/sparc64/kernel/iommu.c
index 070a484..4b9115a 100644
--- a/arch/sparc64/kernel/iommu.c
+++ b/arch/sparc64/kernel/iommu.c
@@ -580,7 +580,7 @@ static int dma_4u_map_sg(struct device *dev, struct
scatterlist *sglist,
/* Step 1: Prepare scatter list. */
- npages = prepare_sg(sglist, nelems);
+ npages = prepare_sg(dev, sglist, nelems);
/* Step 2: Allocate a cluster and context, if necessary. */
diff --git a/arch/sparc64/kernel/iommu_common.c
b/arch/sparc64/kernel/iommu_common.c
index b70324e..62c3218 100644
--- a/arch/sparc64/kernel/iommu_common.c
+++ b/arch/sparc64/kernel/iommu_common.c
@@ -4,6 +4,7 @@
* Copyright (C) 1999 David S. Miller ([EMAIL PROTECTED])
*/
+#include
#include "iommu_common.h"
/* You are _strongly_ advised to enable the following debugging code
@@ -201,21 +202,24 @@ void verify_sglist(struct scatterlist *sglist, int nents,
iopte_t *iopte, int np
}
#endif
-unsigned long prepare_sg(struct scatterlist *sg, int nents)
+unsigned long prepare_sg(struct device *dev, struct scatterlist *sg, int nents)
{
struct scatterlist *dma_sg = sg;
unsigned long prev;
u32 dent_addr, dent_len;
+ unsigned int max_seg_size;
prev = (unsigned long) sg_virt(sg);
prev += (unsigned long) (dent_len = sg->length);
dent_addr = (u32) ((unsigned long)(sg_virt(sg)) & (IO_PAGE_SIZE - 1UL));
+ max_seg_size = dma_get_max_seg_size(dev);
while (--nents) {
unsigned long addr;
sg = sg_next(sg);
addr = (unsigned long) sg_virt(sg);
- if (! VCONTIG(prev, addr)) {
+ if (! VCONTIG(prev, addr) ||
+ dent_len + sg->length > max_seg_size) {
dma_sg->dma_address = dent_addr;
dma_sg->dma_length = dent_len;
dma_sg = sg_next(dma_sg);
diff --git a/arch/sparc64/kernel/iommu_common.h
b/arch/sparc64/kernel/iommu_common.h
index 75b5a58..a90d046 100644
--- a/arch/sparc64/kernel/iommu_common.h
+++ b/arch/sparc64/kernel/iommu_common.h
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -46,4 +47,4 @@ extern void verify_sglist(struct scatterlist *sg, int nents,
iopte_t *iopte, int
#define VCONTIG(__X, __Y) (((__X) == (__Y)) || \
(((__X) | (__Y)) << (64UL - PAGE_SHIFT)) ==
0UL)
-extern unsigned long prepare_sg(struct scatterlist *sg, int nents);
+extern unsigned long prepare_sg(struct device *dev, struct scatterlist *sg,
int nents);
diff --git a/arch/sparc64/kernel/pci_sun4v.c b/arch/sparc64/kernel/pci_sun4v.c
index 8c4875b..cc03021 100644
--- a/arch/sparc64/kernel/pci_sun4v.c
+++ b/arch/sparc64/kernel/pci_sun4v.c
@@ -490,7 +490,7 @@ static int dma_4v_map_sg(struct device *dev, struct
scatterlist *sglist,
goto bad;
/* Step 1: Prepare scatter list. */
- npages = prepare_sg(sglist, nelems);
+ npages = prepare_sg(dev, sglist, nelems);
/* Step 2: Allocate a cluster and context, if necessary. */
spin_lock_irqsave(&iommu->lock, flags);
--
1.5.2.4
-
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 -mm 09/11] call blk_queue_segment_boundary in __scsi_alloc_queue
request_queue and device struct must have the same value of a segment
size limit. This patch adds blk_queue_segment_boundary in
__scsi_alloc_queue so LLDs don't need to call both
blk_queue_segment_boundary and set_dma_max_seg_size. A LLD can change
the default value (64KB) can call device_dma_parameters accessors like
pci_set_dma_max_seg_size when allocating scsi_host.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_lib.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 61fdaf0..23a30ab 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1645,6 +1645,7 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
request_fn_proc *request_fn)
{
struct request_queue *q;
+ struct device *dev = shost->shost_gendev.parent;
q = blk_init_queue(request_fn, NULL);
if (!q)
@@ -1673,6 +1674,8 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
blk_queue_segment_boundary(q, shost->dma_boundary);
+ blk_queue_max_segment_size(q, dma_get_max_seg_size(dev));
+
if (!shost->use_clustering)
clear_bit(QUEUE_FLAG_CLUSTER, &q->queue_flags);
return q;
--
1.5.2.4
-
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 -mm 05/11] IA64: make sba_iommu respect the segment size limits
This patch makes sba iommu respect segment size limits when merging sg
lists.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
arch/ia64/hp/common/sba_iommu.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index bc859a3..82bf7fa 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -1265,7 +1265,7 @@ sba_fill_pdir(
* the sglist do both.
*/
static SBA_INLINE int
-sba_coalesce_chunks( struct ioc *ioc,
+sba_coalesce_chunks(struct ioc *ioc, struct device *dev,
struct scatterlist *startsg,
int nents)
{
@@ -1275,6 +1275,7 @@ sba_coalesce_chunks( struct ioc *ioc,
struct scatterlist *dma_sg;/* next DMA stream head */
unsigned long dma_offset, dma_len; /* start/len of DMA stream */
int n_mappings = 0;
+ unsigned int max_seg_size = dma_get_max_seg_size(dev);
while (nents > 0) {
unsigned long vaddr = (unsigned long) sba_sg_address(startsg);
@@ -1314,6 +1315,9 @@ sba_coalesce_chunks( struct ioc *ioc,
> DMA_CHUNK_SIZE)
break;
+ if (dma_len + startsg->length > max_seg_size)
+ break;
+
/*
** Then look for virtually contiguous blocks.
**
@@ -1441,7 +1445,7 @@ int sba_map_sg(struct device *dev, struct scatterlist
*sglist, int nents, int di
** w/o this association, we wouldn't have coherent DMA!
** Access to the virtual address is what forces a two pass algorithm.
*/
- coalesced = sba_coalesce_chunks(ioc, sglist, nents);
+ coalesced = sba_coalesce_chunks(ioc, dev, sglist, nents);
/*
** Program the I/O Pdir
--
1.5.2.4
-
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] hptiop: fix type mismatch warning
drivers/scsi/hptiop.c: In function 'hptiop_host_request_callback': drivers/scsi/hptiop.c:378: warning: comparison of distinct pointer types lacks a cast drivers/scsi/hptiop.c:378: warning: comparison of distinct pointer types lacks a cast Use min_t(size_t, ...) to fix. Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> --- diff --git a/drivers/scsi/hptiop.c b/drivers/scsi/hptiop.c index 0844331..7fc532b 100644 --- a/drivers/scsi/hptiop.c +++ b/drivers/scsi/hptiop.c @@ -376,7 +376,7 @@ static void hptiop_host_request_callback(struct hptiop_hba *hba, u32 _tag) memset(&scp->sense_buffer, 0, sizeof(scp->sense_buffer)); memcpy(&scp->sense_buffer, &req->sg_list, - min(sizeof(scp->sense_buffer), + min_t(size_t, sizeof(scp->sense_buffer), le32_to_cpu(req->dataxfer_length))); break; - 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] scsi/sym53c8xx: Fix a warning in sym_eh_handler
In 2.6.24-rc1 I see the following warning:
drivers/scsi/sym53c8xx_2/sym_glue.c: In function "sym_eh_handler":
drivers/scsi/sym53c8xx_2/sym_glue.c:612: warning: "io_reset" may be used
uninitialized in this function
Although gcc is wrong and the code is actually correct, it can easily
be made more obvious to keep the compiler quiet.
Signed-off-by: Jean Delvare <[EMAIL PROTECTED]>
---
drivers/scsi/sym53c8xx_2/sym_glue.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
--- linux-2.6.24-rc1.orig/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-10-24
09:59:46.0 +0200
+++ linux-2.6.24-rc1/drivers/scsi/sym53c8xx_2/sym_glue.c2007-10-24
11:53:14.0 +0200
@@ -609,8 +609,8 @@ static int sym_eh_handler(int op, char *
*/
#define WAIT_FOR_PCI_RECOVERY 35
if (pci_channel_offline(pdev)) {
- struct completion *io_reset;
- int finished_reset = 0;
+ struct completion *io_reset = NULL;
+ int finished_reset;
init_completion(&eh_done);
spin_lock_irq(shost->host_lock);
/* Make sure we didn't race */
@@ -618,15 +618,14 @@ static int sym_eh_handler(int op, char *
if (!sym_data->io_reset)
sym_data->io_reset = &eh_done;
io_reset = sym_data->io_reset;
- } else {
- finished_reset = 1;
}
spin_unlock_irq(shost->host_lock);
- if (!finished_reset)
+ if (io_reset) {
finished_reset = wait_for_completion_timeout(io_reset,
WAIT_FOR_PCI_RECOVERY*HZ);
- if (!finished_reset)
- return SCSI_FAILED;
+ if (!finished_reset)
+ return SCSI_FAILED;
+ }
}
spin_lock_irq(shost->host_lock);
--
Jean Delvare
-
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: [GIT PATCH] final SCSI pieces for the merge window
Jeff Garzik wrote: > James Bottomley wrote: >> On Tue, 2007-10-23 at 17:09 -0400, Jeff Garzik wrote: >>> James Bottomley wrote: This should be the final SCSI updates; it's mainly just a few accessor completion updates and two driver merges (sym2 and qla2xxx) we also secured DaveM's agreement to remove fcal/fc4, which explains the high removal line count. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git >>> I guess I have the go-ahead to merge the end-CDROM-polling async >>> notification work you've been repeatedly ignoring? >> >> I haven't been ignoring it ... it just needs quite a bit of work; the >> best way to accelerate it seems to be simply to do it (add the >> supported/trigger event bitmasks and expand the infrastructure). I just >> haven't had the time within the merge window. > > James, things cannot get bottlenecked like this. You have had MONTHS to > say something like this. The code was ready BEFORE the merge window. > > I really think you have the knowledge to be SCSI maintainer, but not the > time. Jeff, If only I had a dollar (Canadian unit please) for each day some of my libata patches were queued up to you before you accepted them. Remember MODE SELECT ... On a more serious note, it looks like the job of the SCSI maintainer is getting larger and more onerous. Perhaps some folks should check if James has been provided with the appropriate resources. Doug Gilbert - 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 1/1] cciss: update copyright notices
On Tue, Oct 23 2007, Mike Miller wrote: > PATCH 1 of 1 > > This patch updates the copyright information for the cciss driver. It > includes extending the year to 2007 (how timely) and some minor corrections > deemed necessary by HP legal and the Open Source Review Board. Please > consider this patch for inclusion. I added your patch, Mike. -- 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: Add ACCUSYS RAID driver for Linux i386/x86-64
On Mon, 22 Oct 2007 18:17:49 +0800 "Peter Chan" <[EMAIL PROTECTED]> wrote:
> Dear Morton
>
> Thanks for your doing.
> We modified source code as your requested. If you have any comment please
> let me know.
> Do you need RAID HBA to test at this stage? If "yes", Which address can i
> ship RAID HBA for you?
Please, you really will need to become a bit more familiar with the way we
work. As far as I know, nobody in the linux world uses RAR format - that's
a windows thing. I doubt if anyone except I has actually gone to the
effort to decrypt that attachment.
Start with
Documentation/SubmittingPatches
Documentation/SubmittingDrivers
Documentation/SubmitChecklist
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
http://linux.yyz.us/patch-format.html
There are a number of remaining stylistic things which we can look at more
closely when we have patches which are in a usable form.
- Linux doesn't use capitalisation in variable names. Use "tail", not "Tail"
- Linux uses underscored to separate words. Use "reply_frame", not
"replyframe" or "ReplyFrame".
- We don't like to see code which has any dependency on
LINUX_VERSION_CODE or KENREL_VERSION: the code in Linux is suppsoed to
work correctly in the version of the kernel which it s found and that's
it.
- I don't know what this:
+#if defined(CONFIG_MODVERSIONS) && !defined(MODVERSIONS)
+ #define MODVERSIONS
+#endif
is doing, but it's probably wrong.
- Use request_node, not RequestNode, etc.
- Don't parenthesise the argument to `return'.
- I see at least one U32 in there. Please use u32. (Does U32 even work?)
- This:
+static int acs_ame_get_log(
+ struct Acs_Adapter *acs_adt,
+ struct EventLog *event_log)
isn't preferred style. Use
static int acs_ame_get_log(struct Acs_Adapter *acs_adt,
struct EventLog *event_log)
or, if you particularly dislike that, blow the 80-col rule and do
static int acs_ame_get_log(struct Acs_Adapter *acs_adt, struct EventLog
*event_log)
- This
+ writel((replyframe), base_addr+AME_REPLY_MSG_PORT);
is overparenthesised.
- Beware that the scatter/gather APIs just got significantly changed.
You code might need adjustment to work against the latest mainline tree.
- What does CHAR_DEV do? Probably it should be a Kconfig CONFIG_* option.
- All the code around acs_ame_schedule_command() (which is incorrectly
identified as arcmsr_schedule_command in its comment block) is indented a
tab stop. That's really weird. Please make it normal.
- acs_ame_schedule_command() has an up-to-sixty-second busywait. Bad.
Can we get a sleep+wakeup in there?
- This:
+ struct
+ {
+ unsigned int vendor_id;
+ unsigned int device_id;
+ } const acs_ame_devices[] = {
+ { 0x14D6, DEVICEID_ACS_61000_XX }
+ , { 0x14D6, DEVICEID_ACS_62000_08 }
+ , { 0x1AB6, DEVICEID_ACS_61000_XX }
+ , { 0x1AB6, DEVICEID_ACS_62000_08 }
+ };
should be
static const struct {
unsigned int vendor_id;
unsigned int device_id;
} acs_ame_devices[] = {
{ 0x14D6, DEVICEID_ACS_61000_XX },
{ 0x14D6, DEVICEID_ACS_62000_08 },
{ 0x1AB6, DEVICEID_ACS_61000_XX },
{ 0x1AB6, DEVICEID_ACS_62000_08 },
};
which has many changes from the original.
I'd have thought that the kernel already has a data type for this, but
I can't find it. Most drivers just rely upon the normal PCI device ID
tables. It is suspicious that this one doesn't.
Anyway, that's just from a quick scan. There are a huge number of similar
issues in there. Please take some time to study some well-maintained Linux
driver code and the interfaces which scsi and PCI drivers use and try to
make this driver a lot more Linux-like, thanks.
-
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
