Re: [PATCH] Fix Bug for cadence i2c interrupt overrunning buffer

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

 



Hi Wolfram,

On 13.10.2017 20:46, Wolfram Sang wrote:
> On Sat, Oct 07, 2017 at 04:32:29PM +1100, Andrew Worsley wrote:
>>> Thank you for the bug report. I don't know the hardware in detail, but I
>>> am a bit confused...
>>>
>>>> ---
>>>>   This bug reliably caused a stack corruption when the hardware provided more data than
>>>> asked for in the i2c request. The hardware (a tpm) very occasionally appends a burst of
>>>> 0xff to the end of the data requested and the i2c interrupt handler mindlessly copies all
>>>> the data right past the end of the buffer and in my case across the stack. :-(
>>>
>>> ... because you as the master should have control over how many bytes
>>> you want to have. If you are done, send NAK+STOP and the message is
>>> over. Is it really the device (which one is it BTW?)? Or is the FIFO
>>> handling of the master driver buggy?
>>>
>>> Michal, Sören?
>>
>> Just a quick comment - as I don't have time at the moment to look
>> deeply into the driver at the moment.
>>
>> I was just looking at Ch 20 of the TRM on the i2c under Read Transfer
>> and it says step 4 write the number of requested bytes to the Transfer
>> Size Register.
>>
>> But in the code it talks about a work around for large receive operation.
>>
>> Looking at the change log: commit  9fae82e1acda
>>
>> Explains for transfers > 252 bytes that
>>
>>      "the transfer size register has to be maintained at a value >= 1
>>
>> So my guess is the code is trying to keep this transfer size non-zero
>> and so just keeps pulling more bytes our of the slave i2c device. I
>> find it is hard to follow the complex code though.
>>
>> My buggy condition was a transfer of 128 bytes so it is not hit this
>> condition except in that the slave supplies way more bytes than was in
>> the original i2c_transfer request.
> 
> So, let's add Harini Katakam to CC who implemented this. But I'd be
> happy for anyone from Xilinx to respond...

It is still in my inbox to look at more details or ask my colleague to
look at it. I simply didn't have a time to do it.

Thanks,
Michal



[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux