From: Zinc Lim <limzhineng2@gmail.com>
To: alexanderduyck@fb.com, kuba@kernel.org, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@kernel.org, pabeni@redhat.com,
linux@roeck-us.net, horms@kernel.org, hmohsin@meta.com,
mike.marciniszyn@gmail.com
Cc: kernel-team@meta.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org,
zinclim@meta.com, limzhineng2@gmail.com
Subject: [PATCH net-next v4 0/6] eth: fbnic: expand hwmon sensor support
Date: Wed, 14 Oct 2026 15:22:18 -0700 [thread overview]
Message-ID: <20261014222225.2803660-1-limzhineng2@gmail.com> (raw)
The firmware capability response carries per-board sensor thresholds,
and the firmware reports which range a sensor has entered whenever it
crosses one of them. This series surfaces both to userspace:
- Move the sensor read logic out of fbnic_mac, closer to its only
caller in the hwmon code, and drop the now-unused get_sensor op.
- Cache the temperature and voltage readings for the current jiffy so
a burst of attribute reads issues a single firmware round-trip.
- Parse and expose the temperature (min/max/crit) and voltage
(min/max) thresholds. Thresholds the firmware does not report are
not exposed.
- Parse the range firmware reports, both in the unsolicited threshold
event and in the sensor read response, and cache it per sensor.
- Expose temp1_alarm and in0_alarm from that cached range, and notify
on each crossing through hwmon_notify_event().
- Derive the range from the reading carried with the event, on old
firmware that predates range reporting.
Changes from v3:
- Moved cache seeding to fbnic_mbx_init() in patch 2, so it also runs
on resume and AER recovery paths rather than only on probe.
- Dropped previous patch exposing all hwmon attributes unconditionally as
read-only. Thresholds the firmware does not report are now not visible
in sysfs.
- Collapsed the five per-threshold alarm attributes
(temp1_{min,max,crit}_alarm, in0_{min,max}_alarm) into one alarm per
sensor, temp1_alarm and in0_alarm. Firmware reports which range a
sensor is in rather than per-limit flags, so a single attribute
matches what the hardware reports.
- That alarm now comes from the reported range rather than from a
driver-side comparison of a live reading against the thresholds.
- Split the alarm work into two: patch 4 parses and caches the range,
from both the unsolicited event and the sensor read response, and
patch 5 exposes the attributes and notifies on each crossing. The
previous "firmware notifies hwmon on sensor threshold events" patch 6
is now folded into those.
- Added patch 6 for firmware that predates range reporting, which
flags only that a limit was exceeded.
Changes from v2:
- Addressed Jakub's patch 3 feedback on jiffy comparison when
checking cache validity.
Changes from v1:
- Addressed Jakub's patch 6 feedback on including a
if (!IS_REACHABLE(CONFIG_HWMON)) return; guard.
Zinc Lim (6):
eth: fbnic: move sensor read logic out of fbnic_mac
eth: fbnic: cache hwmon sensor readings
eth: fbnic: report temperature and voltage thresholds via hwmon
eth: fbnic: parse the alarm range reported by firmware
eth: fbnic: report temperature and voltage alarms via hwmon
eth: fbnic: derive the alarm range on older firmware
drivers/net/ethernet/meta/fbnic/fbnic.h | 11 +
drivers/net/ethernet/meta/fbnic/fbnic_fw.c | 140 +++++++-
drivers/net/ethernet/meta/fbnic/fbnic_fw.h | 44 +++
drivers/net/ethernet/meta/fbnic/fbnic_hwmon.c | 332 ++++++++++++++++--
drivers/net/ethernet/meta/fbnic/fbnic_mac.c | 55 ---
drivers/net/ethernet/meta/fbnic/fbnic_mac.h | 2 -
6 files changed, 500 insertions(+), 84 deletions(-)
--
2.53.0-Meta
next reply other threads:[~2026-10-14 22:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 22:22 Zinc Lim [this message]
2026-10-14 22:22 ` [PATCH net-next v4 1/6] eth: fbnic: move sensor read logic out of fbnic_mac Zinc Lim
2026-10-14 22:22 ` [PATCH net-next v4 2/6] eth: fbnic: cache hwmon sensor readings Zinc Lim
2026-10-14 22:22 ` [PATCH net-next v4 3/6] eth: fbnic: report temperature and voltage thresholds via hwmon Zinc Lim
2026-10-14 22:22 ` [PATCH net-next v4 4/6] eth: fbnic: parse the alarm range reported by firmware Zinc Lim
2026-10-14 22:22 ` [PATCH net-next v4 5/6] eth: fbnic: report temperature and voltage alarms via hwmon Zinc Lim
2026-10-14 22:22 ` [PATCH net-next v4 6/6] eth: fbnic: derive the alarm range on older firmware Zinc Lim
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=20261014222225.2803660-1-limzhineng2@gmail.com \
--to=limzhineng2@gmail.com \
--cc=alexanderduyck@fb.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=hmohsin@meta.com \
--cc=horms@kernel.org \
--cc=kernel-team@meta.com \
--cc=kuba@kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=mike.marciniszyn@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=zinclim@meta.com \
/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®