On Mon, Apr 17, 2017 at 07:05:30PM +0200, Karim Eshapa wrote: > On Sun, 16 Apr 2017 12:53:28 -0700,Guenter Roeck wrote: > > On 04/16/2017 09:33 AM, Karim Eshapa wrote: > >> > >> that's useful for the scheduler, power management unless > >> the driver needs to delay in atomic context > >> look at documentation/timers/timers-howto > > > > Possibly, but how can you guarantee that the restart function is called with > > interrupts enabled ? Also, why would it be necessary or even useful for the > > scheduler to do anything while the system is in the process of restarting ? > > From signaling or interruption point of view msleep() is uninterruptible. > your process will sleep and won't be waked up until finish the time. > > From the cpu load and power point of view, mdelay() makes your code > stucked doing nothing until the delay finishes so, it's still headache > to the schedular from time slot perspective. > Although it's restating but it's still a long process that takes time. > > In addittion to mdelay() isn't preferable in case of large delays +10 as it uses udelay() > > But the question now what about ptotecting your HW while being accessed > through manipulating the registers. and what about memory reordering may be generated > by the compiler or the machine itself! while accessing a sequence of registers. > We are in the process of _resetting the system_ in this function. If the function works, it won't return from the call to mdelay(). If anything, I would argue that we don't want to use anything but mdelay() in this situation. Sorry, I don't see the point you are trying to make. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
