Received: by 2002:a17:90b:8d0:0:0:0:0 with SMTP id ds16csp5063444pjb; Mon, 27 Jul 2020 11:59:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyCj3qtA+jfshrz2q+u+AzkS9FyOqIr8hM37SZVzfI7i2i99YhQEwSLmt8OfFhrUEPm4xJs X-Received: by 2002:aa7:da4c:: with SMTP id w12mr22086076eds.122.1595876382805; Mon, 27 Jul 2020 11:59:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595876382; cv=none; d=google.com; s=arc-20160816; b=QobUjPAGXHSA9Q3LQmkc27LylShzC4FtHmACFB8OtNAUU4qZZDgg8DbaGBPv4QassA 2USATZu0k1x9tbTxUVP15+GJke5LZO0SM13eszcOKI1ZjUUWxOlfjLncxtrFJAFhTFkB WmlA6y4bFctBJlxQTgBzGaoisxr90Keiz8oa7GpF9HoCu9UeULR2X4UNJca5MW9HJZmL yWWyGva4ahrEr49Vf5n9GpAamuHwlDKa1NoY3Ifu0D9OY01PWnZV/5MyMkyRYyW//inc jTYre9DRIRCi5vBpvhYymSKnXxoXhvVOkcl+4Z/J5M58Z5K2YvfN9mwb1gPZfLUlOriV OAKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=S/d3QZopmWoMCylBWlEjyseL3UZKFwkafoCw5DPEfRk=; b=T4ZDTEh1gz+cxJ2kLGBaLE1mSlUMDgepGws0SImciRSnqI4E4AoMjdO9EwAkSwtOhj iuoiAQAQNJVeWAKfC4GVa+Cw3WwKl1+eBXbT6Mm9cWy6PR9h+NlFVc9nc8ylT+BXYfI0 7c2KVzLFT2wkeV4iDUXJey+oAHMudEX0oIclE80B+m8xyGlbxt6Z/v3GQzUl//Mxx41a 37N7nVzDYVJMnO6AX/CZnBH46sGYTFZiYT5c3IY9JfRmIxOJNNlke8EpPq/3mK+HHqEg AYya8uaWAEsaTA9Wk+YZJe/TOOTUBJLDnHgkQwQysVYkC9lSHBSfezgRPRM92Jb1qJBy MZhw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 8si6106117edv.523.2020.07.27.11.59.20; Mon, 27 Jul 2020 11:59:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731219AbgG0Rcf (ORCPT + 99 others); Mon, 27 Jul 2020 13:32:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38750 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726617AbgG0Rcf (ORCPT ); Mon, 27 Jul 2020 13:32:35 -0400 Received: from shards.monkeyblade.net (shards.monkeyblade.net [IPv6:2620:137:e000::1:9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 76076C061794; Mon, 27 Jul 2020 10:32:35 -0700 (PDT) Received: from localhost (unknown [IPv6:2601:601:9f00:477::3d5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 60921128719F1; Mon, 27 Jul 2020 10:15:49 -0700 (PDT) Date: Mon, 27 Jul 2020 10:32:33 -0700 (PDT) Message-Id: <20200727.103233.2024296985848607297.davem@davemloft.net> To: andrew@lunn.ch Cc: ilial@codeaurora.org, kuba@kernel.org, jiri@mellanox.com, edumazet@google.com, ap420073@gmail.com, xiyou.wangcong@gmail.com, maximmi@mellanox.com, ilia.lin@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] net: dev: Add API to check net_dev readiness From: David Miller In-Reply-To: <20200726194528.GC1661457@lunn.ch> References: <1595792274-28580-1-git-send-email-ilial@codeaurora.org> <20200726194528.GC1661457@lunn.ch> X-Mailer: Mew version 6.8 on Emacs 26.3 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]); Mon, 27 Jul 2020 10:15:49 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Andrew Lunn Date: Sun, 26 Jul 2020 21:45:28 +0200 > I also have to wonder why a network device driver is being probed the > subsys_initcall. This makes me wonder how this interface could even be useful. The only way to fix the problem is to change when the device is probed, which would mean changing which initcall it uses. So at run time, this information can't do much.