[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <76c43b76-518c-a2d3-c200-d02aa9125e1d@samsung.com>
Date: Thu, 23 Jun 2016 08:13:30 +0200
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc: Robin Murphy <robin.murphy@....com>,
iommu@...ts.linux-foundation.org,
linux-arm-kernel@...ts.infradead.org,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Marc Zyngier <marc.zyngier@....com>,
Catalin Marinas <catalin.marinas@....com>,
Joerg Roedel <joro@...tes.org>,
Will Deacon <will.deacon@....com>,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
Sinan Kaya <okaya@...eaurora.org>, linux-acpi@...r.kernel.org,
Hanjun Guo <hanjun.guo@...aro.org>,
Tomasz Nowicki <tn@...ihalf.com>, Jon Masters <jcm@...hat.com>
Subject: Re: [RFC PATCH v2 03/15] arm64: mm: change IOMMU notifier action to
attach DMA ops
Hi Lorenzo,
On 2016-06-21 18:06, Lorenzo Pieralisi wrote:
> Hi Marek,
>
> On Tue, Jun 21, 2016 at 09:53:20AM +0200, Marek Szyprowski wrote:
>> Hi Robin,
>>
>>
>> On 2016-06-17 11:27, Robin Murphy wrote:
>>> Hi Lorenzo,
>>>
>>> I think this patch makes sense even independent of the rest of the
>>> series, one nit inline notwithstanding.
>>>
>>> Marek; I'm curious as to whether this could make the workaround in
>>> 722ec35f7 obsolete as well, or are all the drivers also bound
>>> super-early in the setup you had there?
>> Yes, this will solve that problem too. I will also hide some possible
>> deferred probe issues, because the moment at which IOMMU is activated
>> will be postponed. The only drawback with this approach is the fact
>> that is drivers won't be allowed to do any dma-mapping operations on
>> devices, which they don't own. This should not be a big issue, but
>> this was the reason to setup IOMMU on device add instead of driver
>> bind.
>>
>> While at it, please make sure that the case of failed client driver
>> probe will be handled properly. IOMMU might do some operations while
>> setting up and if the client driver fails to probe (for whatever
>> reason, might be a deferred probe too), those operation has to be
>> undone. However the current code of the driver core won't call any
>> notifier (like BUS_NOTIFY_UNBOUND_DRIVER or whatever else) in such
>> case.
> Isn't Andy's commit 14b6257a5f3d enough ? Is that what you had in
> mind ?
>
>> Long time ago I used BUS_NOTIFY_BIND_DRIVER based approach for my
>> Exynos IOMMU patches and had to extend bus core with such patch:
>> https://patchwork.kernel.org/patch/4678181/ to properly cleanup
>> after failed client driver probe and avoid leaking resources. Please
>> read the discussion, because some changes were requested to it.
> It looks like commit 14b6257a5f3d ("device core: add
> BUS_NOTIFY_DRIVER_NOT_BOUND notification") does what you
> are requesting, please let me know if that's enough.
Yes, that's exactly the change I needed that time. Nice to see that it
finally landed in mainline.
> I will revert the changes in 722ec35f7 and fold them in the
> new version along with Robin's suggestions.
Okay.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Powered by blists - more mailing lists