From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754073AbdCIWbm (ORCPT ); Thu, 9 Mar 2017 17:31:42 -0500 Received: from mail5.windriver.com ([192.103.53.11]:48058 "EHLO mail5.wrs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753981AbdCIWbk (ORCPT ); Thu, 9 Mar 2017 17:31:40 -0500 Date: Thu, 9 Mar 2017 17:31:32 -0500 From: Paul Gortmaker To: Peter Rosin CC: , Jonathan Cameron Subject: Re: [PATCH] mux-core: make it explicitly non-modular Message-ID: <20170309223132.GJ7825@windriver.com> References: <20170307224115.9394-1-paul.gortmaker@windriver.com> <05d65cbe-340a-740c-6cb3-2c63d21ea4d9@axentia.se> <20170308143847.GA22171@windriver.com> <0945642d-0f21-3b92-d90a-6999e1d47900@axentia.se> <20170309003253.GD22171@windriver.com> <6e336af0-792d-f0fa-face-f23007cbaca3@axentia.se> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <6e336af0-792d-f0fa-face-f23007cbaca3@axentia.se> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [Re: [PATCH] mux-core: make it explicitly non-modular] On 09/03/2017 (Thu 13:01) Peter Rosin wrote: > On 2017-03-09 10:39, Peter Rosin wrote: > > *snip* *snip* > > >> Per the above use case (minimal vmlinux) the unload isn't so important, > >> and in many cases it may be racy or simply not make sense. If that is > >> the case, you don't need to provide a module_exit, and in the past I > >> think we used to bump the module use count at a successful load to > >> prevent unloading ; there might be a more elegant method now; google is > >> your friend here. Also, I don't think name reuse/confusion is an issue. > > > > Ok, I thought it all boiled down to making the mux-core Kconfig a tristate > > option and changing subsys_initcall(...) to module_init(...). > > > > But if I do that, I cannot be sure that the mux-core has been initialized > > before drivers and clients start to use it in the non-modular case (if > > things are modules, the dependencies should ensure that the mux-core is > > loaded/initialized before any users are loaded). But there is no > > topological sorting going on for ordering init calls in the non-modular > > case. > > > > In short, I get: > > > > WARNING: CPU: 0 PID: 1 at drivers/base/class.c:438: class_find_device+0xac/0xb8 > > class_find_device called for class 'mux' before it was initialized [...] > > > > So, it appears that I also have to determine if the core has been > > initialized in all its entry points and return -EPROBE_DEFER (or something) > > when not. I suppose I could instead initialize on-demand, but that seems > > more difficult the do without races... > > > > Am I missing something? > > I did some digging and e.g. drivers/uwb was moved before drivers/usb in > commit ae5d82cb8d60 ("uwb: build UWB before USB/WUSB") to resolve what > appears to be a similar situation. I suppose I could just move mux up in > drivers/Makefile so that it is before both i2c and iio. So, you can "cheat" and leave it as subsys_initcall (and add a comment why it is) and it will be subsys_initcall when built-in and module_init when modular -- that should work too, and if you look around you'll probably see many other existing instances of that going on. init.h #ifndef MODULE [...] #define subsys_initcall(fn) __define_initcall(fn, 4) module.h #else /* MODULE */ [...] #define subsys_initcall(fn) module_init(fn) Paul. -- > > Cheers, > peda >