[ofa-general] Re: commit bb350d1decd9c48ffaa7f7e263df3056df9f4f21
FUJITA Tomonori
fujita.tomonori at lab.ntt.co.jp
Mon Jul 23 04:20:55 PDT 2007
From: "Michael S. Tsirkin" <mst at dev.mellanox.co.il>
Subject: commit bb350d1decd9c48ffaa7f7e263df3056df9f4f21
Date: Mon, 23 Jul 2007 10:57:54 +0300
> Hi!
> commit bb350d1decd9c48ffaa7f7e263df3056df9f4f21 includes this snippet:
>
> @@ -468,20 +465,8 @@ static void srp_unmap_data(struct scsi_cmnd *scmnd,
> req->fmr = NULL;
> }
>
> - /*
> - * This handling of non-SG commands can be killed when the
> - * SCSI midlayer no longer generates non-SG commands.
> - */
> - if (likely(scmnd->use_sg)) {
> - nents = scmnd->use_sg;
> - scat = scmnd->request_buffer;
> - } else {
> - nents = 1;
> - scat = &req->fake_sg;
> - }
> -
> - ib_dma_unmap_sg(target->srp_host->dev->dev, scat, nents,
> - scmnd->sc_data_direction);
> + ib_dma_unmap_sg(target->srp_host->dev->dev, scsi_sglist(scmnd),
> + scsi_sg_count(scmnd), scmnd->sc_data_direction);
>
> Since scsi_sg_count is simply use_sg, and scsi_sglist is simply request_buffer,
> why is this the right things to do?
That will change shortly.
http://marc.info/?l=linux-scsi&m=118364319919621&w=2
> Is there a reason to believe that scsi_sg_count is never 0 here?
Yeah, scsi-ml doesn't send non-SG commands now.
More information about the general
mailing list