Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757316AbYHNHWS (ORCPT ); Thu, 14 Aug 2008 03:22:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752253AbYHNHWE (ORCPT ); Thu, 14 Aug 2008 03:22:04 -0400 Received: from sh.osrg.net ([192.16.179.4]:37325 "EHLO sh.osrg.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752129AbYHNHWD (ORCPT ); Thu, 14 Aug 2008 03:22:03 -0400 Date: Thu, 14 Aug 2008 16:21:32 +0900 To: stefanr@s5r6.in-berlin.de Cc: fujita.tomonori@lab.ntt.co.jp, grundler@google.com, linux1394-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org Subject: Re: [PATCH update] ieee1394: sbp2: enforce s/g segment size limit From: FUJITA Tomonori In-Reply-To: References: <20080814095549S.fujita.tomonori@lab.ntt.co.jp> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20080814162010E.fujita.tomonori@lab.ntt.co.jp> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3355 Lines: 99 On Thu, 14 Aug 2008 09:12:01 +0200 (CEST) Stefan Richter wrote: > On 14 Aug, FUJITA Tomonori wrote: > > On Wed, 13 Aug 2008 12:19:59 +0200 (CEST) > > Stefan Richter wrote: > >> I keep the original scsi_sg_count to call dma_unmap_sg with it > >> later. > > > > You need to keep it? You can access to it via scsi_sg_count when > > calling dma_unmap_sg? Seems that firewire code does. > > Yes, I can easily do it this way; fixed below. > > [...nents in dma_unmap_sg...] > > This is from Documentation/DMA-mapping.txt > > Right. How did I forget about that? > > > > From: Stefan Richter > Subject: ieee1394: sbp2: remove redundant struct members > > Signed-off-by: Stefan Richter > --- > drivers/ieee1394/sbp2.c | 14 +++++--------- > drivers/ieee1394/sbp2.h | 4 ---- > 2 files changed, 5 insertions(+), 13 deletions(-) > > Index: linux/drivers/ieee1394/sbp2.c > =================================================================== > --- linux.orig/drivers/ieee1394/sbp2.c > +++ linux/drivers/ieee1394/sbp2.c > @@ -656,11 +656,11 @@ static struct sbp2_command_info *sbp2uti > static void sbp2util_mark_command_completed(struct sbp2_lu *lu, > struct sbp2_command_info *cmd) > { > - if (cmd->sg_buffer) { > - dma_unmap_sg(lu->ud->ne->host->device.parent, cmd->sg_buffer, > - cmd->sg_count, cmd->sg_dir); > - cmd->sg_buffer = NULL; > - } > + if (scsi_sg_count(cmd->Current_SCpnt) > 0) static inline unsigned scsi_sg_count(struct scsi_cmnd *cmd) so > + if (scsi_sg_count(cmd->Current_SCpnt)) make more sense, I think. It looks a nice cleanup except for it. > + dma_unmap_sg(lu->ud->ne->host->device.parent, > + scsi_sglist(cmd->Current_SCpnt), > + scsi_sg_count(cmd->Current_SCpnt), > + cmd->Current_SCpnt->sc_data_direction); > list_move_tail(&cmd->list, &lu->cmd_orb_completed); > } > > @@ -1505,10 +1505,6 @@ static int sbp2_prep_command_orb_sg(stru > if (n == 0) > return -ENOMEM; > > - cmd->sg_buffer = sg; > - cmd->sg_count = sg_count; > - cmd->sg_dir = dma_dir; > - > orb->data_descriptor_hi = ORB_SET_NODE_ID(hi->host->node_id); > orb->misc |= ORB_SET_DIRECTION(orb_direction); > > Index: linux/drivers/ieee1394/sbp2.h > =================================================================== > --- linux.orig/drivers/ieee1394/sbp2.h > +++ linux/drivers/ieee1394/sbp2.h > @@ -252,10 +252,6 @@ struct sbp2_command_info { > struct sbp2_unrestricted_page_table > scatter_gather_element[SG_ALL] __attribute__((aligned(8))); > dma_addr_t sge_dma; > - > - struct scatterlist *sg_buffer; > - int sg_count; > - enum dma_data_direction sg_dir; > }; > > /* Per FireWire host */ > > > -- > Stefan Richter > -=====-==--- =--- -===- > http://arcgraph.de/sr/ > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/