Re: [PATCH] cxd2820r: fix possible out-of-array lookup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Antti

2011/7/23 Antti Palosaari <crope@xxxxxx>:
> On 07/23/2011 02:01 AM, HoP wrote:
>>
>> 2011/7/23 Antti Palosaari<crope@xxxxxx>:
>>>
>>> On 07/23/2011 01:47 AM, HoP wrote:
>>>>
>>>> 2011/7/23 Antti Palosaari<crope@xxxxxx>:
>>>>>
>>>>> On 07/23/2011 01:18 AM, HoP wrote:
>>>>>>
>>>>>> In case of i2c write operation there is only one element in msg[]
>>>>>> array.
>>>>>> Don't access msg[1] in that case.
>>>>>
>>>>> NACK.
>>>>> I suspect you confuse now local msg2 and msg that is passed as function
>>>>> parameter. Could you double check and explain?

Can you confirm your NACK?

As I wrote before, my patch was about read access out of msg[] array
parameter of function cxd2820r_tuner_i2c_xfer() in case when msg[]
array has only one element (what should be case when using
tda18271_write_regs() for example). Or am I still missed something?

[snip]

> And one point more for I2C implementations, i2c_transfer() should implement
> repeated start sequence to messages given. But I am almost sure there is
> rather none I2C adapter HW which can do that really. Whole i2c_transfer()

Strange enought. Or may better say that linux/i2c.h must fool if you are right,
because there you can read:

--- linux/i2c.h ---
 * An i2c_msg is the low level representation of one segment of an I2C
 * transaction.  It is visible to drivers in the @i2c_transfer() procedure,
 * to userspace from i2c-dev, and to I2C adapter drivers through the
 * @i2c_adapter.@master_xfer() method.
 *
 * Except when I2C "protocol mangling" is used, all I2C adapters implement
 * the standard rules for I2C transactions.  Each transaction begins with a
 * START.  That is followed by the slave address, and a bit encoding read
 * versus write.  Then follow all the data bytes, possibly including a byte
 * with SMBus PEC.  The transfer terminates with a NAK, or when all those
 * bytes have been transferred and ACKed.  If this is the last message in a
 * group, it is followed by a STOP.  Otherwise it is followed by the next
 * @i2c_msg transaction segment, beginning with a (repeated) START.
---

It says quite the reverse - all multimessage transfers have using
repeated START.
Very annoying. At least for kernel newbies.

Regards

Honza
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux