On 05/01/15 17:56, Joe Perches wrote: > On Mon, 2015-01-05 at 19:50 +0200, Daniel Baluta wrote: >> On Mon, Jan 5, 2015 at 6:42 PM, Joe Perches <joe@xxxxxxxxxxx> wrote: >>> On Mon, 2015-01-05 at 16:20 +0200, Daniel Baluta wrote: >>>> On Mon, Jan 5, 2015 at 3:09 PM, Joe Perches <joe@xxxxxxxxxxx> wrote: >>>>> On Mon, 2015-01-05 at 12:51 +0200, Daniel Baluta wrote: >>>>>> On Thu, Jan 1, 2015 at 2:10 AM, Kevin Tsai <ktsai@xxxxxxxxxxxxxxxx> wrote: >>>>>>> CM3232 is an advanced ambient light sensor with I2C protocol interface. >>>>>>> The I2C slave address is internally hardwired as 0x10 (7-bit). Writing >>>>>>> to configure register is byte mode, but reading ALS register requests to >>>>>>> use word mode for 16-bit resolution. >>> [] >>>>>> You could directly return i2c_smbus_write_byte_data(..). >>>>> >>>>> Sometimes it's better to return a specific value >>>>> for the error instead of depending on correctness >>>>> of all the indirect functions in the call chain. >>>>> >>>>> In this case, all the smbus_xfer functions must >>>>> return 0 on success. Do they? >>>> >>>> Yes. >>>> >>>> http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L2845 >>> >>> This doesn't show that adapter->algo->smbus_xfer() >>> returns 0, you have to look at the code for that >>> indirectly called function. >> >> I based my answer on the comment at the top of the function: >> >> 2845 * This executes an SMBus protocol operation, and returns a negative >> 2846 * errno code else zero on success. > > Sure, but comments and code often differ and the > implementation of any of those smbus_xfer functions > could return a positive value like the byte value or > the number of bytes written instead of 0. > > For correctness, you'd have to inspect them all. > > If some new future smbus_xfer function was written > incorrectly, the return value from this function could > now be positive. > That would however, clearly be a bug and likely to cause all sorts of issues elsewhere given the documentation requires that it does return 0 on success and people will have been relying on it. Jonathan > cheers, Joe > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
