* Re: [PATCH v2 2/2] hwmon: (pmbus/lx1308) Add support for LX1308
From: Guenter Roeck @ 2026-04-30 18:18 UTC (permalink / raw)
To: Brian Chiang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260428-add-support-lx1308-v2-2-90f115954143@inventec.com>
On Tue, Apr 28, 2026 at 12:19:29PM +0000, Brian Chiang wrote:
> Add support for the Luxshare LX1308, a high-efficiency 12V 860W
> DC/DC power module. The module operates from 40-60V input voltage.
>
> Signed-off-by: Brian Chiang <chiang.brian@inventec.com>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: trivial: Add LX1308 support
From: Guenter Roeck @ 2026-04-30 18:18 UTC (permalink / raw)
To: Brian Chiang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260428-add-support-lx1308-v2-1-90f115954143@inventec.com>
On Tue, Apr 28, 2026 at 12:19:28PM +0000, Brian Chiang wrote:
> Add device tree bindings for the Luxshare LX1308, a high-efficiency
> 12V 860W DC/DC power module with PMBus interface.
>
> Signed-off-by: Brian Chiang <chiang.brian@inventec.com>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH] Documentation: hwmon: fix link to ideapad-laptop.c file
From: Guenter Roeck @ 2026-04-30 17:57 UTC (permalink / raw)
To: Ninad Naik
Cc: sergiomelas, corbet, skhan, linux-hwmon, linux-doc, linux-kernel,
me, linux-kernel-mentees
In-Reply-To: <20260417191411.713958-1-ninadnaik07@gmail.com>
On Sat, Apr 18, 2026 at 12:44:11AM +0530, Ninad Naik wrote:
> The ideapad-laptop.c file now exists inside drivers/platform/x86/lenovo/
> directory. Updating the GitHub link to the correct path.
>
> Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove ISDN subsystem and Bluetooth CMTP
From: patchwork-bot+bluetooth @ 2026-04-30 17:55 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
skhan, marcel, luiz.dentz, mchehab+huawei, jani.nikula, gregkh,
demarchi, rdunlap, justonli, ivecera, jonathan.cameron, kees,
marco.crivellari, ferr.lambarginio, nihaal, mingo, tglx, linmq006,
linux-doc, linux-bluetooth
In-Reply-To: <20260421022108.1299678-1-kuba@kernel.org>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 20 Apr 2026 19:21:07 -0700 you wrote:
> Remove the ISDN (mISDN, CAPI) subsystem and Bluetooth CMTP protocol
> from the kernel tree.
>
> ISDN is a pretty old technology and it's unclear whether anyone still
> uses it. I went over the last few years of git history and all the
> commits are either tree-wide conversions or syzbot/static analyzer
> fixes.
>
> [...]
Here is the summary with links:
- [net-deletions] net: remove ISDN subsystem and Bluetooth CMTP
https://git.kernel.org/bluetooth/bluetooth-next/c/4f10f1dfb235
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3 2/2] hwmon: (pmbus/max20830) add driver for max20830
From: Guenter Roeck @ 2026-04-30 17:55 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc
In-Reply-To: <20260417-dev_max20830-v3-2-0cb8d56067aa@analog.com>
,
On Fri, Apr 17, 2026 at 04:27:14PM +0800, Alexis Czezar Torreno wrote:
> Add support for MAX20830 step-down DC-DC switching regulator with
> PMBus interface. It allows monitoring of input/output voltage,
> output current and temperature through the PMBus serial interface.
>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> ---
...
> +
> + /*
> + * Use i2c_smbus_read_i2c_block_data() instead of
> + * i2c_smbus_read_block_data() to support I2C controllers
> + * which do not support SMBus block reads.
> + */
> + ret = i2c_smbus_read_i2c_block_data(client, PMBUS_IC_DEVICE_ID,
> + I2C_SMBUS_BLOCK_MAX, buf);
> + if (ret < 0)
> + return dev_err_probe(&client->dev, ret,
> + "Failed to read IC_DEVICE_ID\n");
> +
> + /* First byte is the block length (including itself). */
> + len = buf[0];
> + if (len != 9 || ret < len)
> + return dev_err_probe(&client->dev, -ENODEV,
> + "IC_DEVICE_ID length mismatch: reported %u, read %d\n",
> + len, ret);
> +
> + /* Data is at buf[1..8], so null terminator goes at buf[9]. */
I ended up checking the kernel code. As it turns out,
i2c_smbus_read_i2c_block_data does _not_ return the length in byte 0.
It returns the first byte of the actual data, and the length as return
value. See i2c_smbus_read_i2c_block_data() in drivers/i2c/i2c-core-smbus.c.
So this can not work as written. Something like
if (i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BLOCK_DATA))
ret = i2c_smbus_read_block_data(client, PMBUS_IC_DEVICE_ID, data_buf);
else
ret = i2c_smbus_read_i2c_block_data(client, PMBUS_IC_DEVICE_ID,
I2C_SMBUS_BLOCK_MAX, buf);
should do, assuming that support for I2C_FUNC_SMBUS_BLOCK_DATA and/or
I2C_FUNC_SMBUS_READ_I2C_BLOCK was checked before.
Thanks,
Guenter
^ permalink raw reply
* [PATCH net-next v2 2/2] dpll: zl3073x: report FFO as DPLL vs input reference offset
From: Ivan Vecera @ 2026-04-30 17:36 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Leon Romanovsky, Mark Bloch, Michal Schmidt, Paolo Abeni,
Pasi Vaananen, Petr Oros, Prathosh Satish, Saeed Mahameed,
Shuah Khan, Simon Horman, Tariq Toukan, Vadim Fedorenko,
linux-doc, linux-kernel, linux-rdma
In-Reply-To: <20260430173611.3312596-1-ivecera@redhat.com>
Replace the per-reference frequency offset measurement (which was
redundant with measured-frequency) with a direct read of the DPLL's
delta frequency offset vs its tracked input reference.
The new implementation uses the dpll_df_offset_x register with
ref_ofst=1 via the dpll_df_read_x semaphore mechanism. This
provides 2^-48 resolution (~3.5 fE) and reports the actual
frequency difference between the DPLL and its active input.
FFO is now reported only for the active input pin in the nested
(pin vs parent DPLL) context. Top-level FFO returns -ENODATA.
Rewrite ffo_check to compare the cached df_offset converted to PPT
instead of using the old per-reference measurement. Remove the
ref_ffo_update periodic measurement and the ref ffo field since
they are no longer needed.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/chan.c | 31 +++++++++++++++++++++++--
drivers/dpll/zl3073x/chan.h | 14 ++++++++++++
drivers/dpll/zl3073x/core.c | 45 -------------------------------------
drivers/dpll/zl3073x/dpll.c | 34 ++++++++++++----------------
drivers/dpll/zl3073x/ref.h | 14 ------------
drivers/dpll/zl3073x/regs.h | 15 +++++++++++++
6 files changed, 72 insertions(+), 81 deletions(-)
diff --git a/drivers/dpll/zl3073x/chan.c b/drivers/dpll/zl3073x/chan.c
index 2f48ca2391494..2fe3c3da84bb5 100644
--- a/drivers/dpll/zl3073x/chan.c
+++ b/drivers/dpll/zl3073x/chan.c
@@ -18,6 +18,7 @@
int zl3073x_chan_state_update(struct zl3073x_dev *zldev, u8 index)
{
struct zl3073x_chan *chan = &zldev->chan[index];
+ u64 val;
int rc;
rc = zl3073x_read_u8(zldev, ZL_REG_DPLL_MON_STATUS(index),
@@ -25,8 +26,34 @@ int zl3073x_chan_state_update(struct zl3073x_dev *zldev, u8 index)
if (rc)
return rc;
- return zl3073x_read_u8(zldev, ZL_REG_DPLL_REFSEL_STATUS(index),
- &chan->refsel_status);
+ rc = zl3073x_read_u8(zldev, ZL_REG_DPLL_REFSEL_STATUS(index),
+ &chan->refsel_status);
+ if (rc)
+ return rc;
+
+ /* Read df_offset vs tracked reference */
+ rc = zl3073x_poll_zero_u8(zldev, ZL_REG_DPLL_DF_READ(index),
+ ZL_DPLL_DF_READ_SEM);
+ if (rc)
+ return rc;
+
+ rc = zl3073x_write_u8(zldev, ZL_REG_DPLL_DF_READ(index),
+ ZL_DPLL_DF_READ_SEM | ZL_DPLL_DF_READ_REF_OFST);
+ if (rc)
+ return rc;
+
+ rc = zl3073x_poll_zero_u8(zldev, ZL_REG_DPLL_DF_READ(index),
+ ZL_DPLL_DF_READ_SEM);
+ if (rc)
+ return rc;
+
+ rc = zl3073x_read_u48(zldev, ZL_REG_DPLL_DF_OFFSET(index), &val);
+ if (rc)
+ return rc;
+
+ chan->df_offset = sign_extend64(val, 47);
+
+ return 0;
}
/**
diff --git a/drivers/dpll/zl3073x/chan.h b/drivers/dpll/zl3073x/chan.h
index 481da2133202b..4353809c69122 100644
--- a/drivers/dpll/zl3073x/chan.h
+++ b/drivers/dpll/zl3073x/chan.h
@@ -17,6 +17,7 @@ struct zl3073x_dev;
* @ref_prio: reference priority registers (4 bits per ref, P/N packed)
* @mon_status: monitor status register value
* @refsel_status: reference selection status register value
+ * @df_offset: frequency offset vs tracked reference in 2^-48 steps
*/
struct zl3073x_chan {
struct_group(cfg,
@@ -26,6 +27,7 @@ struct zl3073x_chan {
struct_group(stat,
u8 mon_status;
u8 refsel_status;
+ s64 df_offset;
);
};
@@ -37,6 +39,18 @@ int zl3073x_chan_state_set(struct zl3073x_dev *zldev, u8 index,
int zl3073x_chan_state_update(struct zl3073x_dev *zldev, u8 index);
+/**
+ * zl3073x_chan_df_offset_get - get cached df_offset vs tracked reference
+ * @chan: pointer to channel state
+ *
+ * Return: frequency offset in 2^-48 steps
+ */
+static inline s64
+zl3073x_chan_df_offset_get(const struct zl3073x_chan *chan)
+{
+ return chan->df_offset;
+}
+
/**
* zl3073x_chan_mode_get - get DPLL channel operating mode
* @chan: pointer to channel state
diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c
index 5f1e70f3e40a0..b3345060490db 100644
--- a/drivers/dpll/zl3073x/core.c
+++ b/drivers/dpll/zl3073x/core.c
@@ -704,44 +704,6 @@ zl3073x_ref_freq_meas_update(struct zl3073x_dev *zldev)
return 0;
}
-/**
- * zl3073x_ref_ffo_update - update reference fractional frequency offsets
- * @zldev: pointer to zl3073x_dev structure
- *
- * The function asks device to latch the latest measured fractional
- * frequency offset values, reads and stores them into the ref state.
- *
- * Return: 0 on success, <0 on error
- */
-static int
-zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
-{
- int i, rc;
-
- rc = zl3073x_ref_freq_meas_latch(zldev,
- ZL_REF_FREQ_MEAS_CTRL_REF_FREQ_OFF);
- if (rc)
- return rc;
-
- /* Read DPLL-to-REFx frequency offset measurements */
- for (i = 0; i < ZL3073X_NUM_REFS; i++) {
- s32 value;
-
- /* Read value stored in units of 2^-32 signed */
- rc = zl3073x_read_u32(zldev, ZL_REG_REF_FREQ(i), &value);
- if (rc)
- return rc;
-
- /* Convert to ppt
- * ffo = (10^12 * value) / 2^32
- * ffo = ( 5^12 * value) / 2^20
- */
- zldev->ref[i].ffo = mul_s64_u64_shr(value, 244140625, 20);
- }
-
- return 0;
-}
-
static void
zl3073x_dev_periodic_work(struct kthread_work *work)
{
@@ -776,13 +738,6 @@ zl3073x_dev_periodic_work(struct kthread_work *work)
}
}
- /* Update references' fractional frequency offsets */
- rc = zl3073x_ref_ffo_update(zldev);
- if (rc)
- dev_warn(zldev->dev,
- "Failed to update fractional frequency offsets: %pe\n",
- ERR_PTR(rc));
-
list_for_each_entry(zldpll, &zldev->dplls, list)
zl3073x_dpll_changes_check(zldpll);
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index f2d430d1a8e7b..af50cd6200001 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -299,8 +299,12 @@ zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
{
struct zl3073x_dpll_pin *pin = pin_priv;
- /* Only rx vs tx symbol rate FFO is supported */
- if (dpll)
+ /* Only nested FFO (pin vs parent DPLL) is supported */
+ if (!dpll)
+ return -ENODATA;
+
+ /* Report FFO only for the active pin */
+ if (pin->operstate != DPLL_PIN_OPERSTATE_ACTIVE)
return -ENODATA;
*ffo = pin->freq_offset;
@@ -1733,37 +1737,27 @@ zl3073x_dpll_pin_phase_offset_check(struct zl3073x_dpll_pin *pin)
}
/**
- * zl3073x_dpll_pin_ffo_check - check for pin fractional frequency offset change
+ * zl3073x_dpll_pin_ffo_check - check for FFO change on active pin
* @pin: pin to check
*
- * Check for the given pin's fractional frequency change.
- *
- * Return: true on fractional frequency offset change, false otherwise
+ * Return: true on change, false otherwise
*/
static bool
zl3073x_dpll_pin_ffo_check(struct zl3073x_dpll_pin *pin)
{
struct zl3073x_dpll *zldpll = pin->dpll;
- struct zl3073x_dev *zldev = zldpll->dev;
- const struct zl3073x_ref *ref;
- u8 ref_id;
+ const struct zl3073x_chan *chan;
s64 ffo;
- /* Get reference monitor status */
- ref_id = zl3073x_input_pin_ref_get(pin->id);
- ref = zl3073x_ref_state_get(zldev, ref_id);
-
- /* Do not report ffo changes if the reference monitor report errors */
- if (!zl3073x_ref_is_status_ok(ref))
+ if (pin->operstate != DPLL_PIN_OPERSTATE_ACTIVE)
return false;
- /* Compare with previous value */
- ffo = zl3073x_ref_ffo_get(ref);
+ chan = zl3073x_chan_state_get(zldpll->dev, zldpll->id);
+ ffo = mul_s64_u64_shr(zl3073x_chan_df_offset_get(chan),
+ 244140625, 36);
+
if (pin->freq_offset != ffo) {
- dev_dbg(zldev->dev, "%s freq offset changed: %lld -> %lld\n",
- pin->label, pin->freq_offset, ffo);
pin->freq_offset = ffo;
-
return true;
}
diff --git a/drivers/dpll/zl3073x/ref.h b/drivers/dpll/zl3073x/ref.h
index 55e80e4f08734..e140ca3ea17dc 100644
--- a/drivers/dpll/zl3073x/ref.h
+++ b/drivers/dpll/zl3073x/ref.h
@@ -22,7 +22,6 @@ struct zl3073x_dev;
* @freq_ratio_n: FEC mode divisor
* @sync_ctrl: reference sync control
* @config: reference config
- * @ffo: current fractional frequency offset
* @meas_freq: measured input frequency in Hz
* @mon_status: reference monitor status
*/
@@ -40,7 +39,6 @@ struct zl3073x_ref {
u8 config;
);
struct_group(stat, /* Status */
- s64 ffo;
u32 meas_freq;
u8 mon_status;
);
@@ -58,18 +56,6 @@ int zl3073x_ref_state_update(struct zl3073x_dev *zldev, u8 index);
int zl3073x_ref_freq_factorize(u32 freq, u16 *base, u16 *mult);
-/**
- * zl3073x_ref_ffo_get - get current fractional frequency offset
- * @ref: pointer to ref state
- *
- * Return: the latest measured fractional frequency offset
- */
-static inline s64
-zl3073x_ref_ffo_get(const struct zl3073x_ref *ref)
-{
- return ref->ffo;
-}
-
/**
* zl3073x_ref_meas_freq_get - get measured input frequency
* @ref: pointer to ref state
diff --git a/drivers/dpll/zl3073x/regs.h b/drivers/dpll/zl3073x/regs.h
index 8015808bdf548..9578f00095282 100644
--- a/drivers/dpll/zl3073x/regs.h
+++ b/drivers/dpll/zl3073x/regs.h
@@ -164,6 +164,11 @@
#define ZL_DPLL_MODE_REFSEL_MODE_NCO 4
#define ZL_DPLL_MODE_REFSEL_REF GENMASK(7, 4)
+#define ZL_REG_DPLL_DF_READ(_idx) \
+ ZL_REG_IDX(_idx, 5, 0x28, 1, ZL3073X_MAX_CHANNELS, 1)
+#define ZL_DPLL_DF_READ_SEM BIT(4)
+#define ZL_DPLL_DF_READ_REF_OFST BIT(3)
+
#define ZL_REG_DPLL_MEAS_CTRL ZL_REG(5, 0x50, 1)
#define ZL_DPLL_MEAS_CTRL_EN BIT(0)
#define ZL_DPLL_MEAS_CTRL_AVG_FACTOR GENMASK(7, 4)
@@ -176,6 +181,16 @@
#define ZL_REG_DPLL_PHASE_ERR_DATA(_idx) \
ZL_REG_IDX(_idx, 5, 0x55, 6, ZL3073X_MAX_CHANNELS, 6)
+/*******************************
+ * Register Pages 6-7, DPLL Data
+ *******************************/
+
+#define ZL_REG_DPLL_DF_OFFSET_03(_idx) \
+ ZL_REG_IDX(_idx, 6, 0x00, 6, 4, 0x20)
+#define ZL_REG_DPLL_DF_OFFSET_4 ZL_REG(7, 0x00, 6)
+#define ZL_REG_DPLL_DF_OFFSET(_idx) \
+ ((_idx) < 4 ? ZL_REG_DPLL_DF_OFFSET_03(_idx) : ZL_REG_DPLL_DF_OFFSET_4)
+
/***********************************
* Register Page 9, Synth and Output
***********************************/
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v2 1/2] dpll: move fractional-frequency-offset-ppt under pin-parent-device
From: Ivan Vecera @ 2026-04-30 17:36 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Leon Romanovsky, Mark Bloch, Michal Schmidt, Paolo Abeni,
Pasi Vaananen, Petr Oros, Prathosh Satish, Saeed Mahameed,
Shuah Khan, Simon Horman, Tariq Toukan, Vadim Fedorenko,
linux-doc, linux-kernel, linux-rdma
In-Reply-To: <20260430173611.3312596-1-ivecera@redhat.com>
Move the fractional-frequency-offset-ppt attribute from the top-level
pin attributes into the pin-parent-device nested attribute set. This
makes it consistent with phase-offset which is already per-parent and
clarifies that FFO PPT represents the frequency difference between
a pin and its parent DPLL device.
The top-level fractional-frequency-offset attribute (in PPM) remains
unchanged for backward compatibility.
Distinguish the two contexts in the ffo_get callback by passing
dpll=NULL for the top-level (rx vs tx symbol rate) call and a valid
dpll pointer for the nested (pin vs parent DPLL) call. Update mlx5
and zl3073x drivers to return -ENODATA for the nested context they
do not yet support.
Add documentation for both FFO attributes to dpll.rst.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
Documentation/driver-api/dpll.rst | 16 +++++++++
Documentation/netlink/specs/dpll.yaml | 11 +++---
drivers/dpll/dpll_netlink.c | 34 ++++++++++++++-----
drivers/dpll/dpll_nl.c | 1 +
drivers/dpll/zl3073x/dpll.c | 4 +++
.../net/ethernet/mellanox/mlx5/core/dpll.c | 4 +++
6 files changed, 56 insertions(+), 14 deletions(-)
diff --git a/Documentation/driver-api/dpll.rst b/Documentation/driver-api/dpll.rst
index 37eaef785e304..8576d360a5815 100644
--- a/Documentation/driver-api/dpll.rst
+++ b/Documentation/driver-api/dpll.rst
@@ -258,6 +258,22 @@ in the ``DPLL_A_PIN_PHASE_OFFSET`` attribute.
``DPLL_A_PHASE_OFFSET_MONITOR`` attr state of a feature
=============================== ========================
+Fractional frequency offset
+===========================
+
+The fractional frequency offset (FFO) represents the frequency difference
+between a pin and its parent DPLL device. It is reported in the
+``DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT`` attribute nested under
+the parent device, in parts per trillion (PPT, 10^-12).
+
+This is analogous to ``DPLL_A_PIN_PHASE_OFFSET`` but in the frequency
+domain. It is typically reported only for the currently active input pin.
+
+The top-level ``DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET`` attribute (in PPM)
+represents the RX vs TX symbol rate offset on the media associated with
+the pin (e.g. for SyncE ethernet ports) and is independent of the
+per-parent FFO PPT attribute.
+
Frequency monitor
=================
diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml
index c45de70a47ce6..a5807169eb126 100644
--- a/Documentation/netlink/specs/dpll.yaml
+++ b/Documentation/netlink/specs/dpll.yaml
@@ -492,12 +492,10 @@ attribute-sets:
name: fractional-frequency-offset-ppt
type: sint
doc: |
- The FFO (Fractional Frequency Offset) of the pin with respect to
- the nominal frequency.
- Value = (frequency_measured - frequency_nominal) / frequency_nominal
+ The FFO (Fractional Frequency Offset) between a pin and its
+ parent DPLL device, similar to phase-offset but in frequency
+ domain.
Value is in PPT (parts per trillion, 10^-12).
- Note: This attribute provides higher resolution than the standard
- fractional-frequency-offset (which is in PPM).
-
name: measured-frequency
type: u64
@@ -534,6 +532,8 @@ attribute-sets:
name: operstate
-
name: phase-offset
+ -
+ name: fractional-frequency-offset-ppt
-
name: pin-parent-pin
subset-of: pin
@@ -703,7 +703,6 @@ operations:
- phase-adjust-max
- phase-adjust
- fractional-frequency-offset
- - fractional-frequency-offset-ppt
- esync-frequency
- esync-frequency-supported
- esync-pulse
diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
index 05cf946b4be5e..39b99382be40d 100644
--- a/drivers/dpll/dpll_netlink.c
+++ b/drivers/dpll/dpll_netlink.c
@@ -418,6 +418,27 @@ dpll_msg_add_phase_offset(struct sk_buff *msg, struct dpll_pin *pin,
static int dpll_msg_add_ffo(struct sk_buff *msg, struct dpll_pin *pin,
struct dpll_pin_ref *ref,
struct netlink_ext_ack *extack)
+{
+ const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
+ s64 ffo;
+ int ret;
+
+ if (!ops->ffo_get)
+ return 0;
+ ret = ops->ffo_get(pin, dpll_pin_on_dpll_priv(ref->dpll, pin),
+ NULL, NULL, &ffo, extack);
+ if (ret) {
+ if (ret == -ENODATA)
+ return 0;
+ return ret;
+ }
+ return nla_put_sint(msg, DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET,
+ div_s64(ffo, 1000000));
+}
+
+static int dpll_msg_add_ffo_ppt(struct sk_buff *msg, struct dpll_pin *pin,
+ struct dpll_pin_ref *ref,
+ struct netlink_ext_ack *extack)
{
const struct dpll_pin_ops *ops = dpll_pin_ops(ref);
struct dpll_device *dpll = ref->dpll;
@@ -433,14 +454,8 @@ static int dpll_msg_add_ffo(struct sk_buff *msg, struct dpll_pin *pin,
return 0;
return ret;
}
- /* Put the FFO value in PPM to preserve compatibility with older
- * programs.
- */
- ret = nla_put_sint(msg, DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET,
- div_s64(ffo, 1000000));
- if (ret)
- return -EMSGSIZE;
- return nla_put_sint(msg, DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT,
+ return nla_put_sint(msg,
+ DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT,
ffo);
}
@@ -686,6 +701,9 @@ dpll_msg_add_pin_dplls(struct sk_buff *msg, struct dpll_pin *pin,
if (ret)
goto nest_cancel;
ret = dpll_msg_add_phase_offset(msg, pin, ref, extack);
+ if (ret)
+ goto nest_cancel;
+ ret = dpll_msg_add_ffo_ppt(msg, pin, ref, extack);
if (ret)
goto nest_cancel;
nla_nest_end(msg, attr);
diff --git a/drivers/dpll/dpll_nl.c b/drivers/dpll/dpll_nl.c
index 58235845fa3d5..23108574b8fb4 100644
--- a/drivers/dpll/dpll_nl.c
+++ b/drivers/dpll/dpll_nl.c
@@ -19,6 +19,7 @@ const struct nla_policy dpll_pin_parent_device_nl_policy[DPLL_A_PIN_OPERSTATE +
[DPLL_A_PIN_STATE] = NLA_POLICY_RANGE(NLA_U32, 1, 3),
[DPLL_A_PIN_OPERSTATE] = NLA_POLICY_RANGE(NLA_U32, 1, 4),
[DPLL_A_PIN_PHASE_OFFSET] = { .type = NLA_S64, },
+ [DPLL_A_PIN_FRACTIONAL_FREQUENCY_OFFSET_PPT] = { .type = NLA_SINT, },
};
const struct nla_policy dpll_pin_parent_pin_nl_policy[DPLL_A_PIN_STATE + 1] = {
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index 6fd718696de0d..f2d430d1a8e7b 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -299,6 +299,10 @@ zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
{
struct zl3073x_dpll_pin *pin = pin_priv;
+ /* Only rx vs tx symbol rate FFO is supported */
+ if (dpll)
+ return -ENODATA;
+
*ffo = pin->freq_offset;
return 0;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/dpll.c b/drivers/net/ethernet/mellanox/mlx5/core/dpll.c
index bce72e8d1bc31..ef2c58c390efa 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/dpll.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/dpll.c
@@ -306,6 +306,10 @@ static int mlx5_dpll_ffo_get(const struct dpll_pin *pin, void *pin_priv,
struct mlx5_dpll *mdpll = pin_priv;
int err;
+ /* Only rx vs tx symbol rate FFO is supported */
+ if (dpll)
+ return -ENODATA;
+
err = mlx5_dpll_synce_status_get(mdpll->mdev, &synce_status);
if (err)
return err;
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v2 0/2] dpll: rework fractional frequency offset reporting
From: Ivan Vecera @ 2026-04-30 17:36 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Leon Romanovsky, Mark Bloch, Michal Schmidt, Paolo Abeni,
Pasi Vaananen, Petr Oros, Prathosh Satish, Saeed Mahameed,
Shuah Khan, Simon Horman, Tariq Toukan, Vadim Fedorenko,
linux-doc, linux-kernel, linux-rdma
Rework how the fractional frequency offset (FFO) is reported in
the DPLL subsystem.
The fractional-frequency-offset-ppt attribute is moved from the
top-level pin attributes into the pin-parent-device nested attribute
set. This makes it consistent with phase-offset (which is already
per-parent) and clarifies that FFO PPT represents the frequency
difference between a pin and its parent DPLL device.
The two FFO contexts are distinguished in the ffo_get callback:
dpll=NULL for the top-level RX vs TX symbol rate offset and a valid
dpll pointer for the nested pin vs DPLL offset.
Patch 1 restructures the DPLL subsystem netlink handling, updates
the YAML spec and driver-api documentation, and adds NULL guards
to mlx5 and zl3073x drivers.
Patch 2 implements the nested FFO for zl3073x using the
dpll_df_offset_x register with ref_ofst=1, providing 2^-48
resolution. The old per-reference frequency measurement is removed
as it was redundant with measured-frequency.
Ivan Vecera (2):
dpll: move fractional-frequency-offset-ppt under pin-parent-device
dpll: zl3073x: report FFO as DPLL vs input reference offset
Documentation/driver-api/dpll.rst | 16 +++++++
Documentation/netlink/specs/dpll.yaml | 11 +++--
drivers/dpll/dpll_netlink.c | 34 ++++++++++----
drivers/dpll/dpll_nl.c | 1 +
drivers/dpll/zl3073x/chan.c | 31 ++++++++++++-
drivers/dpll/zl3073x/chan.h | 14 ++++++
drivers/dpll/zl3073x/core.c | 45 -------------------
drivers/dpll/zl3073x/dpll.c | 34 +++++++-------
drivers/dpll/zl3073x/ref.h | 14 ------
drivers/dpll/zl3073x/regs.h | 15 +++++++
.../net/ethernet/mellanox/mlx5/core/dpll.c | 4 ++
11 files changed, 126 insertions(+), 93 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH v4 2/2] hwmon: add MP2985 driver
From: Guenter Roeck @ 2026-04-30 17:18 UTC (permalink / raw)
To: wenswang
Cc: robh, krzk+dt, conor+dt, corbet, skhan, devicetree, linux-kernel,
linux-hwmon, linux-doc
In-Reply-To: <20260414092921.1067735-2-wenswang@yeah.net>
On Tue, Apr 14, 2026 at 05:29:21PM +0800, wenswang@yeah.net wrote:
> From: Wensheng Wang <wenswang@yeah.net>
>
> Add support for MPS mp2985 controller. This driver exposes
> telemetry and limit value readings and writtings.
>
> Signed-off-by: Wensheng Wang <wenswang@yeah.net>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: hwmon: Add MPS mp2985
From: Guenter Roeck @ 2026-04-30 17:17 UTC (permalink / raw)
To: wenswang
Cc: robh, krzk+dt, conor+dt, corbet, skhan, devicetree, linux-kernel,
linux-hwmon, linux-doc, Krzysztof Kozlowski
In-Reply-To: <20260414092921.1067735-1-wenswang@yeah.net>
On Tue, Apr 14, 2026 at 05:29:20PM +0800, wenswang@yeah.net wrote:
> From: Wensheng Wang <wenswang@yeah.net>
>
> Add support for MPS mp2985 controller.
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Wensheng Wang <wenswang@yeah.net>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 09/14] mm/userfaultfd: add RWP fault delivery and expose UFFDIO_REGISTER_MODE_RWP
From: Kiryl Shutsemau @ 2026-04-30 16:51 UTC (permalink / raw)
To: akpm, rppt, peterx, david
Cc: ljs, surenb, vbabka, Liam.Howlett, ziy, corbet, skhan, seanjc,
pbonzini, jthoughton, aarcange, sj, usama.arif, linux-mm,
linux-kernel, linux-doc, linux-kselftest, kvm, kernel-team
In-Reply-To: <20260427114607.4068647-10-kas@kernel.org>
sashiko.dev -- https://sashiko.dev/#/patchset/20260427114607.4068647-1-kas@kernel.org -- wrote:
> Does this code lose the RWP read protection after a page is swapped out
> and back in?
> [ ... ]
> The restored PTE will be PROT_READ with the uffd bit set, instead of
> PROT_NONE. Will this silently allow subsequent read accesses to succeed
> without triggering the required RWP userfault?
The PROT_NONE restoration on swap-in is performed two commits earlier,
in patch 6/14 "mm: preserve RWP marker across PTE rewrites", which
adds to do_swap_page():
if (pte_swp_uffd(vmf->orig_pte) && userfaultfd_rwp(vma))
pte = pte_modify(pte, PAGE_NONE);
so a swapped-in RWP page comes back as PAGE_NONE | _PAGE_UFFD, not
PROT_READ | _PAGE_UFFD. The same patch covers unuse_pte() (the
swapoff(2) path), restore_exclusive_pte(), and the migration-entry
resolvers; each gates on userfaultfd_rwp(vma) and the swap-pte uffd
bit before re-applying PAGE_NONE.
> Can this sequence cause a state collision between RWP and NUMA-hinted
> UFFD_WP pages?
> If a VMA has both VM_UFFD_WP and VM_UFFD_RWP enabled, [ ... ]
No. VM_UFFD_WP and VM_UFFD_RWP are mutually exclusive.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH 08/14] userfaultfd: add UFFDIO_REGISTER_MODE_RWP and UFFDIO_RWPROTECT plumbing
From: Kiryl Shutsemau @ 2026-04-30 16:46 UTC (permalink / raw)
To: akpm, rppt, peterx, david
Cc: ljs, surenb, vbabka, Liam.Howlett, ziy, corbet, skhan, seanjc,
pbonzini, jthoughton, aarcange, sj, usama.arif, linux-mm,
linux-kernel, linux-doc, linux-kselftest, kvm, kernel-team
In-Reply-To: <20260427114607.4068647-9-kas@kernel.org>
sashiko.dev -- https://sashiko.dev/#/patchset/20260427114607.4068647-1-kas@kernel.org -- wrote:
> + if (enable_rwp)
> + mm_cp_flags = MM_CP_UFFD_RWP;
> + else
> + mm_cp_flags = MM_CP_UFFD_RWP_RESOLVE | MM_CP_TRY_CHANGE_WRITABLE;
>
> Does this unconditionally apply MM_CP_TRY_CHANGE_WRITABLE to the entire range?
Confirmed bug. RWP registration does not require VM_WRITE, so
mmap(PROT_READ)
UFFDIO_REGISTER(MODE_RWP)
UFFDIO_RWPROTECT(<range>, disable)
trips WARN_ON_ONCE(!(vma->vm_flags & VM_WRITE)) inside
maybe_change_pte_writable() on resolve.
The flag belongs inside the iteration, gated on
vma_wants_manual_pte_write_upgrade(vma), matching mwriteprotect_range()
(mm/userfaultfd.c:1003) and userfaultfd_clear_vma() (mm/userfaultfd.c:2182):
for_each_vma_range(vmi, dst_vma, end) {
unsigned long vma_start = max(dst_vma->vm_start, start);
unsigned long vma_end = min(dst_vma->vm_end, end);
unsigned int flags = mm_cp_flags;
if (!enable_rwp && vma_wants_manual_pte_write_upgrade(dst_vma))
flags |= MM_CP_TRY_CHANGE_WRITABLE;
change_protection(&tlb, dst_vma, vma_start, vma_end, flags);
}
Will fold for v2.
> Since change_protection() walks and modifies page tables here, does this
> need to call vma_start_write(vma) first?
No.
This is the same locking pattern as the pre-existing uffd_wp_range() call
that the hunk replaces -- mmap_write_lock without vma_start_write(), which
remains safe for the same reasons:
- mmap_write_lock excludes anything taking mmap_read_lock, including
MADV_DONTNEED and the other PTE-page-freeing paths (try_to_free_pte()
runs under mmap_read_lock + per-VMA locking, never standalone).
- The remaining concurrent reader is the per-VMA-locked page fault
(lock_vma_under_rcu()), which walks PTEs under the PTE lock.
change_protection() also takes the PTE lock when updating, so the
two serialise. A fault that observes a transient pre-resolve PTE
just produces a normal fault delivery and resolves correctly.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Arnaud POULIQUEN @ 2026-04-30 16:40 UTC (permalink / raw)
To: Beleswar Prasad Padhi, Mathieu Poirier
Cc: Shenwei Wang, Andrew Lunn, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Frank Li, Sascha Hauer, Shuah Khan,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski
In-Reply-To: <21de8440-adf7-454b-acfc-06e50882e075@ti.com>
On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
> Hello Arnaud,
>
> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>> Hello,
>>
>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>
>>>> Hi Mathieu,
>>>>
>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>> GPIO driver
>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>> __u8 status;
>>>>>>>>>>> __u8 value;
>>>>>>>>>>> };
>>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>
>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>> + | 1 | 2 |port |line | err | dir|
>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
>>>>>>>>>
>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>
>>>>>>>> Virtio uses two communication channels (virtqueues): one for requests and
>>>>>>> replies, and a second one for events.
>>>>>>>> In contrast, rpmsg provides only a single communication channel, so a
>>>>>>>> type field is required to distinguish between different kinds of messages.
>>>>>>>>
>>>>>>>> Since rpmsg replies and events share the same message format, an additional
>>>>>>> line is introduced to handle both cases.
>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
>>>>>>> uniquely identify the target controller.
>>>>>>>
>>>>>>> I have commented on this before - RPMSG is already providing multiplexing
>>>>>>> capability by way of endpoints. There is no need for a port field. One endpoint,
>>>>>>> one GPIO controller.
>>>>>>>
>>>>>> You still need a way to let the remote side know which port the endpoint maps to, either
>>>>>> by embedding the port information in the message (the current way), or by sending it
>>>>>> separately.
>>>>>>
>>>>> An endpoint is created with every namespace request. There should be
>>>>> one namespace request for every GPIO controller, which yields a unique
>>>>> endpoint for each controller and eliminates the need for an extra
>>>>> field to identify them.
>>>>
>>>>
>>>> Right, but this can still be done by just having one namespace request.
>>>> We can create new endpoints bound to an existing namespace/channel by
>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>> https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daaeec@ti.com/
>>>>
>>>
>>> I will look at your suggestion (i.e link above) later this week or next week.
>>>
>>>> My mental model looks like this for the complete picture:
>>>>
>>>> 1. namespace/channel#1 = rpmsg-io
>>>> a. ept1 -> gpio-controller@1
>>>> b. ept2 -> gpio-controller@2
>>>>
>>>
>>> I've asked for one endpoint per GPIO controller since the very
>>> beginning. I don't yet have a strong opinion on whether to use one
>>> namespace request per GPIO controller or a single request that spins
>>> off multiple endpoints. I'll have to look at your link and reflect on
>>> that. Regardless of how we proceed on that front, multiplexing needs
>>> to happen at the endpoint level rather than the packet level. This is
>>> the only way this work can move forward.
>>>
>>
>> I would be more in favor of Mathieu’s proposal: “An endpoint is created with every namespace request.”
>>
>> If the endpoint is created only on the Linux side, how do we match the Linux endpoint address with the local port field on the remote side?
>
>
> Simply by sending a message to the remote containing the newly created
> endpoint and the port idx. Note that is this done just one time, after this
> Linux need not have the port field in the message everytime its sending
> a message.
>
>>
>> With a multi-namespace approach, the namespace could be rpmsg-io-[addr], where [addr] corresponds to the GPIO controller address in the DT. This would:
>
>
> You will face the same problem in this case also that you asked above:
> "how do we match the Linux endpoint address with the local port field
> on the remote side?"
Sorry I probably introduced confusion here
my sentence should be;
With a multi-namespace approach, the namespace could be rpmsg-io-[port],
where [port] corresponds to the GPIO controller port in the DT.
For instance:
rpmsg {
rpmsg-io {
#address-cells = <1>;
#size-cells = <0>;
gpio@25 {
compatible = "rpmsg-gpio";
reg = <25>;
gpio-controller;
#gpio-cells = <2>;
#interrupt-cells = <2>;
interrupt-controller;
};
gpio@32 {
compatible = "rpmsg-gpio";
reg = <32>;
gpio-controller;
#gpio-cells = <2>;
#interrupt-cells = <2>;
interrupt-controller;
};
};
};
rpmsg-io-25 would match with gpio@25
rpmsg-io-32 would match with gpio@32
>
> Because the endpoint that is created on a namespace request is also
> dynamic in nature. How will the remote know which endpoint addr
> Linux allocated for a namespace that it announced?
>
> As an example/PoC, I created a firmware example which announces
> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
> the other is a TI specific name service "ti.ipc4.ping-pong". You can
> see it created 2 different addresses (0x400 and 0x401) for each of
> the name service request from the same firmware:
>
> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
> [ 9.290275] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xd
> [ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
> [ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel formed from src = 0x400 to dst = 0xe
> [ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new channel: 0x401 -> 0xd!
>
> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
> Back to same problem. Simple solution is to reply to remote with the
> created ept addr and the index.
That why I would like to suggest to use the name service field to
identify the port/controller, instead of the endpoint address.
>
>
>>
>> - match the RPMsg probe with the DT,
>
>
> We can probe from all controllers with a single name service
> announcement too.
>
>> - provide a simple mapping between the port and the endpoint on both sides,
>
>
> We are trying to get rid of this mapping from Linux side to adapt
> the gpio-virtio design.
>
>> - allow multiple endpoints on the remote side,
>
>
> We can support this as well with single nameservice model.
> There is no limitation. Remote has to send a message with
> its newly created ept that's all.
>
>> - provide a simple discovery mechanism for remote capabilities.
>
>
> A single announcement: "rpmsg-io" is also discovery mechanism.
>
> Feel free to let me know if you have concerns with any of the
> suggestions!
My only concern, whatever the solution, is that we find a smart
solution to associate the correct endpoint with the correct GPIO
port/controller defined in the DT.
I may have misunderstood your solution. Could you please help me
understand your proposal by explaining how you would handle three
GPIO ports defined in the DT, considering that the endpoint
addresses on the Linux side can be random?
If I assume there is a unique endpoint on the remote side,
I do not understand how you can match, on the firmware side,
the Linux endpoint address to the GPIO port.
Thanks and Regards,Arnaud
>
> Thanks,
> Beleswar
>
>>
>> Regards,
>> Arnaud
>>
>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>> a. ept1 -> i2c@1
>>>> b. ept2 -> i2c@2
>>>> c. ept3 -> i2c@3
>>>>
>>>> etc...
>>>>
>>>> This way device groups are isolated with each channel/namespace, and
>>>> instances within each device groups are also respected with specific
>>>> endpoints.
>>>>
>>>> Thanks,
>>>> Beleswar
>>>>
>>>
>>
^ permalink raw reply
* Re: [PATCH 07/14] mm: handle VM_UFFD_RWP in khugepaged, rmap, and GUP
From: Kiryl Shutsemau @ 2026-04-30 16:31 UTC (permalink / raw)
To: akpm, rppt, peterx, david
Cc: ljs, surenb, vbabka, Liam.Howlett, ziy, corbet, skhan, seanjc,
pbonzini, jthoughton, aarcange, sj, usama.arif, linux-mm,
linux-kernel, linux-doc, linux-kselftest, kvm, kernel-team
In-Reply-To: <afOCAZ-dTQiLFN0y@thinkstation>
On Thu, Apr 30, 2026 at 05:28:17PM +0100, Kiryl Shutsemau wrote:
> sashiko.dev -- https://sashiko.dev/#/patchset/20260427114607.4068647-1-kas@kernel.org -- wrote:
> > > @@ -1084,9 +1092,29 @@ static __always_inline void __copy_present_ptes(struct vm_area_struct *dst_vma,
> > > pte_t pte, unsigned long addr, int nr)
> > > {
> > > struct mm_struct *src_mm = src_vma->vm_mm;
> > > + bool writable;
> > > +
> > > + /*
> > > + * Snapshot writability before the RWP-disarm rewrite below: when the
> > > + * child is not RWP-armed, pte_modify(pte, dst_vma->vm_page_prot) can
> > > + * silently drop _PAGE_RW from a resolved (no-marker) writable PTE,
> > > + * so a later pte_write(pte) check would skip the COW wrprotect and
> > > + * leave the parent writable over a folio shared with the child.
> > > + */
> > > + writable = pte_write(pte);
> > > +
> > > + /*
> > > + * Child is not RWP-armed: restore accessible protection so the
> > > + * inherited PAGE_NONE does not cost a fault on first read.
> > > + */
> > > + if (!userfaultfd_protected(dst_vma)) {
> > > + if (userfaultfd_rwp(src_vma))
> > > + pte = pte_modify(pte, dst_vma->vm_page_prot);
> > > + pte = pte_clear_uffd(pte);
> > > + }
> > Does this unconditional pte_modify() create invalid clean and writable PTEs
> > for shared mappings?
> >
> > Without checking pte_uffd(pte) first, this blindly modifies every present PTE
> > if the source VMA had RWP enabled. For shared writable mappings, vm_page_prot
> > includes _PAGE_RW. If a PTE was clean and mapped read-only to intercept the
> > first write for filesystem dirty-tracking, pte_modify() forces the write bit
> > on while preserving the clean state.
>
> Two reasons this is safe in practice:
>
> 1. RWP cannot reach a backing that uses the clean-RO + page_mkwrite()
> dirty-tracking pattern. vma_can_userfault() admits RWP only on anon,
> shmem and hugetlbfs (the ones with vm_uffd_ops); regular file-backed
> shared mappings are rejected at register time.
>
> 2. For backings that *do* support shared writable + dirty tracking (i.e.
> the ones RWP isn't enabled on), the fs sets vma->vm_page_prot to RO
> precisely so the first write traps page_mkwrite(). pte_modify(pte,
> dst_vma->vm_page_prot) would not add _PAGE_RW in that configuration
> either.
>
> > Hardware writes could then bypass page_mkwrite(), leaving the filesystem
> > unaware that the page is dirty, and potentially causing silent data loss
> > upon reclaim.
> > Could this also overwrite other important PTE states like NUMA hinting
> > or soft-dirty tracking?
>
> pte_modify() on the supported architectures preserves _PAGE_CHG_MASK,
> which covers _PAGE_DIRTY, _PAGE_ACCESSED, _PAGE_SOFT_DIRTY, and the PFN.
> NUMA hinting is encoded in the protection bits, so a transient hint
> state on a resolved (no-marker) PTE would be lost across this rewrite,
> but that's just a re-prime on the next NUMA scan, not a correctness
> issue.
>
> > @@ -298,6 +298,16 @@ static __always_inline void change_present_ptes(struct mmu_gather *tlb,
> > else if (uffd_wp_resolve || uffd_rwp_resolve)
> > ptent = pte_clear_uffd(ptent);
> >
> > + /*
> > + * The uffd bit on a VM_UFFD_RWP VMA carries PROT_NONE
> > + * semantics. If mprotect() or NUMA hinting changed the
> > + * base protection, restore PAGE_NONE so the PTE still
> > + * traps on any access. pte_modify() preserves
> > + * _PAGE_UFFD.
> > + */
> > + if (userfaultfd_rwp(vma) && pte_uffd(ptent))
> > + ptent = pte_modify(ptent, PAGE_NONE);
> >
> > For VMAs registered with both UFFD WP and RWP, could this silently upgrade
> > Write-Protected pages to Read-Write-Protected?
>
> VM_UFFD_WP and VM_UFFD_RWP are mutually exclusive per VMA. The combination
> is rejected at registration time:
>
> fs/userfaultfd.c, userfaultfd_register():
> if ((vm_flags & VM_UFFD_WP) && (vm_flags & VM_UFFD_RWP))
> goto out; /* -EINVAL */
>
> and re-registration cannot drop either bit (also -EBUSY in the same
> function), so a PTE in a WP-armed VMA can never satisfy
> userfaultfd_rwp(vma); the new branch never fires there.
>
> [ ... ]
> > + /* Re-arm RWP on the moved PTE if dst_vma is RWP-registered. */
> > + if (userfaultfd_rwp(dst_vma)) {
> > + orig_dst_pte = pte_modify(orig_dst_pte, PAGE_NONE);
> > + orig_dst_pte = pte_mkuffd(orig_dst_pte);
> > + }
> > +
> > set_pte_at(mm, dst_addr, dst_pte, orig_dst_pte);
> >
> > Could applying PAGE_NONE unconditionally to newly moved pages trap
> > applications in an infinite fault loop?
>
> No -- the post-MOVE access is delivered as a normal RWP fault. In sync
> mode it goes to the registered handler, which resolves it with
> UFFDIO_RWPROTECT clearing MODE_RWP; in async mode the kernel resolves
> it in-kernel and the faulting thread continues. There is no loop.
>
> The semantics here are intentional: a VM_UFFD_RWP VMA has the contract
> that every present PTE is either an active marker or a tracked-and-
> resolved PTE whose next access will re-trap. UFFDIO_MOVE into such a
> VMA must keep that contract, otherwise the moved-in page would be a
> silent hole in the working-set view. UFFDIO_MOVE has no mode flag for
> "skip protection", by design -- the same way it has no flag to skip
> WP arming if dst_vma were WP-armed (and the equivalent could be added
> there if we ever decide UFFDIO_MOVE should preserve markers in WP
> VMAs too).
>
Oopsie.
I put it in reply to the wrong patch. It suppose to be for 06/14.
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH 07/14] mm: handle VM_UFFD_RWP in khugepaged, rmap, and GUP
From: Kiryl Shutsemau @ 2026-04-30 16:28 UTC (permalink / raw)
To: akpm, rppt, peterx, david
Cc: ljs, surenb, vbabka, Liam.Howlett, ziy, corbet, skhan, seanjc,
pbonzini, jthoughton, aarcange, sj, usama.arif, linux-mm,
linux-kernel, linux-doc, linux-kselftest, kvm, kernel-team
In-Reply-To: <20260427114607.4068647-8-kas@kernel.org>
sashiko.dev -- https://sashiko.dev/#/patchset/20260427114607.4068647-1-kas@kernel.org -- wrote:
> > @@ -1084,9 +1092,29 @@ static __always_inline void __copy_present_ptes(struct vm_area_struct *dst_vma,
> > pte_t pte, unsigned long addr, int nr)
> > {
> > struct mm_struct *src_mm = src_vma->vm_mm;
> > + bool writable;
> > +
> > + /*
> > + * Snapshot writability before the RWP-disarm rewrite below: when the
> > + * child is not RWP-armed, pte_modify(pte, dst_vma->vm_page_prot) can
> > + * silently drop _PAGE_RW from a resolved (no-marker) writable PTE,
> > + * so a later pte_write(pte) check would skip the COW wrprotect and
> > + * leave the parent writable over a folio shared with the child.
> > + */
> > + writable = pte_write(pte);
> > +
> > + /*
> > + * Child is not RWP-armed: restore accessible protection so the
> > + * inherited PAGE_NONE does not cost a fault on first read.
> > + */
> > + if (!userfaultfd_protected(dst_vma)) {
> > + if (userfaultfd_rwp(src_vma))
> > + pte = pte_modify(pte, dst_vma->vm_page_prot);
> > + pte = pte_clear_uffd(pte);
> > + }
> Does this unconditional pte_modify() create invalid clean and writable PTEs
> for shared mappings?
>
> Without checking pte_uffd(pte) first, this blindly modifies every present PTE
> if the source VMA had RWP enabled. For shared writable mappings, vm_page_prot
> includes _PAGE_RW. If a PTE was clean and mapped read-only to intercept the
> first write for filesystem dirty-tracking, pte_modify() forces the write bit
> on while preserving the clean state.
Two reasons this is safe in practice:
1. RWP cannot reach a backing that uses the clean-RO + page_mkwrite()
dirty-tracking pattern. vma_can_userfault() admits RWP only on anon,
shmem and hugetlbfs (the ones with vm_uffd_ops); regular file-backed
shared mappings are rejected at register time.
2. For backings that *do* support shared writable + dirty tracking (i.e.
the ones RWP isn't enabled on), the fs sets vma->vm_page_prot to RO
precisely so the first write traps page_mkwrite(). pte_modify(pte,
dst_vma->vm_page_prot) would not add _PAGE_RW in that configuration
either.
> Hardware writes could then bypass page_mkwrite(), leaving the filesystem
> unaware that the page is dirty, and potentially causing silent data loss
> upon reclaim.
> Could this also overwrite other important PTE states like NUMA hinting
> or soft-dirty tracking?
pte_modify() on the supported architectures preserves _PAGE_CHG_MASK,
which covers _PAGE_DIRTY, _PAGE_ACCESSED, _PAGE_SOFT_DIRTY, and the PFN.
NUMA hinting is encoded in the protection bits, so a transient hint
state on a resolved (no-marker) PTE would be lost across this rewrite,
but that's just a re-prime on the next NUMA scan, not a correctness
issue.
> @@ -298,6 +298,16 @@ static __always_inline void change_present_ptes(struct mmu_gather *tlb,
> else if (uffd_wp_resolve || uffd_rwp_resolve)
> ptent = pte_clear_uffd(ptent);
>
> + /*
> + * The uffd bit on a VM_UFFD_RWP VMA carries PROT_NONE
> + * semantics. If mprotect() or NUMA hinting changed the
> + * base protection, restore PAGE_NONE so the PTE still
> + * traps on any access. pte_modify() preserves
> + * _PAGE_UFFD.
> + */
> + if (userfaultfd_rwp(vma) && pte_uffd(ptent))
> + ptent = pte_modify(ptent, PAGE_NONE);
>
> For VMAs registered with both UFFD WP and RWP, could this silently upgrade
> Write-Protected pages to Read-Write-Protected?
VM_UFFD_WP and VM_UFFD_RWP are mutually exclusive per VMA. The combination
is rejected at registration time:
fs/userfaultfd.c, userfaultfd_register():
if ((vm_flags & VM_UFFD_WP) && (vm_flags & VM_UFFD_RWP))
goto out; /* -EINVAL */
and re-registration cannot drop either bit (also -EBUSY in the same
function), so a PTE in a WP-armed VMA can never satisfy
userfaultfd_rwp(vma); the new branch never fires there.
[ ... ]
> + /* Re-arm RWP on the moved PTE if dst_vma is RWP-registered. */
> + if (userfaultfd_rwp(dst_vma)) {
> + orig_dst_pte = pte_modify(orig_dst_pte, PAGE_NONE);
> + orig_dst_pte = pte_mkuffd(orig_dst_pte);
> + }
> +
> set_pte_at(mm, dst_addr, dst_pte, orig_dst_pte);
>
> Could applying PAGE_NONE unconditionally to newly moved pages trap
> applications in an infinite fault loop?
No -- the post-MOVE access is delivered as a normal RWP fault. In sync
mode it goes to the registered handler, which resolves it with
UFFDIO_RWPROTECT clearing MODE_RWP; in async mode the kernel resolves
it in-kernel and the faulting thread continues. There is no loop.
The semantics here are intentional: a VM_UFFD_RWP VMA has the contract
that every present PTE is either an active marker or a tracked-and-
resolved PTE whose next access will re-trap. UFFDIO_MOVE into such a
VMA must keep that contract, otherwise the moved-in page would be a
silent hole in the working-set view. UFFDIO_MOVE has no mode flag for
"skip protection", by design -- the same way it has no flag to skip
WP arming if dst_vma were WP-armed (and the equivalent could be added
there if we ever decide UFFDIO_MOVE should preserve markers in WP
VMAs too).
--
Kiryl Shutsemau / Kirill A. Shutemov
^ permalink raw reply
* Re: [PATCH] docs: improve formatting and readability of the main README
From: Jonathan Corbet @ 2026-04-30 16:02 UTC (permalink / raw)
To: Darío Ortega Leyva, linux-doc; +Cc: linux-kernel
In-Reply-To: <b0f3ab39-ae35-4a4b-9333-29d78ca58a15@gmail.com>
Darío Ortega Leyva <darioortegaleyva@gmail.com> writes:
> Restructured the main documentation file to use standard Markdown
> headings instead of underlines for better rendering. Added anchor links
> to the "Who Are You?" section to improve navigability for new readers,
> and highlighted the AI Assistant warning for better visibility.
Kernel documentation is in RST format, not Markdown.
jon
^ permalink raw reply
* Re: [RFC PATCH net-next 0/3] netns: optionally inherit IPv4 TCP sysctls from old net
From: Nicolas Dichtel @ 2026-04-30 15:44 UTC (permalink / raw)
To: nmreadelf, davem, edumazet, kuba, pabeni, corbet, dsahern
Cc: horms, chia-yu.chang, idosch, ij, brauner, jack, kuniyu, jlayton,
netdev, linux-doc, linux-kernel, lance.yang, leon.hwang
In-Reply-To: <TY7PR01MB172057C053E8D550485A29A08E0352@TY7PR01MB17205.jpnprd01.prod.outlook.com>
Le 30/04/2026 à 03:30, nmreadelf a écrit :
> a new network namespace starts with built-in TCP defaults.
> In container-heavy setups, operators often tune TCP sysctls in init_net and then
> need to re-apply the same values for each new netns.
>
> This series adds an opt-in mechanism to initialize per-netns IPv4 TCP sysctl
> settings from init_net at netns creation time.
>
> Behavior:
>
> Default is unchanged.
> When net.ipv4.netns_inherit_tcp_sysctls=1, new netns inherit
> TCP sysctl from old_net.
There is the same kind of sysctl for net.{ipv4,ipv6}.conf.{all,default}.*:
net.core.devconf_inherit_init_net.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/sysctl/net.rst#n401
I'm not sure if it's acceptable to use this existing entry to control the TCP
sysctl.
At least, putting the new one in the same place + using the same template for
the name + the same values would be nice. Something like
net.core.tcp_inherit_init_net.
Regards,
Nicolas
^ permalink raw reply
* Re: [PATCH net-next 0/2] dpll: rework fractional frequency offset reporting
From: Ivan Vecera @ 2026-04-30 14:58 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Leon Romanovsky, Mark Bloch, Michal Schmidt, Paolo Abeni,
Pasi Vaananen, Petr Oros, Prathosh Satish, Saeed Mahameed,
Shuah Khan, Simon Horman, Tariq Toukan, Vadim Fedorenko,
linux-doc, linux-kernel, linux-rdma
In-Reply-To: <20260429150817.3059763-1-ivecera@redhat.com>
On 4/29/26 5:08 PM, Ivan Vecera wrote:
> Rework how the fractional frequency offset (FFO) is reported in
> the DPLL subsystem.
>
> The fractional-frequency-offset-ppt attribute is moved from the
> top-level pin attributes into the pin-parent-device nested attribute
> set. This makes it consistent with phase-offset (which is already
> per-parent) and clarifies that FFO PPT represents the frequency
> difference between a pin and its parent DPLL device.
>
> The two FFO contexts are distinguished in the ffo_get callback:
> dpll=NULL for the top-level RX vs TX symbol rate offset and a valid
> dpll pointer for the nested pin vs DPLL offset.
>
> Patch 1 restructures the DPLL subsystem netlink handling, updates
> the YAML spec and driver-api documentation, and adds NULL guards
> to mlx5 and zl3073x drivers.
>
> Patch 2 implements the nested FFO for zl3073x using the
> dpll_df_offset_x register with ref_ofst=1, providing 2^-48
> resolution. The old per-reference frequency measurement is removed
> as it was redundant with measured-frequency.
>
> Ivan Vecera (2):
> dpll: move fractional-frequency-offset-ppt under pin-parent-device
> dpll: zl3073x: report FFO as DPLL vs input reference offset
>
> Documentation/driver-api/dpll.rst | 16 +++++++
> Documentation/netlink/specs/dpll.yaml | 11 +++--
> drivers/dpll/dpll_netlink.c | 34 ++++++++++----
> drivers/dpll/dpll_nl.c | 1 +
> drivers/dpll/zl3073x/chan.c | 31 ++++++++++++-
> drivers/dpll/zl3073x/chan.h | 14 ++++++
> drivers/dpll/zl3073x/core.c | 45 -------------------
> drivers/dpll/zl3073x/dpll.c | 34 +++++++-------
> drivers/dpll/zl3073x/ref.h | 14 ------
> drivers/dpll/zl3073x/regs.h | 15 +++++++
> .../net/ethernet/mellanox/mlx5/core/dpll.c | 4 ++
> 11 files changed, 126 insertions(+), 93 deletions(-)
After merge of "dpll: add pin operational state" this needs to be rebased...
Will send v2.
I.
^ permalink raw reply
* Re: [PATCH v3 2/9] kernel/api: enable kerneldoc-based API specifications
From: Nicolas Schier @ 2026-04-30 14:47 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E . McKenney, Greg Kroah-Hartman, Jonathan Corbet,
Dmitry Vyukov, Randy Dunlap, Cyril Hrubis, Kees Cook, Jake Edge,
David Laight, Askar Safin, Gabriele Paoloni,
Mauro Carvalho Chehab, Christian Brauner, Alexander Viro,
Andrew Morton, Masahiro Yamada, Shuah Khan, Ingo Molnar,
Arnd Bergmann
In-Reply-To: <20260424165130.2306833-3-sashal@kernel.org>
On Fri, Apr 24, 2026 at 12:51:22PM -0400, Sasha Levin wrote:
> This patch adds support for extracting API specifications from
> kernel-doc comments and generating C macro invocations for the
> kernel API specification framework.
>
> Changes include:
> - New kdoc_apispec.py module for generating API spec macros
> - Updates to kernel-doc.py to support -apispec output format
> - Build system integration in Makefile.build
> - Generator script for collecting all API specifications
> - Support for API-specific sections in kernel-doc comments
>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
> Documentation/dev-tools/kernel-api-spec.rst | 11 +
> scripts/Makefile.build | 31 +
> scripts/Makefile.clean | 3 +
> tools/docs/kernel-doc | 5 +
> tools/lib/python/kdoc/kdoc_apispec.py | 1249 +++++++++++++++++++
> tools/lib/python/kdoc/kdoc_output.py | 9 +-
> tools/lib/python/kdoc/kdoc_parser.py | 86 +-
> 7 files changed, 1389 insertions(+), 5 deletions(-)
> create mode 100644 tools/lib/python/kdoc/kdoc_apispec.py
>
> diff --git a/Documentation/dev-tools/kernel-api-spec.rst b/Documentation/dev-tools/kernel-api-spec.rst
> index 395c2294d5209..479bc78797ba8 100644
> --- a/Documentation/dev-tools/kernel-api-spec.rst
> +++ b/Documentation/dev-tools/kernel-api-spec.rst
> @@ -239,6 +239,17 @@ execution context, and return values. Parameter violations are reported via
> ``pr_warn_ratelimited`` and return value violations via ``WARN_ONCE`` to avoid
> flooding the kernel log.
>
> +.. warning::
> +
> + Userspace errno is affected when this option is on. For syscalls that
> + violate their parameter specification, KAPI short-circuits the call and
> + returns ``-EINVAL`` from the validator **before** the real handler runs.
> + That errno can differ from what the real handler would have produced for
> + the same condition (for example, ``-ENOMEM`` from an allocation path or
> + ``-EFAULT`` from a deeper copy-in). ``CONFIG_KAPI_RUNTIME_CHECKS`` is a
> + debug-only option; do not enable it on production kernels or in
> + userspace-visible test environments where error-code fidelity matters.
> +
> Custom Validators
> -----------------
>
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index 3652b85be5459..ef203e490c797 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -174,6 +174,37 @@ ifneq ($(KBUILD_EXTRA_WARN),)
> endif
> endif
>
> +# Generate API spec headers from kernel-doc comments
> +ifeq ($(CONFIG_KAPI_SPEC),y)
> +# Function to check if a file has API specifications
> +has-apispec = $(shell grep -qE '^\s*\*\s*context-flags:' $(src)/$(1) 2>/dev/null && echo $(1))
> +
> +# Get base names without directory prefix
> +c-objs-base := $(notdir $(real-obj-y) $(real-obj-m))
> +# Filter to only .o files with corresponding .c source files
> +c-files := $(foreach o,$(c-objs-base),$(if $(wildcard $(src)/$(o:.o=.c)),$(o:.o=.c)))
Looks to me as if the two lines above are redundant, since 'find'
(below) will find all files gathered in $(c-files).
> +# Also check for any additional .c files that contain API specs but are included
> +extra-c-files := $(shell find $(src) -maxdepth 1 -name "*.c" -exec grep -l '^\s*\*\s*\(long-desc\|context-flags\|state-trans\):' {} \; 2>/dev/null | xargs -r basename -a)
> +# Combine both lists and remove duplicates
> +all-c-files := $(sort $(c-files) $(extra-c-files))
> +# Only include files that actually have API specifications
> +apispec-files := $(foreach f,$(all-c-files),$(call has-apispec,$(f)))
> +# Generate apispec targets with proper directory prefix
> +apispec-y := $(addprefix $(obj)/,$(apispec-files:.c=.apispec.h))
To goal is to find any relevant C file in $(src)/ (but not deeper below)
that holds KAPI documentation, right?
I do not like the find call, as it picks up anything. Might it make
sense to evaluate $(obj-) along with $(obj-y) and $(obj-m) to pick up
all C files that are references in kbuild?
# in top definition block -- before 'include $(kbuild-file)' et al.
obj- :=
# below the definitions of real-obj-{y,m}
real-obj-any := $(call real-search, $(obj-y) $(obj-m) $(obj-), .o, -objs -y -m -)
has-apispec = $(shell grep -lE '^\s*\*\s*context-flags:' $(1) 2>/dev/null)
apispec-y := $(patsubst $(src)/%.c, $(obj)/%.apispec.h, $(call has-apispec,
$(patsubst $(obj)/%.o, $(src)/%.c, $(real-obj-any))))
#...
# Source files that include their own apispec.h need to depend on it
$(apispec-y:.apispec.h=.o): $(obj)/%.o: $(obj)/%.apispec.h
(untested)
> +always-y += $(apispec-y)
> +targets += $(apispec-y)
> +
> +quiet_cmd_apispec = APISPEC $@
> + cmd_apispec = PYTHONDONTWRITEBYTECODE=1 $(KERNELDOC) -apispec \
> + $(KDOCFLAGS) $< > $@ || rm -f $@
> +
> +$(obj)/%.apispec.h: $(src)/%.c $(KERNELDOC) FORCE
> + $(call if_changed,apispec)
> +
> +# Source files that include their own apispec.h need to depend on it
> +$(foreach f,$(apispec-files),$(eval $(obj)/$(f:.c=.o): $(obj)/$(f:.c=.apispec.h)))
> +endif
> +
> # Compile C sources (.c)
> # ---------------------------------------------------------------------------
>
> diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean
> index 6ead00ec7313b..f78dbbe637f27 100644
> --- a/scripts/Makefile.clean
> +++ b/scripts/Makefile.clean
> @@ -35,6 +35,9 @@ __clean-files := $(filter-out $(no-clean-files), $(__clean-files))
>
> __clean-files := $(wildcard $(addprefix $(obj)/, $(__clean-files)))
>
> +# Also clean generated apispec headers (computed dynamically in Makefile.build)
> +__clean-files += $(wildcard $(obj)/*.apispec.h)
We have a list of wildcard clean patterns in top-level Makefile
(line 2114 ff.); please add '*.apispec.h' there instead.
When I apply the series on top of v7.1, compilation fails with
../fs/open.c:2148:10: fatal error: open.apispec.h: No such file or directory
../fs/read_write.c:2519:10: fatal error: read_write.apispec.h: No such file or directory
Kind regards,
Nicolas
^ permalink raw reply
* Re: [PATCH v3 1/9] kernel/api: introduce kernel API specification framework
From: Nicolas Schier @ 2026-04-29 16:43 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E . McKenney, Greg Kroah-Hartman, Jonathan Corbet,
Dmitry Vyukov, Randy Dunlap, Cyril Hrubis, Kees Cook, Jake Edge,
David Laight, Askar Safin, Gabriele Paoloni,
Mauro Carvalho Chehab, Christian Brauner, Alexander Viro,
Andrew Morton, Masahiro Yamada, Shuah Khan, Ingo Molnar,
Arnd Bergmann
In-Reply-To: <20260424165130.2306833-2-sashal@kernel.org>
On Fri, Apr 24, 2026 at 12:51:21PM -0400, Sasha Levin wrote:
...
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 6785982013dce..5643151536439 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -59,6 +59,9 @@ obj-y += dma/
> obj-y += entry/
> obj-y += unwind/
> obj-$(CONFIG_MODULES) += module/
> +obj-$(CONFIG_KAPI_SPEC) += api/
> +# Ensure api/ is always cleaned even when CONFIG_KAPI_SPEC is not set
> +obj- += api/
>
> obj-$(CONFIG_KCMP) += kcmp.o
...
> diff --git a/kernel/api/Makefile b/kernel/api/Makefile
> new file mode 100644
> index 0000000000000..c0a13fc590e4a
> --- /dev/null
> +++ b/kernel/api/Makefile
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0
> +#
> +# Makefile for the Kernel API Specification Framework
> +#
> +
> +# Core API specification framework
> +obj-$(CONFIG_KAPI_SPEC) += kernel_api_spec.o
Bike-shedding: I'd use 'obj-y' here, to state clearly that
kernel_api_spec.c is the core part in the kernel/api/ subdir. If
CONFIG_KAPI_SPEC is unset, the subfir will not be entered at all.
--
Nicolas
^ permalink raw reply
* Re: [PATCH v3 1/9] kernel/api: introduce kernel API specification framework
From: Nicolas Schier @ 2026-04-29 16:32 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Sasha Levin, linux-api, linux-kernel, linux-doc, linux-fsdevel,
linux-kbuild, linux-kselftest, workflows, tools, x86,
Thomas Gleixner, Paul E . McKenney, Greg Kroah-Hartman,
Jonathan Corbet, Dmitry Vyukov, Randy Dunlap, Cyril Hrubis,
Kees Cook, Jake Edge, David Laight, Askar Safin, Gabriele Paoloni,
Mauro Carvalho Chehab, Christian Brauner, Alexander Viro,
Andrew Morton, Masahiro Yamada, Shuah Khan, Ingo Molnar,
Arnd Bergmann
In-Reply-To: <177726106581.2478607.12645653803520391071.b4-review@b4>
On Sun, Apr 26, 2026 at 11:37:45PM -0400, Nathan Chancellor wrote:
> On Fri, 24 Apr 2026 12:51:21 -0400, Sasha Levin <sashal@kernel.org> wrote:
> > diff --git a/kernel/Makefile b/kernel/Makefile
> > index 6785982013dc..564315153643 100644
> > --- a/kernel/Makefile
> > +++ b/kernel/Makefile
> > @@ -59,6 +59,9 @@ obj-y += dma/
> > obj-y += entry/
> > obj-y += unwind/
> > obj-$(CONFIG_MODULES) += module/
> > +obj-$(CONFIG_KAPI_SPEC) += api/
> > +# Ensure api/ is always cleaned even when CONFIG_KAPI_SPEC is not set
> > +obj- += api/
>
> If $(CONFIG_KAPI_SPEC) is not set, shouldn't
>
> obj-$(CONFIG_KAPI_SPEC) += api/
>
> evaluate to
>
> obj- += api/
>
> anyways? Why the duplication? This is the only place in the kernel where
> this would be needed?
yes, this is definitely not needed, as obj- is always evaluated during
'make clean', cp. scripts/Makefile.clean [1].
Kind regards
Nicolas
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.clean?h=v7.1-rc1#n30
^ permalink raw reply
* Re: [PATCH net-next 0/2] dpll: add pin operational state
From: patchwork-bot+netdevbpf @ 2026-04-30 14:30 UTC (permalink / raw)
To: Ivan Vecera
Cc: netdev, arkadiusz.kubalewski, davem, donald.hunter, edumazet,
kuba, jiri, corbet, mschmidt, pabeni, pvaanane, poros,
Prathosh.Satish, skhan, horms, vadim.fedorenko, linux-doc,
linux-kernel
In-Reply-To: <20260428154907.2820654-1-ivecera@redhat.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Tue, 28 Apr 2026 17:49:05 +0200 you wrote:
> Add pin operational state (operstate) to the DPLL subsystem to
> separate administrative intent from actual hardware status.
>
> Currently pin-state mixes what the user requested (connected,
> selectable, disconnected) with what the hardware is actually doing.
> This makes it difficult to diagnose situations where a user sets
> a pin as selectable or connected but the hardware cannot use it
> due to signal issues.
>
> [...]
Here is the summary with links:
- [net-next,1/2] dpll: add pin operational state
https://git.kernel.org/netdev/net-next/c/781c8893a5da
- [net-next,2/2] dpll: zl3073x: implement pin operational state reporting
https://git.kernel.org/netdev/net-next/c/c53f8f8dce77
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next 2/2] dpll: zl3073x: implement pin operational state reporting
From: Paolo Abeni @ 2026-04-30 14:21 UTC (permalink / raw)
To: Ivan Vecera, netdev
Cc: Arkadiusz Kubalewski, David S. Miller, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Jiri Pirko, Jonathan Corbet,
Michal Schmidt, Pasi Vaananen, Petr Oros, Prathosh Satish,
Shuah Khan, Simon Horman, Vadim Fedorenko, linux-doc,
linux-kernel
In-Reply-To: <20260428154907.2820654-3-ivecera@redhat.com>
On 4/28/26 5:49 PM, Ivan Vecera wrote:
> @@ -1828,7 +1862,7 @@ zl3073x_dpll_changes_check(struct zl3073x_dpll *zldpll)
> }
Sashiko says:
---
Will input pin operational state changes fail to generate netlink
notifications when the DPLL channel is in FREERUN or HOLDOVER modes?
---
but such modes can not generate any real notification as explicitly
documented in a previous comment.
/P
^ permalink raw reply
* [RFC PATCH v2.1 2/2] Docs/admin-guide/mm/damon/stat: document kdamond_pid parameter
From: SeongJae Park @ 2026-04-30 14:20 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260430142013.80993-1-sj@kernel.org>
Update DAMON_STAT usage document for newly added kdamond_pid parameter.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/admin-guide/mm/damon/stat.rst | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/admin-guide/mm/damon/stat.rst b/Documentation/admin-guide/mm/damon/stat.rst
index c4b14daeb2dd6..46c5dd96aa2ed 100644
--- a/Documentation/admin-guide/mm/damon/stat.rst
+++ b/Documentation/admin-guide/mm/damon/stat.rst
@@ -89,3 +89,10 @@ percentiles of the idle time values via this read-only parameter. Reading the
parameter returns 101 idle time values in milliseconds, separated by comma.
Each value represents 0-th, 1st, 2nd, 3rd, ..., 99th and 100th percentile idle
times.
+
+kdamond_pid
+-----------
+
+PID of the DAMON thread.
+
+If DAMON_STAT is enabled, this becomes the PID of the worker thread. Else, -1.
--
2.47.3
^ permalink raw reply related
* [RFC PATCH v2.1 0/2] mm/damon/stat: add kdamond_pid parameter
From: SeongJae Park @ 2026-04-30 14:20 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
DAMON_STAT doesn't provide the pid of its kdamond, unlike DAMON_RECLAIM
and DAMON_LRU_SORT. This makes user-space management of DAMON_STAT
unnecessarily complicated. Provide the information via a new parameter,
namely kdamond_pid, and document it.
Changes from RFC v2
- v2: https://lore.kernel.org/20260425203309.108879-1-sj@kernel.org
- Rebase to latest mm-new.
Changes from RFC v1.2
- rfc v1.2: https://lore.kernel.org/20260416002149.87090-1-sj@kernel.org
- Detect and use fresh kdamond pid.
Changes from RFC v1.1
- rfc v1.1: https://lore.kernel.org/20260414235912.98174-1-sj@kernel.org
- Close the parentheses of error handling block.
Changes from RFC
- rfc: https://lore.kernel.org/20260414053742.90296-1-sj@kernel.org
- Fix damon_kdamond_pid() failure handling.
SeongJae Park (2):
mm/damon/stat: add a parameter for reading kdamond pid
Docs/admin-guide/mm/damon/stat: document kdamond_pid parameter
Documentation/admin-guide/mm/damon/stat.rst | 7 ++++
mm/damon/stat.c | 38 +++++++++++++++++++++
2 files changed, 45 insertions(+)
base-commit: b8e00b62c650b2aa471195f663301118fde889c2
--
2.47.3
^ permalink raw reply
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