From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Subject: Re: [PATCH] RFC: platform driver registering via initcall tables Date: Tue, 17 Dec 2019 15:50:03 +0100 Message-ID: <20191217145003.GB3639802@kroah.com> References: <20191217102219.29223-1-info@metux.net> <20191217103152.GB2914497@kroah.com> <6422bc88-6d0a-7b51-aaa7-640c6961b177@metux.net> <20191217140646.GC3489463@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: "Enrico Weigelt, metux IT consult" Cc: "Enrico Weigelt, metux IT consult" , linux-kernel@vger.kernel.org, linus.walleij@linaro.org, bgolaszewski@baylibre.com, dmitry.torokhov@gmail.com, jacek.anaszewski@gmail.com, pavel@ucw.cz, dmurphy@ti.com, arnd@arndb.de, masahiroy@kernel.org, michal.lkml@markovi.net, kafai@fb.com, songliubraving@fb.com, yhs@fb.com, andriin@fb.com, linux-gpio@vger.kernel.org, linux-input@vger.kernel.org, linux-leds@vger.kernel.org, linux-arch@vger.kernel.org, linux-kbuild@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org List-Id: linux-arch.vger.kernel.org On Tue, Dec 17, 2019 at 03:43:56PM +0100, Enrico Weigelt, metux IT consult wrote: > On 17.12.19 15:06, Greg KH wrote: > > > That's not needed, and you are going to break the implicit ordering we > > already have with link order. > > Ups, 10 points for you - I didn't consider that. > > > You are going to have to figure out what > > bus type the driver is, to determine what segment it was in, to figure > > out what was loaded before what. > > hmm, if it's just the ordering by bus type (but not within one bus > type), then it shouldn't be the big deal to fix, as I'll need one table > and register-loop per bus-type anyways. > > By the way: how is there init order ensured with dynamically loaded > modules ? (for cases where there aren't explicit symbol dependencies) See the recent work in the driver core for DT fixes for that very issue. greg k-h From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from new2-smtp.messagingengine.com ([66.111.4.224]:42573 "EHLO new2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727127AbfLQOuI (ORCPT ); Tue, 17 Dec 2019 09:50:08 -0500 Date: Tue, 17 Dec 2019 15:50:03 +0100 From: Greg KH Subject: Re: [PATCH] RFC: platform driver registering via initcall tables Message-ID: <20191217145003.GB3639802@kroah.com> References: <20191217102219.29223-1-info@metux.net> <20191217103152.GB2914497@kroah.com> <6422bc88-6d0a-7b51-aaa7-640c6961b177@metux.net> <20191217140646.GC3489463@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-ID: To: "Enrico Weigelt, metux IT consult" Cc: "Enrico Weigelt, metux IT consult" , linux-kernel@vger.kernel.org, linus.walleij@linaro.org, bgolaszewski@baylibre.com, dmitry.torokhov@gmail.com, jacek.anaszewski@gmail.com, pavel@ucw.cz, dmurphy@ti.com, arnd@arndb.de, masahiroy@kernel.org, michal.lkml@markovi.net, kafai@fb.com, songliubraving@fb.com, yhs@fb.com, andriin@fb.com, linux-gpio@vger.kernel.org, linux-input@vger.kernel.org, linux-leds@vger.kernel.org, linux-arch@vger.kernel.org, linux-kbuild@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org Message-ID: <20191217145003.tNBUKJzfjVh4zsJpX7WcsZEpzbrOpweRWmciJeMTvu0@z> On Tue, Dec 17, 2019 at 03:43:56PM +0100, Enrico Weigelt, metux IT consult wrote: > On 17.12.19 15:06, Greg KH wrote: > > > That's not needed, and you are going to break the implicit ordering we > > already have with link order. > > Ups, 10 points for you - I didn't consider that. > > > You are going to have to figure out what > > bus type the driver is, to determine what segment it was in, to figure > > out what was loaded before what. > > hmm, if it's just the ordering by bus type (but not within one bus > type), then it shouldn't be the big deal to fix, as I'll need one table > and register-loop per bus-type anyways. > > By the way: how is there init order ensured with dynamically loaded > modules ? (for cases where there aren't explicit symbol dependencies) See the recent work in the driver core for DT fixes for that very issue. greg k-h