From: Russell King <rmk@arm.linux.org.uk>
To: linux-kernel@vger.kernel.org
Subject: Initcall / device model meltdown?
Date: Fri, 17 Jan 2003 19:23:56 +0000 [thread overview]
Message-ID: <20030117192356.F13888@flint.arm.linux.org.uk> (raw)
The initcall/device model seems to be quite fragile at the moment with
respect to not oopsing the kernel.
On many StrongARM-based systems, a multifunction chip addressed through
a serial bus is used to provide touchscreen, audio and additional digital
IO. Currently, there are many sub-drivers, some of which are modular
themselves, and some which depend on each other. They currently live
under drivers/misc, for want of a better location. They are all
initialised using module_init(), via the device model driver_register()
function.
The input drivers are also modular, and provide a device class
(input_devclass), which is registered using module_init().
One of the multifunction device drivers is a touchscreen driver, which
should obviously be part of the input device class.
Both the input core and the multifunction chip drivers are using
module_init(), the order in which these are initialised is link-order
specific, and it happens that drivers/input is initialised really late
during boot, after drivers/misc.
Since the device model requires any object to be initialised before it
is used, this causes an oops from devclass_add_driver().
We appear to have two conflicting requirements here:
1. the device model requires a certain initialisation order.
2. modules need to use module_init() which means the initialisation order
is link-order dependent, despite our multi-level initialisation system.
Obviously one solution would be to spread the drivers for this
multifunction chip throughout the kernel tree (ie, by function not
by device) so the touchscreen driver would live under drivers/input.
However, then we need to make sure that the multifunction chip's
bus type is initialised before any of the other subsystems, and of
course, the bus type is initialised using module_init() since it
lives in a module...
I think we need to re-think what we're doing with the initialisation
handling and the device model before these sorts of problems get out
of hand.
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
next reply other threads:[~2003-01-17 19:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-17 19:23 Russell King [this message]
2003-01-17 19:32 ` Initcall / device model meltdown? Jeff Garzik
[not found] ` <3104.1042835842@www5.gmx.net>
2003-01-17 20:48 ` Dominik Brodowski
2003-01-17 19:56 ` Kai Germaschewski
2003-01-17 20:14 ` Russell King
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=20030117192356.F13888@flint.arm.linux.org.uk \
--to=rmk@arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
/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