[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200723113652.GA104096@VM20190228-100.tbsite.net>
Date: Thu, 23 Jul 2020 19:36:52 +0800
From: Baolin Wang <baolin.wang@...ux.alibaba.com>
To: Will Deacon <will@...nel.org>
Cc: joro@...tes.org, robin.murphy@....com, agross@...nel.org,
bjorn.andersson@...aro.org, matthias.bgg@...il.com,
robdclark@...il.com, robh@...nel.org, tomeu.vizoso@...labora.com,
steven.price@....com, alyssa.rosenzweig@...labora.com,
airlied@...ux.ie, daniel@...ll.ch, baolin.wang7@...il.com,
linux-arm-kernel@...ts.infradead.org,
iommu@...ts.linux-foundation.org, linux-arm-msm@...r.kernel.org,
linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v2 2/2] iommu: Add gfp parameter to io_pgtable_ops->map()
On Tue, Jul 14, 2020 at 09:28:21AM +0100, Will Deacon wrote:
> On Fri, Jun 12, 2020 at 11:39:55AM +0800, Baolin Wang wrote:
> > Now the ARM page tables are always allocated by GFP_ATOMIC parameter,
> > but the iommu_ops->map() function has been added a gfp_t parameter by
> > commit 781ca2de89ba ("iommu: Add gfp parameter to iommu_ops::map"),
> > thus io_pgtable_ops->map() should use the gfp parameter passed from
> > iommu_ops->map() to allocate page pages, which can avoid wasting the
> > memory allocators atomic pools for some non-atomic contexts.
> >
> > Signed-off-by: Baolin Wang <baolin.wang@...ux.alibaba.com>
> > ---
> > drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +-
> > drivers/iommu/arm-smmu-v3.c | 2 +-
> > drivers/iommu/arm-smmu.c | 2 +-
> > drivers/iommu/io-pgtable-arm-v7s.c | 18 +++++++++---------
> > drivers/iommu/io-pgtable-arm.c | 18 +++++++++---------
> > drivers/iommu/ipmmu-vmsa.c | 2 +-
> > drivers/iommu/msm_iommu.c | 2 +-
> > drivers/iommu/mtk_iommu.c | 2 +-
> > drivers/iommu/qcom_iommu.c | 2 +-
> > include/linux/io-pgtable.h | 2 +-
> > 10 files changed, 26 insertions(+), 26 deletions(-)
>
> I was a bit nervous about us passing GFP_KERNEL with a spinlock held, but
> it looks like you've checked all the callsites and it looks fine to me, so:
>
> Acked-by: Will Deacon <will@...nel.org>
>
> Joerg -- not sure what you want to do with this one, as it's likely to
> conflict (trivially) with unrelated driver changes.
Thanks Will. Joerg, could you apply this 2 patches if no objection from
your side? Thanks.
Powered by blists - more mailing lists