Re: [PATCH v3] watchdog: Add driver for Gunyah Watchdog
From: Neil Armstrong
Date: Tue Oct 28 2025 - 12:30:51 EST
On 10/28/25 13:27, Pavan Kondeti wrote:
On Tue, Oct 28, 2025 at 12:07:40PM +0100, Krzysztof Kozlowski wrote:
On 28/10/2025 12:04, Krzysztof Kozlowski wrote:
On 28/10/2025 11:58, Hrishabh Rajput wrote:
On 10/28/2025 3:10 PM, Krzysztof Kozlowski wrote:
On 28/10/2025 10:35, Hrishabh Rajput via B4 Relay wrote:
+I don't think you implemented my feedback. This again is executed on
+static int __init gunyah_wdt_init(void)
+{
+ struct arm_smccc_res res;
+ struct device_node *np;
+ int ret;
+
+ /* Check if we're running on a Qualcomm device */
+ np = of_find_compatible_node(NULL, NULL, "qcom,smem");
every platform, e.g. on Samsung, pointlessly.
Implement previous feedback.
Do you want us to add platform device from another driver which is
probed only on Qualcomm devices (like socinfo from previous discussion)
and get rid of the module init function entirely? As keeping anything in
the module init will get it executed on all platforms.
Instead of asking the same can you read previous discussion? What is
unclear here:
https://lore.kernel.org/all/3b901f9d-dbfa-4f93-a8d2-3e89bd9783c9@xxxxxxxxxx/
?
With this patch version, we have tried to reduce the code execution on
non-Qualcomm devices (also tried the alternative as mentioned in the
cover letter). Adding platform device from another driver as described
above would eliminate it entirely, please let us know if you want us to
do that.
Why do I need to repeat the same as last time?
Now I see that you completely ignored previous discussion and sent THE
SAME approach.
Our intention is not to waste reviewers time at all. It is just a
misunderstanding on what your comment is about. Let me elaborate further
not to defend our approach here but to get a clarity so that we don't
end up in the same situation when v4 is posted.
https://lore.kernel.org/all/b94d8ca3-af58-4a78-9a5a-12e3db0bf75f@xxxxxxxxxx/
You mentioned here
```
To me socinfo feels even better. That way only, really only qcom devices
will execute this SMC.
```
We interpreted this comment as `avoid executing this SMC on non qcom
devices`. That is exactly what we have done in the current patch. since
`smem` is not present on non qcom devices, we don't make a SMC. In fact
we don't even create platform device/driver.
Please help us understand if the better approach is to just register
platform driver here and let qcom specific code add the platform device.
Also, please help me understand why would non qcom platform who care
about performance load all modules that can be built w/ ARM64. There
will be many init calls and platform drivers registerd but they never
get probed at all since their platform does not support. I am not
defending our aproach, but trying to understand the rationale behind our
approach vs alternatives.
+static int __init gunyah_wdt_init(void)
will be called on ___all____ arm64 systems which uses the vanilla arm64 defconfig,
while we could say the first call of "of_find_compatible_node()" would fail on all
non-qcom platforms this is still unacceptable.
The solution is to attach the wdt init to something only probed on qcom
platforms (not the module init, the _probe_ which is mapped to a DT compatible)
and very generic like socinfo which could accept HYP stuff.
You could also setup the HYP WDT from the qcom scm driver since the
communication is smc based.
Neil
Thanks for your time and valuable feedback. I am told getting negative
NAK. It is waste of our time if you keep ignoring reviewers and force us
to re-iterate the same over and over again.
feedback is better than no feedback from reviewers in my upstream training :-)
We will incorporate your feedback in the next version based on your
answer to the above question.
Thanks,
Pavan