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
prev parent reply other threads:[~2026-09-20 6:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 6:22 [PATCH 1/1] " Kean Ren
2026-09-20 6:22 ` Kean Ren [this message]
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®