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.