Hello ! >> 1. Watchdog timer always decrement until zero, it cant be stopped at all. SR> Yep, same for AR2315+ SoCs. And if interrupt acknowledged by writing SR> one to ISR, then the timer starts counting again from 0xffffffff and SR> generates another one interrupt. Not for ar531x, timer does not overlapping zero on those devices even if ISR flag cleared, and, actually, produce next interrupt. So, setting timer to 0xffffffff does not harm both platforms.
SR> Hardware reset doesn't work on AR2315 since hw bug and cause freeze if SR> issued by watchdog. See details in AR2315 reset routine in SR> arch/mips/ar231x/ar2315.c I tested hw reset on ar531x, and it works. Are you tested it ? Comments in ar2315_restart function are about different situation, not watchdog reset. SR> I would like to propose use different device id strings (e.g. SR> ar2315-watchdog and ar5312-watchdog) to distinguish SoCs models. This SR> would help to solve several issues: SR> - twisted registers (passing adjacent registers via different SR> resources seems a bit odd), Why ? +4-4 address play looks worse for me :) Who cares how registers placed in address map, if we can use two pointers for them ? :) SR> - possibility of hardware reset, SR> - detection of watchdog clock frequency, since according to Axel Gembe SR> patch DWL-2100AP's watchdog timer ticks at 48MHz. Well, interrupt generated each 96 second on my DWL-2100AP, 0xffffffff/96 resulting in 44Mhz clock. 40 MHz - 107 seconds timeout 48 Mhz - 89 seconds 60 sec limit should be enough. For me watchdog routines should be as simple as possible, without bells and whistles because of their life-critical status. -- Sergey mailto:d...@bittu.org.ru _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel