On Thu, Oct 17 2024 at 17:16:54 +02:00:00, AngeloGioacchino Del Regno
<angelogioacchino.delregno@xxxxxxxxxxxxx> wrote:
Il 17/10/24 16:09, Guenter Roeck ha scritto:
On 10/16/24 23:43, yassine.oudjana@xxxxxxxxx wrote:
...
Say I don't want to use the watchdog (which I don't, all I need
from TOPRGU is the resets, I don't care about the watchdog).
Not starting the watchdog means I can't reset the system
because all mtk_wdt_restart will do is make TOPRGU send me an
IRQ that I have no use for.
If you don't want to use the watchdog, then you don't need to care
about bark
interrupts and you don't need any mtk_wdt_restart() functionality
at all :-)
I need mtk_wdt_restart to restart my system. I shouldn't need to
take off my phone's back cover and remove the battery every time
:)
I think what Guenter said makes sense. We should make sure the
watchdog is started when calling mtk_wdt_restart or at least
configured in such a way that we are sure it will issue a system
reset.
It is more than that. There is no limitation in the watchdog API
that says
"you must only use the watchdog kernel driver to reset the system if
the
watchdog has been activated from userspace". Such a limitation would
be
completely arbitrary and not make any sense. It is perfectly fine to
enable
the watchdog from the restart callback if needed. Actually, all
restart
handlers in watchdog drivers have to do that if they indeed use a
watchdog
to reset the system.
Actually, I am not entirely sure I understand what we are arguing
about.
Guenter:
We're arguing about bad configuration and lots of misunderstanding.
Regarding WDT_MODE_EXRST_EN: when enabled, it enables an external
output
reset signal - meaning that it's going to flip the state of a GPIO to
active
(high in Yassine's case - as that's configured through WDT_MODE
BIT(1) and
his 0x5c means that it's flipped on), signaling to another chip
(usually,
the PMIC...!) that we want to reset the system.
Explaining what Yassine is doing with this commit: he is flipping the
IRQ_EN
bit [BIT(5)] in WDT_MODE.
When bit 5 *is set*, the watchdog bark event will only raise an
interrupt and
will not reset the system (that's left to be done to an interrupt
handler in
the driver).
When bit 5 *is NOT set*, the watchdog bark event will trigger a CPU
reset.
Now, my confusion came from the fact that he's trying to fix a
watchdog bark
event so that it triggers system reset, but I didn't understand the
actual
reason why he wants to do that - which is powering off the system!
I'm currently aiming for reboot, not poweroff. There was some point
during development where holding the power button wasn't enough to
force restart and I'm still not sure why that was happening but it's
working now. That's why I was removing the battery to power it off then
turn it on again with the power button.
Yassine:
You don't *have to* rely on the watchdog to reset the system, and if
you use
only that - especially on a smartphone - I'm mostly sure that you'll
get
power leakage.
I did notice that when I tried poweroff. It didn't fully power off and
eventually drained the battery. But again I'm not looking into fixing
poweroff for the time being, I'm focusing on reboot. I'll probably ask
you again about it when I look into fixing poweroff since you seem to
know something about the matter.
Before you read the following - please note that this is platform
dependent
so, take this with a grain of salt: it is the PMIC that should get
configured
to take your system down! I have a hunch that this works for you only
because
the platform will reboot, and then the bootloader will decide to turn
off the
system for you by default (that, unless you send a warm reboot
indication).
That flow looks more like a hack than a solution for an actual
problem.
Now - whether you want to fix your platform or not, this is out of
the scope
of this commit, which is - in the end - still fixing something that
is wrong.
Effectively, as Guenter said, if the watchdog is never started, the
restart
function is not going to reboot the system, so yes this problem needs
to be
fixed.
There are two problems in this driver that can be solved with:
1. Disable IRQ generation when *no irq* is found in DT; and
2. Implement support for reboot in mtk_wdt_isr() by reading the
WDT_STA
register and by then taking appropriate actions.
Of course my preference would be N.2 because:
- The pretimeout way is already supported in the driver, and if you
specify
a pretimeout, then the watchdog will never trigger SYSRST->XRST:
this
is actually a bug (IMO!!), as declaring an IRQ in DT means losing
reset (!);
- The WDT_STA register tells you more than just "SW/HW watchdog
reset asserted"
and that can be extended in the future to support more than that.
However, I recognize that this may be too much work for you, so, if
there's no
way for you to properly add support for N.2 - I can chime in.
As for N.1, the solution is simple: check if
platform_get_irq_optional fails
and - if it does - force unsetting (WDT_MODE_IRQ_EN |
WDT_MODE_DUAL_EN) in
WDT_MODE, if and only if WDT_EN is not set.. but that, in the probe
function!
I still honestly don't see the point in either solution. N.1 sounds
like a hack; the interrupt should be described in DT even if we don't
want to use it since DT is ultimately hardware description and the
interrupt line exists whether we are using it or not. N.2 is
unnecessarily complicating things. I mean why should we make the
watchdog issue an interrupt then in the interrupt handler perform the
reset? When someone calls the restart function they expect an immediate
reset. As Guenter said we should configure the hardware to issue reset
in the reset handler, and I believe that's what I did originally.
