From: Jean Delvare <khali@linux-fr.org>
To: David Brownell <david-b@pacbell.net>
Cc: Ryan Mallon <ryan@bluewatersys.com>,
Uli Luckas <u.luckas@road.de>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
i2c@lm-sensors.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH, RFC] Earlier I2C initialization
Date: Wed, 11 Jun 2008 22:54:16 +0200 [thread overview]
Message-ID: <20080611225416.169574a0@hyperion.delvare> (raw)
In-Reply-To: <200806111327.09298.david-b@pacbell.net>
On Wed, 11 Jun 2008 13:27:09 -0700, David Brownell wrote:
> On Wednesday 11 June 2008, Jean Delvare wrote:
> > On Thu, 12 Jun 2008 08:13:09 +1200, Ryan Mallon wrote:
> > > As David suggested, if i2c is needed early
> > > in enough cases, why not just move it early in the link order? My patch
> > > was just an alternative approach which mimics the current behaviour, but
> > > makes it possible to get any i2c driver early. Why not just mark all of
> > > the drivers/busses that get used on embedded devices as subsys_initcall,
> > > just in case somebody needs them early?
> >
> > Because this is an abuse of subsys_initcall? I guess that was
> > acceptable when only a couple drivers were doing that, but making it
> > official sounds bad.
>
> How would it be an abuse? On those systems, I2C is a "system bus"
> and needs to be initialized early for the same reasons PCI gets set
> up very early on PC hardware.
But the pci subsystem doesn't make use of subsys_initcall(). Instead,
it is simply placed early in the link order.
That being said, I'm not sure if the comparison with the PCI subsystem
holds... I am under the impression that PCI bus handling doesn't
require dedicated drivers? At least I can't see any under drivers/pci.
> There's no rule saying that subsystem initialization may not include
> the essential drivers -- in this case, i2c_adapter drivers. PCI hubs
> and bridges are certainly initialized very early, before module_init
> code runs...
Care to point me to actual code to backup this "certainly"?
> And in fact it seems a bit odd to think that initializing any bus
> subsystem shouldn't be allowed to include its bus adapters. It's
> not as if the subsystem has completed initializiation until those
> adapters are usable!!
I think it makes a lot of sense to initialize the core of a subsystem
early, so that all devices and drivers can be registered. This doesn't
imply registering the hardware bus drivers too, even though in some
cases it is also needed. I doubt that whoever designed subsys_initcall
meant it to be used for all bus drivers, otherwise he/she would have
named it, say, busdrv_initcall.
But don't get me wrong: if subsys_initcall is the way to go, that's
alright with me, that's way less work than having to move drivers to
different directories and fixing the link order.
--
Jean Delvare
next prev parent reply other threads:[~2008-06-11 20:54 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200806091541.43899.u.luckas@road.de>
[not found] ` <20080609135739.GE30971@flint.arm.linux.org.uk>
[not found] ` <484D947D.1090900@bluewatersys.com>
[not found] ` <484D947D.1090900-7Wk5F4Od5/oYd5yxfr4S2w@public.gmane.org>
2008-06-09 20:59 ` Earlier I2C initialization David Brownell
[not found] ` <200806091359.12791.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>
2008-06-09 21:27 ` [PATCH, RFC] " Ryan Mallon
2008-06-10 6:57 ` Jean Delvare
2008-06-10 20:55 ` David Brownell
[not found] ` <200806101355.07792.david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>
2008-06-11 8:11 ` Jean Delvare
2008-06-11 9:00 ` Russell King - ARM Linux
[not found] ` <20080611090016.GA5338-f404yB8NqCZvn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2008-06-11 9:14 ` Jean Delvare
[not found] ` <48503432.6010105@bluewatersys.com>
[not found] ` <48503432.6010105-7Wk5F4Od5/oYd5yxfr4S2w@public.gmane.org>
2008-06-11 12:05 ` Jean Delvare
2008-06-11 18:31 ` David Brownell
2008-06-12 18:44 ` Jean Delvare
2008-06-12 19:57 ` David Brownell
2008-06-24 17:06 ` Jean Delvare
[not found] ` <20080611101130.1a667abe-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-06-11 20:23 ` Ryan Mallon
2008-06-10 21:33 ` Ryan Mallon
2008-06-10 9:46 ` Uli Luckas
2008-06-11 3:12 ` Ryan Mallon
2008-06-11 7:40 ` Jean Delvare
[not found] ` <485031D5.3020606@bluewatersys.com>
[not found] ` <485031D5.3020606-7Wk5F4Od5/oYd5yxfr4S2w@public.gmane.org>
2008-06-11 12:18 ` Jean Delvare
2008-06-11 20:27 ` David Brownell
2008-06-11 20:54 ` Jean Delvare [this message]
2008-06-11 21:24 ` Ryan Mallon
[not found] ` <485042A6.3030705-7Wk5F4Od5/oYd5yxfr4S2w@public.gmane.org>
2008-06-24 16:39 ` Jean Delvare
2008-06-26 21:12 ` Ryan Mallon
2008-06-27 10:41 ` Jean Delvare
2008-06-29 20:34 ` Ryan Mallon
2008-06-11 21:31 ` Maciej W. Rozycki
2008-06-12 20:21 ` David Brownell
[not found] ` <20080611094039.287ac136-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2008-06-11 20:13 ` Ryan Mallon
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=20080611225416.169574a0@hyperion.delvare \
--to=khali@linux-fr.org \
--cc=david-b@pacbell.net \
--cc=i2c@lm-sensors.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=ryan@bluewatersys.com \
--cc=u.luckas@road.de \
/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