Chad,
can you send out your last version with a proper changelog, signoff,
and the ack from Eddie included? Also can you prioritize getting
the shared skb patch tested?
Thanks,
Christoph
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to
On Mon, 2014-08-25 at 15:15 -0400, Chad Dupuis wrote:
>
> On Fri, 22 Aug 2014, Eddie Wai wrote:
>
> > On Fri, 2014-08-22 at 20:12 +0200, Maurizio Lombardi wrote:
> >> Hi Chad,
> >>
> >> On 08/22/2014 02:08 PM, Chad Dupuis wrote:
> >>> Eddie, Maurizio,
> >>>
> >>> Since it looks like there can be
On Fri, 22 Aug 2014, Eddie Wai wrote:
On Fri, 2014-08-22 at 20:12 +0200, Maurizio Lombardi wrote:
Hi Chad,
On 08/22/2014 02:08 PM, Chad Dupuis wrote:
Eddie, Maurizio,
Since it looks like there can be a difference in the pdev would it make sense instead
to convert the unmap function to use
On Fri, 2014-08-22 at 20:12 +0200, Maurizio Lombardi wrote:
> Hi Chad,
>
> On 08/22/2014 02:08 PM, Chad Dupuis wrote:
> > Eddie, Maurizio,
> >
> > Since it looks like there can be a difference in the pdev would it make
> > sense instead to convert the unmap function to use the bare DMA API so
>
Hi Chad,
On 08/22/2014 02:08 PM, Chad Dupuis wrote:
> Eddie, Maurizio,
>
> Since it looks like there can be a difference in the pdev would it make sense
> instead to convert the unmap function to use the bare DMA API so we're
> consistent in our use of hba->pcidev->dev? Maybe something like th
On Fri, Aug 22, 2014 at 08:08:33AM -0400, Chad Dupuis wrote:
> Eddie, Maurizio,
>
> Since it looks like there can be a difference in the pdev would it make
> sense instead to convert the unmap function to use the bare DMA API so
> we're consistent in our use of hba->pcidev->dev? Maybe something
Eddie, Maurizio,
Since it looks like there can be a difference in the pdev would it make
sense instead to convert the unmap function to use the bare DMA
API so we're consistent in our use of hba->pcidev->dev? Maybe something
like this:
diff --git a/drivers/scsi/bnx2fc/bnx2fc_io.c
b/drivers
Hi Eddie,
On 08/20/2014 07:35 PM, Eddie Wai wrote:
> On Mon, 2014-08-04 at 10:20 +0200, Maurizio Lombardi wrote:
>> In the bnx2fc_map_sg() function, the original behaviour is to
>> allocate the DMA memory by directly calling dma_map_sg()
>> instead of using scsi_dma_map().
>>
>> In contrast, bnx2f
On Mon, 2014-08-04 at 10:20 +0200, Maurizio Lombardi wrote:
> In the bnx2fc_map_sg() function, the original behaviour is to
> allocate the DMA memory by directly calling dma_map_sg()
> instead of using scsi_dma_map().
>
> In contrast, bnx2fc_unmap_sg_list() calls scsi_dma_unmap().
>
> The problem
> "Christoph" == Christoph Hellwig writes:
Christoph> Can I get a review for this one, please?
Looks good to me.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a m
Can I get a review for this one, please?
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
In the bnx2fc_map_sg() function, the original behaviour is to
allocate the DMA memory by directly calling dma_map_sg()
instead of using scsi_dma_map().
In contrast, bnx2fc_unmap_sg_list() calls scsi_dma_unmap().
The problem is that bnx2fc_map_sg() passes to the dma_map_sg() function
the pointer t
12 matches
Mail list logo
