[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d69dad81-d025-96ef-863c-553b5ed2dd8e@arm.com>
Date: Wed, 25 Mar 2020 12:31:46 +0000
From: Robin Murphy <robin.murphy@....com>
To: Joerg Roedel <joro@...tes.org>
Cc: "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
"linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>,
"guohanjun@...wei.com" <guohanjun@...wei.com>,
Sudeep Holla <Sudeep.Holla@....com>,
Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
Will Deacon <will@...nel.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Thierry Reding <thierry.reding@...il.com>,
Jean-Philippe Brucker <jean-philippe@...aro.org>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Joerg Roedel <jroedel@...e.de>
Subject: Re: [PATCH v3 10/15] iommu/arm-smmu: Use accessor functions for iommu
private data
On 2020-03-24 10:08 am, Joerg Roedel wrote:
> Hey Robin,
>
> On Mon, Mar 23, 2020 at 04:02:33PM +0000, Robin Murphy wrote:
>> Yikes, this ends up pretty ugly, and I'd prefer not have this much
>> complexity hidden in macros that were intended just to be convenient
>> shorthand. Would you mind pulling in the patch below as a precursor?
>
> Sure thing, but your mail-client seemed to have fiddled with the patch
> so that is is unusable to me. I tried to fix it up, but it still doesn't
> apply. Can you please re-send it to me either via git-send-email or just
> as a mime-attachement?
Oops, sorry - as you might imagine I'm not in my normal workflow :)
Let me rebase that onto something actually in your tree (rather than
whatever detached HEAD this is checked out out on my laptop...) and try
resending it properly.
>> Other than that, the rest of the series looks OK at a glance. We should also
>> move fwspec->ops to dev_iommu, as those are "IOMMU API" data rather than
>> "firmware" data, but let's consider that separately as this series is
>> already long enough.
>
> Yes, moving ops out of fwspec is next on the list, and moving the
> iommu_group pointer into dev_iommu.
Cool, let me know if you need a hand with all the *_iommu_configure()
stuff - I still have plans for overhauling that lot anyway, but not
imminently, so it probably is worthwhile to do the straightforward
housekeeping first.
Thanks,
Robin.
Powered by blists - more mailing lists