Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752084AbdCCR44 (ORCPT ); Fri, 3 Mar 2017 12:56:56 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:51668 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751862AbdCCR4y (ORCPT ); Fri, 3 Mar 2017 12:56:54 -0500 Date: Fri, 03 Mar 2017 09:56:35 -0800 (PST) Message-Id: <20170303.095635.355325147613813698.davem@davemloft.net> To: sunil.kovvuri@gmail.com Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, sgoutham@cavium.com Subject: Re: [PATCH 1/4] net: thunderx: Fix IOMMU translation faults From: David Miller In-Reply-To: <1488538070-12549-2-git-send-email-sunil.kovvuri@gmail.com> References: <1488538070-12549-1-git-send-email-sunil.kovvuri@gmail.com> <1488538070-12549-2-git-send-email-sunil.kovvuri@gmail.com> X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 03 Mar 2017 09:56:36 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1002 Lines: 27 From: sunil.kovvuri@gmail.com Date: Fri, 3 Mar 2017 16:17:47 +0530 > @@ -1643,6 +1650,9 @@ static int nicvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent) > if (!pass1_silicon(nic->pdev)) > nic->hw_tso = true; > > + /* Check if we are attached to IOMMU */ > + nic->iommu_domain = iommu_get_domain_for_dev(dev); This function is not universally available. This looks very hackish to me anyways, how all of this stuff is supposed to work is that you simply use the DMA interfaces unconditionally and whatever is behind the operations takes care of everything. Doing it conditionally in the driver with all of this special IOMMU domain et al. knowledge makes no sense to me at all. I don't see other drivers doing stuff like this at all, so if you're going to handle this in a unique way like this you better write several paragraphs in your commit message explaining why this weird crap is necessary. There is no way I can apply this series as it is current written. Thanks.