From: Jean Delvare <khali@linux-fr.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Paul Mundt <lethal@linux-sh.org>,
linux-next@vger.kernel.org, linux-media@vger.kernel.org,
linux-i2c@vger.kernel.org
Subject: [PATCH] i2c: Don't advertise i2c functions when not available
Date: Fri, 5 Jun 2009 10:13:30 +0200 [thread overview]
Message-ID: <20090605101330.2f93e9ab@hyperion.delvare> (raw)
In-Reply-To: <20090602093431.GA19390@rakim.wolfsonmicro.main>
On Tue, 2 Jun 2009 10:34:32 +0100, Mark Brown wrote:
> On Tue, Jun 02, 2009 at 09:12:29AM +0200, Jean Delvare wrote:
> > What could be done, OTOH, is to surround all the function declarations
> > in <linux/i2c.h> with a simple #ifdef CONFIG_I2C, so that mistakes are
> > caught earlier (build time instead of link time.)
>
> That'd be helpful, yes.
Here you go:
From: Jean Delvare <khali@linux-fr.org>
Subject: i2c: Don't advertise i2c functions when not available
Surround i2c function declarations with ifdefs, so that they aren't
advertised when i2c-core isn't actually built. That way, drivers using
these functions unconditionally will result in an immediate build
failure, rather than a late linking failure which is harder to figure
out.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Paul Mundt <lethal@linux-sh.org>
---
include/linux/i2c.h | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
--- linux-2.6.30-rc8.orig/include/linux/i2c.h 2009-06-05 08:43:48.000000000 +0200
+++ linux-2.6.30-rc8/include/linux/i2c.h 2009-06-05 09:34:27.000000000 +0200
@@ -47,6 +47,7 @@ struct i2c_driver;
union i2c_smbus_data;
struct i2c_board_info;
+#if defined CONFIG_I2C || defined CONFIG_I2C_MODULE
/*
* The master routines are the ones normally used to transmit data to devices
* on a bus (or read from them). Apart from two basic transfer functions to
@@ -93,6 +94,7 @@ extern s32 i2c_smbus_read_i2c_block_data
extern s32 i2c_smbus_write_i2c_block_data(struct i2c_client *client,
u8 command, u8 length,
const u8 *values);
+#endif /* I2C */
/**
* struct i2c_driver - represent an I2C device driver
@@ -260,6 +262,7 @@ struct i2c_board_info {
.type = dev_type, .addr = (dev_addr)
+#if defined CONFIG_I2C || defined CONFIG_I2C_MODULE
/* Add-on boards should register/unregister their devices; e.g. a board
* with integrated I2C, a config eeprom, sensors, and a codec that's
* used in conjunction with the primary hardware.
@@ -283,6 +286,7 @@ extern struct i2c_client *
i2c_new_dummy(struct i2c_adapter *adap, u16 address);
extern void i2c_unregister_device(struct i2c_client *);
+#endif /* I2C */
/* Mainboard arch_initcall() code should register all its I2C devices.
* This is done at arch_initcall time, before declaring any i2c adapters.
@@ -299,7 +303,7 @@ i2c_register_board_info(int busnum, stru
{
return 0;
}
-#endif
+#endif /* I2C_BOARDINFO */
/*
* The following structs are for those who like to implement new bus drivers:
@@ -394,6 +398,7 @@ struct i2c_client_address_data {
/* administration...
*/
+#if defined CONFIG_I2C || defined CONFIG_I2C_MODULE
extern int i2c_add_adapter(struct i2c_adapter *);
extern int i2c_del_adapter(struct i2c_adapter *);
extern int i2c_add_numbered_adapter(struct i2c_adapter *);
@@ -435,6 +440,7 @@ static inline int i2c_adapter_id(struct
{
return adap->nr;
}
+#endif /* I2C */
#endif /* __KERNEL__ */
/**
--
Jean Delvare
next prev parent reply other threads:[~2009-06-05 8:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-27 7:08 [PATCH] i2c: Simplified CONFIG_I2C=n interface Paul Mundt
[not found] ` <20090527070850.GA11221-M7jkjyW5wf5g9hUCZPvPmw@public.gmane.org>
2009-05-27 7:18 ` Jean Delvare
[not found] ` <20090527091831.26b60d6d-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-05-27 7:28 ` Paul Mundt
2009-05-27 12:01 ` Mark Brown
2009-06-02 7:12 ` Jean Delvare
2009-06-02 9:34 ` Mark Brown
2009-06-05 8:13 ` Jean Delvare [this message]
[not found] ` <20090605101330.2f93e9ab-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-06-05 8:42 ` [PATCH] i2c: Don't advertise i2c functions when not available 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=20090605101330.2f93e9ab@hyperion.delvare \
--to=khali@linux-fr.org \
--cc=broonie@opensource.wolfsonmicro.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).