Hi Tim,
On 17.03.22 17:54, Tim Wawrzynczak wrote:
On Thu, Mar 17, 2022 at 10:35 AM Nico Huber nico.h@gmx.de wrote:
I'm sorry if this affects your work, but we have very bad experience with unnecessary code changes by CrOS developers. Currently `sb600spi` (the equivalent to `ichspi` for AMD platforms) is broken since months and only CrOS developers could clarify why the code was changed as it was. We need to prevent that this happens to `ichspi` too, right?
Nico
We are certainly not intending to break ichspi or make it worse, we are trying to make it better
I always assume that's the case for everybody :)
Still, sometimes things break and we know already that things can break even due to unnecessary refactorings. And saying the reason for a change is to align with a project with lower quality require- ments seems kind of odd, doesn't it?
And when reviewers are busy with refactorings instead of attending the changes they already merged, that feels very wrong :-/
, perhaps we were a little hasty in trying to get through solutions that were not perhaps the root of the problem, but were discovered along the way.
We are also working with Intel to get some documentation out about the expected behaviors with regard to the multi-master scenarios, hopefully that will help clarify things some in this regard.
If the timeout is the only issue, the hardware works as expected. Stating an expected timeout in the datasheets would have avoided the problem of course :)
Nico