From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Greg KH <greg@kroah.com>
Cc: "Enrico Weigelt, metux IT consult" <info@metux.net>,
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
Subject: Re: [PATCH] RFC: platform driver registering via initcall tables
Date: Tue, 17 Dec 2019 15:43:56 +0100 [thread overview]
Message-ID: <d938b8e1-d9ce-9ad6-4178-86219e99d4df@metux.net> (raw)
In-Reply-To: <20191217140646.GC3489463@kroah.com>
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)
--mtx
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
next prev parent reply other threads:[~2019-12-17 14:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 10:22 Enrico Weigelt, metux IT consult
2019-12-17 10:31 ` Greg KH
2019-12-17 13:44 ` Enrico Weigelt, metux IT consult
2019-12-17 14:06 ` Greg KH
2019-12-17 14:43 ` Enrico Weigelt, metux IT consult [this message]
2019-12-17 14:50 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d938b8e1-d9ce-9ad6-4178-86219e99d4df@metux.net \
--to=lkml@metux.net \
--cc=andriin@fb.com \
--cc=arnd@arndb.de \
--cc=bgolaszewski@baylibre.com \
--cc=bpf@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=dmurphy@ti.com \
--cc=greg@kroah.com \
--cc=info@metux.net \
--cc=jacek.anaszewski@gmail.com \
--cc=kafai@fb.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=netdev@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=songliubraving@fb.com \
--cc=yhs@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®