* Re: [PATCH net-next v5 07/15] net: ethernet: oa_tc6: Support for vendor specific MMS
From: sashiko-bot @ 2026-06-15 17:01 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260614-s2500-mac-phy-support-v5-7-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing state validation in MAC-PHY RX chunk processing leads to a NULL pointer dereference if a start-of-frame chunk is missed.
- [High] The RX path does not limit the accumulated length of ongoing chunks, allowing a malicious hardware device to trigger an `skb_over_panic`.
- [High] Repeated start-of-frame chunks without corresponding end-of-frame chunks will leak newly allocated socket buffers.
--
commit ad9ba89ed1440b885945a45d429d49b23e68bbdf
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
net: ethernet: oa_tc6: Support for vendor specific MMS
OPEN Alliance 10BASE-T1x Serial Interface specification, table 6
allows vendors to use any memory map select (MMS) value between
10 and 15. This new API interface enables vendor to map one of
thes MMS values to MDIO_MMD_VEND1.
> diff --git a/drivers/net/ethernet/oa_tc6/oa_tc6.c b/drivers/net/ethernet/oa_tc6/oa_tc6.c
> index 9410cecfdc2aa..fab7cb84df712 100644
> --- a/drivers/net/ethernet/oa_tc6/oa_tc6.c
> +++ b/drivers/net/ethernet/oa_tc6/oa_tc6.c
> @@ -202,6 +202,18 @@ int oa_tc6_ioctl(struct oa_tc6 *tc6, struct ifreq *rq, int cmd)
> }
> EXPORT_SYMBOL_GPL(oa_tc6_ioctl);
>
> +/**
> + * oa_tc6_set_vend1_mms - Add vendor specific MDIO_MMD to OA TC6 MMS
> + * mapper value.
> + * @tc6: oa_tc6 struct.
> + * @mms: vendor defined MMS value for VEND1 mdio device.
> + */
> +void oa_tc6_set_vend1_mms(struct oa_tc6 *tc6, int mms)
> +{
> + tc6->vend1_mms = mms;
> +}
> +EXPORT_SYMBOL_GPL(oa_tc6_set_vend1_mms);
> +
> static __be32 oa_tc6_prepare_ctrl_header(u32 addr, u8 length,
[Severity: High]
This is a pre-existing issue, but I noticed a potential NULL pointer
dereference during RX chunk processing. If the MAC-PHY sends an RX chunk with
end_valid set and start_valid clear as the first chunk:
drivers/net/ethernet/oa_tc6/oa_tc6.c:oa_tc6_prcs_rx_chunk_payload()
if (end_valid && !start_valid) {
size = end_byte_offset + 1;
oa_tc6_prcs_rx_frame_end(tc6, data, size);
return 0;
}
This function unconditionally calls oa_tc6_update_rx_skb(), which invokes
skb_put() on tc6->rx_skb:
drivers/net/ethernet/oa_tc6/oa_tc6.c:oa_tc6_update_rx_skb()
memcpy(skb_put(tc6->rx_skb, length), payload, length);
Since tc6->rx_skb is only allocated when a chunk with a valid start is
received, it will be NULL in this case. Can a malfunctioning or malicious
MAC-PHY trigger a kernel panic here?
[Severity: High]
This isn't a bug introduced by this patch, but there appears to be a missing
length check when accumulating ongoing RX chunks. If the MAC-PHY streams an
unbroken series of ongoing chunks (start_valid = 0 and end_valid = 0),
oa_tc6_prcs_ongoing_rx_frame() repeatedly appends data:
drivers/net/ethernet/oa_tc6/oa_tc6.c:oa_tc6_prcs_ongoing_rx_frame()
oa_tc6_update_rx_skb(tc6, payload, OA_TC6_CHUNK_PAYLOAD_SIZE);
Since the SKB allocated in oa_tc6_allocate_rx_skb() has a fixed capacity
based on the MTU, could a stream of ongoing chunks eventually exceed the
skb's tailroom and trigger an skb_over_panic()?
[Severity: High]
This is a pre-existing issue, but repeated start-of-frame chunks might leak
socket buffers. When oa_tc6_prcs_rx_chunk_payload() receives a new start
chunk without the previous frame ending, it allocates a new SKB:
drivers/net/ethernet/oa_tc6/oa_tc6.c:oa_tc6_prcs_rx_chunk_payload()
if (start_valid && !end_valid) {
size = OA_TC6_CHUNK_PAYLOAD_SIZE - start_byte_offset;
return oa_tc6_prcs_rx_frame_start(tc6, &data[start_byte_offset],
size, footer);
}
This eventually calls oa_tc6_allocate_rx_skb() which overwrites the
tc6->rx_skb pointer:
drivers/net/ethernet/oa_tc6/oa_tc6.c:oa_tc6_allocate_rx_skb()
tc6->rx_skb = netdev_alloc_skb_ip_align(tc6->netdev, tc6->netdev->mtu +
ETH_HLEN + ETH_FCS_LEN +
OA_TC6_TSTAMP_SZ);
If tc6->rx_skb was already populated from a previously interrupted frame,
the old pointer is overwritten without being freed. Can this be used to
exhaust kernel memory by continuously sending start chunks?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=7
^ permalink raw reply
* Re: [PATCH net-next v5 08/15] net: ethernet: oa_tc6: read, write interface with MMS option
From: sashiko-bot @ 2026-06-15 17:01 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260614-s2500-mac-phy-support-v5-8-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Incorrect teardown order in lan865x_remove allows a race condition leading to a use-after-free on the private netdev structure.
--
commit 6ac71b4b2fa47efef74336ba2f488f113f5cdd43
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
net: ethernet: oa_tc6: read, write interface with MMS option
This commit introduces new read/write APIs to the oa_tc6 framework that
accept the Memory Map Selector (MMS) as a parameter. This allows vendors
to use any memory map selector without having to manually encode the
address prior to calling the API. The lan865x driver is updated to use
these new functions.
> diff --git a/drivers/net/ethernet/microchip/lan865x/lan865x.c b/drivers/net/ethernet/microchip/lan865x/lan865x.c
> index 0277d9737369a..3b555ee698041 100644
> --- a/drivers/net/ethernet/microchip/lan865x/lan865x.c
> +++ b/drivers/net/ethernet/microchip/lan865x/lan865x.c
[ ... ]
> @@ -235,7 +240,8 @@ static void lan865x_multicast_work_handler(struct work_struct *work)
> if (lan865x_clear_all_multicast_addr(priv))
> return;
> }
> - ret = oa_tc6_write_register(priv->tc6, LAN865X_REG_MAC_NET_CFG, regval);
> + ret = oa_tc6_write_register_mms(priv->tc6, LAN865X_REG_MAC_NET_CFG,
> + OA_TC6_PHY_C45_MAC_MMS1, regval);
> if (ret)
> netdev_err(priv->netdev, "Failed to enable promiscuous/multicast/normal mode: %d\n",
> ret);
[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the changes
around the multicast work handler, I noticed an issue with the teardown order
in lan865x_remove().
Can a use-after-free occur here?
drivers/net/ethernet/microchip/lan865x/lan865x.c:lan865x_remove() {
...
cancel_work_sync(&priv->multicast_work);
unregister_netdev(priv->netdev);
oa_tc6_exit(priv->tc6);
free_netdev(priv->netdev);
}
Since cancel_work_sync() is called before unregister_netdev(), couldn't
user-space trigger a configuration change (like toggling promiscuity via
ip link) during this window?
This would call ndo_set_rx_mode and reschedule the multicast work.
When free_netdev() subsequently frees the priv structure, the queued work
would remain on the workqueue, potentially accessing the freed priv pointer
when it later executes.
Should unregister_netdev() be called before cancel_work_sync() so the device
is no longer visible to user-space, preventing further ndo_set_rx_mode calls?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=8
^ permalink raw reply
* Re: [PATCH net-next v5 11/15] net: phy: ncn26000: Support for loopback
From: sashiko-bot @ 2026-06-15 17:01 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260614-s2500-mac-phy-support-v5-11-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The newly added loopback support is broken because the driver's config_aneg implementation blindly overwrites the MII_BMCR register, clearing the loopback bit.
--
commit 5a40363adea3a7ee8be993f04a56cb1d3004a24b
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
net: phy: ncn26000: Support for loopback
Adding loopback support for S2500 internal PHY to help running
loopback test through ethtool.
> diff --git a/drivers/net/phy/ncn26000.c b/drivers/net/phy/ncn26000.c
> index c3a34b2c524d5..afafa81dc22b8 100644
> --- a/drivers/net/phy/ncn26000.c
> +++ b/drivers/net/phy/ncn26000.c
> @@ -178,6 +178,7 @@ static struct phy_driver ncn26000_driver[] = {
> .config_aneg = ncn26000_config_aneg,
> .read_status = ncn26000_read_status,
> .handle_interrupt = ncn26000_handle_interrupt,
> + .set_loopback = genphy_loopback_fixed_speed,
[Severity: High]
Does ncn26000_config_aneg() inadvertently clear the loopback bit that is
configured here?
Looking at the driver's implementation of ncn26000_config_aneg():
drivers/net/phy/ncn26000.c:ncn26000_config_aneg() {
...
// bring up the link
return phy_write(phydev, MII_BMCR, NCN26000_BCMR_LINK_CTRL_BIT);
}
When the interface is brought up, the PHY state machine is asynchronously
scheduled and can transition from PHY_UP by unconditionally calling
ncn26000_config_aneg().
If the user activates the loopback selftest simultaneously, the loopback
bit is set via genphy_loopback_fixed_speed(). However, because
ncn26000_config_aneg() blindly overwrites the MII_BMCR register using
phy_write(), it silently clears the BMCR_LOOPBACK bit.
This causes the hardware loopback to be disabled while the software state
indicates it is active, which can lead to selftest failures and potentially
leak test packets onto the network wire.
Could ncn26000_config_aneg() use phy_modify() instead of phy_write() to
preserve orthogonal bits like BMCR_LOOPBACK?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=11
^ permalink raw reply
* Re: [PATCH net-next v5 12/15] onsemi: s2500: Add driver support for TS2500 MAC-PHY
From: sashiko-bot @ 2026-06-15 17:01 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260614-s2500-mac-phy-support-v5-12-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 12 potential issue(s) to consider:
- [High] Premature exit of the polling kthread leads to a Use-After-Free during driver teardown or RX mode updates.
- [High] Lockless traversal of the multicast address list in the background thread causes data races and potential Use-After-Free.
- [High] PTP adjtime blocks for up to 60 seconds and computes frequency offset incorrectly.
- [High] Failure in s2500_open() leaks the background kthread and leaves the PHY running.
- [High] Failure paths in s2500_probe() do not clean up resources allocated by oa_tc6_init().
- [High] Concurrent Read-Modify-Write of the MAC_CTRL register leads to lost updates.
- [High] The s2500_thread_fun kthread contains a lost wakeup window for kthread_stop() causing 5 second interface teardown hang.
- [Medium] Standard netdev statistics are duplicated in driver-private ethtool -S strings.
- [Medium] The multicast hardware filter is incorrectly left disabled when specific MAC addresses are configured.
- [Medium] IFF_UNICAST_FLT is set but secondary unicast MAC filtering is not implemented.
- [Medium] The initialization function silently ignores failures when configuring the device's MAC address filter.
- [Medium] Incorrect MAC address filter register write ordering for multicast addresses.
--
commit 460baa0800374b033a33a01995e62355074e779a
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
onsemi: s2500: Add driver support for TS2500 MAC-PHY
This commit introduces a new ethernet driver for the onsemi S2500, an 802.3 cg
compliant transceiver with integrated MAC-PHY. It hooks into the Open Alliance
TC6 framework and implements ethtool stats, hardware timestamping, and PTP.
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c
[ ... ]
> +static const char s2500_mac_stat_strings[][ETH_GSTRING_LEN] = {
> + "tx_bytes",
> + "tx_frames",
> + "tx_broadcast_frames",
> + "tx_multicast_frames",
[Severity: Medium]
Is it necessary to duplicate standard network statistics like tx_bytes and
tx_frames here?
Standard hardware counters should typically be exposed through ndo_get_stats64
(struct rtnl_link_stats64) rather than driver-private ethtool -S strings.
[ ... ]
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/s2500_main.c
[ ... ]
> +static int s2500_mac_ctrl_modify_bits(struct s2500_info *priv,
> + u32 in_bits, bool clr)
> +{
> + u32 reg = S2500_REG_MAC_CTRL;
> + u32 rval = 0;
> + int ret;
> +
> + ret = oa_tc6_read_register_mms(priv->tc6, reg,
> + OA_TC6_PHY_C45_MAC_MMS1, &rval);
> + if (!ret) {
> + u32 wval = 0;
> +
> + if (clr)
> + wval = rval & ~in_bits;
> + else
> + wval = rval | in_bits;
> + if (rval != wval)
> + ret = oa_tc6_write_register_mms(priv->tc6, reg,
> + OA_TC6_PHY_C45_MAC_MMS1, wval);
[Severity: High]
Is this read-modify-write cycle safe from concurrent execution?
This function appears to be called from the asynchronous background thread
(s2500_rx_mode_update) as well as the networking stack callbacks (e.g.,
s2500_shutdown in the ndo_stop path). Without locking, a TOCTOU race could
cause one path's modification to overwrite the other's.
[ ... ]
> +static int s2500_init(struct s2500_info *priv)
> +{
[ ... ]
> + /* Program the source MAC address into the device */
> + ret = s2500_set_mac_filter(priv->ndev, priv->ndev->dev_addr);
> +
> + val = S2500_MAC_CTRL_ADRF_BIT | S2500_MAC_CTRL_FCSA_BIT;
> +
> + return s2500_mac_ctrl_modify_bits(priv, val, false);
[Severity: Medium]
Does this intentionally discard the return code from s2500_set_mac_filter()?
If setting the MAC address filter fails, the error in 'ret' is immediately
overwritten. This could cause the driver to silently proceed with a
misconfigured MAC address.
[ ... ]
> +static int s2500_set_multicast_mode(struct s2500_info *priv,
> + unsigned int rx_flags)
> +{
[ ... ]
> + } else {
> + struct netdev_hw_addr *ha;
> + u32 addrh, addrl;
> +
> + /* Disable multicast filter */
> + ret = s2500_mac_ctrl_modify_bits(priv,
> + S2500_MAC_CTRL_MCSF_BIT,
> + true);
> + if (ret)
> + return ret;
> +
> + /* Disable filters */
[Severity: Medium]
Should the multicast filter be re-enabled after writing the specific addresses
to the hardware slots?
The code intentionally disables the global filter (S2500_MAC_CTRL_MCSF_BIT) at
the beginning of this block, but it does not invoke modify_bits(..., false) at
the end, leaving the hardware in all-multicast mode.
[ ... ]
> + i = 1;
> + netdev_for_each_mc_addr(ha, priv->ndev) {
[Severity: High]
Can this lockless iteration race with userspace modifications?
Since this is executed in the background kthread asynchronously, traversing the
multicast list without holding the netif_addr_lock_bh(ndev) lock might
cause list corruption or a use-after-free if dev_mc_add or dev_mc_del runs
concurrently.
[ ... ]
> + ret = oa_tc6_write_register_mms(priv->tc6,
> + S2500_REG_MAC_ADDRFILTH(i),
> + OA_TC6_PHY_C45_MAC_MMS1, addrh);
> + if (ret)
> + return ret;
> +
> + ret = oa_tc6_write_register_mms(priv->tc6,
> + S2500_REG_MAC_ADDRFILTL(i),
> + OA_TC6_PHY_C45_MAC_MMS1, addrl);
[Severity: Medium]
Is this write order correct?
This writes S2500_REG_MAC_ADDRFILTH(i) (which contains the
S2500_MAC_ADDRFILT_EN_BIT enable flag) before writing the
S2500_REG_MAC_ADDRFILTL(i) payload. Writing the enable bit before the data
payload could cause the hardware to match against a partially-updated,
stale MAC address.
[ ... ]
> +static int s2500_thread_fun(void *data)
> +{
[ ... ]
> + do {
> + if (update_rx_mode) {
> + ret = s2500_rx_mode_update(priv);
> + if (unlikely(ret)) {
> + dev_err(&priv->spi->dev, "Failed to set new RX mode");
> + break;
> + }
> + }
[Severity: High]
If s2500_rx_mode_update() fails, this break statement drops out of the loop
causing the kthread to terminate and the kernel to free its task_struct.
However, the driver does not set priv->thread to NULL. When the device is
stopped, won't kthread_stop() blindly dereference the freed task_struct
leading to a use-after-free?
[ ... ]
> + spin_lock_irqsave(&priv->lock, flags);
> + __set_current_state(TASK_INTERRUPTIBLE);
> +
> + update_rx_mode = priv->rx_flags_upd;
> + ret = update_rx_mode;
> +
> + spin_unlock_irqrestore(&priv->lock, flags);
> +
> + if (!ret)
> + tout = schedule_timeout(tout);
> + else
> + set_current_state(TASK_RUNNING);
> + } while (!kthread_should_stop());
> + return 0;
> +}
[Severity: High]
Could kthread_stop() trigger a lost wakeup here?
If kthread_stop() runs after the loop condition is evaluated but before
__set_current_state(), the thread's TASK_RUNNING state will be immediately
overwritten with TASK_INTERRUPTIBLE. The thread would then sleep in
schedule_timeout() for up to 5 seconds, ignoring the stop request.
[ ... ]
> +static int s2500_open(struct net_device *ndev)
> +{
[ ... ]
> + if (IS_ERR(priv->thread)) {
> + ret = PTR_ERR(priv->thread);
> + } else {
> + val = S2500_MAC_CTRL_TXEN_BIT | S2500_MAC_CTRL_RXEN_BIT;
> + ret = s2500_mac_ctrl_modify_bits(priv, val, false);
> +
> + netif_start_queue(priv->ndev);
> + }
> + return ret;
> +}
[Severity: High]
If s2500_mac_ctrl_modify_bits() fails here, the function returns an error
without stopping the kthread or the PHY. Since ndo_stop is not invoked
if ndo_open fails, won't this leak the kthread and leave the PHY running?
[ ... ]
> +static int s2500_stop(struct net_device *ndev)
> +{
[ ... ]
> + s2500_shutdown(priv);
> +
> + kthread_stop(priv->thread);
> + priv->thread = NULL;
> +
> + return 0;
> +}
[ ... ]
> +static int s2500_probe(struct spi_device *spi)
> +{
[ ... ]
> + ndev->priv_flags |= IFF_UNICAST_FLT;
[Severity: Medium]
The driver advertises IFF_UNICAST_FLT, but s2500_set_rx_mode() does not
appear to process ndev->uc (the unicast address list).
Since this flag is set, the kernel won't automatically fall back to promiscuous
mode when secondary unicast addresses are assigned, which may cause traffic for
those addresses to be dropped.
[ ... ]
> + ret = s2500_init(priv);
> + if (unlikely(ret)) {
> + dev_err(&spi->dev, "failed to s2500_init the device");
> + goto err_reg_read;
> + }
[ ... ]
> + ret = register_netdev(ndev);
> + if (ret) {
> + dev_err(&spi->dev, "failed to register the S2500 device\n");
> + ret = -ENODEV;
> +
> + goto err_reg_read;
> + }
> + return 0;
> +
> +err_reg_read:
> + dev_err(&spi->dev, "could not initialize macphy");
> + return ret;
> +}
[Severity: High]
If s2500_init(), s2500_ptp_register(), or register_netdev() fail, this jumps
to err_reg_read but does not clean up the TC6 framework.
Should this call oa_tc6_exit() and oa_tc6_ptp_unregister() to prevent memory
leaks and dangling PTP registrations?
[ ... ]
> --- /dev/null
> +++ b/drivers/net/ethernet/onsemi/s2500/s2500_ptp.c
[ ... ]
> +static int s2500_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
> +{
[ ... ]
> + /* Compute scaled_ppm (Qx.16). scaled_ppm = ppm * 2^16
> + * ppm = (delta_seconds / period_seconds) * 1e6
> + * => scaled_ppm = delta_ns * 65536 / (period_ms * 1000)
> + */
> + num = remaining * 65536LL;
> + den = (s64)period_ms * 1000LL;
> +
> + /* Integer division rounds toward zero; keep sign in numerator */
> + scaled_ppm = div_s64(num, den);
> +
> + /* Apply frequency adjustment */
> + ret = ptp->adjfine(ptp, (long)scaled_ppm);
> + if (ret)
> + break;
> +
> + /* Sleep for the slew period (interruptible). If interrupted, clear
> + * the adjfine and return with -EINTR.
> + */
> + if (msleep_interruptible(period_ms)) {
[Severity: High]
Does this extra multiplication by 1000 result in an incorrect scaled_ppm?
Dividing the denominator by 1000 again will make the frequency adjustment
1000 times too small.
Additionally, the software slewing loop calls msleep_interruptible() for
up to 60 seconds (or 180s total) while holding the ptp_adj_lock. Will this
block the calling userspace servo loop (e.g., ptp4l via clock_adjtime)
in the kernel for excessive periods?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=12
^ permalink raw reply
* Re: [PATCH net-next v5 13/15] onsemi: s2500: Added selftest support to onsemi's S2500 driver
From: sashiko-bot @ 2026-06-15 17:01 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260614-s2500-mac-phy-support-v5-13-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Returning 0 from `get_sset_count` for `ETH_SS_TEST` triggers a `WARN_ON` in the ethtool core when `CONFIG_NET_SELFTESTS` is disabled.
--
commit 8adb07a1816e950bf0dedebd55b13b3a9497928e
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
onsemi: s2500: Added selftest support to onsemi's S2500 driver
This commit introduces ethtool selftest support to the onsemi S2500 MAC-PHY
driver. It exposes selftests by handling the ETH_SS_TEST stringset and
registering the self_test callback in the ethtool operations.
> diff --git a/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c b/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c
> index 85bd8ea50dd8c..334fac71ddea2 100644
> --- a/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c
> +++ b/drivers/net/ethernet/onsemi/s2500/s2500_ethtool.c
[ ... ]
> @@ -229,6 +230,8 @@ static int s2500_get_sset_count(struct net_device *ndev, int sset)
> switch (sset) {
> case ETH_SS_STATS:
> return S2500_MAC_STATS_LEN;
> + case ETH_SS_TEST:
> + return net_selftest_get_count();
[Severity: Medium]
When CONFIG_NET_SELFTESTS is disabled, the dummy implementation of
net_selftest_get_count() defined in include/net/selftests.h returns 0.
Because the driver unconditionally registers the .self_test callback below
in s2500_ethtool_ops:
const struct ethtool_ops s2500_ethtool_ops = {
...
.self_test = net_selftest,
};
Will returning 0 from s2500_get_sset_count() trigger a WARN_ON(test_len == 0)
in the ethtool core ioctl path when a user runs "ethtool -t"?
Could this check for a 0 test count and return -EOPNOTSUPP instead to avoid
the warning?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=13
^ permalink raw reply
* Re: [PATCH net-next v5 14/15] dt-bindings: net: add onsemi's S2500
From: sashiko-bot @ 2026-06-15 17:01 UTC (permalink / raw)
To: Selvamani Rajagopal via B4 Relay; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260614-s2500-mac-phy-support-v5-14-89874b72f725@onsemi.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The device tree binding example incorrectly configures a level-triggered hardware interrupt as edge-triggered (IRQ_TYPE_EDGE_FALLING) instead of level-low (IRQ_TYPE_LEVEL_LOW) to document a software work-around rather than the hardware specification.
--
commit ec7eac5028b65bdc87468f9d30d6acc2c8cd7494
Author: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
dt-bindings: net: add onsemi's S2500
This commit adds a new device tree binding for the onsemi S2500 10BASE-T1S
MACPHY Ethernet Controller. It documents the required properties for the
SPI-connected device and provides an example configuration.
> diff --git a/Documentation/devicetree/bindings/net/onnn,s2500.yaml b/Documentation/devicetree/bindings/net/onnn,s2500.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/onnn,s2500.yaml
[ ... ]
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ethernet@0 {
> + compatible = "onnn,s2500";
> + reg = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <ð0_pins>;
> + interrupt-parent = <&gpio>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
[Severity: Medium]
The commit message mentions the OPEN Alliance specification requires a
level-low interrupt, but the example configures an edge-triggered falling
interrupt to work around a Linux software framework bug.
Should the device tree binding example accurately describe the physical
hardware (IRQ_TYPE_LEVEL_LOW) rather than documenting an OS-specific
software workaround?
Treating a level-sensitive interrupt as edge-sensitive could lead to
missed interrupts and stall the MAC-PHY hardware state machine if the
interrupt line is held low due to multiple pending events. Is it possible
to reflect the correct hardware state in the binding, while handling
the temporary software workaround internally within the driver?
> + spi-max-frequency = <15000000>;
> + };
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260614-s2500-mac-phy-support-v5-0-89874b72f725@onsemi.com?part=14
^ permalink raw reply
* Re: [PATCH v2 2/6] dt-bindings: clock: qcom: sm8550-gcc: Add missing power-domains property
From: sashiko-bot @ 2026-06-15 17:03 UTC (permalink / raw)
To: Neil Armstrong; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260615-topic-sm8x50-tie-gcc-to-cx-v2-2-6b5752dd4747@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The devicetree binding example fails to compile because it uses the macro `RPMHPD_CX` without including its defining header.
--
commit 8ab50c22b4edbee1a4ec4ab581c1e5e14181a614
Author: Neil Armstrong <neil.armstrong@linaro.org>
dt-bindings: clock: qcom: sm8550-gcc: Add missing power-domains property
This commit adds the missing power-domains property to the SM8550 GCC clocks
binding so that GCC votes on provided GDSCs can be propagated to the CX domain.
> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml
> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-gcc.yaml
[ ... ]
> @@ -55,6 +60,7 @@ examples:
> <&ufs_mem_phy 1>,
> <&ufs_mem_phy 2>,
> <&usb_1_qmpphy>;
> + power-domains = <&rpmhpd RPMHPD_CX>;
[Severity: Low]
Does this example fail dt_binding_check because the RPMHPD_CX macro is used
without including <dt-bindings/power/qcom,rpmhpd.h>?
Without the header inclusion, the C preprocessor will not expand the macro,
which usually results in dtc throwing a syntax error when parsing the raw
string during schema validation.
> #clock-cells = <1>;
> #reset-cells = <1>;
> #power-domain-cells = <1>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-topic-sm8x50-tie-gcc-to-cx-v2-0-6b5752dd4747@linaro.org?part=2
^ permalink raw reply
* Re: [PATCH v2 3/6] dt-bindings: clock: qcom: sm8650-gcc: Add missing power-domains property
From: sashiko-bot @ 2026-06-15 17:05 UTC (permalink / raw)
To: Neil Armstrong; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260615-topic-sm8x50-tie-gcc-to-cx-v2-3-6b5752dd4747@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing `#include <dt-bindings/power/qcom,rpmhpd.h>` in the device tree binding example causes `dt_binding_check` to fail with a syntax error.
--
commit cf54041a81ff607a5e2770b322af6489287fb22f
Author: Neil Armstrong <neil.armstrong@linaro.org>
dt-bindings: clock: qcom: sm8650-gcc: Add missing power-domains property
This commit declares CX as a power domain of the GCC to allow votes
on the GDSCs to be propagated. It adds the power-domains property to
the binding and updates the example accordingly.
> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml
> index c7143e2abc80c..9c1504827cbff 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml
[ ... ]
> @@ -58,6 +63,7 @@ examples:
> <&ufs_mem_phy 1>,
> <&ufs_mem_phy 2>,
> <&usb_1_qmpphy>;
> + power-domains = <&rpmhpd RPMHPD_CX>;
[Severity: Low]
Does this example need to include <dt-bindings/power/qcom,rpmhpd.h> for the
RPMHPD_CX macro to be resolved?
Without the header include in the YAML file, the macro remains unexpanded
during preprocessing. This can cause dtc to fail with a syntax error during
make dt_binding_check because it expects an integer cell value inside the
property array.
> #clock-cells = <1>;
> #reset-cells = <1>;
> #power-domain-cells = <1>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-topic-sm8x50-tie-gcc-to-cx-v2-0-6b5752dd4747@linaro.org?part=3
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: dts: qcom: sm8650: fix soundwire ports properties
From: sashiko-bot @ 2026-06-15 17:05 UTC (permalink / raw)
To: Neil Armstrong; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260615-topic-sm8650-upstream-cpu-props-v3-3-eeb6e9fa7581@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Prepending an element to the `qcom,ports-*` arrays for `swr2` shifts the configuration indices, corrupting the SoundWire Master Port configurations for the TX codec.
--
commit a1c9b1d54073d838cfb9e5474d5c6e26f81803b9
Author: Neil Armstrong <neil.armstrong@linaro.org>
arm64: dts: qcom: sm8650: fix soundwire ports properties
This commit updates the soundwire port counts and properties to match the
actual hardware configuration, addressing deprecation warnings for din/out
ports.
> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> index 090a4739ebc1d..b1293fdb1481c 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
[ ... ]
> @@ -4831,17 +4831,17 @@ swr2: soundwire@6d30000 {
> pinctrl-names = "default";
>
> qcom,din-ports = <4>;
> - qcom,dout-ports = <0>;
> -
> - qcom,ports-sinterval-low = /bits/ 8 <0x01 0x01 0x03 0x03>;
> - qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x01 0x01>;
> - qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x00 0x00>;
> - qcom,ports-hstart = /bits/ 8 <0xff 0xff 0xff 0xff>;
> - qcom,ports-hstop = /bits/ 8 <0xff 0xff 0xff 0xff>;
> - qcom,ports-word-length = /bits/ 8 <0xff 0xff 0xff 0xff>;
> - qcom,ports-block-pack-mode = /bits/ 8 <0xff 0xff 0xff 0xff>;
> - qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff>;
> - qcom,ports-lane-control = /bits/ 8 <0x01 0x02 0x00 0x00>;
> + qcom,dout-ports = <1>;
> +
> + qcom,ports-sinterval-low = /bits/ 8 <0x00 0x01 0x01 0x03 0x03>;
[Severity: High]
Does prepending an element to the qcom,ports-* arrays in swr2 shift the
absolute index mapping expected by the TX codec's qcom,tx-port-mapping?
The soundwire driver maps these array elements sequentially to pconfig[1]
through pconfig[nports]. Slave devices, such as the WCD9395 TX codec, rely
on absolute Master Port indices defined in their board-level tx-port-mapping
properties to directly index pconfig and program fixed hardware registers.
By prepending a new element to account for dout-ports = 1, it appears all
subsequent configurations are shifted. As a result, pconfig[2] might now
receive data from array index 0 instead of index 1 (for example, lane_control
would change from 0x02 to 0x01).
Will this misconfigure the active TX SoundWire ports and break capture audio
functionality on SM8650 boards?
> + qcom,ports-offset1 = /bits/ 8 <0x00 0x00 0x00 0x01 0x01>;
> + qcom,ports-offset2 = /bits/ 8 <0x00 0x00 0x00 0x00 0x00>;
> + qcom,ports-hstart = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
> + qcom,ports-hstop = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
> + qcom,ports-word-length = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
> + qcom,ports-block-pack-mode = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
> + qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff 0xff>;
> + qcom,ports-lane-control = /bits/ 8 <0xff 0x01 0x02 0x00 0x00>;
>
> #address-cells = <2>;
> #size-cells = <0>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-topic-sm8650-upstream-cpu-props-v3-0-eeb6e9fa7581@linaro.org?part=3
^ permalink raw reply
* Re: [PATCH RFC v3 1/6] arm64: dts: qcom: add PMIC5 Gen3 macros for channel numbers
From: sashiko-bot @ 2026-06-15 17:07 UTC (permalink / raw)
To: Neil Armstrong; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260615-topic-sm8x50-adc5-gen3-v3-1-216a2b5ccb85@linaro.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Incorrect include guards ('ACD5' instead of 'ADC5') in the PMIC specific ADC headers.
- [Low] Leading space before SPDX-License-Identifier comment.
--
commit 3eda1039cbb8425b3c3af45f1320fc946f6b44cd
Author: Neil Armstrong <neil.armstrong@linaro.org>
arm64: dts: qcom: add PMIC5 Gen3 macros for channel numbers
This commit adds PMIC5 Gen3 macros to calculate ADC channel numbers based on
SPMI bus numbers and sensor configurations. It moves the macro definitions from
dt-bindings to local includes for better DT source readability.
Link: https://lore.kernel.org/all/20250826083657.4005727-4-jishnu.prakash@oss.qualcomm.com/
> diff --git a/arch/arm64/boot/dts/qcom/qcom,adc5-gen3-channels.h b/arch/arm64/boot/dts/qcom/qcom,adc5-gen3-channels.h
> new file mode 100644
> index 0000000000000..a8aac9ae6f404
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcom,adc5-gen3-channels.h
> @@ -0,0 +1,88 @@
> + /* SPDX-License-Identifier: GPL-2.0 */
[Severity: Low]
This isn't a bug, but there is a leading space before the SPDX identifier on
the first line. Could this be removed to ensure automated scanners and
checkpatch.pl find the tag where they expect it?
[ ... ]
> diff --git a/arch/arm64/boot/dts/qcom/qcom,pm8550-adc5-gen3.h b/arch/arm64/boot/dts/qcom/qcom,pm8550-adc5-gen3.h
> new file mode 100644
> index 0000000000000..2a6338812d4e9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcom,pm8550-adc5-gen3.h
> @@ -0,0 +1,46 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#ifndef _QCOM_PM8550_ACD5_GEN3_H
> +#define _QCOM_PM8550_ACD5_GEN3_H
[Severity: Low]
This isn't a bug, but should these header guards use ADC5 instead of ACD5?
[ ... ]
> diff --git a/arch/arm64/boot/dts/qcom/qcom,pm8550b-adc5-gen3.h b/arch/arm64/boot/dts/qcom/qcom,pm8550b-adc5-gen3.h
> new file mode 100644
> index 0000000000000..312daa846f798
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcom,pm8550b-adc5-gen3.h
> @@ -0,0 +1,85 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#ifndef _QCOM_PM8550B_ACD5_GEN3_H
> +#define _QCOM_PM8550B_ACD5_GEN3_H
[Severity: Low]
This isn't a bug, but there is also a typo here using ACD5 instead of ADC5
in the include guards.
[ ... ]
> diff --git a/arch/arm64/boot/dts/qcom/qcom,pm8550vx-adc5-gen3.h b/arch/arm64/boot/dts/qcom/qcom,pm8550vx-adc5-gen3.h
> new file mode 100644
> index 0000000000000..7a261a7a9cb08
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcom,pm8550vx-adc5-gen3.h
> @@ -0,0 +1,22 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#ifndef _QCOM_PM8550VX_ACD5_GEN3_H
> +#define _QCOM_PM8550VX_ACD5_GEN3_H
[Severity: Low]
This isn't a bug, but this guard also has the ACD5 typo.
[ ... ]
> diff --git a/arch/arm64/boot/dts/qcom/qcom,pmk8550-adc5-gen3.h b/arch/arm64/boot/dts/qcom/qcom,pmk8550-adc5-gen3.h
> new file mode 100644
> index 0000000000000..60b3b9c60d4e2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcom,pmk8550-adc5-gen3.h
> @@ -0,0 +1,52 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
> + */
> +
> +#ifndef _QCOM_PMK8550_ACD5_GEN3_H
> +#define _QCOM_PMK8550_ACD5_GEN3_H
[Severity: Low]
This isn't a bug, but this guard has the same ACD5 typo as well.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-topic-sm8x50-adc5-gen3-v3-0-216a2b5ccb85@linaro.org?part=1
^ permalink raw reply
* Re: [PATCH v6 1/7] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Luca Leonardo Scorcia @ 2026-06-15 17:09 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Julien Massot,
Louis-Alexis Eyraud, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260615-palatable-aerobics-3091229b6ada@spud>
Hi,
yes, sorry about that, series v6 has been superseded by v7 (I replied
to the thread and marked it as archived in patchwork, please let me
know if I have to do something else to mark it as obsolete).
Sashiko was correct, the regulators node is required for this device.
Sashiko also has suggestions for v7, a few pre existing issues and a
few nits here and there but some are actual improvements. One bit that
caught my eye is the use of the modeset register in the
mt6392_ldo_get_mode function. I have to double check that with the
data sheet and the android kernel sources. Not sure if I can do that
before next week though.
Is there any way I can trigger a Sashiko review before sending patches
to the ML?
Thank you,
Luca
^ permalink raw reply
* Re: [PATCH v2 4/6] arm64: dts: qcom: sm8450: Add missing CX power domain to GCC
From: sashiko-bot @ 2026-06-15 17:10 UTC (permalink / raw)
To: Neil Armstrong; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260615-topic-sm8x50-tie-gcc-to-cx-v2-4-6b5752dd4747@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing `pm_genpd_remove()` and error path cleanup in `gdsc_register()` leads to use-after-free in `gpd_list` upon unbind or probe failure.
--
commit e4315c043469a13f84ee75ac94f4e0790692142c
Author: Neil Armstrong <neil.armstrong@linaro.org>
arm64: dts: qcom: sm8450: Add missing CX power domain to GCC
This commit associates the GCC with RPMHPD_CX by adding a power-domains
property to the device tree, preventing under-voltage conditions by allowing
votes to propagate.
> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> @@ -935,6 +935,7 @@ soc: soc@0 {
> gcc: clock-controller@100000 {
> compatible = "qcom,gcc-sm8450";
> reg = <0x0 0x00100000 0x0 0x1f4200>;
> + power-domains = <&rpmhpd RPMHPD_CX>;
[Severity: High]
This is a pre-existing issue, but since this patch configures the power
domains for this device, it brings up a concern in the underlying Qualcomm
GDSC driver framework.
If probe fails or the module is unloaded, does the error handling in
gdsc_register() leave dangling pointers in the core gpd_list?
Looking at drivers/clk/qcom/gdsc.c:gdsc_register(), if a subsequent
gdsc_init() fails, it returns directly:
drivers/clk/qcom/gdsc.c:gdsc_register() {
for (i = 0; i < num; i++) {
if (!scs[i])
continue;
...
ret = gdsc_init(scs[i]);
if (ret)
return ret;
}
}
This seems to leak the previously initialized power domains in the global
gpd_list because it misses calling pm_genpd_remove() for scs[0..i-1].
Similarly, if of_genpd_add_provider_onecell() fails at the end of the
function, it also returns immediately or bypasses domain removal:
drivers/clk/qcom/gdsc.c:gdsc_register() {
...
return of_genpd_add_provider_onecell(dev->of_node, data);
err_pm_subdomain_remove:
gdsc_pm_subdomain_remove(desc, i);
return ret;
}
Furthermore, gdsc_unregister() removes subdomains and deletes the provider,
but entirely misses pm_genpd_remove() before the backing memory is freed
on module unload:
drivers/clk/qcom/gdsc.c:gdsc_unregister() {
...
gdsc_pm_subdomain_remove(desc, num);
of_genpd_del_provider(dev->of_node);
}
Could this result in a use-after-free kernel panic if gpd_list is iterated
(for example, by genpd_power_off_unused() or debugfs) after an unbind or
probe failure?
> #clock-cells = <1>;
> #reset-cells = <1>;
> #power-domain-cells = <1>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-topic-sm8x50-tie-gcc-to-cx-v2-0-6b5752dd4747@linaro.org?part=4
^ permalink raw reply
* [PATCH] hw_random: timeriomem-rng: add configurable read width and data mask
From: Jad Keskes @ 2026-06-15 17:09 UTC (permalink / raw)
To: Olivia Mackall, Herbert Xu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alexander Clouter,
linux-crypto, devicetree, linux-kernel, Jad Keskes
The TODO for supporting read sizes other than 32 bits and masking has
been sitting in this driver since 2009. Implement it.
Add width (8, 16, or 32 bits) and mask properties to the platform data
and device tree bindings. The read loop dispatches on width using
readb/readw/readl so a configured 8-bit access doesn't trigger a bus
error on hardware that rejects 32-bit reads to that address. The mask
is ANDed with the value before storing.
These are platform properties, not runtime policy -- width depends on
SoC integration, mask reflects which output bits carry entropy.
The alignment check in probe is updated to verify the resource is
aligned to the configured width instead of hardcoding 4-byte alignment.
Signed-off-by: Jad Keskes <inasj268@gmail.com>
---
.../bindings/rng/timeriomem-rng.yaml | 76 ++++++++++++++++++
drivers/char/hw_random/timeriomem-rng.c | 78 +++++++++++++++----
include/linux/timeriomem-rng.h | 12 +++
3 files changed, 153 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rng/timeriomem-rng.yaml
diff --git a/Documentation/devicetree/bindings/rng/timeriomem-rng.yaml b/Documentation/devicetree/bindings/rng/timeriomem-rng.yaml
new file mode 100644
index 000000000000..0d8460e9f916
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/timeriomem-rng.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/timeriomem-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Timer IOMEM Hardware Random Number Generator
+
+description: |
+ This binding covers platforms that have a single IO memory address which
+ provides periodic random data. The driver reads from the address at a
+ fixed interval, returning a configurable-width value masked to the desired
+ bits.
+
+maintainers:
+ - Alexander Clouter <alex@digriz.org.uk>
+
+properties:
+ compatible:
+ enum:
+ - timeriomem_rng
+
+ reg:
+ maxItems: 1
+
+ period:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Interval in microseconds between reads. New random data is expected to
+ be available at this rate.
+
+ quality:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0
+ description:
+ Estimated entropy per 1024 bits of data, in the same scale as the
+ kernel's hwrng core (0-1024).
+
+ width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 32
+ enum: [8, 16, 32]
+ description:
+ Access width in bits. Determines whether the read is performed as
+ an 8-bit, 16-bit, or 32-bit bus access.
+
+ mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0xFFFFFFFF
+ description:
+ Mask applied to the value read from the register. Bits set to 0 in
+ the mask are cleared in the output data. Default (no mask) passes
+ all bits through.
+
+required:
+ - compatible
+ - reg
+ - period
+
+additionalProperties: false
+
+examples:
+ - |
+ rng@f0001000 {
+ compatible = "timeriomem_rng";
+ reg = <0xf0001000 0x4>;
+ period = <100000>;
+ };
+
+ rng@f0002000 {
+ compatible = "timeriomem_rng";
+ reg = <0xf0002000 0x1>;
+ period = <50000>;
+ width = <8>;
+ mask = <0xFF>;
+ };
diff --git a/drivers/char/hw_random/timeriomem-rng.c b/drivers/char/hw_random/timeriomem-rng.c
index e61f06393209..930898852147 100644
--- a/drivers/char/hw_random/timeriomem-rng.c
+++ b/drivers/char/hw_random/timeriomem-rng.c
@@ -14,7 +14,9 @@
* has to do is provide the address and 'wait time' that new data becomes
* available.
*
- * TODO: add support for reading sizes other than 32bits and masking
+ * The read width (8, 16, or 32 bits) and an optional data mask can be
+ * configured through platform data or device tree properties. Default is
+ * 32-bit reads with no mask.
*/
#include <linux/completion.h>
@@ -34,6 +36,8 @@ struct timeriomem_rng_private {
void __iomem *io_base;
ktime_t period;
unsigned int present:1;
+ unsigned int width;
+ u32 mask;
struct hrtimer timer;
struct completion completion;
@@ -48,6 +52,7 @@ static int timeriomem_rng_read(struct hwrng *hwrng, void *data,
container_of(hwrng, struct timeriomem_rng_private, rng_ops);
int retval = 0;
int period_us = ktime_to_us(priv->period);
+ int chunk = priv->width / 8;
/*
* There may not have been enough time for new data to be generated
@@ -71,11 +76,28 @@ static int timeriomem_rng_read(struct hwrng *hwrng, void *data,
usleep_range(period_us,
period_us + max(1, period_us / 100));
- *(u32 *)data = readl(priv->io_base);
- retval += sizeof(u32);
- data += sizeof(u32);
- max -= sizeof(u32);
- } while (wait && max > sizeof(u32));
+ switch (priv->width) {
+ case 8: {
+ u8 val = readb(priv->io_base) & priv->mask;
+ *(u8 *)data = val;
+ break;
+ }
+ case 16: {
+ u16 val = readw(priv->io_base) & priv->mask;
+ *(u16 *)data = val;
+ break;
+ }
+ case 32: {
+ u32 val = readl(priv->io_base) & priv->mask;
+ *(u32 *)data = val;
+ break;
+ }
+ }
+
+ retval += chunk;
+ data += chunk;
+ max -= chunk;
+ } while (wait && max > chunk);
/*
* Block any new callers until the RNG has had time to generate new
@@ -125,11 +147,8 @@ static int timeriomem_rng_probe(struct platform_device *pdev)
if (IS_ERR(priv->io_base))
return PTR_ERR(priv->io_base);
- if (res->start % 4 != 0 || resource_size(res) < 4) {
- dev_err(&pdev->dev,
- "address must be at least four bytes wide and 32-bit aligned\n");
- return -EINVAL;
- }
+ priv->width = 32;
+ priv->mask = 0xFFFFFFFF;
if (pdev->dev.of_node) {
int i;
@@ -145,9 +164,42 @@ static int timeriomem_rng_probe(struct platform_device *pdev)
if (!of_property_read_u32(pdev->dev.of_node,
"quality", &i))
priv->rng_ops.quality = i;
+
+ of_property_read_u32(pdev->dev.of_node,
+ "width", &priv->width);
+ of_property_read_u32(pdev->dev.of_node,
+ "mask", &priv->mask);
} else {
period = pdata->period;
priv->rng_ops.quality = pdata->quality;
+
+ if (pdata->width_set)
+ priv->width = pdata->width;
+ if (pdata->mask_set)
+ priv->mask = pdata->mask;
+ }
+
+ if (priv->width == 0)
+ priv->width = 32;
+
+ switch (priv->width) {
+ case 8:
+ case 16:
+ case 32:
+ break;
+ default:
+ dev_err(&pdev->dev, "invalid width %u, must be 8, 16, or 32\n",
+ priv->width);
+ return -EINVAL;
+ }
+
+ if (res->start % (priv->width / 8) != 0 ||
+ resource_size(res) < priv->width / 8) {
+ dev_err(&pdev->dev,
+ "address must be at least %u-bit aligned (%u byte%s)\n",
+ priv->width, priv->width / 8,
+ priv->width / 8 > 1 ? "s" : "");
+ return -EINVAL;
}
priv->period = us_to_ktime(period);
@@ -167,8 +219,8 @@ static int timeriomem_rng_probe(struct platform_device *pdev)
return err;
}
- dev_info(&pdev->dev, "32bits from 0x%p @ %dus\n",
- priv->io_base, period);
+ dev_info(&pdev->dev, "%ubit from %p @ %dus\n",
+ priv->width, priv->io_base, period);
return 0;
}
diff --git a/include/linux/timeriomem-rng.h b/include/linux/timeriomem-rng.h
index 672df7fbf6c1..b4202ad2f507 100644
--- a/include/linux/timeriomem-rng.h
+++ b/include/linux/timeriomem-rng.h
@@ -16,6 +16,18 @@ struct timeriomem_rng_data {
/* bits of entropy per 1024 bits read */
unsigned int quality;
+
+ /* read width (8, 16, or 32), 0 means 32 */
+ unsigned int width;
+
+ /* set to true if width is explicitly provided */
+ bool width_set;
+
+ /* mask applied to raw read value */
+ u32 mask;
+
+ /* set to true if mask is explicitly provided */
+ bool mask_set;
};
#endif /* _LINUX_TIMERIOMEM_RNG_H */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH RFC v3 5/6] arm64: dts: qcom: sm8650-qrd: add SPMI ADC channels and thermal nodes
From: sashiko-bot @ 2026-06-15 17:11 UTC (permalink / raw)
To: Neil Armstrong; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260615-topic-sm8x50-adc5-gen3-v3-5-216a2b5ccb85@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Device Tree unit address mismatch for PM8550VE die temperature ADC channel.
--
commit 6952f92c17c33d46a9fedfb44cee4f92301811b9
Author: Neil Armstrong <neil.armstrong@linaro.org>
arm64: dts: qcom: sm8650-qrd: add SPMI ADC channels and thermal nodes
This commit adds the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system. It also adds thermal nodes, sorted by the
sensor channel to be coherent with the system thermal nodes ordering.
> diff --git a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
> index a3982ae229290..0f5f9e55586ad 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8650-qrd.dts
[ ... ]
> @@ -1040,27 +1129,217 @@ led@3 {
[ ... ]
> + /* PM8550VS_E Channel nodes */
> + channel@403 {
> + reg = <PM8550VS_ADC5_GEN3_DIE_TEMP(4)>;
> + label = "pm8550vs_e_die_temp";
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + /* PM8550VE Channel nodes */
> + channel@503 {
> + reg = <PM8550VE_ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
[Severity: Low]
Does this unit address match the evaluated reg property?
Since PMK8550VE_SID is 8 in sm8650-qrd.dts, the macro
PM8550VE_ADC5_GEN3_DIE_TEMP(PMK8550VE_SID) evaluates to 0x803.
Would naming the node channel@803 instead of channel@503 prevent a
unit_address_vs_reg warning from the device tree compiler?
> + label = "pm8550ve_die_temp";
> + qcom,pre-scaling = <1 1>;
> + };
> +
> + /* PM8550VS_G Channel nodes */
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-topic-sm8x50-adc5-gen3-v3-0-216a2b5ccb85@linaro.org?part=5
^ permalink raw reply
* Re: [PATCH RFC v3 6/6] arm64: dts: qcom: sm8650-hdk: add SPMI ADC channels and thermal nodes
From: sashiko-bot @ 2026-06-15 17:15 UTC (permalink / raw)
To: Neil Armstrong; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260615-topic-sm8x50-adc5-gen3-v3-6-216a2b5ccb85@linaro.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Mismatch between the device tree node unit-address (`channel@503`) and the evaluated `reg` property (`0x803`), violating Device Tree specifications.
--
commit 0ba8e109ec38cf4d6ce92bd1b9d00c8dcbbce432
Author: Neil Armstrong <neil.armstrong@linaro.org>
arm64: dts: qcom: sm8650-hdk: add SPMI ADC channels and thermal nodes
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the other PMICS
on the system. The thermal nodes are sorted by the sensor channel to be
coherent with the system thermal nodes ordering.
> diff --git a/arch/arm64/boot/dts/qcom/sm8650-hdk.dts b/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
> index eabc828c05b4c..cc2d341760a90 100644
> --- a/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8650-hdk.dts
[ ... ]
> @@ -1041,27 +1130,217 @@ led@3 {
[ ... ]
> + /* PM8550VE Channel nodes */
> + channel@503 {
> + reg = <PM8550VE_ADC5_GEN3_DIE_TEMP(PMK8550VE_SID)>;
[Severity: Low]
Does this unit-address match the evaluated reg property?
Since PMK8550VE_SID is 8 for the SM8650 platform, the macro
PM8550VE_ADC5_GEN3_DIE_TEMP(PMK8550VE_SID) evaluates to 0x803.
Should the node be named channel@803 to comply with the Device Tree
specifications and prevent a dtc unit_address_vs_reg compiler warning?
> + label = "pm8550ve_die_temp";
> + qcom,pre-scaling = <1 1>;
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-topic-sm8x50-adc5-gen3-v3-0-216a2b5ccb85@linaro.org?part=6
^ permalink raw reply
* Re: [PATCH RFC v3 3/6] arm64: dts: qcom: sm8550-qrd: add SPMI ADC channels and thermal nodes
From: sashiko-bot @ 2026-06-15 17:15 UTC (permalink / raw)
To: Neil Armstrong; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260615-topic-sm8x50-adc5-gen3-v3-3-216a2b5ccb85@linaro.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Missing `qcom,hw-settle-time` for the `channel@749` 100kΩ pull-up thermistor (`pm8550b_wls_therm`), leading to inaccurate temperature readings.
- [Low] The ADC channel nodes are not sorted by their unit address, violating standard device tree conventions.
--
commit 4a45cdf2d6ed588ab63165c08752b51ef046be4f
Author: Neil Armstrong <neil.armstrong@linaro.org>
arm64: dts: qcom: sm8550-qrd: add SPMI ADC channels and thermal nodes
Add the SPMI ADC channels on the PMK8550 SPMI5 ADC3 for the
other PMICS on the system.
The thermal nodes are sorted by the sensor channel to be
coherent with the system thermal nodes ordering.
> diff --git a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
> index 2fb2e0be5e4c6..8405cb9e0d6db 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8550-qrd.dts
[ ... ]
> + channel@18e {
> + reg = <PM8550_ADC5_GEN3_VPH_PWR(1)>;
> + label = "pm8550_vph_pwr";
> + qcom,pre-scaling = <1 3>;
> + };
> +
> + channel@144 {
> + reg = <PM8550_ADC5_GEN3_AMUX_THM1_100K_PU(1)>;
> + label = "pm8550_msm_therm";
> + qcom,ratiometric;
> + qcom,hw-settle-time = <200>;
> + qcom,pre-scaling = <1 1>;
> + qcom,adc-tm;
> + };
[Severity: Low]
This isn't a bug, but should channel@18e be placed after channel@144
to keep the nodes ordered alphanumerically by unit address?
[ ... ]
> + channel@78e {
> + reg = <PM8550B_ADC5_GEN3_VPH_PWR(7)>;
> + label = "pm8550b_vph_pwr";
> + qcom,pre-scaling = <1 3>;
> + };
> +
> + channel@78f {
> + reg = <PM8550B_ADC5_GEN3_VBAT_SNS_QBG(7)>;
> + label = "pm8550b_vbat_sns_qbg";
> + qcom,pre-scaling = <1 6>;
> + };
> +
> + channel@747 {
> + reg = <PM8550B_ADC5_GEN3_AMUX_THM4_USB_THERM_100K_PU(7)>;
> + label = "pm8550b_usb_therm";
> + qcom,ratiometric;
> + qcom,hw-settle-time = <200>;
> + qcom,pre-scaling = <1 1>;
> + qcom,adc-tm;
> + };
[Severity: Low]
Similar to the above, this isn't a bug, but should channel@78e and
channel@78f be placed after channel@747 and channel@749 to maintain
proper unit address sorting?
> +
> + channel@749 {
> + reg = <PM8550B_ADC5_GEN3_AMUX_THM6_GPIO10_100K_PU(7)>;
> + label = "pm8550b_wls_therm";
> + qcom,ratiometric;
> + qcom,pre-scaling = <1 1>;
> + qcom,adc-tm;
> + };
[Severity: Medium]
Does this node need qcom,hw-settle-time = <200> like the other 100K
pull-up thermistor channels in this patch?
Without it, the ADC measurement falls back to the default settle time,
which might be insufficient for this high-impedance path and lead to
inaccurate temperature readings for the pm8550b_wls_therm channel.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-topic-sm8x50-adc5-gen3-v3-0-216a2b5ccb85@linaro.org?part=3
^ permalink raw reply
* [RESEND] arm64: dts: mediatek: mt8516: remove cpu3 armpll clock-name
From: Luca Leonardo Scorcia @ 2026-06-15 17:21 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
devicetree, linux-kernel, linux-arm-kernel
The armpll clock in cpu3 clock-names property comes from MediaTek sources,
but it's unused in the kernel and not populated in the clocks property.
Let's remove it and align the node with other cpu nodes of the same SoC.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
arch/arm64/boot/dts/mediatek/mt8516.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8516.dtsi b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
index b5e753759465..596f673a0d88 100644
--- a/arch/arm64/boot/dts/mediatek/mt8516.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
@@ -95,7 +95,7 @@ cpu3: cpu@3 {
<&CPU_SLEEP_0_0 &CPU_SLEEP_0_0 &CPU_SLEEP_0_0>;
clocks = <&infracfg CLK_IFR_MUX1_SEL>,
<&topckgen CLK_TOP_MAINPLL_D2>;
- clock-names = "cpu", "intermediate", "armpll";
+ clock-names = "cpu", "intermediate";
operating-points-v2 = <&cluster0_opp>;
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 3/3] regulator: qcom-refgen: add support for the IPQ9650 SoC
From: Kathiravan Thirumoorthy @ 2026-06-15 17:24 UTC (permalink / raw)
To: Mark Brown
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, linux-arm-msm, linux-kernel, devicetree,
Dmitry Baryshkov
In-Reply-To: <737655dd-2059-421d-a9ca-91ebd1b1209b@sirena.org.uk>
On 6/15/2026 9:28 PM, Mark Brown wrote:
> On Mon, Jun 15, 2026 at 02:05:49PM +0530, Kathiravan Thirumoorthy wrote:
>> IPQ9650 SoC has 2 REFGEN blocks providing the reference current to the
>> PCIe and USB, UNIPHY PHYs. For the other SoCs, clock for this block is
>> enabled on power up but that's not the case for IPQ9650 and we have to
>> enable those clocks explicitly to bring up the PHYs properly.
>> +static int qcom_ipq9650_refgen_enable(struct regulator_dev *rdev)
>> +{
>> + struct qcom_refgen_drvdata *drvdata = rdev_get_drvdata(rdev);
>> + int ret;
>> +
>> + ret = clk_bulk_prepare_enable(drvdata->num_clks, drvdata->clks);
>> + if (ret)
>> + return ret;
>> +
>> + return 0;
>> +}
>> +static int qcom_ipq9650_refgen_disable(struct regulator_dev *rdev)
>> +{
>> + struct qcom_refgen_drvdata *drvdata = rdev_get_drvdata(rdev);
>> +
>> + clk_bulk_disable_unprepare(drvdata->num_clks, drvdata->clks);
>> +
>> + return 0;
>> +}
>> +static const struct regulator_desc ipq9650_refgen_desc = {
>> + .enable_reg = REFGEN_REG_REFGEN_STATUS,
>> + .enable_mask = REFGEN_STATUS_OUT_MASK,
>> + .enable_val = REFGEN_STATUS_OUT_ENABLE,
>> + .ops = &(const struct regulator_ops) {
>> + .enable = qcom_ipq9650_refgen_enable,
>> + .disable = qcom_ipq9650_refgen_disable,
>> + .is_enabled = regulator_is_enabled_regmap,
>> + },
> This looks like a get_status() operation, not an enable operation? The
> enables and disables are pure clock operations.
Thanks, Mark for the review. If I understand correctly, I should track
the clock enable/disable operations and return that state in the
is_enabled() callback (as I did in v1). Please let me know if my
understanding does not align with your expectations.
^ permalink raw reply
* [PATCH V13 0/9] Add Invensense ICM42607
From: Chris Morgan @ 2026-06-15 17:25 UTC (permalink / raw)
To: linux-iio
Cc: andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
From: Chris Morgan <macromorgan@hotmail.com>
Add support for the ICM42607 IMU. This sensor shares the same
functionality but a different register layout with the existing
ICM42600.
This driver should work with the ICM42607 and ICM42607P over both I2C
and SPI, however only the ICM42607P over I2C could be tested.
Changes Since V1:
- Instead of creating a new driver, merged with the existing inv_icm42600
driver. This necessitated adding some code to the existing driver to
permit using a different register layout for the same functionality.
- Split changes up a bit more to decrease the size of the individual
patches. Note that patch 0004 is still pretty hefty; if I need to split
further I may need to create some temporary stub functions.
- Used guard() and PM_RUNTIME_ACQUIRE_AUTOSUSPEND() on the new functions
per Jonathan's recommendations.
Changes Since V2:
- Went back to using a new driver on advice from Invensense engineer.
- Further split changes up into smaller chunks of functionality. Note
still that the largest patch is approximately 900 lines, and that while
the driver compiles cleanly at each commit it is not able to drive the
hardware until the commit that adds the Interrupt (as it also adds the
Makefile).
- Change the error to a warning when the devicetree binding does not match
the hardware ID.
- Dropped the ack on the devicetree bindings, as I am creating a new file
(for a new driver) instead of modifying the existing one.
Changes Since V3:
- Numerous small fixes (too many to list here). Thank you to everyone who
provided feedback.
- Split power management additions into an additional commit to break
things up further.
- Consolidated devicetree documentation in existing
invensense,icm42600.yaml file.
- Removed most of the FIELD_PREP from header file to c files to make code
easier to read.
- Changed scale values to 2D arrays for Gyro and Accelerometer.
- Removed IIO_CHAN_INFO_CALIBBIAS attribute.
Changes Since V4:
- Additional numerous small fixes, thank you again for all the feedback.
- Dropped power control API and instead run device in low noise mode.
- Split devicetree bindings into two distinct changes.
- Reordered adding of enums and structs to main header file so that they
are only brought in when needed.
- Stopped using enum for driver data and instead am using pointer to
device specific driver data.
Changes Since V5:
- Corrected use of "dev_warn_probe" to just "dev_warn".
- Fixed some return scenarios which would unconditionally return 0
when an error was present.
- Corrected use of max() to min() for bounds checking. max() was
incorrect.
- Fixed using "st->conf.accel.odr" in the gyroscope function. It
should have been "st->conf.gyro.odr" which it now is.
- Additional small fixes suggested by "sashiko.dev".
- Added a regmap cache. I used the datasheet to try and determine
which registers might change without explicit writes.
Changes Since V6:
- Corrected additional errors identified by sashiko.dev, mostly
fixing potential deadlocks, missing calls for pm runtime, and
potential overflow issues.
Changes Since V7:
- Dropped Wake on Movement patches, since some of the functionality
was only available for a device on which I cannot test.
- Dropped support for SPI 3-Wire mode, since it complicated the
bus setup (and I lack the hardware to test such features anyway).
- Fixed a few additional bugs identified by sashiko.dev bot.
Changes Since V8:
- Added back IRQ dropped accidentally when dropping wake on movement
patches.
- Dropped "Reviewed-By" tag on patch 2 because of substantial changes
made to devicetree binding documentation.
- Additional small fixes as suggested.
Changes Since V9:
- Removed interrupts (and buffers) from the driver. I previously was
unable to detect deadlocks because it turns out my IRQ was not even
wired correctly in my device.
- Updated devicetree binding commits to make interrupts optional for
users of the icm42607 driver.
Changes Since V10:
- Explicitly specified enum values in header file.
- Removed additional dead code for buffer handling.
- Cleaned up headers.
- Added additional locks as requested by sashiko.dev bot.
Changes Since V11:
- Since driver has shrunk in size considerably, moved i2c bits into
first code commit. This ensures that the very first commit with code
can now be compiled. The commit after that adds SPI support as it
was in the previous versions.
- Used pahole to optimize inv_icm42607_state. Reordering elements
reduced size in memory from 384 bytes to 256 bytes.
- Added a map of all readable registers and all writeable registers
according to the datasheet.
- Added back some missing headers pointed out by the maintainers.
- Added FIELD_PREP in a few more places to make the code more
obvious on what it's doing.
- Added a comment to the power management code to note that
temperature sensor being enabled doesn't matter as the clocks
are off by default when the gyro and accel channels are off.
- Removed iio_device_claim_direct() calls since it was no longer
needed.
- Fixed shared_by_all attributes for temperature sensor.
- Additional miscellanous fixes as requested.
Changes Since V12:
- Removed aligned buffer from inv_icm42607_state struct as we do not
currently have the need for it.
- Corrected the order of the odr values in the accel and gyro files
as the values were out of order (the place in the array corresponds
to the register value).
- Stopped setting the clock value depending upon the temp config. The
datasheet advised to keep using the default value.
- Corrected logic when changing between states. We only need to pause
when a sensor changes from off to an on state or when the gyro
changes from an on state to off.
- Added missing includes for several files.
Chris Morgan (9):
dt-bindings: iio: imu: icm42600: Add mount-matrix to icm42600
dt-bindings: iio: imu: icm42600: Add icm42607
iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
iio: imu: inv_icm42607: Add SPI For icm42607
iio: imu: inv_icm42607: Add PM support for icm42607
iio: imu: inv_icm42607: Add Temp Support in icm42607
iio: imu: inv_icm42607: Add Accelerometer for icm42607
iio: imu: inv_icm42607: Add Gyroscope to icm42607
arm64: dts: rockchip: Add icm42607p IMU for RG-DS
.../bindings/iio/imu/invensense,icm42600.yaml | 20 +-
.../dts/rockchip/rk3568-anbernic-rg-ds.dts | 8 +-
drivers/iio/imu/Kconfig | 1 +
drivers/iio/imu/Makefile | 1 +
drivers/iio/imu/inv_icm42607/Kconfig | 30 +
drivers/iio/imu/inv_icm42607/Makefile | 13 +
drivers/iio/imu/inv_icm42607/inv_icm42607.h | 410 +++++++++++++
.../iio/imu/inv_icm42607/inv_icm42607_accel.c | 373 ++++++++++++
.../iio/imu/inv_icm42607/inv_icm42607_core.c | 546 ++++++++++++++++++
.../iio/imu/inv_icm42607/inv_icm42607_gyro.c | 369 ++++++++++++
.../iio/imu/inv_icm42607/inv_icm42607_i2c.c | 98 ++++
.../iio/imu/inv_icm42607/inv_icm42607_spi.c | 108 ++++
.../iio/imu/inv_icm42607/inv_icm42607_temp.c | 81 +++
.../iio/imu/inv_icm42607/inv_icm42607_temp.h | 37 ++
14 files changed, 2093 insertions(+), 2 deletions(-)
create mode 100644 drivers/iio/imu/inv_icm42607/Kconfig
create mode 100644 drivers/iio/imu/inv_icm42607/Makefile
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
--
2.43.0
^ permalink raw reply
* [PATCH V13 1/9] dt-bindings: iio: imu: icm42600: Add mount-matrix to icm42600
From: Chris Morgan @ 2026-06-15 17:25 UTC (permalink / raw)
To: linux-iio
Cc: andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan, Krzysztof Kozlowski
In-Reply-To: <20260615172554.160910-1-macroalpha82@gmail.com>
From: Chris Morgan <macromorgan@hotmail.com>
Add mount-matrix attribute to schema. This attribute has been supported
since the first revision of this driver, but was not documented.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../devicetree/bindings/iio/imu/invensense,icm42600.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
index 119e28a833fd..9b2af104f186 100644
--- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
@@ -53,6 +53,8 @@ properties:
drive-open-drain:
type: boolean
+ mount-matrix: true
+
vdd-supply:
description: Regulator that provides power to the sensor
--
2.43.0
^ permalink raw reply related
* [PATCH V13 2/9] dt-bindings: iio: imu: icm42600: Add icm42607
From: Chris Morgan @ 2026-06-15 17:25 UTC (permalink / raw)
To: linux-iio
Cc: andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan, Krzysztof Kozlowski
In-Reply-To: <20260615172554.160910-1-macroalpha82@gmail.com>
From: Chris Morgan <macromorgan@hotmail.com>
Add the ICM42607 and ICM42607P inertial measurement unit.
This device is functionally very similar to the icm42600 series with a
very different register layout. The driver does not require an
interrupt for these specific chip revisions.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../bindings/iio/imu/invensense,icm42600.yaml | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
index 9b2af104f186..81b6e85decd5 100644
--- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
@@ -30,6 +30,8 @@ properties:
- invensense,icm42600
- invensense,icm42602
- invensense,icm42605
+ - invensense,icm42607
+ - invensense,icm42607p
- invensense,icm42622
- invensense,icm42631
- invensense,icm42686
@@ -67,10 +69,24 @@ properties:
required:
- compatible
- reg
- - interrupts
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - invensense,icm42600
+ - invensense,icm42602
+ - invensense,icm42605
+ - invensense,icm42622
+ - invensense,icm42631
+ - invensense,icm42686
+ - invensense,icm42688
+ then:
+ required:
+ - interrupts
unevaluatedProperties: false
--
2.43.0
^ permalink raw reply related
* [PATCH V13 3/9] iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
From: Chris Morgan @ 2026-06-15 17:25 UTC (permalink / raw)
To: linux-iio
Cc: andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260615172554.160910-1-macroalpha82@gmail.com>
From: Chris Morgan <macromorgan@hotmail.com>
Add the core component of a new inv_icm42607 driver. This includes
a few setup functions and the full register definition in the
header file, as well as the bits necessary to compile and probe the
device when used on an i2c bus.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
drivers/iio/imu/Kconfig | 1 +
drivers/iio/imu/Makefile | 1 +
drivers/iio/imu/inv_icm42607/Kconfig | 18 +
drivers/iio/imu/inv_icm42607/Makefile | 7 +
drivers/iio/imu/inv_icm42607/inv_icm42607.h | 347 ++++++++++++++++++
.../iio/imu/inv_icm42607/inv_icm42607_core.c | 280 ++++++++++++++
.../iio/imu/inv_icm42607/inv_icm42607_i2c.c | 97 +++++
7 files changed, 751 insertions(+)
create mode 100644 drivers/iio/imu/inv_icm42607/Kconfig
create mode 100644 drivers/iio/imu/inv_icm42607/Makefile
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
index 7e0181c27bb6..8bab4616be20 100644
--- a/drivers/iio/imu/Kconfig
+++ b/drivers/iio/imu/Kconfig
@@ -109,6 +109,7 @@ config KMX61
be called kmx61.
source "drivers/iio/imu/inv_icm42600/Kconfig"
+source "drivers/iio/imu/inv_icm42607/Kconfig"
source "drivers/iio/imu/inv_icm45600/Kconfig"
source "drivers/iio/imu/inv_mpu6050/Kconfig"
diff --git a/drivers/iio/imu/Makefile b/drivers/iio/imu/Makefile
index 13fb7846e9c9..3268dc2371ae 100644
--- a/drivers/iio/imu/Makefile
+++ b/drivers/iio/imu/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_FXOS8700_I2C) += fxos8700_i2c.o
obj-$(CONFIG_FXOS8700_SPI) += fxos8700_spi.o
obj-y += inv_icm42600/
+obj-y += inv_icm42607/
obj-y += inv_icm45600/
obj-y += inv_mpu6050/
diff --git a/drivers/iio/imu/inv_icm42607/Kconfig b/drivers/iio/imu/inv_icm42607/Kconfig
new file mode 100644
index 000000000000..083c212087ab
--- /dev/null
+++ b/drivers/iio/imu/inv_icm42607/Kconfig
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+config INV_ICM42607
+ tristate
+ select IIO_BUFFER
+ select IIO_INV_SENSORS_TIMESTAMP
+
+config INV_ICM42607_I2C
+ tristate "InvenSense ICM-42607 I2C driver"
+ depends on I2C
+ select INV_ICM42607
+ select REGMAP_I2C
+ help
+ This driver supports the InvenSense ICM-42607 motion tracking
+ device over I2C.
+
+ This driver can be built as a module. The module will be called
+ inv-icm42607-i2c.
diff --git a/drivers/iio/imu/inv_icm42607/Makefile b/drivers/iio/imu/inv_icm42607/Makefile
new file mode 100644
index 000000000000..32046e2727d7
--- /dev/null
+++ b/drivers/iio/imu/inv_icm42607/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+obj-$(CONFIG_INV_ICM42607) += inv-icm42607.o
+inv-icm42607-y += inv_icm42607_core.o
+
+obj-$(CONFIG_INV_ICM42607_I2C) += inv-icm42607-i2c.o
+inv-icm42607-i2c-y += inv_icm42607_i2c.o
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
new file mode 100644
index 000000000000..a6a58571935f
--- /dev/null
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
@@ -0,0 +1,347 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2026 InvenSense, Inc.
+ */
+
+#ifndef INV_ICM42607_H_
+#define INV_ICM42607_H_
+
+#include <linux/bits.h>
+#include <linux/iio/iio.h>
+#include <linux/mutex.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/time.h>
+#include <linux/types.h>
+
+/*
+ * Serial bus slew rates. Rates are expressed as range between the two
+ * values with the midpoint as the typical rate. For the final value of
+ * 2ns, 2ns is considered the max value with no expressed minimum or
+ * typical value.
+ */
+enum inv_icm42607_slew_rate {
+ INV_ICM42607_SLEW_RATE_20_60NS = 0,
+ INV_ICM42607_SLEW_RATE_12_36NS = 1,
+ INV_ICM42607_SLEW_RATE_6_19NS = 2,
+ INV_ICM42607_SLEW_RATE_4_14NS = 3,
+ INV_ICM42607_SLEW_RATE_2_6NS = 4,
+ INV_ICM42607_SLEW_RATE_2NS = 5,
+ INV_ICM42607_SLEW_RATE_NB
+};
+
+enum inv_icm42607_sensor_mode {
+ INV_ICM42607_SENSOR_MODE_OFF = 0,
+ INV_ICM42607_SENSOR_MODE_STANDBY = 1,
+ INV_ICM42607_SENSOR_MODE_LOW_POWER = 2,
+ INV_ICM42607_SENSOR_MODE_LOW_NOISE = 3,
+ INV_ICM42607_SENSOR_MODE_NB
+};
+
+/* gyroscope fullscale values */
+enum inv_icm42607_gyro_fs {
+ INV_ICM42607_GYRO_FS_2000DPS = 0,
+ INV_ICM42607_GYRO_FS_1000DPS = 1,
+ INV_ICM42607_GYRO_FS_500DPS = 2,
+ INV_ICM42607_GYRO_FS_250DPS = 3,
+ INV_ICM42607_GYRO_FS_NB
+};
+
+/* accelerometer fullscale values */
+enum inv_icm42607_accel_fs {
+ INV_ICM42607_ACCEL_FS_16G = 0,
+ INV_ICM42607_ACCEL_FS_8G = 1,
+ INV_ICM42607_ACCEL_FS_4G = 2,
+ INV_ICM42607_ACCEL_FS_2G = 3,
+ INV_ICM42607_ACCEL_FS_NB
+};
+
+/* ODR values - Note Gyro does not support ODR less than 12.5Hz */
+enum inv_icm42607_odr {
+ INV_ICM42607_ODR_1600HZ = 5,
+ INV_ICM42607_ODR_800HZ = 6,
+ INV_ICM42607_ODR_400HZ = 7,
+ INV_ICM42607_ODR_200HZ = 8,
+ INV_ICM42607_ODR_100HZ = 9,
+ INV_ICM42607_ODR_50HZ = 10,
+ INV_ICM42607_ODR_25HZ = 11,
+ INV_ICM42607_ODR_12_5HZ = 12,
+ INV_ICM42607_ODR_6_25HZ_LP = 13,
+ INV_ICM42607_ODR_3_125HZ_LP = 14,
+ INV_ICM42607_ODR_1_5625HZ_LP = 15,
+ INV_ICM42607_ODR_NB
+};
+
+/* Low-Noise mode sensor data filter (bandwidth) */
+enum inv_icm42607_filter_bw {
+ INV_ICM42607_FILTER_BYPASS = 0,
+ INV_ICM42607_FILTER_BW_180HZ = 1,
+ INV_ICM42607_FILTER_BW_121HZ = 2,
+ INV_ICM42607_FILTER_BW_73HZ = 3,
+ INV_ICM42607_FILTER_BW_53HZ = 4,
+ INV_ICM42607_FILTER_BW_34HZ = 5,
+ INV_ICM42607_FILTER_BW_25HZ = 6,
+ INV_ICM42607_FILTER_BW_16HZ = 7,
+ INV_ICM42607_FILTER_BW_NB
+};
+
+/* Signed so that negative values can signify an invalid condition. */
+struct inv_icm42607_sensor_conf {
+ int mode;
+ int fs;
+ int odr;
+ int filter;
+};
+
+struct inv_icm42607_conf {
+ struct inv_icm42607_sensor_conf gyro;
+ struct inv_icm42607_sensor_conf accel;
+ bool temp_en;
+};
+
+struct inv_icm42607_hw {
+ const char *name;
+ const struct inv_icm42607_conf *conf;
+ u8 whoami;
+};
+
+/**
+ * struct inv_icm42607_state - driver state variables
+ * @hw: Hardware specific data.
+ * @lock: lock for serializing multiple registers access.
+ * @map: regmap pointer.
+ * @vddio_supply: I/O voltage regulator for the chip.
+ * @conf: chip sensors configurations.
+ * @orientation: sensor chip orientation relative to main hardware.
+ */
+struct inv_icm42607_state {
+ const struct inv_icm42607_hw *hw;
+ struct mutex lock;
+ struct regmap *map;
+ struct regulator *vddio_supply;
+ struct inv_icm42607_conf conf;
+ struct iio_mount_matrix orientation;
+};
+
+/* Virtual register addresses: @bank on MSB (4 upper bits), @address on LSB */
+
+/* Register Map for User Bank 0 */
+#define INV_ICM42607_REG_MCLK_RDY 0x00
+
+#define INV_ICM42607_REG_DEVICE_CONFIG 0x01
+#define INV_ICM42607_DEVICE_CONFIG_SPI_AP_4WIRE BIT(2)
+#define INV_ICM42607_DEVICE_CONFIG_SPI_MODE BIT(0)
+
+#define INV_ICM42607_REG_SIGNAL_PATH_RESET 0x02
+#define INV_ICM42607_SIGNAL_PATH_RESET_SOFT_RESET BIT(4)
+#define INV_ICM42607_SIGNAL_PATH_RESET_FIFO_FLUSH BIT(2)
+
+#define INV_ICM42607_REG_DRIVE_CONFIG1 0x03
+#define INV_ICM42607_DRIVE_CONFIG1_I3C_DDR_MASK GENMASK(5, 3)
+#define INV_ICM42607_DRIVE_CONFIG1_I3C_SDR_MASK GENMASK(2, 0)
+
+#define INV_ICM42607_REG_DRIVE_CONFIG2 0x04
+#define INV_ICM42607_DRIVE_CONFIG2_I2C_MASK GENMASK(5, 3)
+#define INV_ICM42607_DRIVE_CONFIG2_ALL_MASK GENMASK(2, 0)
+
+#define INV_ICM42607_REG_DRIVE_CONFIG3 0x05
+#define INV_ICM42607_DRIVE_CONFIG3_SPI_MASK GENMASK(2, 0)
+
+#define INV_ICM42607_REG_INT_CONFIG 0x06
+#define INV_ICM42607_INT_CONFIG_INT2_LATCHED BIT(5)
+#define INV_ICM42607_INT_CONFIG_INT2_PUSH_PULL BIT(4)
+#define INV_ICM42607_INT_CONFIG_INT2_ACTIVE_HIGH BIT(3)
+#define INV_ICM42607_INT_CONFIG_INT2_ACTIVE_LOW 0x00
+#define INV_ICM42607_INT_CONFIG_INT1_LATCHED BIT(2)
+#define INV_ICM42607_INT_CONFIG_INT1_PUSH_PULL BIT(1)
+#define INV_ICM42607_INT_CONFIG_INT1_ACTIVE_HIGH BIT(0)
+#define INV_ICM42607_INT_CONFIG_INT1_ACTIVE_LOW 0x00
+
+/* all sensor data are 16 bits (2 registers wide) in big-endian */
+#define INV_ICM42607_REG_TEMP_DATA1 0x09
+#define INV_ICM42607_REG_TEMP_DATA0 0x0A
+#define INV_ICM42607_REG_ACCEL_DATA_X1 0x0B
+#define INV_ICM42607_REG_ACCEL_DATA_X0 0x0C
+#define INV_ICM42607_REG_ACCEL_DATA_Y1 0x0D
+#define INV_ICM42607_REG_ACCEL_DATA_Y0 0x0E
+#define INV_ICM42607_REG_ACCEL_DATA_Z1 0x0F
+#define INV_ICM42607_REG_ACCEL_DATA_Z0 0x10
+#define INV_ICM42607_REG_GYRO_DATA_X1 0x11
+#define INV_ICM42607_REG_GYRO_DATA_X0 0x12
+#define INV_ICM42607_REG_GYRO_DATA_Y1 0x13
+#define INV_ICM42607_REG_GYRO_DATA_Y0 0x14
+#define INV_ICM42607_REG_GYRO_DATA_Z1 0x15
+#define INV_ICM42607_REG_GYRO_DATA_Z0 0x16
+#define INV_ICM42607_DATA_INVALID -32768
+
+#define INV_ICM42607_REG_TMST_FSYNCH 0x17
+#define INV_ICM42607_REG_TMST_FSYNCL 0x18
+
+/* APEX Data Registers */
+#define INV_ICM42607_REG_APEX_DATA0 0x31
+#define INV_ICM42607_REG_APEX_DATA1 0x32
+#define INV_ICM42607_REG_APEX_DATA2 0x33
+#define INV_ICM42607_REG_APEX_DATA3 0x34
+#define INV_ICM42607_REG_APEX_DATA4 0x1D
+#define INV_ICM42607_REG_APEX_DATA5 0x1E
+
+#define INV_ICM42607_REG_PWR_MGMT0 0x1F
+#define INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL BIT(7)
+#define INV_ICM42607_PWR_MGMT0_IDLE BIT(4)
+#define INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK GENMASK(3, 2)
+#define INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK GENMASK(1, 0)
+
+#define INV_ICM42607_REG_GYRO_CONFIG0 0x20
+#define INV_ICM42607_GYRO_CONFIG0_FS_SEL_MASK GENMASK(6, 5)
+#define INV_ICM42607_GYRO_CONFIG0_ODR_MASK GENMASK(3, 0)
+
+#define INV_ICM42607_REG_ACCEL_CONFIG0 0x21
+#define INV_ICM42607_ACCEL_CONFIG0_FS_SEL_MASK GENMASK(6, 5)
+#define INV_ICM42607_ACCEL_CONFIG0_ODR_MASK GENMASK(3, 0)
+
+#define INV_ICM42607_REG_TEMP_CONFIG0 0x22
+#define INV_ICM42607_TEMP_CONFIG0_FILTER_MASK GENMASK(6, 4)
+
+#define INV_ICM42607_REG_GYRO_CONFIG1 0x23
+#define INV_ICM42607_GYRO_CONFIG1_FILTER_MASK GENMASK(2, 0)
+
+#define INV_ICM42607_REG_ACCEL_CONFIG1 0x24
+#define INV_ICM42607_ACCEL_CONFIG1_AVG_MASK GENMASK(6, 4)
+#define INV_ICM42607_ACCEL_CONFIG1_FILTER_MASK GENMASK(2, 0)
+
+#define INV_ICM42607_REG_APEX_CONFIG0 0x25
+#define INV_ICM42607_APEX_CONFIG0_DMP_POWER_SAVE_EN BIT(3)
+#define INV_ICM42607_APEX_CONFIG0_DMP_INIT_EN BIT(2)
+#define INV_ICM42607_APEX_CONFIG0_DMP_MEM_RESET_EN BIT(0)
+
+#define INV_ICM42607_REG_APEX_CONFIG1 0x26
+#define INV_ICM42607_APEX_CONFIG1_SMD_ENABLE BIT(6)
+#define INV_ICM42607_APEX_CONFIG1_FF_ENABLE BIT(5)
+#define INV_ICM42607_APEX_CONFIG1_TILT_ENABLE BIT(4)
+#define INV_ICM42607_APEX_CONFIG1_PED_ENABLE BIT(3)
+#define INV_ICM42607_APEX_CONFIG1_DMP_ODR_MASK GENMASK(1, 0)
+
+#define INV_ICM42607_REG_WOM_CONFIG 0x27
+#define INV_ICM42607_WOM_CONFIG_INT_DUR_MASK GENMASK(4, 3)
+#define INV_ICM42607_WOM_CONFIG_INT_MODE BIT(2)
+#define INV_ICM42607_WOM_CONFIG_MODE BIT(1)
+#define INV_ICM42607_WOM_CONFIG_EN BIT(0)
+
+#define INV_ICM42607_REG_FIFO_CONFIG1 0x28
+#define INV_ICM42607_FIFO_CONFIG1_MODE BIT(1)
+#define INV_ICM42607_FIFO_CONFIG1_BYPASS BIT(0)
+
+#define INV_ICM42607_REG_FIFO_CONFIG2 0x29
+#define INV_ICM42607_REG_FIFO_CONFIG3 0x2A
+#define INV_ICM42607_FIFO_WATERMARK_VAL(_wm) \
+ cpu_to_le16((_wm) & GENMASK(11, 0))
+/* FIFO is 2048 bytes, let 12 samples for reading latency */
+#define INV_ICM42607_FIFO_WATERMARK_MAX (2048 - 12 * 16)
+#define INV_ICM42607_FIFO_1SENSOR_PACKET_SIZE 8
+#define INV_ICM42607_FIFO_2SENSORS_PACKET_SIZE 16
+
+#define INV_ICM42607_REG_INT_SOURCE0 0x2B
+#define INV_ICM42607_INT_SOURCE0_ST_INT1_EN BIT(7)
+#define INV_ICM42607_INT_SOURCE0_FSYNC_INT1_EN BIT(6)
+#define INV_ICM42607_INT_SOURCE0_PLL_RDY_INT1_EN BIT(5)
+#define INV_ICM42607_INT_SOURCE0_RESET_DONE_INT1_EN BIT(4)
+#define INV_ICM42607_INT_SOURCE0_DRDY_INT1_EN BIT(3)
+#define INV_ICM42607_INT_SOURCE0_FIFO_THS_INT1_EN BIT(2)
+#define INV_ICM42607_INT_SOURCE0_FIFO_FULL_INT1_EN BIT(1)
+#define INV_ICM42607_INT_SOURCE0_AGC_RDY_INT1_EN BIT(0)
+
+#define INV_ICM42607_REG_INT_SOURCE1 0x2C
+#define INV_ICM42607_INT_SOURCE1_I3C_ERROR_INT1_EN BIT(6)
+#define INV_ICM42607_INT_SOURCE1_SMD_INT1_EN BIT(3)
+#define INV_ICM42607_INT_SOURCE1_WOM_INT1_EN GENMASK(2, 0)
+
+#define INV_ICM42607_REG_INT_SOURCE3 0x2D
+#define INV_ICM42607_INT_SOURCE3_ST_INT2_EN BIT(7)
+#define INV_ICM42607_INT_SOURCE3_FSYNC_INT2_EN BIT(6)
+#define INV_ICM42607_INT_SOURCE3_PLL_RDY_INT2_EN BIT(5)
+#define INV_ICM42607_INT_SOURCE3_RESET_DONE_INT2_EN BIT(4)
+#define INV_ICM42607_INT_SOURCE3_DRDY_INT2_EN BIT(3)
+#define INV_ICM42607_INT_SOURCE3_FIFO_THS_INT2_EN BIT(2)
+#define INV_ICM42607_INT_SOURCE3_FIFO_FULL_INT2_EN BIT(1)
+#define INV_ICM42607_INT_SOURCE3_AGC_RDY_INT2_EN BIT(0)
+
+#define INV_ICM42607_REG_INT_SOURCE4 0x2E
+#define INV_ICM42607_INT_SOURCE4_I3C_ERROR_INT2_EN BIT(6)
+#define INV_ICM42607_INT_SOURCE4_SMD_INT2_EN BIT(3)
+#define INV_ICM42607_INT_SOURCE4_WOM_Z_INT2_EN BIT(2)
+#define INV_ICM42607_INT_SOURCE4_WOM_Y_INT2_EN BIT(1)
+#define INV_ICM42607_INT_SOURCE4_WOM_X_INT2_EN BIT(0)
+
+#define INV_ICM42607_REG_FIFO_LOST_PKT0 0x2F
+#define INV_ICM42607_REG_FIFO_LOST_PKT1 0x30
+
+#define INV_ICM42607_REG_INTF_CONFIG0 0x35
+#define INV_ICM42607_INTF_CONFIG0_FIFO_COUNT_FORMAT BIT(6)
+#define INV_ICM42607_INTF_CONFIG0_FIFO_COUNT_ENDIAN BIT(5)
+#define INV_ICM42607_INTF_CONFIG0_SENSOR_DATA_ENDIAN BIT(4)
+#define INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_MASK GENMASK(1, 0)
+#define INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_SPI_DIS 2
+#define INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_I2C_DIS 3
+
+#define INV_ICM42607_REG_INTF_CONFIG1 0x36
+#define INV_ICM42607_INTF_CONFIG1_I3C_SDR_EN BIT(3)
+#define INV_ICM42607_INTF_CONFIG1_I3C_DDR_EN BIT(2)
+#define INV_ICM42607_INTF_CONFIG1_CLKSEL_MASK GENMASK(1, 0)
+#define INV_ICM42607_INTF_CONFIG1_CLKSEL_INT 0
+#define INV_ICM42607_INTF_CONFIG1_CLKSEL_PLL 1
+#define INV_ICM42607_INTF_CONFIG1_CLKSEL_OFF 2
+
+#define INV_ICM42607_REG_INT_STATUS_DRDY 0x39
+#define INV_ICM42607_INT_STATUS_DRDY_DATA_RDY BIT(0)
+
+#define INV_ICM42607_REG_INT_STATUS 0x3A
+#define INV_ICM42607_INT_STATUS_ST BIT(7)
+#define INV_ICM42607_INT_STATUS_FSYNC BIT(6)
+#define INV_ICM42607_INT_STATUS_PLL_RDY BIT(5)
+#define INV_ICM42607_INT_STATUS_RESET_DONE BIT(4)
+#define INV_ICM42607_INT_STATUS_FIFO_THS BIT(2)
+#define INV_ICM42607_INT_STATUS_FIFO_FULL BIT(1)
+#define INV_ICM42607_INT_STATUS_AGC_RDY BIT(0)
+
+#define INV_ICM42607_REG_INT_STATUS2 0x3B
+#define INV_ICM42607_INT_STATUS2_SMD BIT(3)
+#define INV_ICM42607_INT_STATUS2_WOM_INT GENMASK(2, 0)
+
+#define INV_ICM42607_REG_INT_STATUS3 0x3C
+#define INV_ICM42607_INT_STATUS3_STEP_DET BIT(5)
+#define INV_ICM42607_INT_STATUS3_STEP_CNT_OVF BIT(4)
+#define INV_ICM42607_INT_STATUS3_TILT_DET BIT(3)
+#define INV_ICM42607_INT_STATUS3_FF_DET BIT(2)
+
+/*
+ * FIFO access registers
+ * FIFO count is 16 bits (2 registers) big-endian
+ * FIFO data is a continuous read register to read FIFO content
+ */
+#define INV_ICM42607_REG_FIFO_COUNTH 0x3D
+#define INV_ICM42607_REG_FIFO_COUNTL 0x3E
+#define INV_ICM42607_REG_FIFO_DATA 0x3F
+
+#define INV_ICM42607_REG_WHOAMI 0x75
+#define INV_ICM42607P_WHOAMI 0x60
+#define INV_ICM42607_WHOAMI 0x67
+
+/* Timings as listed in section 3 of datasheet */
+#define INV_ICM42607_POWER_UP_TIME_US (100 * USEC_PER_MSEC)
+#define INV_ICM42607_RESET_TIME_MS 1
+#define INV_ICM42607_ACCEL_STARTUP_TIME_MS 10
+#define INV_ICM42607_GYRO_STARTUP_TIME_MS 30
+#define INV_ICM42607_GYRO_STOP_TIME_MS 45
+#define INV_ICM42607_TEMP_STARTUP_TIME_MS 77
+
+typedef int (*inv_icm42607_bus_setup)(struct inv_icm42607_state *);
+
+extern const struct regmap_config inv_icm42607_regmap_config;
+extern const struct inv_icm42607_hw inv_icm42607_hw_data;
+extern const struct inv_icm42607_hw inv_icm42607p_hw_data;
+
+int inv_icm42607_core_probe(struct regmap *regmap,
+ const struct inv_icm42607_hw *hw,
+ inv_icm42607_bus_setup bus_setup);
+
+#endif
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
new file mode 100644
index 000000000000..4b8e19091786
--- /dev/null
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
@@ -0,0 +1,280 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2026 InvenSense, Inc.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <linux/dev_printk.h>
+#include <linux/device/devres.h>
+#include <linux/err.h>
+#include <linux/iio/iio.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/time.h>
+#include <linux/types.h>
+
+#include "inv_icm42607.h"
+
+static bool inv_icm42607_is_readable_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case INV_ICM42607_REG_MCLK_RDY ... INV_ICM42607_REG_INT_CONFIG:
+ case INV_ICM42607_REG_TEMP_DATA1 ... INV_ICM42607_REG_TMST_FSYNCL:
+ case INV_ICM42607_REG_APEX_DATA4 ... INV_ICM42607_REG_INTF_CONFIG1:
+ case INV_ICM42607_REG_INT_STATUS_DRDY ... INV_ICM42607_REG_FIFO_DATA:
+ case INV_ICM42607_REG_WHOAMI:
+ return true;
+ }
+
+ return false;
+}
+
+static bool inv_icm42607_is_writeable_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case INV_ICM42607_REG_DEVICE_CONFIG ... INV_ICM42607_REG_INT_CONFIG:
+ case INV_ICM42607_REG_PWR_MGMT0 ... INV_ICM42607_REG_INT_SOURCE4:
+ case INV_ICM42607_REG_INTF_CONFIG0 ... INV_ICM42607_REG_INTF_CONFIG1:
+ return true;
+ }
+
+ return false;
+}
+
+static bool inv_icm42607_is_volatile_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case INV_ICM42607_REG_MCLK_RDY:
+ case INV_ICM42607_REG_SIGNAL_PATH_RESET:
+ case INV_ICM42607_REG_TEMP_DATA1 ... INV_ICM42607_REG_APEX_DATA5:
+ case INV_ICM42607_REG_APEX_CONFIG0:
+ case INV_ICM42607_REG_FIFO_CONFIG2 ... INV_ICM42607_REG_FIFO_CONFIG3:
+ case INV_ICM42607_REG_FIFO_LOST_PKT0 ... INV_ICM42607_REG_APEX_DATA3:
+ case INV_ICM42607_REG_INT_STATUS_DRDY:
+ case INV_ICM42607_REG_INT_STATUS ... INV_ICM42607_REG_FIFO_DATA:
+ return true;
+ }
+
+ return false;
+}
+
+const struct regmap_config inv_icm42607_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .writeable_reg = inv_icm42607_is_writeable_reg,
+ .readable_reg = inv_icm42607_is_readable_reg,
+ .volatile_reg = inv_icm42607_is_volatile_reg,
+ .max_register = INV_ICM42607_REG_WHOAMI,
+ .cache_type = REGCACHE_MAPLE,
+};
+EXPORT_SYMBOL_NS_GPL(inv_icm42607_regmap_config, "IIO_ICM42607");
+
+/* chip initial default configuration */
+static const struct inv_icm42607_conf inv_icm42607_default_conf = {
+ .gyro = {
+ .mode = INV_ICM42607_SENSOR_MODE_OFF,
+ .fs = INV_ICM42607_GYRO_FS_1000DPS,
+ .odr = INV_ICM42607_ODR_100HZ,
+ .filter = INV_ICM42607_FILTER_BW_25HZ,
+ },
+ .accel = {
+ .mode = INV_ICM42607_SENSOR_MODE_OFF,
+ .fs = INV_ICM42607_ACCEL_FS_4G,
+ .odr = INV_ICM42607_ODR_100HZ,
+ .filter = INV_ICM42607_FILTER_BW_25HZ,
+ },
+ .temp_en = false,
+};
+
+const struct inv_icm42607_hw inv_icm42607_hw_data = {
+ .whoami = INV_ICM42607_WHOAMI,
+ .name = "icm42607",
+ .conf = &inv_icm42607_default_conf,
+};
+EXPORT_SYMBOL_NS_GPL(inv_icm42607_hw_data, "IIO_ICM42607");
+
+const struct inv_icm42607_hw inv_icm42607p_hw_data = {
+ .whoami = INV_ICM42607P_WHOAMI,
+ .name = "icm42607p",
+ .conf = &inv_icm42607_default_conf,
+};
+EXPORT_SYMBOL_NS_GPL(inv_icm42607p_hw_data, "IIO_ICM42607");
+
+static int inv_icm42607_set_conf(struct inv_icm42607_state *st,
+ const struct inv_icm42607_conf *conf)
+{
+ unsigned int val;
+ int ret;
+
+ val = FIELD_PREP(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, conf->gyro.mode);
+ val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, conf->accel.mode);
+ ret = regmap_write(st->map, INV_ICM42607_REG_PWR_MGMT0, val);
+ if (ret)
+ return ret;
+
+ val = FIELD_PREP(INV_ICM42607_GYRO_CONFIG0_FS_SEL_MASK, conf->gyro.fs);
+ val |= FIELD_PREP(INV_ICM42607_GYRO_CONFIG0_ODR_MASK, conf->gyro.odr);
+ ret = regmap_write(st->map, INV_ICM42607_REG_GYRO_CONFIG0, val);
+ if (ret)
+ return ret;
+
+ val = FIELD_PREP(INV_ICM42607_ACCEL_CONFIG0_FS_SEL_MASK, conf->accel.fs);
+ val |= FIELD_PREP(INV_ICM42607_ACCEL_CONFIG0_ODR_MASK, conf->accel.odr);
+ ret = regmap_write(st->map, INV_ICM42607_REG_ACCEL_CONFIG0, val);
+ if (ret)
+ return ret;
+
+ val = FIELD_PREP(INV_ICM42607_GYRO_CONFIG1_FILTER_MASK, conf->gyro.filter);
+ ret = regmap_update_bits(st->map, INV_ICM42607_REG_GYRO_CONFIG1,
+ INV_ICM42607_GYRO_CONFIG1_FILTER_MASK, val);
+ if (ret)
+ return ret;
+
+ val = FIELD_PREP(INV_ICM42607_ACCEL_CONFIG1_FILTER_MASK, conf->accel.filter);
+ ret = regmap_update_bits(st->map, INV_ICM42607_REG_ACCEL_CONFIG1,
+ INV_ICM42607_ACCEL_CONFIG1_FILTER_MASK, val);
+ if (ret)
+ return ret;
+
+ st->conf = *conf;
+
+ return 0;
+}
+
+static int inv_icm42607_setup(struct inv_icm42607_state *st,
+ inv_icm42607_bus_setup inv_icm42607_bus_setup)
+{
+ const struct device *dev = regmap_get_device(st->map);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(st->map, INV_ICM42607_REG_WHOAMI, &val);
+ if (ret)
+ return ret;
+
+ /* Warn, but don't fail. */
+ if (val != st->hw->whoami)
+ dev_warn(dev, "Unknown whoami %#02x expected %#02x (%s)\n",
+ val, st->hw->whoami, st->hw->name);
+
+ ret = regmap_write(st->map, INV_ICM42607_REG_SIGNAL_PATH_RESET,
+ INV_ICM42607_SIGNAL_PATH_RESET_SOFT_RESET);
+ if (ret)
+ return ret;
+
+ fsleep(1 * USEC_PER_MSEC);
+
+ /*
+ * No polling interval specified in datasheet, so use reset time as
+ * polling interval and 10x reset time as timeout period.
+ */
+ ret = regmap_read_poll_timeout(st->map, INV_ICM42607_REG_INT_STATUS,
+ val, val & INV_ICM42607_INT_STATUS_RESET_DONE,
+ 1 * USEC_PER_MSEC, 10 * USEC_PER_MSEC);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "reset error, reset done bit not set\n");
+
+ /* Sync the regcache again after a reset. */
+ regcache_mark_dirty(st->map);
+ ret = regcache_sync(st->map);
+ if (ret)
+ return ret;
+
+ ret = inv_icm42607_bus_setup(st);
+ if (ret)
+ return ret;
+
+ ret = regmap_set_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
+ INV_ICM42607_INTF_CONFIG0_SENSOR_DATA_ENDIAN);
+ if (ret)
+ return ret;
+
+ val = FIELD_PREP(INV_ICM42607_INTF_CONFIG1_CLKSEL_MASK,
+ INV_ICM42607_INTF_CONFIG1_CLKSEL_PLL);
+ ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG1,
+ INV_ICM42607_INTF_CONFIG1_CLKSEL_MASK,
+ val);
+ if (ret)
+ return ret;
+
+ return inv_icm42607_set_conf(st, st->hw->conf);
+}
+
+static int inv_icm42607_enable_vddio_reg(struct inv_icm42607_state *st)
+{
+ int ret;
+
+ ret = regulator_enable(st->vddio_supply);
+ if (ret)
+ return ret;
+
+ fsleep(INV_ICM42607_POWER_UP_TIME_US);
+
+ return 0;
+}
+
+static void inv_icm42607_disable_vddio_reg(void *_data)
+{
+ struct inv_icm42607_state *st = _data;
+
+ regulator_disable(st->vddio_supply);
+}
+
+int inv_icm42607_core_probe(struct regmap *regmap,
+ const struct inv_icm42607_hw *hw,
+ inv_icm42607_bus_setup inv_icm42607_bus_setup)
+{
+ struct device *dev = regmap_get_device(regmap);
+ struct inv_icm42607_state *st;
+ int ret;
+
+ st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return -ENOMEM;
+
+ ret = devm_mutex_init(dev, &st->lock);
+ if (ret)
+ return ret;
+
+ st->hw = hw;
+ st->map = regmap;
+
+ ret = iio_read_mount_matrix(dev, &st->orientation);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to retrieve mounting matrix\n");
+
+ ret = devm_regulator_get_enable(dev, "vdd");
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to get vdd regulator\n");
+
+ st->vddio_supply = devm_regulator_get(dev, "vddio");
+ if (IS_ERR(st->vddio_supply))
+ return dev_err_probe(dev, PTR_ERR(st->vddio_supply),
+ "Failed to get vddio regulator\n");
+
+ ret = inv_icm42607_enable_vddio_reg(st);
+ if (ret)
+ return ret;
+
+ ret = devm_add_action_or_reset(dev, inv_icm42607_disable_vddio_reg, st);
+ if (ret)
+ return ret;
+
+ /* Setup chip registers (includes WHOAMI check, reset check, bus setup) */
+ ret = inv_icm42607_setup(st, inv_icm42607_bus_setup);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+EXPORT_SYMBOL_NS_GPL(inv_icm42607_core_probe, "IIO_ICM42607");
+
+MODULE_AUTHOR("InvenSense, Inc.");
+MODULE_DESCRIPTION("InvenSense ICM-42607 device driver");
+MODULE_LICENSE("GPL");
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
new file mode 100644
index 000000000000..bde931752eb8
--- /dev/null
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2026 InvenSense, Inc.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/dev_printk.h>
+#include <linux/err.h>
+#include <linux/i2c.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+
+
+#include "inv_icm42607.h"
+
+static int inv_icm42607_i2c_bus_setup(struct inv_icm42607_state *st)
+{
+ unsigned int val;
+ int ret;
+
+ ret = regmap_clear_bits(st->map, INV_ICM42607_REG_INTF_CONFIG1,
+ INV_ICM42607_INTF_CONFIG1_I3C_DDR_EN |
+ INV_ICM42607_INTF_CONFIG1_I3C_SDR_EN);
+ if (ret)
+ return ret;
+
+ val = FIELD_PREP(INV_ICM42607_DRIVE_CONFIG2_I2C_MASK,
+ INV_ICM42607_SLEW_RATE_12_36NS);
+ ret = regmap_update_bits(st->map, INV_ICM42607_REG_DRIVE_CONFIG2,
+ INV_ICM42607_DRIVE_CONFIG2_I2C_MASK, val);
+ if (ret)
+ return ret;
+
+ val = FIELD_PREP(INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_MASK,
+ INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_SPI_DIS);
+ return regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
+ INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_MASK,
+ val);
+}
+
+static int inv_icm42607_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ const struct inv_icm42607_hw *hw;
+ struct regmap *regmap;
+
+ hw = i2c_get_match_data(client);
+ if (!hw)
+ return dev_err_probe(dev, -ENODEV, "Failed to get i2c data\n");
+
+ regmap = devm_regmap_init_i2c(client, &inv_icm42607_regmap_config);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap),
+ "Failed to register i2c regmap\n");
+
+ return inv_icm42607_core_probe(regmap, hw, inv_icm42607_i2c_bus_setup);
+}
+
+static const struct i2c_device_id inv_icm42607_id[] = {
+ {
+ .name = "icm42607",
+ .driver_data = (kernel_ulong_t)&inv_icm42607_hw_data,
+ }, {
+ .name = "icm42607p",
+ .driver_data = (kernel_ulong_t)&inv_icm42607p_hw_data,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, inv_icm42607_id);
+
+static const struct of_device_id inv_icm42607_of_matches[] = {
+ {
+ .compatible = "invensense,icm42607",
+ .data = &inv_icm42607_hw_data,
+ }, {
+ .compatible = "invensense,icm42607p",
+ .data = &inv_icm42607p_hw_data,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, inv_icm42607_of_matches);
+
+static struct i2c_driver inv_icm42607_driver = {
+ .driver = {
+ .name = "inv-icm42607-i2c",
+ .of_match_table = inv_icm42607_of_matches,
+ },
+ .id_table = inv_icm42607_id,
+ .probe = inv_icm42607_probe,
+};
+module_i2c_driver(inv_icm42607_driver);
+
+MODULE_AUTHOR("InvenSense, Inc.");
+MODULE_DESCRIPTION("InvenSense ICM-42607 I2C driver");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_ICM42607");
--
2.43.0
^ permalink raw reply related
* [PATCH V13 4/9] iio: imu: inv_icm42607: Add SPI For icm42607
From: Chris Morgan @ 2026-06-15 17:25 UTC (permalink / raw)
To: linux-iio
Cc: andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260615172554.160910-1-macroalpha82@gmail.com>
From: Chris Morgan <macromorgan@hotmail.com>
Add SPI driver support for InvenSense ICM-42607 devices.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
drivers/iio/imu/inv_icm42607/Kconfig | 12 ++
drivers/iio/imu/inv_icm42607/Makefile | 3 +
.../iio/imu/inv_icm42607/inv_icm42607_spi.c | 107 ++++++++++++++++++
3 files changed, 122 insertions(+)
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
diff --git a/drivers/iio/imu/inv_icm42607/Kconfig b/drivers/iio/imu/inv_icm42607/Kconfig
index 083c212087ab..23f461f57afc 100644
--- a/drivers/iio/imu/inv_icm42607/Kconfig
+++ b/drivers/iio/imu/inv_icm42607/Kconfig
@@ -16,3 +16,15 @@ config INV_ICM42607_I2C
This driver can be built as a module. The module will be called
inv-icm42607-i2c.
+
+config INV_ICM42607_SPI
+ tristate "InvenSense ICM-42607 SPI driver"
+ depends on SPI_MASTER
+ select INV_ICM42607
+ select REGMAP_SPI
+ help
+ This driver supports the InvenSense ICM-42607 motion tracking
+ device over SPI.
+
+ This driver can be built as a module. The module will be called
+ inv-icm42607-spi.
diff --git a/drivers/iio/imu/inv_icm42607/Makefile b/drivers/iio/imu/inv_icm42607/Makefile
index 32046e2727d7..be109102e203 100644
--- a/drivers/iio/imu/inv_icm42607/Makefile
+++ b/drivers/iio/imu/inv_icm42607/Makefile
@@ -5,3 +5,6 @@ inv-icm42607-y += inv_icm42607_core.o
obj-$(CONFIG_INV_ICM42607_I2C) += inv-icm42607-i2c.o
inv-icm42607-i2c-y += inv_icm42607_i2c.o
+
+obj-$(CONFIG_INV_ICM42607_SPI) += inv-icm42607-spi.o
+inv-icm42607-spi-y += inv_icm42607_spi.o
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
new file mode 100644
index 000000000000..6072ed7adc86
--- /dev/null
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
@@ -0,0 +1,107 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2026 InvenSense, Inc.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/dev_printk.h>
+#include <linux/err.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/spi/spi.h>
+
+#include "inv_icm42607.h"
+
+static int inv_icm42607_spi_bus_setup(struct inv_icm42607_state *st)
+{
+ unsigned int val;
+ int ret;
+
+ /* Only support 4-wire mode for now. */
+ ret = regmap_set_bits(st->map, INV_ICM42607_REG_DEVICE_CONFIG,
+ INV_ICM42607_DEVICE_CONFIG_SPI_AP_4WIRE);
+ if (ret)
+ return ret;
+
+ ret = regmap_clear_bits(st->map, INV_ICM42607_REG_INTF_CONFIG1,
+ INV_ICM42607_INTF_CONFIG1_I3C_DDR_EN |
+ INV_ICM42607_INTF_CONFIG1_I3C_SDR_EN);
+ if (ret)
+ return ret;
+
+ val = FIELD_PREP(INV_ICM42607_DRIVE_CONFIG3_SPI_MASK,
+ INV_ICM42607_SLEW_RATE_2NS);
+ ret = regmap_update_bits(st->map, INV_ICM42607_REG_DRIVE_CONFIG3,
+ INV_ICM42607_DRIVE_CONFIG3_SPI_MASK, val);
+ if (ret)
+ return ret;
+
+ val = FIELD_PREP(INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_MASK,
+ INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_I2C_DIS);
+ return regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
+ INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_MASK,
+ val);
+}
+
+static int inv_icm42607_probe(struct spi_device *spi)
+{
+ const struct inv_icm42607_hw *hw;
+ struct device *dev = &spi->dev;
+ struct regmap *regmap;
+
+ hw = spi_get_device_match_data(spi);
+ if (!hw)
+ return dev_err_probe(dev, -ENODEV, "Failed to get SPI data\n");
+
+ if (spi->mode & SPI_3WIRE)
+ return dev_err_probe(dev, -ENODEV, "SPI 3-wire mode not supported\n");
+
+ regmap = devm_regmap_init_spi(spi, &inv_icm42607_regmap_config);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap),
+ "Failed to register spi regmap\n");
+
+ return inv_icm42607_core_probe(regmap, hw,
+ inv_icm42607_spi_bus_setup);
+}
+
+static const struct spi_device_id inv_icm42607_spi_id_table[] = {
+ {
+ .name = "icm42607",
+ .driver_data = (kernel_ulong_t)&inv_icm42607_hw_data,
+ }, {
+ .name = "icm42607p",
+ .driver_data = (kernel_ulong_t)&inv_icm42607p_hw_data,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(spi, inv_icm42607_spi_id_table);
+
+static const struct of_device_id inv_icm42607_of_matches[] = {
+ {
+ .compatible = "invensense,icm42607",
+ .data = &inv_icm42607_hw_data,
+ },
+ {
+ .compatible = "invensense,icm42607p",
+ .data = &inv_icm42607p_hw_data,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, inv_icm42607_of_matches);
+
+static struct spi_driver inv_icm42607_driver = {
+ .driver = {
+ .name = "inv-icm42607-spi",
+ .of_match_table = inv_icm42607_of_matches,
+ },
+ .id_table = inv_icm42607_spi_id_table,
+ .probe = inv_icm42607_probe,
+};
+module_spi_driver(inv_icm42607_driver);
+
+MODULE_AUTHOR("InvenSense, Inc.");
+MODULE_DESCRIPTION("InvenSense ICM-42607 SPI driver");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_ICM42607");
--
2.43.0
^ permalink raw reply related
* [PATCH V13 5/9] iio: imu: inv_icm42607: Add PM support for icm42607
From: Chris Morgan @ 2026-06-15 17:25 UTC (permalink / raw)
To: linux-iio
Cc: andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260615172554.160910-1-macroalpha82@gmail.com>
From: Chris Morgan <macromorgan@hotmail.com>
Add power management support for the ICM42607 device driver.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
drivers/iio/imu/inv_icm42607/inv_icm42607.h | 18 +++
.../iio/imu/inv_icm42607/inv_icm42607_core.c | 139 ++++++++++++++++++
.../iio/imu/inv_icm42607/inv_icm42607_i2c.c | 1 +
.../iio/imu/inv_icm42607/inv_icm42607_spi.c | 1 +
4 files changed, 159 insertions(+)
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
index a6a58571935f..4f4f541027dc 100644
--- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
@@ -9,6 +9,7 @@
#include <linux/bits.h>
#include <linux/iio/iio.h>
#include <linux/mutex.h>
+#include <linux/pm.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
#include <linux/time.h>
@@ -105,12 +106,20 @@ struct inv_icm42607_hw {
u8 whoami;
};
+struct inv_icm42607_suspended {
+ enum inv_icm42607_sensor_mode gyro;
+ enum inv_icm42607_sensor_mode accel;
+ bool temp;
+};
+
/**
* struct inv_icm42607_state - driver state variables
* @hw: Hardware specific data.
* @lock: lock for serializing multiple registers access.
* @map: regmap pointer.
* @vddio_supply: I/O voltage regulator for the chip.
+ * @vddio_en: I/O voltage status for runtime PM.
+ * @suspended: suspended sensors configuration.
* @conf: chip sensors configurations.
* @orientation: sensor chip orientation relative to main hardware.
*/
@@ -119,6 +128,8 @@ struct inv_icm42607_state {
struct mutex lock;
struct regmap *map;
struct regulator *vddio_supply;
+ bool vddio_en;
+ struct inv_icm42607_suspended suspended;
struct inv_icm42607_conf conf;
struct iio_mount_matrix orientation;
};
@@ -334,11 +345,18 @@ struct inv_icm42607_state {
#define INV_ICM42607_GYRO_STOP_TIME_MS 45
#define INV_ICM42607_TEMP_STARTUP_TIME_MS 77
+/*
+ * Suspend delay assumed from other icm42600 series device, not
+ * documented in datasheet.
+ */
+#define INV_ICM42607_SUSPEND_DELAY_MS (2 * USEC_PER_MSEC)
+
typedef int (*inv_icm42607_bus_setup)(struct inv_icm42607_state *);
extern const struct regmap_config inv_icm42607_regmap_config;
extern const struct inv_icm42607_hw inv_icm42607_hw_data;
extern const struct inv_icm42607_hw inv_icm42607p_hw_data;
+extern const struct dev_pm_ops inv_icm42607_pm_ops;
int inv_icm42607_core_probe(struct regmap *regmap,
const struct inv_icm42607_hw *hw,
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
index 4b8e19091786..64f5d263de4f 100644
--- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
@@ -4,6 +4,7 @@
*/
#include <linux/bitfield.h>
+#include <linux/cleanup.h>
#include <linux/delay.h>
#include <linux/dev_printk.h>
#include <linux/device/devres.h>
@@ -11,6 +12,7 @@
#include <linux/iio/iio.h>
#include <linux/module.h>
#include <linux/mutex.h>
+#include <linux/pm_runtime.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
#include <linux/time.h>
@@ -103,6 +105,63 @@ const struct inv_icm42607_hw inv_icm42607p_hw_data = {
};
EXPORT_SYMBOL_NS_GPL(inv_icm42607p_hw_data, "IIO_ICM42607");
+static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
+ enum inv_icm42607_sensor_mode gyro,
+ enum inv_icm42607_sensor_mode accel,
+ bool temp, unsigned int *sleep_ms)
+{
+ enum inv_icm42607_sensor_mode oldaccel = st->conf.accel.mode;
+ enum inv_icm42607_sensor_mode oldgyro = st->conf.gyro.mode;
+ bool oldtemp = st->conf.temp_en;
+ unsigned int sleepval_ms;
+ unsigned int val;
+ int ret;
+
+ if (gyro == oldgyro && accel == oldaccel && temp == oldtemp)
+ return 0;
+
+ /*
+ * Datasheet on page 14.26 says we need to ensure the gyro sensor is on
+ * for a minimum of 45ms. So if we transition from an on state to an
+ * off state wait 45ms to ensure a sufficient pause before power off.
+ */
+ if (!gyro && oldgyro)
+ fsleep(INV_ICM42607_GYRO_STOP_TIME_MS * USEC_PER_MSEC);
+
+ val = FIELD_PREP(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, gyro);
+ val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, accel);
+ ret = regmap_write(st->map, INV_ICM42607_REG_PWR_MGMT0, val);
+ if (ret)
+ return ret;
+
+ st->conf.gyro.mode = gyro;
+ st->conf.accel.mode = accel;
+ st->conf.temp_en = temp;
+
+ /*
+ * If a state change occurs from off to on, sleep for the startup
+ * time of the sensor, unless a sleep_ms is specified. Since more
+ * than one sensor can be transitioned from off to on, select the
+ * maximum time from each of the sensors changing from off to on.
+ */
+ sleepval_ms = 0;
+ if (temp && !oldtemp)
+ sleepval_ms = max(sleepval_ms, INV_ICM42607_TEMP_STARTUP_TIME_MS);
+
+ if (accel && !oldaccel)
+ sleepval_ms = max(sleepval_ms, INV_ICM42607_ACCEL_STARTUP_TIME_MS);
+
+ if (gyro && !oldgyro)
+ sleepval_ms = max(sleepval_ms, INV_ICM42607_GYRO_STARTUP_TIME_MS);
+
+ if (sleep_ms)
+ *sleep_ms = sleepval_ms;
+ else if (sleepval_ms)
+ fsleep(sleepval_ms * USEC_PER_MSEC);
+
+ return 0;
+}
+
static int inv_icm42607_set_conf(struct inv_icm42607_state *st,
const struct inv_icm42607_conf *conf)
{
@@ -208,12 +267,17 @@ static int inv_icm42607_enable_vddio_reg(struct inv_icm42607_state *st)
{
int ret;
+ if (st->vddio_en)
+ return 0;
+
ret = regulator_enable(st->vddio_supply);
if (ret)
return ret;
fsleep(INV_ICM42607_POWER_UP_TIME_US);
+ st->vddio_en = true;
+
return 0;
}
@@ -221,7 +285,12 @@ static void inv_icm42607_disable_vddio_reg(void *_data)
{
struct inv_icm42607_state *st = _data;
+ if (!st->vddio_en)
+ return;
+
regulator_disable(st->vddio_supply);
+
+ st->vddio_en = false;
}
int inv_icm42607_core_probe(struct regmap *regmap,
@@ -236,6 +305,8 @@ int inv_icm42607_core_probe(struct regmap *regmap,
if (!st)
return -ENOMEM;
+ dev_set_drvdata(dev, st);
+
ret = devm_mutex_init(dev, &st->lock);
if (ret)
return ret;
@@ -271,10 +342,78 @@ int inv_icm42607_core_probe(struct regmap *regmap,
if (ret)
return ret;
+ ret = devm_pm_runtime_set_active_enabled(dev);
+ if (ret)
+ return ret;
+
+ pm_runtime_set_autosuspend_delay(dev, INV_ICM42607_SUSPEND_DELAY_MS);
+ pm_runtime_use_autosuspend(dev);
+
return 0;
}
EXPORT_SYMBOL_NS_GPL(inv_icm42607_core_probe, "IIO_ICM42607");
+static int inv_icm42607_suspend(struct device *dev)
+{
+ struct inv_icm42607_state *st = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_force_suspend(dev);
+ if (ret)
+ return ret;
+
+ inv_icm42607_disable_vddio_reg(st);
+
+ return 0;
+}
+
+static int inv_icm42607_resume(struct device *dev)
+{
+ struct inv_icm42607_state *st = dev_get_drvdata(dev);
+ int ret;
+
+ ret = inv_icm42607_enable_vddio_reg(st);
+ if (ret)
+ return ret;
+
+ return pm_runtime_force_resume(dev);
+}
+
+static int inv_icm42607_runtime_suspend(struct device *dev)
+{
+ struct inv_icm42607_state *st = dev_get_drvdata(dev);
+
+ guard(mutex)(&st->lock);
+
+ /* save sensors state */
+ st->suspended.gyro = st->conf.gyro.mode;
+ st->suspended.accel = st->conf.accel.mode;
+ st->suspended.temp = st->conf.temp_en;
+
+ return inv_icm42607_set_pwr_mgmt0(st, INV_ICM42607_SENSOR_MODE_OFF,
+ INV_ICM42607_SENSOR_MODE_OFF, false,
+ NULL);
+}
+
+static int inv_icm42607_runtime_resume(struct device *dev)
+{
+ struct inv_icm42607_state *st = dev_get_drvdata(dev);
+
+ guard(mutex)(&st->lock);
+
+ /* restore sensors state */
+ return inv_icm42607_set_pwr_mgmt0(st, st->suspended.gyro,
+ st->suspended.accel,
+ st->suspended.temp, NULL);
+}
+
+EXPORT_NS_GPL_DEV_PM_OPS(inv_icm42607_pm_ops, IIO_ICM42607) = {
+ SYSTEM_SLEEP_PM_OPS(inv_icm42607_suspend, inv_icm42607_resume)
+ RUNTIME_PM_OPS(inv_icm42607_runtime_suspend,
+ inv_icm42607_runtime_resume,
+ NULL)
+};
+
MODULE_AUTHOR("InvenSense, Inc.");
MODULE_DESCRIPTION("InvenSense ICM-42607 device driver");
MODULE_LICENSE("GPL");
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
index bde931752eb8..aed04be28528 100644
--- a/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
@@ -85,6 +85,7 @@ static struct i2c_driver inv_icm42607_driver = {
.driver = {
.name = "inv-icm42607-i2c",
.of_match_table = inv_icm42607_of_matches,
+ .pm = pm_ptr(&inv_icm42607_pm_ops),
},
.id_table = inv_icm42607_id,
.probe = inv_icm42607_probe,
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
index 6072ed7adc86..137cd34582d8 100644
--- a/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
@@ -95,6 +95,7 @@ static struct spi_driver inv_icm42607_driver = {
.driver = {
.name = "inv-icm42607-spi",
.of_match_table = inv_icm42607_of_matches,
+ .pm = pm_ptr(&inv_icm42607_pm_ops),
},
.id_table = inv_icm42607_spi_id_table,
.probe = inv_icm42607_probe,
--
2.43.0
^ permalink raw reply related
* [PATCH V13 6/9] iio: imu: inv_icm42607: Add Temp Support in icm42607
From: Chris Morgan @ 2026-06-15 17:25 UTC (permalink / raw)
To: linux-iio
Cc: andy, nuno.sa, dlechner, jic23, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260615172554.160910-1-macroalpha82@gmail.com>
From: Chris Morgan <macromorgan@hotmail.com>
Add functions for reading temperature sensor data.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
drivers/iio/imu/inv_icm42607/Makefile | 1 +
drivers/iio/imu/inv_icm42607/inv_icm42607.h | 3 +
.../iio/imu/inv_icm42607/inv_icm42607_core.c | 18 +++++
.../iio/imu/inv_icm42607/inv_icm42607_temp.c | 81 +++++++++++++++++++
.../iio/imu/inv_icm42607/inv_icm42607_temp.h | 37 +++++++++
5 files changed, 140 insertions(+)
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
diff --git a/drivers/iio/imu/inv_icm42607/Makefile b/drivers/iio/imu/inv_icm42607/Makefile
index be109102e203..c04953ed42ce 100644
--- a/drivers/iio/imu/inv_icm42607/Makefile
+++ b/drivers/iio/imu/inv_icm42607/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_INV_ICM42607) += inv-icm42607.o
inv-icm42607-y += inv_icm42607_core.o
+inv-icm42607-y += inv_icm42607_temp.o
obj-$(CONFIG_INV_ICM42607_I2C) += inv-icm42607-i2c.o
inv-icm42607-i2c-y += inv_icm42607_i2c.o
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
index 4f4f541027dc..726b836582a2 100644
--- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
@@ -358,6 +358,9 @@ extern const struct inv_icm42607_hw inv_icm42607_hw_data;
extern const struct inv_icm42607_hw inv_icm42607p_hw_data;
extern const struct dev_pm_ops inv_icm42607_pm_ops;
+int inv_icm42607_set_temp_conf(struct inv_icm42607_state *st, bool enable,
+ unsigned int *sleep_ms);
+
int inv_icm42607_core_probe(struct regmap *regmap,
const struct inv_icm42607_hw *hw,
inv_icm42607_bus_setup bus_setup);
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
index 64f5d263de4f..644cd7f821b9 100644
--- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
@@ -162,6 +162,24 @@ static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
return 0;
}
+int inv_icm42607_set_temp_conf(struct inv_icm42607_state *st, bool enable,
+ unsigned int *sleep_ms)
+{
+ unsigned int val;
+ int ret;
+
+ val = FIELD_PREP(INV_ICM42607_TEMP_CONFIG0_FILTER_MASK,
+ INV_ICM42607_FILTER_BW_34HZ);
+ ret = regmap_update_bits(st->map, INV_ICM42607_REG_TEMP_CONFIG0,
+ INV_ICM42607_TEMP_CONFIG0_FILTER_MASK, val);
+ if (ret)
+ return ret;
+
+ return inv_icm42607_set_pwr_mgmt0(st, st->conf.gyro.mode,
+ st->conf.accel.mode, enable,
+ sleep_ms);
+}
+
static int inv_icm42607_set_conf(struct inv_icm42607_state *st,
const struct inv_icm42607_conf *conf)
{
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
new file mode 100644
index 000000000000..9a60e1a478b0
--- /dev/null
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2026 InvenSense, Inc.
+ */
+
+#include <linux/cleanup.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/iio/iio.h>
+#include <linux/mutex.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+#include <linux/unaligned.h>
+
+#include "inv_icm42607.h"
+#include "inv_icm42607_temp.h"
+
+static int inv_icm42607_temp_read(struct inv_icm42607_state *st, s16 *temp)
+{
+ struct device *dev = regmap_get_device(st->map);
+ u8 raw[2];
+ int ret;
+
+ PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
+ ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+ if (ret)
+ return ret;
+
+ guard(mutex)(&st->lock);
+
+ st->conf.temp_en = true;
+ ret = inv_icm42607_set_temp_conf(st, st->conf.temp_en, NULL);
+ st->conf.temp_en = false;
+ if (ret)
+ return ret;
+
+ ret = regmap_bulk_read(st->map, INV_ICM42607_REG_TEMP_DATA1,
+ raw, sizeof(raw));
+ if (ret)
+ return ret;
+
+ *temp = get_unaligned_be16(raw);
+ if (*temp == INV_ICM42607_DATA_INVALID)
+ return -EINVAL;
+
+ return 0;
+}
+
+int inv_icm42607_temp_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
+ s16 temp;
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ ret = inv_icm42607_temp_read(st, &temp);
+ if (ret)
+ return ret;
+ *val = temp;
+ return IIO_VAL_INT;
+ /*
+ * T°C = (temp / 128) + 25
+ * Tm°C = 1000 * ((temp * 100 / 12800) + 25)
+ * scale: 100000 / 12800 ~= 7.8125
+ * offset: 3200
+ */
+ case IIO_CHAN_INFO_SCALE:
+ *val = 7;
+ *val2 = 812500000;
+ return IIO_VAL_INT_PLUS_NANO;
+ case IIO_CHAN_INFO_OFFSET:
+ *val = 3200;
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
new file mode 100644
index 000000000000..cb7b460ffb44
--- /dev/null
+++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
@@ -0,0 +1,37 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Copyright (C) 2026 InvenSense, Inc.
+ */
+
+#ifndef INV_ICM42607_TEMP_H_
+#define INV_ICM42607_TEMP_H_
+
+#include <linux/bitops.h>
+
+struct iio_dev;
+struct iio_chan_spec;
+
+#define INV_ICM42607_TEMP_CHAN(_index) \
+{ \
+ .type = IIO_TEMP, \
+ .info_mask_separate = \
+ BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_OFFSET) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+ .info_mask_shared_by_all = \
+ BIT(IIO_CHAN_INFO_SAMP_FREQ), \
+ .info_mask_shared_by_all_available = \
+ BIT(IIO_CHAN_INFO_SAMP_FREQ), \
+ .scan_index = _index, \
+ .scan_type = { \
+ .sign = 's', \
+ .realbits = 16, \
+ .storagebits = 16, \
+ }, \
+}
+
+int inv_icm42607_temp_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask);
+
+#endif
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox