From: Kean Ren <rh_king@163.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
linux-hwmon@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Kean Ren <rh_king@163.com>
Subject: [PATCH 0/1] hwmon: (spd5118) support write protected devices
Date: Sun, 20 Sep 2026 14:22:25 +0800 [thread overview]
Message-ID: <20260920062230.2437291-2-rh_king@163.com> (raw)
In-Reply-To: <20260920062230.2437291-1-rh_king@163.com>
This patch makes the spd5118 driver usable on systems that do not allow
writes to SPD devices, while keeping the temperature sensor available.
Problem
=======
On many systems the SMBus controller is configured to block writes to SPD
addresses 0x50-0x57. On the i801 family this is SPD Write Disable
(SMBHSTCFG bit 4), set by the BIOS; reads are unaffected. There is no way
for a driver to query this.
The driver assumes that it can write to the device, which does not hold on
such systems:
- writes to the hwmon attributes always fail with -ENXIO
- the temperature sensor disable in spd5118_suspend() fails silently
- spd5118_resume() fails in regcache_sync(), and the kernel reports a
device resume failure:
spd5118 0-0050: Failed to write b = 0: -6
spd5118 0-0050: PM: failed to resume async: error -6
Register 0xb in that message is the page selector register, which regmap
writes back from its cache at the end of regcache_sync(). The write of the
saved configuration register before that fails as well, but the cache code
does not report that error.
What the patch does
===================
Detect write protection once at probe time by writing the page selector
register back with the value just read from it. This is a no-op on a device
which accepts writes, and it fails if writes are blocked. If writes are not
possible, run the device read-only:
- drop the register cache (REGCACHE_NONE), so that regcache_sync() cannot
attempt any write; this is what makes resume work
- skip the writes in the suspend and resume callbacks
- expose the writable attributes as 0444
- do not clear a latched alarm status from the alarm read path, as that
requires a write
- limit the nvmem 'eeprom' attribute to the currently selected page,
instead of returning errors for pages that cannot be reached
What is kept
============
The temperature sensor remains usable. For a chip which is already on page
0 - the normal case - reading the temperature and the temperature limits
does not need any write: regmap only writes the page selector when the
selected page actually changes.
What is not available on such systems
=====================================
- the temperature limits cannot be configured
- the sensor cannot be disabled during suspend, so it keeps running
- SPD EEPROM pages 1..7 are not readable, because selecting a page is
itself a write (the attribute is limited accordingly)
- a chip which reports a non-zero page and needs the page reset in
spd5118_i2c_init() is still rejected at probe, since that reset is also
a write
Relation to earlier proposals
=============================
Two other approaches were posted for the same problem:
1) Make the driver read-only as well, and additionally avoid instantiating
it on an i801 adapter when SPD writes are disabled:
hwmon: (spd5118) restrict writes under SPD write protection
https://lore.kernel.org/all/20250416-for-upstream-spd5118-spd-write-prot-detect-v1-2-8b3bcafe9dad@canonical.com/
i2c: i801: don't instantiate spd5118 under SPD Write Disable
https://lore.kernel.org/all/20250430-for-upstream-i801-spd5118-no-instantiate-v2-2f54d91ae2c7@canonical.com/
2) Expose the restriction as an adapter quirk and have spd5118 fail probe,
on the grounds that write access is mandatory (including a follow-up
suggestion to skip SPD instantiation on such adapters):
i2c: i801: Detect SPD Write Disable and expose as adapter quirk
https://lore.kernel.org/all/20260205102942.28745-1-tinsaetadesse2015@gmail.com/
This patch is deliberately limited to the driver side. It is complementary
to gating instantiation on the adapter side rather than competing with it:
not instantiating avoids probing a driver which cannot work on a given bus,
while tolerating a write protected device keeps the driver correct when it
is instantiated anyway - from devicetree, from userspace via new_device, or
on a controller which blocks SPD writes without the adapter driver knowing
about it.
The trade-off this patch makes is that DDR5 memory temperature monitoring
keeps working on affected systems, instead of not being available at all.
Testing
=======
Tested on a Lenovo ThinkPad P1 Gen 9 (DDR5), with SPD Write Disable set by
the BIOS:
- before: suspend-to-idle woke immediately; suspend_stats.failed_resume
incremented on every cycle (14 times) and last_failed_dev was "0-0050"
- after: 10 suspend/resume cycles with failed_resume and failed_suspend
remaining 0
- the chip is still detected and reports its temperature; the writable
attributes are 0444
Kean Ren (1):
hwmon: (spd5118) support write protected devices
Documentation/hwmon/spd5118.rst | 10 ++++
drivers/hwmon/spd5118.c | 110 +++++++++++++++++++++++++++++++++++-----
2 files changed, 108 insertions(+), 12 deletions(-)
--
2.53.0
next prev parent reply other threads:[~2026-09-20 6:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 6:22 [PATCH 1/1] hwmon: (spd5118) support write protected devices Kean Ren
2026-09-20 6:22 ` Kean Ren [this message]
2026-09-20 6:30 ` sashiko-bot
2026-09-21 14:16 ` Guenter Roeck
2026-09-22 2:31 ` Kean Ren
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=20260920062230.2437291-2-rh_king@163.com \
--to=rh_king@163.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.