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@xxxxxxx> >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
