[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <faeccc75-79e9-ddb6-446d-88ab63fe4e1f@arm.com>
Date: Thu, 11 Jan 2018 12:24:11 +0000
From: Robin Murphy <robin.murphy@....com>
To: JeffyChen <jeffy.chen@...k-chips.com>,
Marek Szyprowski <m.szyprowski@...sung.com>,
linux-kernel@...r.kernel.org
Cc: jcliang@...omium.org, tfiga@...omium.org,
linux-samsung-soc@...r.kernel.org, Kukjin Kim <kgene@...nel.org>,
devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org,
iommu@...ts.linux-foundation.org,
Frank Rowand <frowand.list@...il.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Rob Clark <robdclark@...il.com>,
Will Deacon <will.deacon@....com>,
Joerg Roedel <joro@...tes.org>,
Rob Herring <robh+dt@...nel.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/9] iommu/of: Drop early initialisation hooks
Hi Jeffy,
On 11/01/18 11:14, JeffyChen wrote:
> Hi Marek,
>
> Thanks for your reply.
>
> On 01/11/2018 05:40 PM, Marek Szyprowski wrote:
>> Hi Jeffy,
>>
>> On 2018-01-11 09:22, Jeffy Chen wrote:
>>> With the probe-deferral mechanism, early initialisation hooks are no
>>> longer needed.
>>>
>>> Suggested-by: Robin Murphy <robin.murphy@....com>
In fact, shortly after I said that I had a "how hard can it be?" moment
and took a crack at it myself - sorry, I should probably have cc'd you
on that series[1].
>>> Signed-off-by: Jeffy Chen <jeffy.chen@...k-chips.com>
>>> ---
>>>
>>> drivers/iommu/arm-smmu-v3.c | 2 +-
>>> drivers/iommu/arm-smmu.c | 12 ++++++------
>>> drivers/iommu/exynos-iommu.c | 2 +-
>>
>> For Exynos IOMMU:
>> Acked-by: Marek Szyprowski <m.szyprowski@...sung.com>
>>
>> IPMMU and MSM IOMMU are no longer multi-platform safe after this patch.
>> It breaks them in the same way as my commit 928055a01b3f ("iommu/exynos:
>> Remove custom platform device registration code") broke Exynos IOMMU.
>>
>> You need a similar fix for them:
>> https://www.spinics.net/lists/arm-kernel/msg627648.html
>
> hmmm, right, i did saw this fix in the rockchip iommu driver too.
>
> and there're also some other iommu drivers put bus_set_iommu in their
> probe() to avoid that.
>
> maybe we can do it in the iommu framework?
>
> for example:
> 1/ add a bus type member to struct iommu_device
> 2/ and a iommu_device_set_bus()
> 3/ do the bus_set_iommu stuff in iommu_device_register()
> 4/ undo bus_set_iommu in iommu_device_unregister()
Ultimately we'd like to get rid of the bus relationship altogether, so I
don't think it's really worth adding more infrastructure around it.
Having of-iommu-based drivers set bus ops at probe time, and others
conditionally from an initcall, is pretty clean and simple, so I'd
rather stick with that approach for now.
Robin.
[1]
https://lists.linuxfoundation.org/pipermail/iommu/2018-January/025395.html
Powered by blists - more mailing lists