On 10/26/23 15:17, Lakshmi Yadlapati wrote:
The MAX31785 has shown erratic behaviour across multiple system designs, unexpectedly clock stretching and NAKing transactions. Experimentation shows that this seems to be triggered by a register access directly back to back with a previous register write. Experimentation also shows that inserting a small delay after register writes makes the issue go away. Use a similar solution to what the max15301 driver does to solve the same problem. Create a custom set of bus read and write functions that make sure that the delay is added. Signed-off-by: Lakshmi Yadlapati <lakshmiy@xxxxxxxxxx> --- V3 -> V4: Fixed warnings realted to this commit
I also asked about the use of udelay() instead of usleep_range() or fsleep(). I see you did not change the code. Fine, but please explain why the use of udelay() instead of the alternative is desirable or needed here, and don't just ignore review feedback. Thanks, Guenter