From patchwork Fri Jun 23 14:57:59 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Shameerali Kolothum Thodi X-Patchwork-Id: 106266 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp251854qgd; Fri, 23 Jun 2017 07:59:08 -0700 (PDT) X-Received: by 10.99.113.14 with SMTP id m14mr8700530pgc.63.1498229948119; Fri, 23 Jun 2017 07:59:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498229948; cv=none; d=google.com; s=arc-20160816; b=0vqEAjCev9XuIH9G0qVWcaq26qtDGJNxT41WC0ThRh1OaB96biwu6JmuodG88X/YCK 8k5fwXyCr/V4jo14wI6zPBcUkOKYyGCsW8Zfz8/f83WqTtv6gnIyo/8nH6GnNvMJhm/7 rYVqDHdUUFo0G7gaJffmmEom+BaztoQoFOYkhDNTNDA+of51aoBMRdHp/vSbBLmwiD1Y BKNOLk9UHxI9tcGYyGkg4eFp5iZQXjEEdZx7FlJzQGSfR1eOmdbsI+feYm17RyUB09dr jYWtdskZ9IlG1FSG6j+FmMn1Gzl3pY6ZwWgMRiF8cfZ9pCIDWMwcKmWRR49uz91ewmxf FKOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=thlg+2vEQ6O7CsG8DNse4+2qSIHe8x+1VV55DBznIdk=; b=p6eQiI1wgTITPRDKwzgRG/V9SWAKsHachnlPb/mSYGuCHDi4clnJ4tjjaLbIAlMKWa 7rHLEsU0GKAOqqar7s2XOg2d0nacTLbL3O0NSvnswyklaapBuEdsZbtZKh55EvH80M3q kpekqW1cYjZzvO/duYaPBO6YUUH1cbpAdeOC/862PEnevF1qSAXBtmyy56EMLVFmAsUH MQnQdmssPEXnRKZmsl1ydbCoO3wWW/38X70Yt1o/3abjnHzDV5wcHaDHJRI1rSnzkWdF CfjaNe91OLVaM2/PmKKPXumkw1dClhIEfO8HwV8MC7zKgPXPvkQdebuVNF4/rtgnZgkr mShw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p11si3597830pgn.190.2017.06.23.07.59.07; Fri, 23 Jun 2017 07:59:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-acpi-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-acpi-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754413AbdFWO7H (ORCPT + 8 others); Fri, 23 Jun 2017 10:59:07 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:8834 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754411AbdFWO7G (ORCPT ); Fri, 23 Jun 2017 10:59:06 -0400 Received: from 172.30.72.54 (EHLO DGGEML402-HUB.china.huawei.com) ([172.30.72.54]) by dggrg02-dlp.huawei.com (MOS 4.4.6-GA FastPath queued) with ESMTP id APW88329; Fri, 23 Jun 2017 22:58:59 +0800 (CST) Received: from S00345302A-PC.china.huawei.com (10.203.177.212) by DGGEML402-HUB.china.huawei.com (10.3.17.38) with Microsoft SMTP Server id 14.3.301.0; Fri, 23 Jun 2017 22:58:47 +0800 From: shameer To: , , , , , CC: , , , , , , , , , shameer Subject: [PATCH v3 0/2] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI) Date: Fri, 23 Jun 2017 15:57:59 +0100 Message-ID: <20170623145801.325244-1-shameerali.kolothum.thodi@huawei.com> X-Mailer: git-send-email 2.12.0.windows.1 MIME-Version: 1.0 X-Originating-IP: [10.203.177.212] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.594D2CB4.01B0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e792d87ee9901dee47b360a78646dcfa Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On certain HiSilicon platforms (Hip06/Hip07) the GIC ITS and PCIe RC deviates from the standard implementation and this breaks PCIe MSI functionality when SMMU is enabled. The HiSilicon erratum 161010801 describes this limitation of certain HiSilicon platforms to support the SMMU mappings for MSI transactions. On these platforms GICv3 ITS translator is presented with the deviceID by extending the MSI payload data to 64 bits to include the deviceID. Hence, the PCIe controller on this platforms has to differentiate the MSI payload against other DMA payload and has to modify the MSI payload. This basically makes it difficult for this platforms to have a SMMU translation for MSI. This patch implements a ACPI table based quirk to reserve the hw msi regions in the smmu-v3 driver which means these address regions will not be translated and will be excluded from iova allocations. To implement this quirk, the following changes are incorporated: 1. Added a generic helper function to IORT code to retrieve and reserve the HW ITS address regions. 2. Added quirk to SMMUv3 to reserve HW ITS address regions based on IORT SMMUv3 model. This is based on the following patches: 1. https://patchwork.kernel.org/patch/9740733/ 2. https://patchwork.kernel.org/patch/9730491/ Thanks, Shameer Changelog: v2 --> v3 Addressed comments from Lorenzo and Robin: -Removed dev_is_pci() check in smmuV3 driver. -Don't treat device not having an ITS mapping as an error in iort helper function. v1 --> v2 -patch 2/2: Invoke iort helper fn based on fwnode type(acpi). RFCv2 -->PATCH -Incorporated Lorenzo's review comments. RFC v1 --> RFC v2 Based on Robin's review comments, -Removed the generic erratum framework. -Using IORT/MADT tables to retrieve the ITS base addr instead of vendor specific CSRT table. shameer (2): acpi:iort: Add an IORT helper function to reserve HW ITS address regions for IOMMU drivers iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801 drivers/acpi/arm64/iort.c | 91 ++++++++++++++++++++++++++++++++++++++-- drivers/iommu/arm-smmu-v3.c | 30 +++++++++++-- drivers/irqchip/irq-gic-v3-its.c | 3 +- include/linux/acpi_iort.h | 7 +++- 4 files changed, 122 insertions(+), 9 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html