Hi Rasmus, On Tue, 3 Aug 2021 at 00:48, Rasmus Villemoes <rasmus.villem...@prevas.dk> wrote: > > On 02/08/2021 21.20, Simon Glass wrote: > > Hi Rasmus, > > > >> But let me one last time repeat why I think the post_probe approach is > >> the cleanest and a natural fit for DM: post_probe is (AIUI) a place > >> where a uclass can do some action it wants done for every device > >> belonging to that uclass. When CONFIG_WATCHDOG_AUTOSTART is set, > >> wdt_uclass does have such an action. When it's not set, the post_probe > >> method is a no-op. > > > > I can certainly see you point. It definitely looks very natural for DM. > > > > But I still think the problem of a device possibly resetting the board > > when probed (despite the various watchdog-reset things sprinkled > > throughout the code) > > But that is the _very point_ of having the developer be able to opt in > [1] to starting the watchdog device ASAP (i.e. as soon as U-Boot is > capable of handling it). If some part of the boot process hangs or > U-Boot goes into an inf-loop without hitting a WATCHDOG_RESET in there, > one wants (or may want) the board to reset and hopefully follow some > other path the next time around. If the developer/project doesn't want > or need that, WATCHDOG_AUTOSTART can be disabled. And if the developer
That requires a rebuild though. This is more of a driver-model thing than anything else and I know it seems like a minor point. But the way it is designed at present, probing a device should get it ready for use and not actually start it doing something. That is the way all(?) devices work and I think it makes sense to keep watchdogs consistent with that. > wants to make use of this, it makes sense to have the watchdog device > monitor as much of the boot process as possible. This is not an issue, since you enable all watchdogs immediately at present. > > [1] ok, for historical reasons it's default-y, so actually an opt-out > knob, but the developer does have a choice regardless. > Regards, Simon
