[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200805222007.07146.david-b@pacbell.net>
Date: Thu, 22 May 2008 20:07:06 -0700
From: David Brownell <david-b@...bell.net>
To: "Maciej W. Rozycki" <macro@...ux-mips.org>
Cc: Jean Delvare <khali@...ux-fr.org>,
Alessandro Zummo <a.zummo@...ertech.it>,
Andrew Morton <akpm@...ux-foundation.org>,
Atsushi Nemoto <anemo@....ocn.ne.jp>,
David Woodhouse <dwmw2@...radead.org>,
Ralf Baechle <ralf@...ux-mips.org>,
Thomas Gleixner <tglx@...utronix.de>,
rtc-linux@...glegroups.com, i2c@...sensors.org,
linux-mips@...ux-mips.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 6/6] RTC: Trivially probe for an M41T80 (#2)
On Tuesday 13 May 2008, Maciej W. Rozycki wrote:
> Then I am not sure how i2c_new_probed_device() could be used for a
> baseboard device. With an option card bearing an I2C adapter it can be
> done at the time the card, including the adapter, is initialized. With a
> baseboard adapter it really begs to be in board initialization.
One idiom to consider is callbacks (or notifications) when the
relevant i2c_adapter is registered.
Some of the GPIO drivers do that, so that they can hook up the
relevant devices or options. Example, when an pcf8574 expander
is used to drive LEDs, the "this chip got registered" callback
can register the relevant "leds-gpio" platform device. Or when
it's used to switch power to other devices, sometimes they must
defer registration till then too (power them up first, *then* it
makes sense to register them).
This could handle that "board has this I2C RTC -or- that one"
case pretty cleanly; but then, so would having a "probe first"
flag that's specific to the i2c_board_info. (So long as the
probe logic could distinguish the devices... which will not in
the most general case work from i2c-core code.)
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists