This patch is way too big for what it does. Lots of whitespace
and similar noise (did those headers *need* rearranging?).
But most importantly, that driver already uses SMBus calls.
So you shouldn't *stop* it from using them by adding wrapper
code like this:
> +static int m41t80_write_byte_data(struct i2c_client *client, u8 reg, u8 val)
> +{
> + if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
> + return m41t80_i2c_transfer(client, 1, reg, 1, &val);
> + else
> + return i2c_smbus_write_byte_data(client, reg, val);
> +}
That's because if an I2C controller can execute that protocol,
it can do so through the SMBus calls too. And the current code
already verifies that will work ... those wrappers are pointless,
as well as untested.
The chip docs basically tell us that if the underlying SMBus
controller can issue i2c_smbus_read_i2c_block_data() and its
write-side sibling, it can *easily* talk to this chip.
So wouldn't it be a better idea to just replace the existing
calls to i2c_transfer() with those pseudo-SMBus block calls?
And then *separately* add workarounds for i2c-sibyte, and
similar controllers that don't offer block transfers? Maybe
using your existing structure ... just not replacing those
existing perfectly-fine SMBus calls.
- Dave
_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c
