i2c: Bus drivers don't have to support I2C_M_REV_DIR_ADDR
PATCH 1/1 i2c: Bus drivers don't have to support I2C_M_REV_DIR_ADDR
I2C bus drivers don't have to support I2C_M_REV_DIR_ADDR. It is a deviation from the I2C specification, which only makes sense to implement when really needed.
--- drivers/i2c/busses/i2c-iop3xx.c | 6 ------ drivers/i2c/busses/i2c-mv64xxx.c | 3 --- drivers/i2c/busses/i2c-powermac.c | 2 -- 3 files changed, 11 deletions(-)
drivers/i2c/busses/i2c-iop3xx.c +0 -6
@@ -56,12 +56,6 @@ iic_cook_addr(struct i2c_msg *msg)if (msg->flags &I2C_M_RD ) addr |=1 ; -/* -* Read or Write? -*/ -if (msg->flags &I2C_M_REV_DIR_ADDR ) - addr ^=1 ; -return addr; }
drivers/i2c/busses/i2c-mv64xxx.c +0 -3
@@ -338,9 +338,6 @@ mv64xxx_i2c_prepare_for_io(struct mv64xxif (msg->flags &I2C_M_RD ) dir =1 ; -if (msg->flags &I2C_M_REV_DIR_ADDR ) - dir ^=1 ; -if (msg->flags &I2C_M_TEN ) { drv_data->addr1 =0xf0 | (((u32 )msg->addr &0x300 ) >>7 ) | dir; drv_data->addr2 = (u32 )msg->addr &0xff ;
drivers/i2c/busses/i2c-powermac.c +0 -2
@@ -156,8 +156,6 @@ static int i2c_powermac_master_xfer( strreturn -EINVAL ; read = (msgs->flags &I2C_M_RD ) !=0 ; addrdir = (msgs->addr <<1 ) | read; -if (msgs->flags &I2C_M_REV_DIR_ADDR ) - addrdir ^=1 ; rc =pmac_i2c_open (bus,0 );if (rc)
Signature · 1 line
Jean Delvare
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines · Jean Delvare
I2C bus drivers don't have to support
I2C_M_REV_DIR_ADDR. It is a deviation from the I2C specification, which only makes sense to implement when really needed.
Probably the right thing to do, does anything actually use this support?
Quoted 6 lines
Signed-off-by Jean Delvare <[email protected]>Cc Ben Dooks <[email protected]>--- drivers/i2c/busses/i2c-iop3xx.c | 6 ------ drivers/i2c/busses/i2c-mv64xxx.c | 3 --- drivers/i2c/busses/i2c-powermac.c | 2 --
I assume that I should merge this in my -next tree?
Signature · 3 lines
Ben ([email protected], http://www.fluff.org/) 'a smiley only costs 4 bytes'
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Ben,
Quoted 7 lines · Ben Dooks
Quoted 3 lines · Jean Delvare
I2C bus drivers don't have to support
I2C_M_REV_DIR_ADDR. It is a deviation from the I2C specification, which only makes sense to implement when really needed.Probably the right thing to do, does anything actually use this support?
As far as I know, the only chip which uses this is the "Maven" which is found on some Matrox G450 graphics cards to handle the second head.
As the i2c-matroxfb driver builds on top of i2c-algo-bit, i2c-algo-bit is the only driver which needs to implement I2C_M_REV_DIR_ADDR.
I've left it in i2c-algo-pcf and i2c-s3c2410 for now because at least they properly declare the I2C_FUNC_PROTOCOL_MANGLING functionality, but this could be reconsidered.
The other protocol mangling flags are in a similar situation. For example I2C_M_NOSTART is only used by the Intel i915 and Matrox Maven chips. Both use i2c-algo-but, but no less than 9 other I2C adapter drivers implement it! Most of these implementations have most probably never been tested, and I wouldn't be surprised if some don't work.
I2C_M_IGNORE_NAK is only used by the msp3400 audio processing driver. But it is implemented by embedded I2C adapter drivers which probably will never see this chip: i2c-davinci, i2c-omap, i2c-s3c2410 and i2c-stu300.
I2C_M_NO_RD_ACK is only used by the ks0127 video driver, and only i2c-algo-bit implements it. That one is correct.
Quoted 8 lines
Quoted 6 lines
Signed-off-by Jean Delvare <[email protected]>Cc Ben Dooks <[email protected]>--- drivers/i2c/busses/i2c-iop3xx.c | 6 ------ drivers/i2c/busses/i2c-mv64xxx.c | 3 --- drivers/i2c/busses/i2c-powermac.c | 2 --I assume that I should merge this in my -next tree?
Probably, yes. For now I have this patch in my own -next tree, but as all drivers affected are embedded ones, it would fit better in yours.
I leave it up to you to decide what to do with the i2c-s3c2410 driver. As I understand it, it doesn't need to implement I2C_M_REV_DIR_ADDR nor I2C_M_IGNORE_NAK nor I2C_M_NOSTART, so you could simplify the code a bit and stop defining I2C_FUNC_PROTOCOL_MANGLING.
BTW, is your -next tree visible somewhere? It might be convenient for me to be able to check what it includes.
Signature · 1 line
Jean Delvare