From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755540AbcA1OTm (ORCPT ); Thu, 28 Jan 2016 09:19:42 -0500 Received: from mout.kundenserver.de ([217.72.192.74]:53899 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755327AbcA1OSV (ORCPT ); Thu, 28 Jan 2016 09:18:21 -0500 From: Arnd Bergmann To: Robin Murphy Cc: Mark Rutland , Suravee Suthikulpanit , will.deacon@arm.com, robh+dt@kernel.org, pawel.moll@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, arm@kernel.org, brijeshkumar.singh@amd.com, thomas.lendacky@amd.com, leo.duran@amd.com Subject: Re: [PATCH 11/13] dtb: amd: Add PCIe SMMU device tree node Date: Thu, 28 Jan 2016 15:17:33 +0100 Message-ID: <6645680.g0j8d12m6d@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <56AA07AA.7050701@arm.com> References: <1453929121-12171-1-git-send-email-Suravee.Suthikulpanit@amd.com> <20160128111453.GG17123@leverpostej> <56AA07AA.7050701@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:c6QLxHDDtWjUUevBsc8cIyNYNNAWr4Ccnb6vx1Z78yIl8dYxmva 0saWq8Y2LGX4k+cpy3X1O2NtxWJICCF41V97O/TGlVDpAGqKq+IaGvMS7prOKWtxw3yDxM9 MnPSf9NTsN+fA6MrkKu+lAsy0EYfndOizNeeuFj+s97WhMdK59L30iUPKQVrLRN3E9n9F7A SUp4UX6FimM9GC0996L2g== X-UI-Out-Filterresults: notjunk:1;V01:K0:oAiTN/9AWI4=:qJBhFudWmqG+r3UwER2GEy 63qRAr1SkaABr9L1StYrwE8Wz+SKhufI8WZaTKOioFt4X62ynmco6G0LuYcmLkwpg7oKsmPmN l9SeVCKd2n0/MS1oEk1SFcrs3/1vETy/qicVrGDaQcuw63lMcWon4FQv3QLkxV6KxTLpQFjoM 2u9pLX8NOcABIo/XgfcBlIHtJta5XB67skUNGzOjFyoYcewvOas7MZR17myRdSsolUgeUZc0s iwEv7F48VOQxI//FTKgHfXbhY01jQ+WQ6mPbjDb9RT53epV1MbB9DLqqAX3uYTGjRr3id+8Je oA4aPSlJDAVx1jUJbLyp8i9edvF7wTG7eM3A4zXeGxsSi6mr4GIcq9S5ytgeRuYq1SALlxigL iptKBHx23DoA2olQo+NzqbabyzbB5h5+qy+0RDpiXFxYyDqpOhxKDyizlDEvEnk7BT0Gt9tCY BEecZLuaMmXNbl7SdWGGfrjiixjdhLmGL6CY/0K1mUllm/PGxKpAL+ICmxcTcoyKLd9NhzD2S OJI4OgGs8JcI6jEOrM+uXiQX+0hHeGnHmC19bqJWDqSQemav5NSop/UPV2pJJmpzqzaWhEsbc HqArPrHCFztr4kQk7xONxjoPGOd7ZUg5dHg6KXt/o5Hx6vW0CEyM0NtFLgkm3zFjTQByuTn1N JPv3l4NM/4prAa/SDkH1DsXYpwCxsUE+EzRrOe8MnRbWRIwolvLx4iD68BmhAmomV965TDXF0 gRSHMfNGI+NuwijL Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 28 January 2016 12:20:58 Robin Murphy wrote: > > > > Will, Robin, thoughts? > > Any IDs specified here would only apply to DMA by the "platform device" > side of the host controller itself (as would an equivalent "iommus" > property on pcie0 once I finish the SMMUv2 generic binding support I'm > working on). In terms of PCI devices, the "mmu-masters" property is > overloaded such that only its existence matters, to identify that there > _is_ a relationship between the SMMU and the PCI bus(es) behind that > host controller. I wasn't aware that this was actually still specified. I had hoped we were getting rid of mmu-masters before anyone actually started using it, but now I see it in ns2.dtsi and fsl-ls2080a.dtsi. Does anyone know what happened to the plan to use the iommu DT binding for the ARM SMMU instead? Do we now have to support both ways indefinitely? Arnd