I2C slave support

I2C slave support

[Jean Delvare]

Hi Wolfram,

I find it confusing that I2C slave support is included even when
CONFIG_I2C_SLAVE is not set. I don't know if this was discussed before?
Most systems don't need this code so including it unconditionally seems
suboptimal.

I am considering adding ifdefs around the code to only include it when
CONFIG_I2C_SLAVE is set. Alternatively the code could be moved to a
separate module altogether. What do you think?

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: I2C slave support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]


> I find it confusing that I2C slave support is included even when
> CONFIG_I2C_SLAVE is not set. I don't know if this was discussed before?

I was thinking about it but was undecided between "size of code added
unconditionally" and "ugly #ifdeffing the code".

> I am considering adding ifdefs around the code to only include it when
> CONFIG_I2C_SLAVE is set. Alternatively the code could be moved to a
> separate module altogether. What do you think?

Own module: Again, undecided. On the one hand it makes for a nice
encapsulation, on the other hand there is overhead for having another
module. I am very happy that the core code for slave support is so slim.

Mabye #ifdef is a good start. I could do it as well, I don't mind.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: I2C slave support

[Jean Delvare]

Hi Wolfram,

On Mon, 26 Jan 2015 12:33:29 +0100, Wolfram Sang wrote:
> > I find it confusing that I2C slave support is included even when
> > CONFIG_I2C_SLAVE is not set. I don't know if this was discussed before?
> 
> I was thinking about it but was undecided between "size of code added
> unconditionally" and "ugly #ifdeffing the code".
> 
> > I am considering adding ifdefs around the code to only include it when
> > CONFIG_I2C_SLAVE is set. Alternatively the code could be moved to a
> > separate module altogether. What do you think?
> 
> Own module: Again, undecided. On the one hand it makes for a nice
> encapsulation, on the other hand there is overhead for having another
> module. I am very happy that the core code for slave support is so slim.

I gave a try to the separate module approach and I have to agree that
it seems overkill given the small amount of code.

> Mabye #ifdef is a good start. I could do it as well, I don't mind.

Something like this?

From: Jean Delvare <jdelvare-l3A5Bk7waGM@public.gmane.org>
Subject: i2c: Only include slave support if selected

Make the slave support depend on CONFIG_I2C_SLAVE. Otherwise it gets
included unconditionally, even when it is not needed.

Signed-off-by: Jean Delvare <jdelvare-l3A5Bk7waGM@public.gmane.org>
Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
---
 drivers/i2c/i2c-core.c |    2 ++
 include/linux/i2c.h    |    4 ++++
 2 files changed, 6 insertions(+)

