linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
To: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Roland Dreier <roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: RDMA/cxgb4: Support on-chip SQs
Date: Wed, 30 Jan 2013 15:36:48 -0600	[thread overview]
Message-ID: <51099270.5070406@opengridcomputing.com> (raw)
In-Reply-To: <20130130210006.GA22134-mgFCXtclrQlZLf2FXnZxJA@public.gmane.org>

I wonder, then, what the correct service is to get the cpu physical 
address from a kernel virtual address returned from 
dma_alloc_coherent()?  I think this is correct as-is, since I think 
dma_alloc_coherent() falls under the "directly mapped" addresses in the 
virt_to_phys() prototype comment.

What do you think Roland?

On 1/30/2013 3:00 PM, Dan Carpenter wrote:
> Hello Steve Wise,
>
> The patch c6d7b26791a2: "RDMA/cxgb4: Support on-chip SQs" from Sep
> 13, 2010, leads to the following warning:
> "drivers/infiniband/hw/cxgb4/qp.c:98 alloc_host_sq()
> 	error: 'sq->queue' came from dma_alloc_coherent() so we can't
> 	do virt_to_phys()"
>
> drivers/infiniband/hw/cxgb4/qp.c
>      92  static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
>      93  {
>      94          sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev), sq->memsize,
>      95                                         &(sq->dma_addr), GFP_KERNEL);
>      96          if (!sq->queue)
>      97                  return -ENOMEM;
>      98          sq->phys_addr = virt_to_phys(sq->queue);
>      99          pci_unmap_addr_set(sq, mapping, sq->dma_addr);
>     100          return 0;
>     101  }
>
> This is a new Smatch check.  I don't know the rules on virt_to_phys yet
> but here is the relevant comment.
>
> /**
>   *      virt_to_phys    -       map virtual addresses to physical
>   *      @address: address to remap
>   *
>   *      The returned physical address is the physical (CPU) mapping for
>   *      the memory address given. It is only valid to use this function on
>   *      addresses directly mapped or allocated via kmalloc.
>   *
>   *      This function does not give bus mappings for DMA transfers. In
>   *      almost all conceivable cases a device driver should not be using
>   *      this function
>   */
>
> regards,
> dan carpenter

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2013-01-30 21:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-30 21:00 RDMA/cxgb4: Support on-chip SQs Dan Carpenter
     [not found] ` <20130130210006.GA22134-mgFCXtclrQlZLf2FXnZxJA@public.gmane.org>
2013-01-30 21:36   ` Steve Wise [this message]
     [not found]     ` <51099270.5070406-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
2013-01-30 21:44       ` Jason Gunthorpe
     [not found]         ` <20130130214425.GA5674-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2013-01-30 21:51           ` Steve Wise
     [not found]             ` <510995DC.4020602-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
2013-01-30 22:18               ` Jason Gunthorpe
2013-01-30 22:34           ` Roland Dreier
     [not found]             ` <CAL1RGDXQW44TTaCZ0rzBAXG1oK3EsiKJXj5+cA1jUJHb85VFNQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-01-30 22:49               ` Steve Wise
2013-01-30 21:45       ` Dan Carpenter
2013-01-30 21:52         ` Steve Wise
     [not found]           ` <51099622.40505-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
2013-01-30 22:17             ` Steve Wise
2013-03-23 21:30       ` Dan Carpenter
2013-03-23 22:54         ` Steve Wise
2013-03-25 16:14         ` Roland Dreier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51099270.5070406@opengridcomputing.com \
    --to=swise-7bpotxp6k4+p2yhjcf5u+vpxobypeauw@public.gmane.org \
    --cc=dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=roland-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).