Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1709896
| From | Christoph Hellwig <hch@lst.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 2/2] of: Restrict DMA configuration |
| Date | 2017-08-11 20:10 +0200 |
| Message-ID | <udmxI-6Oo-3@gated-at.bofh.it> (permalink) |
| References | <udl8B-5QR-11@gated-at.bofh.it> <udl8C-5QR-27@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Aug 11, 2017 at 05:29:57PM +0100, Robin Murphy wrote:
> The good news is that DT already gives us the ammunition to do the right
> thing - anything lacking a "dma-ranges" property should be considered
> not to have a mapping of DMA address space from its children to its
> parent, thus anything for which of_dma_get_range() does not succeed does
> not need DMA configuration.
That sounds like a good heuristic.
At least in theory apparently :(
> The bad news is that strictly enforcing that would likely break just
> about every FDT platform out there, since most authors have either not
> considered the property at all or have mistakenly assumed that omitting
> "dma-ranges" is equivalent to including the empty property. Thus we have
> little choice but to special-case platform, AMBA and PCI devices so they
> continue to receive configuration unconditionally as before. At least
> anything new will have to get it right in future...
That still sounds like a useful compromise.
> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
> if (ret < 0) {
> + /*
> + * For legacy reasons, we have to assume some devices need
> + * DMA configuration regardless of whether "dma-ranges" is
> + * correctly specified or not.
> + */
> + if (!dev_is_pci(dev) &&
> +#ifdef CONFIG_ARM_AMBA
> + dev->bus != &amba_bustype &&
> +#endif
> + dev->bus != &platform_bus_type)
> + return ret == -ENODEV ? 0 : ret;
> +
It would be really nice to have dev_is_amba and dev_is_plaform helpers
to reduce the ifdef mess.
But it should be okay even without that cleanup.
> + if (!size)
> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
I find this way to deal with an overflow really odd, but given that it's
just moved around I'm not going to complain.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 1/2] of: Fix DMA mask generation Robin Murphy <robin.murphy@arm.com> - 2017-08-11 18:40 +0200
[PATCH 2/2] of: Restrict DMA configuration Robin Murphy <robin.murphy@arm.com> - 2017-08-11 18:40 +0200
Re: [PATCH 2/2] of: Restrict DMA configuration Christoph Hellwig <hch@lst.de> - 2017-08-11 20:10 +0200
Re: [PATCH 2/2] of: Restrict DMA configuration Rob Herring <robh+dt@kernel.org> - 2017-08-14 22:10 +0200
Re: [PATCH 2/2] of: Restrict DMA configuration Robin Murphy <robin.murphy@arm.com> - 2017-08-15 12:20 +0200
Re: [PATCH 2/2] of: Restrict DMA configuration Rob Herring <robh+dt@kernel.org> - 2017-08-15 16:30 +0200
Re: [PATCH 1/2] of: Fix DMA mask generation Christoph Hellwig <hch@lst.de> - 2017-08-11 20:00 +0200
Re: [PATCH 1/2] of: Fix DMA mask generation Rob Herring <robh+dt@kernel.org> - 2017-08-14 23:20 +0200
Re: [PATCH 1/2] of: Fix DMA mask generation Christoph Hellwig <hch@lst.de> - 2017-08-17 10:30 +0200
csiph-web