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

- From: Grygorii Strashko \<grygorii.strashko@ti.com\>
- Date: 2018-07-27 20:41:32 
- List: linux-arm-kernel
- Page: https://ratatoskr.run/linux-arm-kernel/2018/07/8771708
- Thread: https://ratatoskr.run/linux-arm-kernel/2018/07/8771456/t.md

```text


On 07/27/2018 03:11 PM, Robin Murphy wrote:
> 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.

Ideally ;), but in reality - dev->of_node not always initialized for child devices :(

> 
> 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).

Yep. For usb I wouldn't call it hack (dma controller device was introduced
to avoid DMA props copying).

Thanks for your comments.

-- 
regards,
-grygorii
```