Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp3545463imm; Wed, 5 Sep 2018 01:49:10 -0700 (PDT) X-Google-Smtp-Source: ANB0VdanUzlATczvcu9KXGWXdlFDn4Y/J6mUhNzYeTzqPSTvYfc3KWpnKitei4/BmWiTo59Szx9G X-Received: by 2002:a63:6501:: with SMTP id z1-v6mr20318824pgb.419.1536137350104; Wed, 05 Sep 2018 01:49:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536137350; cv=none; d=google.com; s=arc-20160816; b=XCMlGFYgIP6WfWaNm3GRjdza6KrgRz8T5bOP340hQXuGNYlSHSVNEZGIWrnB3JSM+b 7IHC24gzp3bsoaMG/BPoeZTivb4N9RZAd42ar36C3Q0sJnMM6OlfEw6CLyt00iv7sYY9 n997RxYFR2eP+DtUjulFD1AQmzk7FEyO1vwj1ld8zyYHOi/DkiZiFJT4W+0kzQjvCxOx uOewbV5DKlihpz174cjW1ugyTPd9Ot4iHB41yzlx2kWwikRTWOPeRQsgd1dXWn8729J5 vOHOvKw9WgEkEuzmkB0TZ2bi3xVknMzMC+d/6nfMHWnqqSY8aLL3GvEgn8yIJfwQvx9j lwsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=12x8icumOoH8gljiy8fMleJPUAxFo7mJ01/mik7IOro=; b=Hrhkeg/Tu5anLggbD9Hcl7ARrfqcs+KBPdaf5lvEc6NVajOCVm5p4nxKZRj925UoSS kiCx8387vUL1wHbyOYsNbR7EdWayrJaLdrYNHYvUGBR54TYFhz+HFxh7WFya7zUGqCbQ jq2+ANCrDV7WA3nSqhDOckAbmjBJlDRiN+c7UGo7Ng1PDftyyZ+d4c1Xg/dKF5s1/IvH JH+0osj2eiQA7peCercNIZejDeIyO33Ha+uF/iUICS2LGbl7D5DkUKB+kB3BbLrco8Jm dC+7IrHd5AW+PAjXYrbNZHuQaViM6YF9ww50MAm4dUa7zpjWSUefJQVmq6F/zLUn7YCS wqMQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 d1-v6si1393228pla.103.2018.09.05.01.48.53; Wed, 05 Sep 2018 01:49:10 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727835AbeIENQ7 (ORCPT + 99 others); Wed, 5 Sep 2018 09:16:59 -0400 Received: from bmailout3.hostsharing.net ([176.9.242.62]:48307 "EHLO bmailout3.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726401AbeIENQ7 (ORCPT ); Wed, 5 Sep 2018 09:16:59 -0400 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout3.hostsharing.net (Postfix) with ESMTPS id 34D7F100E4162; Wed, 5 Sep 2018 10:47:47 +0200 (CEST) Received: by h08.hostsharing.net (Postfix, from userid 100393) id CEFA8597FA; Wed, 5 Sep 2018 10:47:46 +0200 (CEST) Date: Wed, 5 Sep 2018 10:47:46 +0200 From: Lukas Wunner To: Mika Westerberg Cc: linux-kernel@vger.kernel.org, Andreas Noever , Michael Jamet , Yehezkel Bernat , Lu Baolu Subject: Re: [PATCH 2/2] thunderbolt: Initialize after IOMMUs Message-ID: <20180905084746.xmckzskxzsdliz3e@wunner.de> References: <20180903132012.23531-1-mika.westerberg@linux.intel.com> <20180903132012.23531-2-mika.westerberg@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180903132012.23531-2-mika.westerberg@linux.intel.com> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 03, 2018 at 04:20:12PM +0300, Mika Westerberg wrote: > If IOMMU is enabled and Thunderbolt driver is built into the kernel > image, it will be probed before IOMMUs are attached to the PCI bus. > Because of this DMA mappings the driver does will not go through IOMMU > and start failing right after IOMMUs are enabled. > > For this reason move the Thunderbolt driver initialization happen at > rootfs level. > > Signed-off-by: Mika Westerberg > --- > drivers/thunderbolt/nhi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/thunderbolt/nhi.c b/drivers/thunderbolt/nhi.c > index 88cff05a1808..5cd6bdfa068f 100644 > --- a/drivers/thunderbolt/nhi.c > +++ b/drivers/thunderbolt/nhi.c > @@ -1191,5 +1191,5 @@ static void __exit nhi_unload(void) > tb_domain_exit(); > } > > -fs_initcall(nhi_init); > +rootfs_initcall(nhi_init); > module_exit(nhi_unload); What if the rootfs is located on a Thunderbolt-attached drive and the thunderbolt driver needs to establish tunnels to that drive before rootfs can be accessed? Doesn't the above break such a setup? I think the dependency on the IOMMU should be open coded by returning -EPROBE_DEFER from the ->probe hook if it's not yet attached. Shuffling around initcall order is just applying duct tape. Commit acb40d841257 already changed module_init() to fs_initcall() and now it has to be changed again. Shows how fragile this is. Thanks, Lukas