[U-Boot] [PATCH v2 2/2] xilinx_xiic: Fix transfer initialisation

[Melin Tomas]

On 6/26/19 3:48 PM, Marek Vasut wrote:
> On 6/26/19 2:45 PM, Melin Tomas wrote:
>> On 6/26/19 3:26 PM, Marek Vasut wrote:
>>> On 6/26/19 2:19 PM, Melin Tomas wrote:
>>>> On 6/26/19 2:49 PM, Marek Vasut wrote:
>>>>> On 6/26/19 1:25 PM, Melin Tomas wrote:
>>>>>> On 6/26/19 1:47 PM, Marek Vasut wrote:
>>>>>>
>>>>>>> On 6/26/19 12:39 PM, Melin Tomas wrote:
>>>>>>>
>>>>>>>> As such, it's probably a good idea to keep the same delay values here as
>>>>>>>> in the original driver unless good reason to use something else.
>>>>>>>>
>>>>>>>> As what goes for the original reasoning for 3ms, the commit history does
>>>>>>>> not mention that so I cannot comment.
>>>>>>> So would you be so kind and research this ?
>>>>>> Based on a short study of other i2c bus drivers it seems most have bus
>>>>>> busy timeout checks.
>>>>>>
>>>>>> The timeout values seems to differ, ranging from milliseconds to seconds.
>>>>> Yep
>>>>>
>>>>>> So probably it's just a number, after all it's just a check to know if
>>>>>> we are good to go.
>>>>> And is the number large enough ?
>>>> As mentioned, good approach is probably using value known to work
>>>> instead of
>>>>
>>>> guessing a new number.
>>> So why did kernel pick that specific number ? Surely there was some
>>> reasoning, they didn't just pull it out of /dev/random .
>> Yes, history does not tell.
>>
>> I do see that this driver uses timeout of 1000ms for bus busy when
>> probing, perhaps you can enlighten how that number was concluded? If
>> that could give some clues about this.
> I don't know.

But you are author of that line?

> You're the patch author, it's your responsibility to know why you're
> adding/changing the code you're adding/changing.

yes, and the reasoning is:

* the value has been deemed good in original driver. If it would be bad, 
probably it would have been changed during course of time

* the value has been tested for this driver as well with success


thanks,

Tomas