All of lore.kernel.org
 help / color / mirror / Atom feed
From: stefan.eletzhofer@eletztrick.de
To: Greg KH <greg@kroah.com>,
	stefan.eletzhofer@eletztrick.de, linux-kernel@vger.kernel.org
Subject: Re: i2c_get_client() missing?
Date: Wed, 28 Apr 2004 10:13:57 +0200	[thread overview]
Message-ID: <20040428081357.GA11274@gonzo.local> (raw)
In-Reply-To: <20040427192119.A21965@flint.arm.linux.org.uk>

On Tue, Apr 27, 2004 at 07:21:19PM +0100, Russell King wrote:
> On Tue, Apr 27, 2004 at 08:35:12AM -0700, Greg KH wrote:
> > Where do you need to access it from?  Why do all of the current drivers
> > not need it?
> 
> The "traditional Linux" i2c model is one where the i2c bus is local to
> the card, so the overall driver knows where the bus is, and what devices
> to expect, and it's all nicely encapsulated.
> 
> The variant on that is the i2c sensor stuff, where the individual i2c
> bus device drivers export data to userspace themselves.
> 
> However, there's another class, where the i2c bus contains things like
> RTC and system control stuff, which can be found on embedded devices.
> Such an i2c bus is often shared between multiple parts of the system,
> and lumping them all together into one massive driver does not make
> sense.

Thats exactly what I tried to say with my other post. Thanks for spelling
it more precisely.

> 
> For instance, one platform I have here has an i2c bus with a RTC on,
> and optionally a couple of EEPROMs giving the dimentions of the memory
> on a couple of expansion boards.  It doesn't make sense to lump the
> RTC code along side the memory controller configuration code, along
> with the i2c bus driver.

Again, exatly what I thought when I split up I2C RTC chip access and
higher level RTC device handling stuff.

> 
> I2C is much much more than sensors and graphics capture chips.

Definitely.

> -- 
> Russell King
>  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
>                  2.6 Serial core
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Eletztrick Computing - Customized Linux Development
Stefan Eletzhofer, Marktstrasse 43, DE-88214 Ravensburg
http://www.eletztrick.de

  reply	other threads:[~2004-04-28  8:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-04-27 15:01 i2c_get_client() missing? stefan.eletzhofer
2004-04-27 15:35 ` Greg KH
2004-04-27 16:46   ` stefan.eletzhofer
2004-04-27 18:21   ` Russell King
2004-04-28  8:13     ` stefan.eletzhofer [this message]
2004-04-28 13:36     ` stefan.eletzhofer

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=20040428081357.GA11274@gonzo.local \
    --to=stefan.eletzhofer@eletztrick.de \
    --cc=greg@kroah.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.