All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Paul Mundt <lethal@linux-sh.org>,
	linux-next@vger.kernel.org, linux-media@vger.kernel.org,
	linux-i2c@vger.kernel.org
Subject: Re: [PATCH] i2c: Simplified CONFIG_I2C=n interface.
Date: Wed, 27 May 2009 13:01:40 +0100	[thread overview]
Message-ID: <20090527120140.GC1970@sirena.org.uk> (raw)
In-Reply-To: <20090527091831.26b60d6d@hyperion.delvare>

On Wed, May 27, 2009 at 09:18:31AM +0200, Jean Delvare wrote:

> Violent nack. Drivers which optionally use I2C are a minority.

It's extremely common for devices like the CODECs and PMICs used in
embedded systems to have both I2C and SPI interfaces, selectable via a
pin strap at power on.  It's less common to have the SPI option for
things like hardware monitoring chips found in PCs but for anything that
might be I/O bound the high speed interface is a very common option.

> Designing them in such a way that a single #ifdef CONFIG_I2C will make
> them work can't be that hard, really. Not to mention that having a
> dozen stubs in i2c.h in the CONFIG_I2C=n case won't save you much work
> at the driver level anyway, because you certainly need to run different
> code paths depending on how the device is connected, and you also have
> to differentiate between the "I2C support is missing" case and the "I2C
> device registration failed" case, etc.

For the devices I've dealt with there's very little work at the driver
level - the various interfaces that can be used each probe using the
normal device model, set some register read/write operations and
possibly some other things and then call into the bulk of the driver
which has all the I/O abstracted away from it.

The error handling is already an issue with the current situation since
people are just silently building out the I2C support when I2C is not
enabled.  At the minute the main problem is with people not remembering
to do the #ifdef (a lot of platforms really need I2C enabled to be
useful so people never think to do the build without).

  parent reply	other threads:[~2009-05-27 12:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-27  7:08 [PATCH] i2c: Simplified CONFIG_I2C=n interface Paul Mundt
2009-05-27  7:18 ` Jean Delvare
2009-05-27  7:18   ` Jean Delvare
2009-05-27  7:28   ` Paul Mundt
2009-05-27  7:28     ` Paul Mundt
2009-05-27 12:01   ` Mark Brown [this message]
2009-06-02  7:12     ` Jean Delvare
2009-06-02  9:34       ` Mark Brown
2009-06-05  8:13         ` [PATCH] i2c: Don't advertise i2c functions when not available Jean Delvare
2009-06-05  8:42           ` Mark Brown
2009-06-05  8:42             ` Mark Brown

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=20090527120140.GC1970@sirena.org.uk \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=khali@linux-fr.org \
    --cc=lethal@linux-sh.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-next@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.