From: Christoph Berliner <caberliner@gmail.com>
To: linux@roeck-us.net, wim@linux-watchdog.org
Cc: linux-watchdog@vger.kernel.org, linux-kernel@vger.kernel.org,
Christoph Berliner <caberliner@gmail.com>
Subject: [PATCH v3] watchdog: sp5100_tco: allow unreserved MMIO on GA-78LMT-USB3
Date: Fri, 21 Aug 2026 16:25:11 +0200 [thread overview]
Message-ID: <20260821142511.49934-1-caberliner@gmail.com> (raw)
In-Reply-To: <20260820231409.8427-1-caberliner@gmail.com>
The Gigabyte GA-78LMT-USB3 firmware programs the legacy SP5100
watchdog MMIO window at 0xfec000f0. This address falls inside the
IOAPIC resource, so sp5100_tco fails to reserve it and aborts probing.
Do not relocate or reprogram the watchdog. Instead, add a narrowly
scoped DMI quirk for this board which permits use of the
firmware-provided MMIO address without reserving it.
The exception is limited to the legacy SP5100 register layout, the
GA-78LMT-USB3 DMI identity, and the firmware address 0xfec000f0.
All other systems retain the existing resource reservation behavior.
On the affected system the watchdog initializes successfully and
/dev/watchdog0 is registered while the firmware-programmed watchdog
base remains unchanged at 0xfec000f0 during load and unload.
Tested on a Gigabyte GA-78LMT-USB3 with AMD SBx00 SMBus controller
(PCI 1002:4385, revision 0x3c).
Signed-off-by: Christoph Berliner <caberliner@gmail.com>
---
Thanks Guenter. I reworked the patch along the lines you suggested.
v3 is a complete replacement of the v2 relocation approach. None of the
relocation code from v2 is retained.
Instead, v3 adds a narrowly scoped DMI quirk for the affected
GA-78LMT-USB3. On that system, and only for the legacy SP5100 register
layout with the firmware-programmed watchdog address 0xfec000f0, the
driver is allowed to map and use the existing watchdog MMIO window
without reserving it.
The watchdog base is not relocated or reprogrammed. All other systems
retain the existing resource reservation behavior.
I tested the new path on the affected machine and again from a fresh
clone of the published GitHub repository. The watchdog initializes
successfully and /dev/watchdog0 is registered, while the firmware MMIO
base remains unchanged at 0xfec000f0 before, during and after driver use.
No separate SP5100 TCO resource is added to /proc/iomem.
Changes in v3:
- replace the v2 relocation approach entirely; none of the relocation
code from v2 is retained
- add a DMI quirk for the affected Gigabyte GA-78LMT-USB3
- allow the firmware-programmed 0xfec000f0 watchdog window to be used
without reserving it
- restrict the exception to the legacy SP5100 register layout and the
known firmware address
- leave all other systems on the existing resource reservation path
- hardware-test the new path and verify that the watchdog MMIO base
remains unchanged
drivers/watchdog/sp5100_tco.c | 61 ++++++++++++++++++++++++++++++++---
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/sp5100_tco.c b/drivers/watchdog/sp5100_tco.c
index 7e99c3b1f367..6c85f11cff24 100644
--- a/drivers/watchdog/sp5100_tco.c
+++ b/drivers/watchdog/sp5100_tco.c
@@ -33,6 +33,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/init.h>
+#include <linux/dmi.h>
#include <linux/io.h>
#include <linux/ioport.h>
#include <linux/module.h>
@@ -240,6 +241,35 @@ static u32 sp5100_tco_read_pm_reg32(u8 index)
return val;
}
+/*
+ * The Gigabyte GA-78LMT-USB3 firmware programs the legacy SP5100 watchdog
+ * MMIO window at 0xfec000f0. This address lies inside the IOAPIC resource,
+ * so the generic resource reservation fails even though firmware explicitly
+ * assigns the watchdog to this address.
+ *
+ * Keep this exception narrowly scoped to the affected system and firmware
+ * address. Do not relocate or otherwise reprogram the watchdog.
+ */
+#define SP5100_WDT_GA78LMT_MMIO 0xfec000f0
+
+static const struct dmi_system_id sp5100_tco_unreserved_mmio_dmi[] = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Gigabyte Technology Co., Ltd."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "GA-78LMT-USB3"),
+ },
+ },
+ {}
+};
+
+static bool sp5100_tco_allow_unreserved_mmio(struct sp5100_tco *tco,
+ u32 mmio_addr)
+{
+ return tco->tco_reg_layout == sp5100 &&
+ mmio_addr == SP5100_WDT_GA78LMT_MMIO &&
+ dmi_check_system(sp5100_tco_unreserved_mmio_dmi);
+}
+
static u32 sp5100_tco_request_region(struct device *dev,
u32 mmio_addr,
const char *dev_name)
@@ -259,6 +289,7 @@ static u32 sp5100_tco_prepare_base(struct sp5100_tco *tco,
const char *dev_name)
{
struct device *dev = tco->wdd.parent;
+ bool reserved = false;
dev_dbg(dev, "Got 0x%08x from SBResource_MMIO register\n", mmio_addr);
@@ -266,11 +297,29 @@ static u32 sp5100_tco_prepare_base(struct sp5100_tco *tco,
return -ENODEV;
/* Check for MMIO address and alternate MMIO address conflicts */
- if (mmio_addr)
- mmio_addr = sp5100_tco_request_region(dev, mmio_addr, dev_name);
+ if (mmio_addr) {
+ u32 requested_addr;
+
+ requested_addr = sp5100_tco_request_region(dev, mmio_addr,
+ dev_name);
+ if (requested_addr) {
+ mmio_addr = requested_addr;
+ reserved = true;
+ } else if (sp5100_tco_allow_unreserved_mmio(tco, mmio_addr)) {
+ dev_info(dev,
+ "Using firmware watchdog MMIO 0x%08x without reserving it\n",
+ mmio_addr);
+ } else {
+ mmio_addr = 0;
+ }
+ }
- if (!mmio_addr && alt_mmio_addr)
- mmio_addr = sp5100_tco_request_region(dev, alt_mmio_addr, dev_name);
+ if (!mmio_addr && alt_mmio_addr) {
+ mmio_addr = sp5100_tco_request_region(dev, alt_mmio_addr,
+ dev_name);
+ if (mmio_addr)
+ reserved = true;
+ }
if (!mmio_addr) {
dev_err(dev, "Failed to reserve MMIO or alternate MMIO region\n");
@@ -280,7 +329,9 @@ static u32 sp5100_tco_prepare_base(struct sp5100_tco *tco,
tco->tcobase = devm_ioremap(dev, mmio_addr, SP5100_WDT_MEM_MAP_SIZE);
if (!tco->tcobase) {
dev_err(dev, "MMIO address 0x%08x failed mapping\n", mmio_addr);
- devm_release_mem_region(dev, mmio_addr, SP5100_WDT_MEM_MAP_SIZE);
+ if (reserved)
+ devm_release_mem_region(dev, mmio_addr,
+ SP5100_WDT_MEM_MAP_SIZE);
return -ENOMEM;
}
--
2.55.0
next prev parent reply other threads:[~2026-08-21 14:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 22:25 [PATCH] watchdog: sp5100_tco: add reversible legacy MMIO relocation Christoph Berliner
2026-08-20 22:39 ` sashiko-bot
2026-08-20 23:14 ` [PATCH v2] " Christoph Berliner
2026-08-20 23:26 ` sashiko-bot
2026-08-21 0:59 ` Guenter Roeck
2026-08-21 14:25 ` Christoph Berliner [this message]
2026-08-21 16:56 ` [PATCH v3] watchdog: sp5100_tco: allow unreserved MMIO on GA-78LMT-USB3 Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260821142511.49934-1-caberliner@gmail.com \
--to=caberliner@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=wim@linux-watchdog.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox