From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED0F6C433F5 for ; Thu, 6 Sep 2018 11:47:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A92C720857 for ; Thu, 6 Sep 2018 11:47:03 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A92C720857 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727677AbeIFQWG (ORCPT ); Thu, 6 Sep 2018 12:22:06 -0400 Received: from mga06.intel.com ([134.134.136.31]:27971 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725929AbeIFQWG (ORCPT ); Thu, 6 Sep 2018 12:22:06 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Sep 2018 04:47:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,338,1531810800"; d="scan'208";a="72078596" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.157]) by orsmga006.jf.intel.com with SMTP; 06 Sep 2018 04:46:53 -0700 Received: by lahna (sSMTP sendmail emulation); Thu, 06 Sep 2018 14:46:52 +0300 Date: Thu, 6 Sep 2018 14:46:52 +0300 From: Mika Westerberg To: Lukas Wunner 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: <20180906114652.GK2283@lahna.fi.intel.com> References: <20180903132012.23531-1-mika.westerberg@linux.intel.com> <20180903132012.23531-2-mika.westerberg@linux.intel.com> <20180905084746.xmckzskxzsdliz3e@wunner.de> <20180905094602.GH2283@lahna.fi.intel.com> <20180906081337.3mosfpfggfmoj633@wunner.de> <20180906103602.GV2283@lahna.fi.intel.com> <20180906110049.gfdhurvkvvdjw7zh@wunner.de> <20180906110756.GY2283@lahna.fi.intel.com> <20180906112101.qmhkcqx73zmmko3q@wunner.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180906112101.qmhkcqx73zmmko3q@wunner.de> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 06, 2018 at 01:21:01PM +0200, Lukas Wunner wrote: > On Thu, Sep 06, 2018 at 02:07:56PM +0300, Mika Westerberg wrote: > > On Thu, Sep 06, 2018 at 01:00:49PM +0200, Lukas Wunner wrote: > > > On Thu, Sep 06, 2018 at 01:36:02PM +0300, Mika Westerberg wrote: > > > > On Thu, Sep 06, 2018 at 10:13:37AM +0200, Lukas Wunner wrote: > > > > > So with this patch, you rely on the linker ordering nhi_init() after > > > > > ir_dev_scope_init(), however to the best of my knowledge the link > > > > > order is not guaranteed. > > > > > > > > What says that? > > > > > > Within the same initcall level, the ordering is determined by the Makefile > > > AFAIK. Someone changes the Makefile, your dependency scheme falls apart. > > > > There are other drivers doing the same so they would fail as well. It is > > common practice AFAIK. > > That doesn't make it a *good* practice. It is good enough for our case. > > > > > Looking at commit acb40d841257, which started this, I'm wondering > > > > > why you did not simply export tbnet_init() and call it from the > > > > > thunderbolt driver after the property stuff has been fully set up? > > > > > After all, thunderbolt-net is useless without thunderbolt or am I > > > > > missing something? Then you could revert back to module_init(). > > > > > > > > The same reason you don't call PCI driver functions from PCI core. It > > > > makes absolutely zero sense. > > > > > > > > Thunderbolt is bus and provides driver API to drivers. We hopefully are > > > > getting other service drivers (say SCSI over TBT) that are going to be > > > > use the same interfaces. > > > > > > Then add a blocking notifier chain into which these service drivers can > > > hook. Other buses have that as well. > > > > It is really too complex to add notifier just for that. This works fine > > and is not against any kernel principles I am aware of. > > Well, there's a difference between "it works and gets the job done, > let's move on" and "let's try to find a solution that fixes not just > this use case but potentially benefits others as well". > > FWIW, what I had in mind is a blocking notifier chain that gets called > when a bus registers or unregisters. TB service drivers would then check > if it's tb_bus_type and start initialization. Like I said, I think it is too complex. If we ever need to change the initcall level third time (which I doubt) we can start thinking about more complex solutions.