All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.