All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: thomas.lendacky-5C7GfCeVMHo@public.gmane.org,
	iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>
Subject: Re: [PATCH 1/2] kernel/dma/direct: take DMA offset into account in dma_direct_supported
Date: Wed, 29 Aug 2018 18:59:56 +0200	[thread overview]
Message-ID: <20180829165956.GA6787@lst.de> (raw)
In-Reply-To: <0e95df80-38f7-7970-ef74-419567f13fdc-5wv7dgnIgG8@public.gmane.org>

On Fri, Aug 24, 2018 at 12:11:23PM +0100, Robin Murphy wrote:
> On 24/08/18 07:53, Christoph Hellwig wrote:
>> When a device has a DMA offset the dma capable result will change due
>> to the difference between the physical and DMA address.  Take that into
>> account.
>
> The "phys_to_dma(..., DMA_BIT_MASK(...))" idiom always looks like a glaring 
> error at first glance, but this whole function is fairly unintuitive 
> anyway, and ultimately I think the change does work out to be correct.
>
> It might be nicer if we could reference max_zone_pfns[] for a bit more 
> clarity, but I guess that's not arch-independent.

Not just arch specific, but also local variables.  There is
arch_zone_lowest_possible_pfn in page_alloc.c, but that gets discarded
after init.  That being said this is the right direction and I'll
look into it for 4.20 or later.

  parent reply	other threads:[~2018-08-29 16:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-24  6:53 two dma-direct fixes for 4.18 Christoph Hellwig
     [not found] ` <20180824065324.654-1-hch-jcswGhMUV9g@public.gmane.org>
2018-08-24  6:53   ` [PATCH 1/2] kernel/dma/direct: take DMA offset into account in dma_direct_supported Christoph Hellwig
     [not found]     ` <20180824065324.654-2-hch-jcswGhMUV9g@public.gmane.org>
2018-08-24 11:11       ` Robin Murphy
     [not found]         ` <0e95df80-38f7-7970-ef74-419567f13fdc-5wv7dgnIgG8@public.gmane.org>
2018-08-29 16:59           ` Christoph Hellwig [this message]
2018-08-24  6:53   ` [PATCH 2/2] kernel/dma/direct: refine dma_direct_alloc zone selection Christoph Hellwig
     [not found]     ` <20180824065324.654-3-hch-jcswGhMUV9g@public.gmane.org>
2018-08-24 11:38       ` Robin Murphy
     [not found]         ` <bfba5bae-a88c-f777-ba1f-f0db310904dc-5wv7dgnIgG8@public.gmane.org>
2018-08-24 11:49           ` Robin Murphy

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=20180829165956.GA6787@lst.de \
    --to=hch-jcswghmuv9g@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=robin.murphy-5wv7dgnIgG8@public.gmane.org \
    --cc=thomas.lendacky-5C7GfCeVMHo@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.