--- linux-3.19-rc6.orig/drivers/i2c/i2c-core.c	2015-01-26 12:47:26.467671896 +0100
+++ linux-3.19-rc6/drivers/i2c/i2c-core.c	2015-01-26 12:50:23.541420438 +0100
@@ -2962,6 +2962,7 @@ trace:
 }
 EXPORT_SYMBOL(i2c_smbus_xfer);
 
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
 int i2c_slave_register(struct i2c_client *client, i2c_slave_cb_t slave_cb)
 {drivers/i2c/i2c-smbus.c
 	int ret;
@@ -3009,6 +3010,7 @@ int i2c_slave_unregister(struct i2c_clie
 	return ret;
 }
 EXPORT_SYMBOL_GPL(i2c_slave_unregister);
+#endif
 
 MODULE_AUTHOR("Simon G. Vogl <simon-nD9nYVNVf00W+b/DJNNodF6hYfS7NtTn@public.gmane.org>");
 MODULE_DESCRIPTION("I2C-Bus main module");
--- linux-3.19-rc6.orig/include/linux/i2c.h	2015-01-26 12:47:26.470671959 +0100
+++ linux-3.19-rc6/include/linux/i2c.h	2015-01-26 12:52:00.027462551 +0100
@@ -222,7 +222,9 @@ struct i2c_client {
 	struct device dev;		/* the device structure		*/
 	int irq;			/* irq issued by device		*/
 	struct list_head detected;
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
 	i2c_slave_cb_t slave_cb;	/* callback for slave mode	*/
+#endif
 };
 #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
 
@@ -247,6 +249,7 @@ static inline void i2c_set_clientdata(st
 
 /* I2C slave support */
 
+#if IS_ENABLED(CONFIG_I2C_SLAVE)
 enum i2c_slave_event {
 	I2C_SLAVE_REQ_READ_START,
 	I2C_SLAVE_REQ_READ_END,
@@ -263,6 +266,7 @@ static inline int i2c_slave_event(struct
 {
 	return client->slave_cb(client, event, val);
 }
+#endif
 
 /**
  * struct i2c_board_info - template for device creation


-- 
Jean Delvare
SUSE L3 Support

Re: I2C slave support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]


> > Own module: Again, undecided. On the one hand it makes for a nice
> > encapsulation, on the other hand there is overhead for having another
> > module. I am very happy that the core code for slave support is so slim.
> 
> I gave a try to the separate module approach and I have to agree that
> it seems overkill given the small amount of code.

OK, thanks for trying!

> Something like this?

Yes, pretty much what I had in mind. One issue, though:

> +#if IS_ENABLED(CONFIG_I2C_SLAVE)
>  enum i2c_slave_event {
>  	I2C_SLAVE_REQ_READ_START,
>  	I2C_SLAVE_REQ_READ_END,
> @@ -263,6 +266,7 @@ static inline int i2c_slave_event(struct
>  {
>  	return client->slave_cb(client, event, val);
>  }
> +#endif

This should fail because bus drivers need those enums for their slave
backend. Try building i2c-sh_mobile which builds with an x86 toolchain
as well.

* Either we leave this included, so bus drivers don't need any ifdeffery

or

* we mandate that bus drivers also use the ifedeffery. Then, we could
  also mask out the (un)reg_slave callbacks in struct i2c_adapter

What do you think?


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: I2C slave support

[Jean Delvare]

On Mon, 26 Jan 2015 17:30:13 +0100, Wolfram Sang wrote:
> 
> > > Own module: Again, undecided. On the one hand it makes for a nice
> > > encapsulation, on the other hand there is overhead for having another
> > > module. I am very happy that the core code for slave support is so slim.
> > 
> > I gave a try to the separate module approach and I have to agree that
> > it seems overkill given the small amount of code.
> 
> OK, thanks for trying!
> 
> > Something like this?
> 
> Yes, pretty much what I had in mind. One issue, though:
> 
> > +#if IS_ENABLED(CONFIG_I2C_SLAVE)
> >  enum i2c_slave_event {
> >  	I2C_SLAVE_REQ_READ_START,
> >  	I2C_SLAVE_REQ_READ_END,
> > @@ -263,6 +266,7 @@ static inline int i2c_slave_event(struct
> >  {
> >  	return client->slave_cb(client, event, val);
> >  }
> > +#endif
> 
> This should fail because bus drivers need those enums for their slave
> backend. Try building i2c-sh_mobile which builds with an x86 toolchain
> as well.

Sorry I missed that, because there is currently no i2c bus driver
implementing slave support on x86-64.

> * Either we leave this included, so bus drivers don't need any ifdeffery

We can do that. The enum itself has no run-time cost so I don't mind.

> or
> 
> * we mandate that bus drivers also use the ifedeffery. Then, we could
>   also mask out the (un)reg_slave callbacks in struct i2c_adapter
> 
> What do you think?

Oh, I admit I completely missed the (un)reg_slave callbacks in my first
patch.

While I am happy with a few ifdefs in i2c-core and i2c.h, I agree it
will become messy if these are required in device drivers as well.

Hmm, what about bus drivers with slave mode support must select
CONFIG_I2C_SLAVE? This solves my problem nicely, and makes no change
compared to the current situation for people using slave mode.

Thanks,
-- 
Jean Delvare
SUSE L3 Support

Re: I2C slave support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 240 bytes --]


> Hmm, what about bus drivers with slave mode support must select
> CONFIG_I2C_SLAVE? This solves my problem nicely, and makes no change
> compared to the current situation for people using slave mode.

I like that! Let's do it this way.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: I2c slave support

[Jack]

Extremely sorry, May be I left the subject field blank.

On Fri, May 28, 2010 at 10:39 AM, Justin P. Mattock
<justinmattock@gmail.com> wrote:
> On 05/27/2010 10:01 PM, Jack wrote:
>
> Hi,
> Thanks,
>
> First solution needs additional GPIO pins, I have used all the pins.
> I'm going with the other solution, writing slave driver on the MIPS side.
> The MIPS provides an interrupt vector for the I2C bus.
>
> Regards,
> Jack
> .
>
>
> On Thu, May 27, 2010 at 11:25 AM, Haojian Zhuang
> <haojian.zhuang@gmail.com> wrote:
>
>
> On Thu, May 27, 2010 at 1:05 PM, linux_newbie good
> <mylinux.list@gmail.com> wrote:
>
>
> Hi,
>
> My board has a MIPS based Processor and a micro-controller.  The
> communication between these two interfaces is through an I2C bus. The
> Linux driver for my I2C controller (i mean the one in MIPS processor)
> has support for master transmitter and master receiver whereas I could
> not find support for slave TX and slave RX modes. Do I need to write
> my own functions for slave support? If so, what kind of changes need
> to be done, for slave mode support? Is there any other sample driver
> which can help ?
>
>
>
>
> Maybe you needn't write a slave I2C driver on MIPS side. It should
> based on your system requirement.
>
> I suggest the solution in below may be easier.
>
> ++++++++++++++                             ++++++++++++
> + MIPS (Master)  + -----> I2C -----------> + MCU (Slave)  +
> +                        +<----GPIO INT <----- +                     +
> ++++++++++++++                             ++++++++++++
>
> Since MIPS is master, it can read/write data from slave directly.
> While MCU want to contact with MIPS, it can trigger INT first. Then
> MIPS can query MCU and feed its required.
>
> Perhaps you may not choice this solution. You have to write slave
> driver on MIPS side and both master/slave driver on MCU side. You can
> refer to $LINUX/drivers/i2c/busses/i2c-pxa.c for reference. i2c-pxa
> driver supports both master and slave mode.
>
> Thanks
> Haojian
>
>
>
> --
> 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/
>
>
>
> change of subject: this morning xorg with their list was having
> issues with the subject line showing peoples e-mails
> and now I see something similar here.
> i.g. Re: mylinux.list@gmail.com
> (is it me or am I seeing things?)
>
> Justin P. Mattock
>