On Mon, Jan 14, 2019 at 10:58:02PM +0100, Andreas Kemnade wrote: > On Mon, 14 Jan 2019 11:51:29 +0100 > Johan Hovold <johan@xxxxxxxxxx> wrote: > > here is a second part of a reply. I'm not sure I received the first part if you're saying you replied to my mail in two parts? > [...] > > > > In pseudo code we have: > > > > > > > > activate: > > > > - toggle on-off > > > > - wait(data-received, ACTIVATE_TIMEOUT + REPORT_CYCLE) > > > > - reception: success > > > > > > Note: we can also get the goodbye/shutdown message from the chip here > > > so there are chances of a false success, but since we initially power down, > > > we will rule out wrong state here. > > > > Good point. Unless we know the current state, we'd need to sleep for > > HIBERNATE_TIMEOUT before waiting for data reception. > > And probably this also magically (together with my > runtime_get/put()-pair) in _probe()) worked around the > problems fixed by the. > gnss: sirf: fix activation retry handling The retry-handling fix would only avoid a successful last retry attempt incorrectly being reported as a failure, so I don't think that would change much here. > Well, with the last patchset and short report cycle we can detect state > changes to off state reliably but state changes to on state > only unreliably (which was, as said, not the intention). If the GPS chip > behaves well enough, we will not see trouble. > > Now with long report cycles: Off state detection will always return > success. On state detection (in its current wonky form) will see the > state change messages and will also always return success. If initial > state is correct, this works at least in a wonky way. > > I do not like these wonky things too much. So I would rather see > well-defined behavior with well-known limitations. > > State change failures are probably not only a theoretical thing, > so it is a good idea to track that. Good, sounds like we're on the same page then. Thanks, Johan
