[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5c7918b6-c506-680b-cb0f-9e5f6a7038d9@arm.com>
Date: Tue, 18 Aug 2020 15:47:55 +0100
From: Robin Murphy <robin.murphy@....com>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: devel@...verdev.osuosl.org, devicetree@...r.kernel.org,
Joerg Roedel <jroedel@...e.de>,
Manivannan Sadhasivam <mani@...nel.org>,
Chenfeng <puck.chen@...ilicon.com>, linuxarm@...wei.com,
Wei Xu <xuwei5@...ilicon.com>, linux-kernel@...r.kernel.org,
iommu@...ts.linux-foundation.org, Rob Herring <robh+dt@...nel.org>,
John Stultz <john.stultz@...aro.org>, mauro.chehab@...wei.com,
Suzhuangluan <suzhuangluan@...ilicon.com>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 00/16] IOMMU driver for Kirin 960/970
On 2020-08-17 08:49, Mauro Carvalho Chehab wrote:
> Add a driver for the Kirin 960/970 iommu.
>
> As on the past series, this starts from the original 4.9 driver from
> the 96boards tree:
>
> https://github.com/96boards-hikey/linux/tree/hikey970-v4.9
>
> The remaining patches add SPDX headers and make it build and run with
> the upstream Kernel.
>
> Chenfeng (1):
> iommu: add support for HiSilicon Kirin 960/970 iommu
>
> Mauro Carvalho Chehab (15):
> iommu: hisilicon: remove default iommu_map_sg handler
> iommu: hisilicon: map and unmap ops gained new arguments
> iommu: hisi_smmu_lpae: rebase it to work with upstream
> iommu: hisi_smmu: remove linux/hisi/hisi-iommu.h
> iommu: hisilicon: cleanup its code style
> iommu: hisi_smmu_lpae: get rid of IOMMU_SEC and IOMMU_DEVICE
> iommu: get rid of map/unmap tile functions
> iommu: hisi_smmu_lpae: use the right code to get domain-priv data
> iommu: hisi_smmu_lpae: convert it to probe_device
> iommu: add Hisilicon Kirin970 iommu at the building system
> iommu: hisi_smmu_lpae: cleanup printk macros
> iommu: hisi_smmu_lpae: make OF compatible more standard
Echoing the other comments about none of the driver patches being CC'd
to the IOMMU list...
Still, I dug the series up on lore and frankly I'm not sure what to make
of it - AFAICS the "driver" is just yet another implementation of Arm
LPAE pagetable code, with no obvious indication of how those pagetables
ever get handed off to IOMMU hardware (and indeed no indication of IOMMU
hardware at all). Can you explain how it's supposed to work?
And as a pre-emptive strike, we really don't need any more LPAE
implementations - that's what the io-pgtable library is all about (which
incidentally has been around since 4.0...). I think that should make the
issue of preserving authorship largely moot since there's no need to
preserve most of the code anyway ;)
Robin.
> dt: add an spec for the Kirin36x0 SMMU
> dt: hi3670-hikey970.dts: load the SMMU driver on Hikey970
> staging: hikey9xx: add an item about the iommu driver
>
> .../iommu/hisilicon,kirin36x0-smmu.yaml | 55 ++
> .../boot/dts/hisilicon/hi3670-hikey970.dts | 3 +
> drivers/staging/hikey9xx/Kconfig | 9 +
> drivers/staging/hikey9xx/Makefile | 1 +
> drivers/staging/hikey9xx/TODO | 1 +
> drivers/staging/hikey9xx/hisi_smmu.h | 196 ++++++
> drivers/staging/hikey9xx/hisi_smmu_lpae.c | 648 ++++++++++++++++++
> 7 files changed, 913 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iommu/hisilicon,kirin36x0-smmu.yaml
> create mode 100644 drivers/staging/hikey9xx/hisi_smmu.h
> create mode 100644 drivers/staging/hikey9xx/hisi_smmu_lpae.c
>
Powered by blists - more mailing lists