[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e227cf1e-f00a-5cdb-487c-bf0046f3acbb@arm.com>
Date: Wed, 17 Jan 2018 11:36:03 +0000
From: Robin Murphy <robin.murphy@....com>
To: Tomasz Figa <tfiga@...omium.org>,
Jeffy Chen <jeffy.chen@...k-chips.com>
Cc: linux-kernel@...r.kernel.org, Ricky Liang <jcliang@...omium.org>,
simon xue <xxm@...k-chips.com>,
Heiko Stuebner <heiko@...ech.de>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
"open list:IOMMU DRIVERS" <iommu@...ts.linux-foundation.org>,
Joerg Roedel <joro@...tes.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 05/13] iommu/rockchip: Fix error handling in init
On 17/01/18 05:26, Tomasz Figa wrote:
> On Tue, Jan 16, 2018 at 10:25 PM, Jeffy Chen <jeffy.chen@...k-chips.com> wrote:
>> It's hard to undo bus_set_iommu() in the error path, so move it to the
>> end of rk_iommu_probe().
>
> Does this work fine now? I remember we used to need this called in an
> early initcall for all the ARM/ARM64 DMA stuff to work.
It will do once we get to patch #11 (where the IOMMU_OF_DECLARE ensures
that masters defer until iommu_register() has set ops with a non-NULL
.of_xlate callback); in the meantime you might end up depending on DT
probe order as to whether the master uses the IOMMU or not. I'd say it's
up to you guys whether you consider that a bisection-breaker or not.
Robin.
Powered by blists - more mailing lists