[1/4] i2c: add FUNC flag for slave capabilities

Commit Message

Wolfram Sang May 14, 2015, 12:40 p.m. UTC

From: Wolfram Sang <[e-mail]>

So users can check in advance if there is slave support.

Signed-off-by: Wolfram Sang <[e-mail]>
---
 include/uapi/linux/i2c.h | 1 +
 1 file changed, 1 insertion(+)

Comments

Uwe Kleine-König May 15, 2015, 11:37 a.m. UTC | #1

Hello Wolfram,

On Thu, May 14, 2015 at 02:40:02PM +0200, Wolfram Sang wrote:
> From: Wolfram Sang <[e-mail]>
> 
> So users can check in advance if there is slave support.
I wonder if the core should check if .{,un}reg_slave is != NULL and
automatically set this bit accordingly.

Best regards
Uwe

Wolfram Sang May 16, 2015, 8:22 a.m. UTC | #2

On Fri, May 15, 2015 at 01:37:44PM +0200, Uwe Kleine-König wrote:
> Hello Wolfram,
> 
> On Thu, May 14, 2015 at 02:40:02PM +0200, Wolfram Sang wrote:
> > From: Wolfram Sang <[e-mail]>
> > 
> > So users can check in advance if there is slave support.
> I wonder if the core should check if .{,un}reg_slave is != NULL and
> automatically set this bit accordingly.

I thought about this, too, but decided against it. Maybe some driver
doesn't want to make its slave interface public because it is
specialized for one use-case only (thinking ECs here)? Also, doing it
would be a little inconsistent, since we could do the same for
I2C_FUNC_I2C when master_xfer is populated. So, let's start simple I'd
say.

Uwe Kleine-König May 16, 2015, 9:27 a.m. UTC | #3

Hello Wolfram,

On Sat, May 16, 2015 at 10:22:16AM +0200, Wolfram Sang wrote:
> On Fri, May 15, 2015 at 01:37:44PM +0200, Uwe Kleine-König wrote:
> > On Thu, May 14, 2015 at 02:40:02PM +0200, Wolfram Sang wrote:
> > > From: Wolfram Sang <[e-mail]>
> > > 
> > > So users can check in advance if there is slave support.
> > I wonder if the core should check if .{,un}reg_slave is != NULL and
> > automatically set this bit accordingly.
> 
> I thought about this, too, but decided against it. Maybe some driver
> doesn't want to make its slave interface public because it is
> specialized for one use-case only (thinking ECs here)? Also, doing it
Hmm, I'd not say this is a valid reason. Sounds like policy in the
kernel?!

Does the framework check for the slave support flag before binding a
slave to the controler? I assume that not, but wonder if it should.

> would be a little inconsistent, since we could do the same for
> I2C_FUNC_I2C when master_xfer is populated. So, let's start simple I'd
> say.

Best regards
Uwe

Wolfram Sang May 16, 2015, 10:09 a.m. UTC | #4

> Does the framework check for the slave support flag before binding a
> slave to the controler? I assume that not, but wonder if it should.

I think this nails it: Currently, the core doesn't use any I2C_FUNC_*
flags for checking anything. It is solely for exposing information to
users. I'd like to have FUNC_SLAVE in line with that for now.

If we are going to change that, it should be a seperate thread and not
limited to FUNC_SLAVE. I might note that for me this is not a priority
issue, so don't expect patches from me ;)

Patch

diff --git a/include/uapi/linux/i2c.h b/include/uapi/linux/i2c.h
index 0e949cbfd33338..b0a7dd61eb353a 100644
--- a/include/uapi/linux/i2c.h
+++ b/include/uapi/linux/i2c.h
@@ -87,6 +87,7 @@  struct i2c_msg {
 #define I2C_FUNC_PROTOCOL_MANGLING	0x00000004 /* I2C_M_IGNORE_NAK etc. */
 #define I2C_FUNC_SMBUS_PEC		0x00000008
 #define I2C_FUNC_NOSTART		0x00000010 /* I2C_M_NOSTART */
+#define I2C_FUNC_SLAVE			0x00000020
 #define I2C_FUNC_SMBUS_BLOCK_PROC_CALL	0x00008000 /* SMBus 2.0 */
 #define I2C_FUNC_SMBUS_QUICK		0x00010000
 #define I2C_FUNC_SMBUS_READ_BYTE	0x00020000