Gunyah is a Type-I hypervisor which was introduced in the patch series
[1]. It is an open source hypervisor. The source repo is available at
[2].

The Gunyah Hypervisor doesn't allow its Virtual Machines to directly
access the MMIO watchdog. It either provides the fully emulated MMIO
based watchdog interface or the SMC-based watchdog interface depending
on the hypervisor configuration.
The SMC-based watchdog follows ARM's SMC Calling Convention (SMCCC)
version 1.1 and uses Vendor Specific Hypervisor Service Calls space.

This patch series adds support for the SMC-based watchdog interface
provided by the Gunyah Hypervisor.

This series is tested on SM8750 platform.

[1]
https://lore.kernel.org/all/20240222-gunyah-v17-0-1e9da6763d38@quicinc.com/

[2]
https://github.com/quic/gunyah-hypervisor

Signed-off-by: Hrishabh Rajput <hrishabh.rajput@oss.qualcomm.com>
---
Changes in v8:
- Fix error handling in gunyah_wdt_probe() to fail silently with -ENODEV
  if WDT_STATUS call returns -EOPNOTSUPP, indicating support for Gunyah
  watchdog is not present. Fail with logs for other errors.
- Link to v7: https://lore.kernel.org/r/20251114-gunyah_watchdog-v7-0-f5c155b941d5@oss.qualcomm.com

Changes in v7:
- Convert local `const` arrays to `static const` to optimize
  initialization and stack allocation.
- Link to v6: https://lore.kernel.org/r/20251112-gunyah_watchdog-v6-0-38ad01f8dac0@oss.qualcomm.com

Changes in v6:
- Fix build issues reported by the kernel test robot on PowerPC and RISC-V
  architectures by adding IS_ENABLED(CONFIG_HAVE_ARM_SMCCC_DISCOVERY) check
  before calling arm_smccc_hypervisor_has_uuid().
- Link to v5: https://lore.kernel.org/r/20251107-gunyah_watchdog-v5-0-4c6e3fb6eb17@oss.qualcomm.com

Changes in v5:
- Move the gunyah_wdt device registration from the SMEM driver to the
  SCM driver. Add additional logic to check if we're running under the
  Gunyah Hypervisor.
- Implement .remove() for gunyah_wdt driver to make it not persistent.
- Link to v4: https://lore.kernel.org/r/20251031-gunyah_watchdog-v4-0-7abb1ee11315@oss.qualcomm.com

Changes in v4:
- Move the contents of gunyah_wdt_init() to qcom_smem_probe() to make
  sure we're registering the watchdog only on the Qualcomm devices.
- Link to v3: https://lore.kernel.org/r/20251028-gunyah_watchdog-v3-1-e6d1ea438b1d@oss.qualcomm.com

Changes in v3:
- Move back to platform driver model. In module init, determine if we're
  running on a Qualcomm device and there is no supported memory-mapped
  watchdog present. Then proceed to register platform device and driver
  for SMC-based Gunyah watchdog.
- To determine if we're running on a Qualcomm device we're checking the
  presence of "qcom,smem" compatible devicetree node. As an alternative,
  we also tried using socinfo for the same purpose. When both
  gunyah_wdt and socinfo drivers were made built-in, it couldn't be
  ensured that the socinfo driver probed successfully before gunyah_wdt
  init was called. Hence, we resorted to the devicetree node approach.
- Limit the errors listed in gunyah_error to the ones that can be
  produced by the driver.
- Link to v2: https://lore.kernel.org/r/20251006-gunyah_watchdog-v2-1-b99d41d45450@oss.qualcomm.com

Changes in v2:
- Move away from platform driver model since the devicetree overlay does
  not happen by default.
  See https://lore.kernel.org/all/91002189-9d9e-48a2-8424-c42705fed3f8@quicinc.com/
- Only when MMIO-based watchdog device is absent in the devicetree,
  proceed to detect SMC-based watchdog using GUNYAH_WDT_STATUS SMC and
  initialize if SMC returns success.
- Implement pm notifiers as gunyah_wdt is no longer a platform driver so
  dev_pm_ops cannot be used.
- Pretimeout IRQ is no longer supported.
- Remove struct gunyah_wdt since it is not required.
- Move the contents of gunyah_errno.h to gunyah_wdt.c.
- Link to v1: https://lore.kernel.org/r/20250903-gunyah_watchdog-v1-0-3ae690530e4b@oss.qualcomm.com

---
Hrishabh Rajput (2):
      firmware: qcom: scm: Register gunyah watchdog device
      watchdog: Add driver for Gunyah Watchdog

 MAINTAINERS                      |   1 +
 drivers/firmware/qcom/qcom_scm.c |  53 ++++++++
 drivers/watchdog/Kconfig         |  13 ++
 drivers/watchdog/Makefile        |   1 +
 drivers/watchdog/gunyah_wdt.c    | 261 +++++++++++++++++++++++++++++++++++++++
 5 files changed, 329 insertions(+)
