[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20071024203515E.fujita.tomonori@lab.ntt.co.jp>
Date: Wed, 24 Oct 2007 20:35:15 +0900
From: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To: jeff@...zik.org
Cc: tomof@....org, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org,
James.Bottomley@...elEye.com, aacraid@...ptec.com,
fujita.tomonori@....ntt.co.jp
Subject: Re: [PATCH -mm 11/11] aacraid: use pci_set_dma_max_seg_size
On Wed, 24 Oct 2007 07:31:30 -0400
Jeff Garzik <jeff@...zik.org> 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 <fujita.tomonori@....ntt.co.jp>
> > ---
> > 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists