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

Marek Vasut marex at denx.de
Wed Jun 26 12:48:14 UTC 2019


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.

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

-- 
Best regards,
Marek Vasut


More information about the U-Boot mailing list