---
base-commit: 6a23ae0a96a600d1d12557add110e0bb6e32730c
change-id: 20250903-gunyah_watchdog-2d2649438e29

Best regards,
-- 
Hrishabh Rajput <hrishabh.rajput@oss.qualcomm.com>

Hi Bjorn, Guenter, and Wim,

Just a gentle ping on this series.

Since the patches have received Reviewed-by tags from Dmitry and 
Guenter, I wanted to confirm the merge strategy.

Bjorn: Are you planning to pick the QCOM SCM changes separately through 
your tree, or would you prefer the whole series go through the Watchdog 
tree?
If the latter, do we need an explicit Acked-by from you for QCOM SCM patch?

Thanks,
Hrishabh

On 02/12/2025 12:23, Hrishabh Rajput wrote:
> Hi Bjorn, Guenter, and Wim,
> 
> Just a gentle ping on this series.

It's merge window. There was no point in pinging just before merge
window and is even worse to ping now. Nothing can happen with this
patchset and such pings is only noise.

> 
> Since the patches have received Reviewed-by tags from Dmitry and 
> Guenter, I wanted to confirm the merge strategy.
> 
> Bjorn: Are you planning to pick the QCOM SCM changes separately through 
> your tree, or would you prefer the whole series go through the Watchdog 
> tree?
> If the latter, do we need an explicit Acked-by from you for QCOM SCM patch?

Where did you document dependencies between patches and any non-obvious
merging? I open cover letter and there is NOTHING. I look at patch
changelog and also NOTHING.

So if you tell us nothing, why would we care to think we need to do
anything special here?

You must explicitly document every dependency, both external and between
patches, in the cover letter. At least cover letter, some people (e.g.
mostly me) don't even read them...

Best regards,
Krzysztof

On 12/2/2025 9:29 PM, Krzysztof Kozlowski wrote:
> On 02/12/2025 12:23, Hrishabh Rajput wrote:
>> Hi Bjorn, Guenter, and Wim,
>>
>> Just a gentle ping on this series.
> 
> It's merge window. There was no point in pinging just before merge
> window and is even worse to ping now. Nothing can happen with this
> patchset and such pings is only noise.
> 

Thanks for the guidance and apologies for the noise created during the 
merge window.

>>
>> Since the patches have received Reviewed-by tags from Dmitry and
>> Guenter, I wanted to confirm the merge strategy.
>>
>> Bjorn: Are you planning to pick the QCOM SCM changes separately through
>> your tree, or would you prefer the whole series go through the Watchdog
>> tree?
>> If the latter, do we need an explicit Acked-by from you for QCOM SCM patch?
> 
> Where did you document dependencies between patches and any non-obvious
> merging? I open cover letter and there is NOTHING. I look at patch
> changelog and also NOTHING.
> 
> So if you tell us nothing, why would we care to think we need to do
> anything special here?
> 
> You must explicitly document every dependency, both external and between
> patches, in the cover letter. At least cover letter, some people (e.g.
> mostly me) don't even read them...
> 

This is a miss from my end. The following information should have been 
the part of the cover letter:
```
This series spans 2 subsystems and is split as follows:
- Patch 1: QCOM SCM - Register Gunyah Watchdog Platform device
- Patch 2: Watchdog - Add Gunyah Watchdog driver

Dependency:
There is no build-time dependency between the patches, but Patch 1 is 
required for Patch 2 to function.

Merge strategies:
- Strategy 1: Take both patches via the Watchdog tree.
- Strategy 2: Take Patch 1 via QCM SCM maintainter's tree, Patch 2 via 
Watchdog tree.

Since the patches concern primarily with the Watchdog, I suggest we go 
ahead with Strategy 1. If this is acceptable, I request an Acked-by from 
QCOM SCM maintainer for Patch 1.
```

I understand that this should have been a part of the cover letter. If 
it helps the process, I can add the above information in the cover 
letter and resend as v9. Since there are no other fixes, v9 would only 
contain the cover letter changes.

Thanks,
Hrishabh

Hi Bjorn and Wim,

