Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751562AbdGZNxV convert rfc822-to-8bit (ORCPT ); Wed, 26 Jul 2017 09:53:21 -0400 Received: from gloria.sntech.de ([95.129.55.99]:49796 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750921AbdGZNxT (ORCPT ); Wed, 26 Jul 2017 09:53:19 -0400 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Joerg Roedel Cc: Simon Xue , Rob Herring , Mark Rutland , linux-rockchip@lists.infradead.org, iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org Subject: Re: [PATCH V3 1/4] ARM64: dts: rockchip: rk3328 add iommu nodes Date: Wed, 26 Jul 2017 15:53:06 +0200 Message-ID: <1668393.AqADimcrsl@diego> User-Agent: KMail/5.2.3 (Linux/4.8.0-2-amd64; KDE/5.27.0; x86_64; ; ) In-Reply-To: <20170726122753.GQ15833@8bytes.org> References: <1500863530-32792-1-git-send-email-xxm@rock-chips.com> <7545443.2JTXH2SMA9@diego> <20170726122753.GQ15833@8bytes.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 973 Lines: 24 Hi Joerg, Am Mittwoch, 26. Juli 2017, 14:27:53 CEST schrieb Joerg Roedel: > On Wed, Jul 26, 2017 at 01:44:02PM +0200, Heiko St?bner wrote: > > I really would prefer iommu dt-nodes going through my tree :-) > > > > Especially as parts of these conflict with already pending patches for > > graphics support and with the iommu nodes sitting in your tree these > > would need to wait another kernel release. > > Sure, no problem. I have nothing pushed yet, so it's easy to remove > again. Do you want to take all three patch-sets from Simon through your > tree or just this one? no, I'm of course fine with (and even very much in favor of) iommu-code going through your tree :-) . I just want to keep the devicetree changes together to prevent conflicts (and unnecessary wait times). Having code and dts changes go through different trees is no problem, as they don't have a compile-time dependencies on each other and come together nicely in linux-next again. Heiko