From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Mon, 01 Dec 2014 14:52:57 +0100 Subject: [PATCH v5 0/8] Introduce automatic DMA configuration for IOMMU masters In-Reply-To: <1417181386-18142-1-git-send-email-will.deacon@arm.com> References: <1417181386-18142-1-git-send-email-will.deacon@arm.com> Message-ID: <2496335.D95hVHbola@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Friday 28 November 2014 13:29:38 Will Deacon wrote: > Hi all, > > Here is v5 of the patches I've previously sent here: > > RFCv1: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/283023.html > RFCv2: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/283752.html > RFCv3: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/287031.html > RFCv4: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/302711.html > > Changes since RFCv4 include: > > - Dropped the RFC tag, since has been used by a couple of people now > > - Dropped the DMA segment configuration from of_dma_configure, as there > appear to be assumptions about 64k segments elsewhere in the kernel > > - Added acks/tested-bys (thanks to everybody who reviewed the series) > > - A few small fixes for issues found by Marek > > Arnd: Is this too late for 3.19? We could merge the first 6 patches > with no issues, since there aren't any callers of of_iommu_init > without patch 7 anyway. > > Up to you. I think this looks great overall. My only feedback is the exact same comment that Joerg already made: On Friday 28 November 2014 14:03:36 jroedel at suse.de wrote: > Hmm, I don't like the idea of storing private data in iommu_ops. But > given that this is already an improvement we can build on later, here is > my > > Acked-by: Joerg Roedel > > To further improve this we should probably introduce a seperate > iommu-descriptor data-structure later which then describes a single > hardware iommu device. so I second that and add my Acked-by: Arnd Bergmann Now, who should merge this series? I think someone should put all eight patches into linux-next now, and if something goes wrong with the last two, then we skip them for 3.19. Arnd