On Mon, Dec 15, 2025 at 06:30:47PM +0530, Hrishabh Rajput wrote:
> 
> 
> On 12/2/2025 9:29 PM, Krzysztof Kozlowski wrote:
> > On 02/12/2025 12:23, Hrishabh Rajput wrote:
> > > Hi Bjorn, Guenter, and Wim,
> > > 
> > > Just a gentle ping on this series.
> > 
> > It's merge window. There was no point in pinging just before merge
> > window and is even worse to ping now. Nothing can happen with this
> > patchset and such pings is only noise.
> > 
> 
> Thanks for the guidance and apologies for the noise created during the merge
> window.
> 
> > > 
> > > Since the patches have received Reviewed-by tags from Dmitry and
> > > Guenter, I wanted to confirm the merge strategy.
> > > 
> > > Bjorn: Are you planning to pick the QCOM SCM changes separately through
> > > your tree, or would you prefer the whole series go through the Watchdog
> > > tree?
> > > If the latter, do we need an explicit Acked-by from you for QCOM SCM patch?
> > 
> > Where did you document dependencies between patches and any non-obvious
> > merging? I open cover letter and there is NOTHING. I look at patch
> > changelog and also NOTHING.
> > 
> > So if you tell us nothing, why would we care to think we need to do
> > anything special here?
> > 
> > You must explicitly document every dependency, both external and between
> > patches, in the cover letter. At least cover letter, some people (e.g.
> > mostly me) don't even read them...
> > 
> 
> This is a miss from my end. The following information should have been the
> part of the cover letter:
> ```
> This series spans 2 subsystems and is split as follows:
> - Patch 1: QCOM SCM - Register Gunyah Watchdog Platform device
> - Patch 2: Watchdog - Add Gunyah Watchdog driver
> 
> Dependency:
> There is no build-time dependency between the patches, but Patch 1 is
> required for Patch 2 to function.
> 
> Merge strategies:
> - Strategy 1: Take both patches via the Watchdog tree.
> - Strategy 2: Take Patch 1 via QCM SCM maintainter's tree, Patch 2 via
> Watchdog tree.
> 
> Since the patches concern primarily with the Watchdog, I suggest we go ahead
> with Strategy 1. If this is acceptable, I request an Acked-by from QCOM SCM
> maintainer for Patch 1.
> ```
> 

Is it possible to pick it up for v6.20? As mentioned above, both patches
don't have compile time dependency, however the QCOM SCM patch is needed
for probing the watchdog device.

Thanks,
Pavan

Hi Bjorn,

On Tue, Jan 06, 2026 at 11:25:49AM +0530, Pavan Kondeti wrote:
> Hi Bjorn and Wim,
> 
> On Mon, Dec 15, 2025 at 06:30:47PM +0530, Hrishabh Rajput wrote:
> > 
> > 
> > On 12/2/2025 9:29 PM, Krzysztof Kozlowski wrote:
> > > On 02/12/2025 12:23, Hrishabh Rajput wrote:
> > > > Hi Bjorn, Guenter, and Wim,
> > > > 
> > > > Just a gentle ping on this series.
> > > 
> > > It's merge window. There was no point in pinging just before merge
> > > window and is even worse to ping now. Nothing can happen with this
> > > patchset and such pings is only noise.
> > > 
> > 
> > Thanks for the guidance and apologies for the noise created during the merge
> > window.
> > 
> > > > 
> > > > Since the patches have received Reviewed-by tags from Dmitry and
> > > > Guenter, I wanted to confirm the merge strategy.
> > > > 
> > > > Bjorn: Are you planning to pick the QCOM SCM changes separately through
> > > > your tree, or would you prefer the whole series go through the Watchdog
> > > > tree?
> > > > If the latter, do we need an explicit Acked-by from you for QCOM SCM patch?
> > > 
> > > Where did you document dependencies between patches and any non-obvious
> > > merging? I open cover letter and there is NOTHING. I look at patch
> > > changelog and also NOTHING.
> > > 
> > > So if you tell us nothing, why would we care to think we need to do
> > > anything special here?
> > > 
> > > You must explicitly document every dependency, both external and between
> > > patches, in the cover letter. At least cover letter, some people (e.g.
> > > mostly me) don't even read them...
> > > 
> > 
> > This is a miss from my end. The following information should have been the
> > part of the cover letter:
> > ```
> > This series spans 2 subsystems and is split as follows:
> > - Patch 1: QCOM SCM - Register Gunyah Watchdog Platform device
> > - Patch 2: Watchdog - Add Gunyah Watchdog driver
> > 
> > Dependency:
> > There is no build-time dependency between the patches, but Patch 1 is
> > required for Patch 2 to function.
> > 
> > Merge strategies:
> > - Strategy 1: Take both patches via the Watchdog tree.
> > - Strategy 2: Take Patch 1 via QCM SCM maintainter's tree, Patch 2 via
> > Watchdog tree.
> > 
> > Since the patches concern primarily with the Watchdog, I suggest we go ahead
> > with Strategy 1. If this is acceptable, I request an Acked-by from QCOM SCM
> > maintainer for Patch 1.
> > ```
> > 
> 
> Is it possible to pick it up for v6.20? As mentioned above, both patches
> don't have compile time dependency, however the QCOM SCM patch is needed
> for probing the watchdog device.
> 

Please let us know if we need to split the series into two separate
patches? or is it fine to get first patch through qcom-next and 2nd
patch through watchdog tree?

Thanks,
Pavan