On Thu, Aug 30, 2018 at 11:35:44AM -0700, Vipul Rahane wrote:
> Hey,
>
> I think that’s a really great idea. One thing I would add is that we
> definitely should honor timeouts in any of the retries. Also, a way to
> disable the retries should be a good idea. Probably making it a syscfg
> which
Sorry, just read Will’s comment.
Did not want to repeat it.
- Vipul
> On Aug 30, 2018, at 11:35 AM, Vipul Rahane wrote:
>
> Hey,
>
> I think that’s a really great idea. One thing I would add is that we
> definitely should honor timeouts in any of the retries. Also, a way to
> disable the
Hey,
I think that’s a really great idea. One thing I would add is that we definitely
should honor timeouts in any of the retries. Also, a way to disable the retries
should be a good idea. Probably making it a syscfg which when set to 0 does not
do any retries.
I am assuming the errors codes
On Thu, Aug 30, 2018 at 09:48:32AM -0700, will sanfilippo wrote:
> I think my only comment is tries vs retries. You always want to make
> at least one try so you would have to set that to 1 every time right?
> I like retries personally but that is just me. Mainly because you
> would never allow
On Thu, Aug 30, 2018 at 07:47:34PM +0300, marko kiiskila wrote:
> > On Aug 30, 2018, at 7:21 PM, Christopher Collins wrote:
> > [1] We should do the same for the other HAL APIs (i.e., non-I2C), but
> > that can come later.
>
> Not sure this makes sense for other ones, as i2c is the only one with
> On Aug 30, 2018, at 7:21 PM, Christopher Collins wrote:
>
> On Wed, Aug 29, 2018 at 10:06:37PM -0500, Greg Stein wrote:
>> On Wed, Aug 29, 2018 at 8:59 PM Christopher Collins
>> wrote:
>>
>>> Hello all,
>>>
>>> I noticed the HAL master I2C API does not include any retry logic. As
>>>
