toggle quoted messageShow quoted text
Indeed, thanks for your positive opinion.
I'll continue to try to check (and also study :) ) existing issues or PRs.
On 2020/12/03 1:49, Cufi, Carles wrote:
Thank you for reply. I understand situation.Thank you, that will certainly help.
I will try to add myself as collaborator of watchdog.
But it seems that Zephyr project rules need two or more reviewers toOf course, but there are things to consider here:
proceed pull requests. And of course, I cannot review my patch.
Maybe it does not help to merge or review my patch even if I will be as
collaborator. RISC-V area is also in same situation...
- If you indeed end up becoming a maintainer, you will be able to take certain decisions over questions or issues that show up in Pull Requests, effectively helping to move progress forward.
- As a consequence of that, if a Pull Request comes from the maintainer, then the requirement for two approvals stands, but the approvals are obviously automatically assumed to come from non-maintainers, so that means you don't need to wait for a maintainer that is non-existent if there are disagreements
In general, it is my opinion that having a maintainer or at least a collaborator will help in getting things merged, regardless of whether the patches come from that maintainer or anybody else.
On 2020/12/01 4:50, Carles Cufi wrote:
Hi Katsuhiro,be much appreciated.
The whole watchdog subsystem is orphaned in fact.
We need maintainers for it, so if anyone wants to volunteer that would
From: email@example.com <firstname.lastname@example.org>
On Behalf Of Katsuhiro Suzuki via lists.zephyrproject.org
Sent: 30 November 2020 18:14
To: zephyr-devel <email@example.com>
Subject: Re: [Zephyr-devel] What is expected behavior of watchdog
It seems that watchdog driver is orphaned.
I would be appreciate it if anyone inform about that...
On 2020/11/28 20:35, Katsuhiro Suzuki wrote:
I'm implementing Watchdog driver for HiFive1 Rev.b.
This watchdog can reset SoC immediately when counter is reaching
timeout. It's suitable feature of WDT_FLAG_RESET_SOC.
But tests/drivers/watchdog/wdt_basic_api/ expected to be calling
back the function 'wdt_int_cb0' even if with WDT_FLAG_RESET_SOC.
I think we cannot do that because SoC reset from watchdog is
immediate and not raise interrupt.
Do other boards pass this watchdog test? If so, I have to add
emulated SoC reset codes in interrupt handler of watchdog.