Re: [PATCH V3 0/8] IOMMU probe deferral support

[Marek Szyprowski <m.szyprowski@samsung.com>]

Hi Sricharan,


On 2016-10-12 08:24, Sricharan wrote:
> On 2016-10-04 19:03, Sricharan R wrote:
>>> Initial post from Laurent Pinchart[1]. This is
>>> series calls the dma ops configuration for the devices
>>> at a generic place so that it works for all busses.
>>> The dma_configure_ops for a device is now called during
>>> the device_attach callback just before the probe of the
>>> bus/driver is called. Similarly dma_deconfigure is called during
>>> device/driver_detach path.
>>>
>>>
>>> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>>>          |                         |
>>> pci_bus_add_device     (device_add/driver_register)
>>>          |                         |
>>> device_attach           device_initial_probe
>>>          |                         |
>>> __device_attach_driver    __device_attach_driver
>>>          |
>>> driver_probe_device
>>>          |
>>> really_probe
>>>          |
>>> dma_configure
>>>
>>>    Similarly on the device/driver_unregister path __device_release_driver is
>>>    called which inturn calls dma_deconfigure.
>>>
>>>    If the ACPI bus code follows the same, we can add acpi_dma_configure
>>>    at the same place as of_dma_configure.
>>>
>>>    This series is based on the recently merged Generic DT bindings for
>>>    PCI IOMMUs and ARM SMMU from Robin Murphy robin.murphy@arm.com [2]
>>>
>>>    This time tested this with platform and pci device for probe deferral
>>>    and reprobe on arm64 based platform. There is an issue on the cleanup
>>>    path for arm64 though, where there is WARN_ON if the dma_ops is reset while
>>>    device is attached to an domain in arch_teardown_dma_ops.
>>>    But with iommu_groups created from the iommu driver, the device is always
>>>    attached to a domain/default_domain. So so the WARN has to be removed/handled
>>>    probably.
>> Thanks for continuing work on this feature! Your can add my:
>>
>> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
>    Thanks for testing this. So the for the below fix, the remove_device callback
>    gets called on the dma_ops cleanup path, so would it be easy to remove the
>    data for the device there ?

I assumed that IOMMU driver cannot be removed reliably, so all 
structures that it
creates are permanent. I didn't use device_add()/device_remove() 
callbacks, because
in current implementation device_add() is called too late (after 
dma-mapping glue
triggers device_attach_iommu()).

Maybe once your patchset is merged, I will move creation and management 
of the all
IOMMU related structures to device_add/remove callbacks.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland