# \[PATCH v2 2/7\] dma-mapping: Generalise dma\_32bit\_limit flag

- From: Robin Murphy \<robin.murphy@arm.com\>
- Date: 2018-07-27 20:11:17 
- List: linux-arm-kernel
- Page: https://ratatoskr.run/linux-arm-kernel/2018/07/8771707
- Thread: https://ratatoskr.run/linux-arm-kernel/2018/07/8771456/t.md

```text
On 2018-07-27 6:45 PM, Grygorii Strashko wrote:
> On 07/23/2018 05:16 PM, Robin Murphy wrote:
>> Whilst the notion of an upstream DMA restriction is most commonly seen
>> in PCI host bridges saddled with a 32-bit native interface, a more
>> general version of the same issue can exist on complex SoCs where a bus
>> or point-to-point interconnect link from a device's DMA master interface
>> to another component along the path to memory (often an IOMMU) may carry
>> fewer address bits than the interfaces at both ends nominally support.
>> In order to properly deal with this, the first step is to expand the
>> dma_32bit_limit flag into an arbitrary mask.
>>
>> To minimise the impact on existing code, we'll make sure to only
>> consider this new mask valid if set. That makes sense anyway, since a
>> mask of zero would represent DMA not being wired up at all, and that
>> would be better handled by not providing valid ops in the first place.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> 
> I'd like to note about some possible issue related to this change.
> 
> There are some places in kernel where parent DMA configuration is copied 
> to the manually created child devices, like:
> mfd-core.c
> mfd_add_device()
>  ????pdev->dev.parent = parent;
>  ????pdev->dev.type = &mfd_dev_type;
>  ????pdev->dev.dma_mask = parent->dma_mask;
>  ????pdev->dev.dma_parms = parent->dma_parms;
>  ????pdev->dev.coherent_dma_mask = parent->coherent_dma_mask;
> 
> Adding or changing generic DMA device properties might affect on such
> subsystems/drivers. Have you considered such cases?

Yes, that's a lovely example of what I class as "bus code" creating a 
child device and initialising its DMA parameters appropriately. The 
subdevice goes on to get associated with an OF node or ACPI companion, 
so when the subdriver for that function binds it should go through its 
own dma_configure() process and pick up any further properties accordingly.

Code which just tries to copy the DMA configuration from an existing 
device to a new one has never worked properly, because there is often 
additional DMA configuration in archdata and other places it cannot 
possibly know about. Last time I looked there were still some specific 
hacks in the USB layer in order to interact correctly with the block 
layer bounce limit, but I think anything truly wrong has been more or 
less flushed out by now (the DMA ops changes for arm64 ACPI support 
caught a fair few IIRC).

Robin.
```