public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Jean Delvare <khali@linux-fr.org>,
	Alessandro Zummo <a.zummo@towertech.it>,
	Andrew Morton <akpm@linux-foundation.org>,
	Atsushi Nemoto <anemo@mba.ocn.ne.jp>,
	David Woodhouse <dwmw2@infradead.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	rtc-linux@googlegroups.com, i2c@lm-sensors.org,
	linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/6] RTC: Trivially probe for an M41T80 (#2)
Date: Thu, 22 May 2008 20:07:06 -0700	[thread overview]
Message-ID: <200805222007.07146.david-b@pacbell.net> (raw)
In-Reply-To: <Pine.LNX.4.55.0805131759580.7267@cliff.in.clinika.pl>

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

      parent reply	other threads:[~2008-05-23  3:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-13  3:27 [PATCH 6/6] RTC: Trivially probe for an M41T80 (#2) Maciej W. Rozycki
2008-05-13 12:28 ` Jean Delvare
2008-05-14  1:13   ` Maciej W. Rozycki
2008-05-19 20:37     ` Jean Delvare
2008-05-20 20:26       ` Maciej W. Rozycki
2008-05-22  9:32         ` Jean Delvare
2008-05-22 16:02           ` Maciej W. Rozycki
2008-05-23  3:07     ` David Brownell [this message]

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=200805222007.07146.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=a.zummo@towertech.it \
    --cc=akpm@linux-foundation.org \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=dwmw2@infradead.org \
    --cc=i2c@lm-sensors.org \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=rtc-linux@googlegroups.com \
    --cc=tglx@linutronix.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