* Re: [RFC] hwmon: add a driver for the temp/voltage sensor on PolarFire SoC
From: Guenter Roeck @ 2026-06-07 23:56 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-hwmon, Lars Randers, Conor Dooley, Jonathan Corbet,
Shuah Khan, Daire McNamara, linux-doc, linux-kernel, linux-riscv,
Valentina.FernandezAlanis
In-Reply-To: <20260528-defog-lasso-84891a72775a@spud>
On 5/28/26 15:34, Conor Dooley wrote:
> On Wed, May 27, 2026 at 09:07:20PM -0700, Guenter Roeck wrote:
>> On Wed, May 27, 2026 at 10:06:11AM +0100, Conor Dooley wrote:
>>> From: Lars Randers <lranders@mail.dk>
>>>
>>> Add a driver for the temperature and voltage sensors on PolarFire SoC.
>>> The temperature reports how hot the die is, and the voltages are the
>>> SoC's 1.05, 1.8 and 2.5 volt rails respectively.
>>>
>>> The hardware supports alarms in theory, but there is an unconfirmed
>>> erratum that prevents clearing them once triggered, so no support is
>>> added.
>>>
>>> The hardware measures voltage with 16 bits, of which 1 is a sign bit and
>>> the remainder holds the voltage as a fixed point integer value. It's
>>> improbable that the hardware will work if the voltages are negative, so
>>> the driver ignores the sign bits.
>>>
>>> There's no dt support etc here because this is the child of a simple-mfd
>>> syscon.
>>>
>>> Signed-off-by: Lars Randers <lranders@mail.dk>
>>> Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
>>> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
>>> ---
>>> Guenter, there's one question here about the unit that update_interval
>>> is in, I didn't see anyone else using us, but I assume that's okay since
>>> the resolution that ms would give would be 8 steps only?
>>> RFC cos the question is also in the driver as a comment.
>>>
>>
>> That just came up in a different context. We'll add a new standard attribute
>> update_interval_us. The existing attribute MUST use ms. Everything else
>> would be an ABI violation.
>
> Cool. Sounds like Ferdinand is working on that based on the other
> thread.
>
> Do you think I should support both update_interval and update_interval_us in
> this driver?
>
I have been thinking about only supporting one for a given driver, but that
doesn't work because there are existing drivers which would benefit from
supporting microsecond-based intervals, so both it is (unless you want to
wait for _us support to be available and then just support that).
> If yes, should I do the ms version now and add the us version later once
> Ferdinand's work is complete?
>
Yes, that is what I would recommend.
Thanks,
Guenter
^ permalink raw reply
* [PATCH RFC v4 6/6] iio: osf: register IIO devices from capabilities
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
Clean up the IIO sample push path.
Drop the redundant temperature scan mask.
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
drivers/iio/opensensorfusion/osf_core.c | 9 +++++----
drivers/iio/opensensorfusion/osf_iio.c | 15 +++------------
2 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/opensensorfusion/osf_core.c b/drivers/iio/opensensorfusion/osf_core.c
index e0a12de01..61ef55646 100644
--- a/drivers/iio/opensensorfusion/osf_core.c
+++ b/drivers/iio/opensensorfusion/osf_core.c
@@ -293,10 +293,11 @@ int osf_core_read_latest_sample(struct osf_device *osf, u16 sensor_type,
latest->sensor_index != sensor_index)
continue;
- if (latest->valid && channel < latest->channel_count) {
- *value = latest->values[channel];
- ret = 0;
- }
+ if (!latest->valid || channel >= latest->channel_count)
+ break;
+
+ *value = latest->values[channel];
+ ret = 0;
break;
}
mutex_unlock(&osf->latest_lock);
diff --git a/drivers/iio/opensensorfusion/osf_iio.c b/drivers/iio/opensensorfusion/osf_iio.c
index 5e5099878..3da3f2bda 100644
--- a/drivers/iio/opensensorfusion/osf_iio.c
+++ b/drivers/iio/opensensorfusion/osf_iio.c
@@ -6,7 +6,6 @@
#include <linux/iio/buffer.h>
#include <linux/iio/iio.h>
#include <linux/iio/kfifo_buf.h>
-#include <linux/string.h>
#include <linux/types.h>
#include <linux/units.h>
@@ -89,10 +88,6 @@ static const unsigned long osf_3axis_available_scan_masks[] = {
0
};
-static const unsigned long osf_temp_available_scan_masks[] = {
- BIT(0),
- 0
-};
static const struct osf_iio_sensor_spec osf_iio_sensor_specs[] = {
{
@@ -125,7 +120,6 @@ static const struct osf_iio_sensor_spec osf_iio_sensor_specs[] = {
.name = "osf-temp",
.channels = osf_temp_channels,
.num_channels = ARRAY_SIZE(osf_temp_channels),
- .available_scan_masks = osf_temp_available_scan_masks,
},
};
@@ -265,21 +259,18 @@ int osf_iio_push_sample(struct iio_dev *indio_dev, const s32 *values,
unsigned int channel_count)
{
struct osf_iio_state *state = iio_priv(indio_dev);
- s32 scan[OSF_MAX_SAMPLE_CHANNELS] = { };
s64 timestamp;
if (channel_count != state->spec->channel_count)
return -EPROTO;
- memcpy(scan, values, channel_count * sizeof(*values));
-
- /* Buffer state can change here; IIO rechecks it during the push path. */
+ /* This is only a fast path; IIO rechecks buffer state while pushing. */
if (!iio_buffer_enabled(indio_dev))
return 0;
timestamp = iio_get_time_ns(indio_dev);
- return iio_push_to_buffers_with_ts_unaligned(indio_dev, scan,
- channel_count * sizeof(*scan),
+ return iio_push_to_buffers_with_ts_unaligned(indio_dev, values,
+ channel_count * sizeof(*values),
timestamp);
}
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v4 5/6] iio: osf: add UART transport
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
Use the generic Open Sensor Fusion compatible.
Avoid board-specific DT compatibles.
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
drivers/iio/opensensorfusion/Kconfig | 4 ++--
drivers/iio/opensensorfusion/osf_serdev.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/opensensorfusion/Kconfig b/drivers/iio/opensensorfusion/Kconfig
index 957caed2b..8b9376d28 100644
--- a/drivers/iio/opensensorfusion/Kconfig
+++ b/drivers/iio/opensensorfusion/Kconfig
@@ -10,5 +10,5 @@ config OPEN_SENSOR_FUSION
help
Build the Open Sensor Fusion UART IIO driver.
- The driver receives OSF0 frames over a serdev UART and registers
- IIO devices for supported capability entries.
+ The driver receives OSF protocol frames over a serdev UART and
+ registers IIO devices for supported capability entries.
diff --git a/drivers/iio/opensensorfusion/osf_serdev.c b/drivers/iio/opensensorfusion/osf_serdev.c
index 1ac93548d..fd36acd1b 100644
--- a/drivers/iio/opensensorfusion/osf_serdev.c
+++ b/drivers/iio/opensensorfusion/osf_serdev.c
@@ -91,7 +91,7 @@ static void osf_serdev_remove(struct serdev_device *serdev)
}
static const struct of_device_id osf_serdev_of_match[] = {
- { .compatible = "opensensorfusion,osf-green" },
+ { .compatible = "opensensorfusion,osf" },
{ }
};
MODULE_DEVICE_TABLE(of, osf_serdev_of_match);
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v4 4/6] iio: osf: add stream parser
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
Keep the parser focused on frame assembly.
Let the core decode complete frames once.
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
drivers/iio/opensensorfusion/osf_stream.c | 38 ++++++-----------------
1 file changed, 9 insertions(+), 29 deletions(-)
diff --git a/drivers/iio/opensensorfusion/osf_stream.c b/drivers/iio/opensensorfusion/osf_stream.c
index a2739c987..957f73716 100644
--- a/drivers/iio/opensensorfusion/osf_stream.c
+++ b/drivers/iio/opensensorfusion/osf_stream.c
@@ -62,8 +62,6 @@ static size_t osf_stream_discard_to_magic(struct osf_stream *stream)
static int osf_stream_process(struct osf_stream *stream)
{
- struct osf_frame frame;
- size_t decoded_len;
size_t discarded;
size_t frame_len;
u32 payload_len;
@@ -82,10 +80,8 @@ static int osf_stream_process(struct osf_stream *stream)
if (!stream->len)
break;
- if (stream->len < OSF_FRAME_HEADER_LEN) {
- stream->stats.partial_frames++;
+ if (stream->len < OSF_FRAME_HEADER_LEN)
break;
- }
if (get_unaligned_le16(stream->buf + 6) !=
OSF_FRAME_HEADER_LEN) {
@@ -106,34 +102,18 @@ static int osf_stream_process(struct osf_stream *stream)
}
frame_len = OSF_FRAME_HEADER_LEN + payload_len + OSF_FRAME_CRC_LEN;
- if (stream->len < frame_len) {
- stream->stats.partial_frames++;
+ if (stream->len < frame_len)
break;
- }
-
- ret = osf_protocol_decode_frame(stream->buf, frame_len, &frame,
- &decoded_len);
- if (ret) {
- if (ret == -EBADMSG)
- stream->stats.bad_crc_frames++;
- stream->stats.dropped_bytes++;
- osf_stream_drop_invalid_head(stream);
- if (!first_err)
- first_err = ret;
- continue;
- }
-
- if (decoded_len != frame_len) {
- stream->stats.dropped_bytes++;
- osf_stream_drop_invalid_head(stream);
- if (!first_err)
- first_err = -EMSGSIZE;
- continue;
- }
ret = osf_core_receive_frame(stream->osf, stream->buf, frame_len);
if (ret) {
- osf_stream_discard(stream, frame_len);
+ if (ret == -EBADMSG) {
+ stream->stats.bad_crc_frames++;
+ stream->stats.dropped_bytes++;
+ osf_stream_drop_invalid_head(stream);
+ } else {
+ osf_stream_discard(stream, frame_len);
+ }
if (!first_err)
first_err = ret;
continue;
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v4 3/6] iio: osf: add protocol decoding
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
Use a FourCC-style wire magic comparison.
Document signed little-endian sample handling.
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
drivers/iio/opensensorfusion/osf_protocol.c | 4 +++-
drivers/iio/opensensorfusion/osf_protocol.h | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/opensensorfusion/osf_protocol.c b/drivers/iio/opensensorfusion/osf_protocol.c
index ed91d3dd5..5bee545f3 100644
--- a/drivers/iio/opensensorfusion/osf_protocol.c
+++ b/drivers/iio/opensensorfusion/osf_protocol.c
@@ -11,6 +11,7 @@
#define OSF_CRC32_INIT GENMASK(31, 0)
#define OSF_CRC32_XOROUT GENMASK(31, 0)
+#define OSF_FRAME_MAGIC 0x3046534f /* "OSF0" little-endian */
static bool osf_sensor_type_valid(u16 sensor_type)
{
@@ -38,7 +39,7 @@ int osf_protocol_decode_frame(const u8 *buf, size_t len,
if (len < OSF_FRAME_MIN_LEN)
return -EMSGSIZE;
- if (buf[0] != 'O' || buf[1] != 'S' || buf[2] != 'F' || buf[3] != '0')
+ if (get_unaligned_le32(buf) != OSF_FRAME_MAGIC)
return -EPROTO;
major = buf[4];
@@ -136,6 +137,7 @@ int osf_protocol_sensor_sample_value(const struct osf_sensor_sample *sample,
if (index >= sample->channel_count)
return -ERANGE;
+ /* Samples are little-endian two's-complement signed values. */
*value = (s32)get_unaligned_le32(sample->samples + index * sizeof(s32));
return 0;
diff --git a/drivers/iio/opensensorfusion/osf_protocol.h b/drivers/iio/opensensorfusion/osf_protocol.h
index 4b6fb131a..c62c2c254 100644
--- a/drivers/iio/opensensorfusion/osf_protocol.h
+++ b/drivers/iio/opensensorfusion/osf_protocol.h
@@ -2,6 +2,7 @@
#ifndef _OSF_PROTOCOL_H
#define _OSF_PROTOCOL_H
+#include <linux/bits.h>
#include <linux/types.h>
#define OSF_PROTOCOL_MAJOR 0
@@ -14,7 +15,7 @@
#define OSF_DEVICE_STATUS_LEN 20
#define OSF_CAP_REPORT_BASE_LEN 4
#define OSF_CAP_SENSOR_ENTRY_LEN 20
-#define OSF_CAPABILITY_FLAGS_MASK 0x00000003U
+#define OSF_CAPABILITY_FLAGS_MASK GENMASK(1, 0)
enum osf_message_type {
OSF_MSG_SENSOR_SAMPLE = 0x0001,
@@ -44,6 +45,7 @@ struct osf_frame {
u64 sequence;
u64 timestamp_us;
u32 flags;
+ /* payload points into the caller-owned frame buffer. */
const u8 *payload;
u32 crc;
};
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v4 2/6] Documentation: iio: add Open Sensor Fusion driver overview
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
Add a short driver-facing overview.
Leave full protocol details to project docs.
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
Documentation/iio/index.rst | 1 +
.../iio/open-sensor-fusion-protocol-v0.rst | 308 ------------------
Documentation/iio/open-sensor-fusion.rst | 62 ++++
MAINTAINERS | 3 +-
4 files changed, 64 insertions(+), 310 deletions(-)
delete mode 100644 Documentation/iio/open-sensor-fusion-protocol-v0.rst
create mode 100644 Documentation/iio/open-sensor-fusion.rst
diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst
index ba3e609c6..2713ec5e0 100644
--- a/Documentation/iio/index.rst
+++ b/Documentation/iio/index.rst
@@ -38,4 +38,5 @@ Industrial I/O Kernel Drivers
adxl345
bno055
ep93xx_adc
+ open-sensor-fusion
opt4060
diff --git a/Documentation/iio/open-sensor-fusion-protocol-v0.rst b/Documentation/iio/open-sensor-fusion-protocol-v0.rst
deleted file mode 100644
index 80852f4cf..000000000
--- a/Documentation/iio/open-sensor-fusion-protocol-v0.rst
+++ /dev/null
@@ -1,308 +0,0 @@
-.. SPDX-License-Identifier: GPL-2.0-only
-
-Open Sensor Fusion protocol v0
-==============================
-
-This document describes the OSF0 UART wire format used by the Open Sensor
-Fusion Linux IIO driver. It is a wire format reference for the host driver. It
-is not a firmware programming interface.
-
-Background
-----------
-
-Open Sensor Fusion is an open hardware project for sensor aggregation devices
-and Linux IIO host support. It is not a generic sensor protocol standard. The
-first concrete hardware target is OSF GREEN, an STM32F405-based board that
-streams OSF0 frames to a Linux host.
-
-Public project documentation is available at:
-
-- https://www.opensensorfusion.org/
-- https://github.com/opensensorfusion
-- https://github.com/opensensorfusion/opensensorfusion-hardware
-- https://github.com/opensensorfusion/opensensorfusion-linux
-
-Wire format and driver subset
------------------------------
-
-OSF0 defines a small device-to-host UART frame format. The current RFC driver
-supports only the subset needed to expose OSF GREEN raw sensor data through
-IIO:
-
-- ``SENSOR_SAMPLE`` frames for accelerometer, gyroscope, magnetometer, and
- temperature samples.
-- ``CAPABILITY_REPORT`` frames used to create the supported IIO devices.
-- ``DEVICE_STATUS`` frames cached for diagnostics.
-
-The driver ignores vendor private message types and does not implement command
-transport, calibration controls, USB transport, fusion output, or runtime
-capability removal.
-
-Device model
-------------
-
-An OSF0 device is a sensor aggregation device. It sends binary frames from the
-device to the host. The host driver decodes the frames and maps supported
-sensors to IIO devices.
-
-The hardware used for smoke testing is an OSF GREEN prototype with an
-STM32F405RGT6 MCU, an ICM42688P-class IMU, and an MMC5983MA magnetometer. That
-hardware is the first supported target for the RFC driver.
-
-Transport
----------
-
-The transport is UART at 115200 baud, 8 data bits, no parity, and 1 stop bit.
-The Linux transport is serdev. The v0 upstream driver covers device-to-host
-frames. Flow control is not used by the tested stream.
-
-Byte order
-----------
-
-All multi-byte integer fields are little-endian. Samples use signed 32-bit
-little-endian integers when ``sample_format`` is ``s32``.
-
-Frame format
-------------
-
-Each frame has a fixed 38-byte header, a payload, and a 4-byte CRC.
-
-.. list-table::
- :header-rows: 1
-
- * - Offset
- - Size
- - Field
- - Description
- * - 0
- - 4
- - magic
- - ASCII ``OSF0``
- * - 4
- - 1
- - protocol_major
- - Must be ``0``
- * - 5
- - 1
- - protocol_minor
- - Minor version
- * - 6
- - 2
- - header_len
- - Must be ``38``
- * - 8
- - 2
- - message_type
- - Message type
- * - 10
- - 4
- - payload_len
- - Payload length in bytes
- * - 14
- - 8
- - sequence
- - Monotonic device sequence
- * - 22
- - 8
- - timestamp_us
- - Device timestamp in microseconds
- * - 30
- - 4
- - flags
- - Message flags
- * - 34
- - 4
- - reserved
- - Must be zero for v0
- * - 38
- - payload_len
- - payload
- - Message payload
- * - 38 + payload_len
- - 4
- - crc32
- - CRC32 over header and payload
-
-The frame CRC is IEEE CRC32 as implemented by ``crc32_le()`` with initial
-value ``0xffffffff`` and final XOR value ``0xffffffff``. The CRC field is not
-included in the CRC input.
-
-Message types
--------------
-
-.. list-table::
- :header-rows: 1
-
- * - Value
- - Name
- - Direction
- * - ``0x0001``
- - ``SENSOR_SAMPLE``
- - device to host
- * - ``0x0002``
- - ``DEVICE_STATUS``
- - device to host
- * - ``0x0003``
- - ``CAPABILITY_REPORT``
- - device to host
-
-Message types ``0x7f00`` through ``0x7fff`` are reserved. Values at or above
-``0x8000`` are vendor private and are ignored by the current RFC driver.
-
-``SENSOR_SAMPLE`` payload
--------------------------
-
-The payload is a 16-byte payload header followed by ``4 * channel_count`` bytes
-of sample data.
-
-.. list-table::
- :header-rows: 1
-
- * - Offset
- - Size
- - Field
- - Description
- * - 0
- - 2
- - sensor_type
- - Sensor type ID
- * - 2
- - 2
- - sensor_index
- - Instance index
- * - 4
- - 2
- - channel_count
- - Number of ``s32`` channels
- * - 6
- - 2
- - sample_format
- - Must be ``1`` (``s32``)
- * - 8
- - 4
- - scale_nano
- - Scale factor in nano-units
- * - 12
- - 4
- - reserved
- - Must be zero for v0
- * - 16
- - 4 * channel_count
- - samples
- - Signed 32-bit channel samples
-
-The current RFC driver accepts only ``sample_format = s32`` and only the fixed
-channel counts used by its supported IIO devices.
-
-``DEVICE_STATUS`` payload
--------------------------
-
-The payload size is 20 bytes. Fields are ``uptime_s``, ``status_flags``,
-``error_flags``, ``dropped_frames``, and a reserved field. Each field is
-32 bits. The reserved field must be zero for v0.
-
-``CAPABILITY_REPORT`` payload
------------------------------
-
-The base payload size is 4 bytes. It contains ``capability_count`` and a
-reserved field. The reserved field must be zero for v0. Each capability entry
-is 20 bytes:
-
-.. list-table::
- :header-rows: 1
-
- * - Offset
- - Size
- - Field
- - Description
- * - 0
- - 2
- - sensor_type
- - Sensor type ID
- * - 2
- - 2
- - sensor_index
- - Instance index
- * - 4
- - 2
- - channel_count
- - Number of channels
- * - 6
- - 2
- - sample_format
- - Must be ``1`` (``s32``)
- * - 8
- - 4
- - scale_nano
- - Scale factor in nano-units
- * - 12
- - 4
- - flags
- - Capability flags
- * - 16
- - 4
- - reserved
- - Must be zero for v0
-
-Capability flag bit 0 means enabled by default. Bit 1 means calibrated data can
-be provided by the device. Other bits are invalid for v0.
-
-Sensor type IDs
----------------
-
-.. list-table::
- :header-rows: 1
-
- * - Value
- - Sensor
- - Current RFC driver mapping
- * - ``0x0001``
- - accelerometer
- - ``IIO_ACCEL``, X/Y/Z
- * - ``0x0002``
- - gyroscope
- - ``IIO_ANGL_VEL``, X/Y/Z
- * - ``0x0003``
- - magnetometer
- - ``IIO_MAGN``, X/Y/Z
- * - ``0x0004``
- - barometer
- - not mapped
- * - ``0x0005``
- - temperature
- - ``IIO_TEMP``
- * - ``0x0006``
- - humidity
- - not mapped
- * - ``0x0007``
- - ambient light
- - not mapped
- * - ``0x0008``
- - proximity
- - not mapped
-
-Scaling
--------
-
-``scale_nano`` is the per-channel scale value in nano-units. The Linux driver
-maps it to ``IIO_CHAN_INFO_SCALE`` as integer plus nano. The exact physical
-unit depends on the IIO channel type.
-
-Timestamps
-----------
-
-The frame header carries ``timestamp_us``, a device-side timestamp in
-microseconds. UART buffering and host scheduling can add delay before a frame
-is processed by the host.
-
-The current RFC driver does not claim production-grade host/device timestamp
-correlation. Buffered IIO timestamps are taken from IIO timestamp clock handling
-when samples are pushed to IIO buffers.
-
-Non-goals for v0 upstream
--------------------------
-
-The v0 upstream driver does not include USB transport, fusion output, Attitude
-and Heading Reference System (AHRS) output, Kalman output, calibration command
-ABI, custom sysfs control surface, production timestamp correlation, or runtime
-capability removal.
diff --git a/Documentation/iio/open-sensor-fusion.rst b/Documentation/iio/open-sensor-fusion.rst
new file mode 100644
index 000000000..244a4fecb
--- /dev/null
+++ b/Documentation/iio/open-sensor-fusion.rst
@@ -0,0 +1,62 @@
+.. SPDX-License-Identifier: GPL-2.0-only
+
+Open Sensor Fusion
+==================
+
+Open Sensor Fusion is a sensor aggregation hub interface. The Linux IIO driver
+receives OSF protocol frames from an attached device, discovers supported sensor
+streams through capability reports, and registers matching IIO devices for the
+sensor classes supported by the driver.
+
+This document is a driver-facing overview for the Linux IIO mapping. The full
+wire protocol, firmware behavior, and hardware model details belong in the Open
+Sensor Fusion project documentation.
+
+Device Model
+------------
+
+An OSF device sends binary frames from the device to the host. The host driver
+uses ``CAPABILITY_REPORT`` messages to discover which sensor streams are
+available. Device Tree describes the attached OSF sensor aggregation hub; it does
+not enumerate the individual sensors discovered at runtime.
+
+The currently supported Linux subset exposes:
+
+* accelerometer samples as ``IIO_ACCEL`` X/Y/Z channels,
+* gyroscope samples as ``IIO_ANGL_VEL`` X/Y/Z channels,
+* magnetometer samples as ``IIO_MAGN`` X/Y/Z channels, and
+* temperature samples as ``IIO_TEMP``.
+
+Protocol Scope
+---------------
+
+The driver supports OSF protocol major version 0 for the initial IIO receive
+path. The current wire magic is ``OSF0``; that string is a wire-format detail and
+is not the Linux driver identity. Protocol versioning is carried by the
+``protocol_major`` and ``protocol_minor`` fields in the frame header.
+
+The initial Linux driver handles device-to-host frames for:
+
+* ``SENSOR_SAMPLE`` buffered and direct-mode sample data,
+* ``CAPABILITY_REPORT`` based IIO device registration, and
+* ``DEVICE_STATUS`` cache updates.
+
+Vendor-private message types are ignored. Command transport, calibration
+control ABI, fusion output ABI, and runtime capability removal are outside the
+initial Linux IIO receive path.
+
+Timestamps
+----------
+
+OSF frames include a device-side ``timestamp_us`` field. Buffered IIO samples use
+an IIO timestamp captured on the host when samples are pushed to IIO buffers.
+The initial driver does not correlate the device timestamp with the host IIO
+clock.
+
+Compatibility Notes
+-------------------
+
+The project protocol documentation should define the compatibility rules for
+reserved fields, optional flags, and trailing extension data. Until those rules
+are finalized, the Linux decoder keeps conservative bounds checks around the
+currently supported message layouts.
diff --git a/MAINTAINERS b/MAINTAINERS
index e227b9aff..2ddefc42d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20015,7 +20015,7 @@ OPEN SENSOR FUSION IIO DRIVER
M: Jinseob Kim <kimjinseob88@gmail.com>
S: Maintained
F: Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
-F: Documentation/iio/open-sensor-fusion-protocol-v0.rst
+F: Documentation/iio/open-sensor-fusion.rst
F: drivers/iio/opensensorfusion/Kconfig
F: drivers/iio/opensensorfusion/Makefile
F: drivers/iio/opensensorfusion/osf_core.*
@@ -20024,7 +20024,6 @@ F: drivers/iio/opensensorfusion/osf_protocol.*
F: drivers/iio/opensensorfusion/osf_serdev.c
F: drivers/iio/opensensorfusion/osf_stream.*
-
OPENCOMPUTE PTP CLOCK DRIVER
M: Vadim Fedorenko <vadim.fedorenko@linux.dev>
L: netdev@vger.kernel.org
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v4 1/6] dt-bindings: iio: add Open Sensor Fusion device
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
In-Reply-To: <20260607234343.22109-1-kimjinseob88@gmail.com>
Describe the OSF sensor aggregation hub.
Use the generic opensensorfusion,osf compatible.
Signed-off-by: Jinseob Kim <kimjinseob88@gmail.com>
---
.../iio/imu/opensensorfusion,osf-green.yaml | 43 -------------------
.../bindings/iio/opensensorfusion,osf.yaml | 43 +++++++++++++++++++
MAINTAINERS | 27 ++++++------
3 files changed, 57 insertions(+), 56 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
diff --git a/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml b/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
deleted file mode 100644
index 626b41fb0..000000000
--- a/Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
+++ /dev/null
@@ -1,43 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/iio/imu/opensensorfusion,osf-green.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: OSF GREEN sensor aggregation board
-
-maintainers:
- - Jinseob Kim <kimjinseob88@gmail.com>
-
-description: |
- OSF GREEN is an STM32F405-based sensor aggregation board from the Open
- Sensor Fusion open hardware project. It sends OSF0 capability, status, and
- sample frames to a host over a UART link.
-
- Open Sensor Fusion is not a generic industry standard. Public project and
- hardware documentation is available at:
-
- https://github.com/opensensorfusion
- https://github.com/opensensorfusion/opensensorfusion-hardware
-
-allOf:
- - $ref: /schemas/serial/serial-peripheral-props.yaml#
-
-properties:
- compatible:
- const: opensensorfusion,osf-green
-
-required:
- - compatible
-
-unevaluatedProperties: false
-
-examples:
- - |
- serial {
- sensor {
- compatible = "opensensorfusion,osf-green";
- };
- };
-
-...
diff --git a/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
new file mode 100644
index 000000000..a4049715a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/opensensorfusion,osf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Open Sensor Fusion Sensor Aggregation Hub
+
+maintainers:
+ - Jinseob Kim <kimjinseob88@gmail.com>
+
+description: |
+ Open Sensor Fusion is a sensor aggregation hub. The hub exposes an OSF
+ protocol data stream over its host interface and may report capabilities and
+ samples for multiple sensor classes. The Linux driver discovers the actual
+ sensor channels from OSF capability reports instead of describing those
+ sensors in Device Tree.
+
+ Open Sensor Fusion is not a generic industry standard. Public project
+ documentation is available at:
+
+ https://github.com/opensensorfusion
+
+allOf:
+ - $ref: /schemas/serial/serial-peripheral-props.yaml#
+
+properties:
+ compatible:
+ const: opensensorfusion,osf
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ serial {
+ sensor {
+ compatible = "opensensorfusion,osf";
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 56181470d..e227b9aff 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19977,19 +19977,6 @@ F: Documentation/networking/oa-tc6-framework.rst
F: drivers/net/ethernet/oa_tc6.c
F: include/linux/oa_tc6.h
-OPEN SENSOR FUSION IIO DRIVER
-M: Jinseob Kim <kimjinseob88@gmail.com>
-S: Maintained
-F: Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
-F: Documentation/iio/open-sensor-fusion-protocol-v0.rst
-F: drivers/iio/opensensorfusion/Kconfig
-F: drivers/iio/opensensorfusion/Makefile
-F: drivers/iio/opensensorfusion/osf_core.*
-F: drivers/iio/opensensorfusion/osf_iio.*
-F: drivers/iio/opensensorfusion/osf_protocol.*
-F: drivers/iio/opensensorfusion/osf_serdev.c
-F: drivers/iio/opensensorfusion/osf_stream.*
-
OPEN FIRMWARE AND FLATTENED DEVICE TREE
M: Rob Herring <robh@kernel.org>
M: Saravana Kannan <saravanak@kernel.org>
@@ -20024,6 +20011,20 @@ F: Documentation/devicetree/
F: arch/*/boot/dts/
F: include/dt-bindings/
+OPEN SENSOR FUSION IIO DRIVER
+M: Jinseob Kim <kimjinseob88@gmail.com>
+S: Maintained
+F: Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
+F: Documentation/iio/open-sensor-fusion-protocol-v0.rst
+F: drivers/iio/opensensorfusion/Kconfig
+F: drivers/iio/opensensorfusion/Makefile
+F: drivers/iio/opensensorfusion/osf_core.*
+F: drivers/iio/opensensorfusion/osf_iio.*
+F: drivers/iio/opensensorfusion/osf_protocol.*
+F: drivers/iio/opensensorfusion/osf_serdev.c
+F: drivers/iio/opensensorfusion/osf_stream.*
+
+
OPENCOMPUTE PTP CLOCK DRIVER
M: Vadim Fedorenko <vadim.fedorenko@linux.dev>
L: netdev@vger.kernel.org
--
2.43.0
^ permalink raw reply related
* [PATCH RFC v4 0/6] iio: add Open Sensor Fusion IIO driver
From: Jinseob Kim @ 2026-06-07 23:43 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
devicetree, linux-kernel, linux-doc
This RFC series adds an Industrial I/O driver for Open Sensor Fusion
sensor aggregation devices.
Open Sensor Fusion is an open hardware project for sensor
aggregation devices. The Linux IIO driver is an initial host-side
implementation for OSF devices. The driver receives OSF frames over
UART, uses device capability reports to discover supported sensor
streams, and exposes supported raw sensor data through IIO devices.
This series is still marked RFC because the DT binding identity, the
supported OSF protocol subset, and protocol extension and backward
compatibility rules are still under review. The v4 series
intentionally models the Linux device as a generic Open Sensor Fusion
device rather than an OSF GREEN board-specific device. OSF GREEN is
the prototype board used for current runtime testing, not the Linux DT
compatible or driver identity.
The current wire format uses the OSF0 magic for protocol major
version 0. That is kept as an internal wire-format detail for
compatibility with existing firmware, tools, and runtime smoke
evidence. The public driver identity remains Open Sensor Fusion / OSF,
with protocol versioning handled by the protocol major/minor fields.
Project links:
https://www.opensensorfusion.org/
https://github.com/opensensorfusion
https://github.com/opensensorfusion/opensensorfusion-hardware
https://github.com/opensensorfusion/opensensorfusion-linux
Runtime testing so far has used an OSF GREEN prototype connected to a
Raspberry Pi over UART. On Raspberry Pi 6.12.75+rpt-rpi-v8, the
driver registered osf-accel, osf-gyro, osf-magn, and osf-temp from a
capability report. Raw reads and software kfifo buffer reads were
tested for all four IIO devices.
Changes since v3:
* Explain why the series is still RFC.
* Move the DT binding out of iio/imu because the device is a sensor
aggregation device rather than an IMU.
* Replace the OSF GREEN board-specific compatible with the generic
opensensorfusion,osf compatible.
* Treat OSF GREEN as tested prototype hardware / board model
information, not as the Linux compatible string.
* Rename the kernel documentation to open-sensor-fusion.rst and
reduce it to a driver-facing overview.
* Add the IIO documentation toctree entry.
* Keep full protocol details and compatibility rules in project
documentation rather than duplicating the full wire specification in
the kernel tree.
* Avoid using OSF0 as the public driver identity; keep it only as the
current wire magic for protocol major version 0.
* Add FourCC-style wire magic handling in the decoder.
* Use GENMASK() for the capability flags mask.
* Clarify signed 32-bit little-endian sample decoding.
* Stop counting normal partial UART receive waits as partial frame
errors.
* Avoid decoding complete frames twice in the stream/core path.
* Remove the local scan[] bounce before
iio_push_to_buffers_with_ts_unaligned() and pass the values buffer
directly.
* Remove the meaningless temperature available_scan_masks entry.
* Update MAINTAINERS paths for the new binding and documentation
names.
Jinseob Kim (6):
dt-bindings: iio: add Open Sensor Fusion device
Documentation: iio: add Open Sensor Fusion driver overview
iio: osf: add protocol decoding
iio: osf: add stream parser
iio: osf: add UART transport
iio: osf: register IIO devices from capabilities
.../iio/imu/opensensorfusion,osf-green.yaml | 43 ---
.../bindings/iio/opensensorfusion,osf.yaml | 43 +++
Documentation/iio/index.rst | 1 +
.../iio/open-sensor-fusion-protocol-v0.rst | 308 ------------------
Documentation/iio/open-sensor-fusion.rst | 62 ++++
MAINTAINERS | 26 +-
drivers/iio/opensensorfusion/Kconfig | 4 +-
drivers/iio/opensensorfusion/osf_core.c | 9 +-
drivers/iio/opensensorfusion/osf_iio.c | 15 +-
drivers/iio/opensensorfusion/osf_protocol.c | 4 +-
drivers/iio/opensensorfusion/osf_protocol.h | 4 +-
drivers/iio/opensensorfusion/osf_serdev.c | 2 +-
drivers/iio/opensensorfusion/osf_stream.c | 38 +--
13 files changed, 145 insertions(+), 414 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/imu/opensensorfusion,osf-green.yaml
create mode 100644 Documentation/devicetree/bindings/iio/opensensorfusion,osf.yaml
delete mode 100644 Documentation/iio/open-sensor-fusion-protocol-v0.rst
create mode 100644 Documentation/iio/open-sensor-fusion.rst
--
2.43.0
^ permalink raw reply
* Re: [PATCH 13/15] accel/qda: Add DSP process creation and release
From: Dmitry Baryshkov @ 2026-06-07 21:16 UTC (permalink / raw)
To: Ekansh Gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <568987b0-6f54-4b51-b1c0-416435e3f564@oss.qualcomm.com>
On Thu, Jun 04, 2026 at 10:47:13AM +0530, Ekansh Gupta wrote:
> On 20-05-2026 19:30, Dmitry Baryshkov wrote:
> > On Tue, May 19, 2026 at 11:46:03AM +0530, Ekansh Gupta via B4 Relay wrote:
> >>
> >> +/**
> >> + * qda_ioctl_init_create() - Create a DSP process
> >> + * @dev: DRM device structure
> >> + * @data: User-space data (struct drm_qda_init_create)
> >> + * @file_priv: DRM file private data
> >> + *
> >> + * Return: 0 on success, negative error code on failure
> >> + */
> >> +int qda_ioctl_init_create(struct drm_device *dev, void *data, struct drm_file *file_priv)
> >> +{
> >> + return fastrpc_invoke(FASTRPC_RMID_INIT_CREATE, dev, data, file_priv);
> >
> > Where is INIT_CREATE_ATTR, which you described earlier?
> INIT_CREATE_ATTR is used while `sc` creation so the DSP considers the
> request is coming with some attributes, the ioctl functions are going to
> be the same in both the cases, so keeping it unchanged and the decision
> is taken while `sc` is getting created.>
Ack, I missed it earlier.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 12/15] accel/qda: Add FastRPC invocation support
From: Dmitry Baryshkov @ 2026-06-07 21:14 UTC (permalink / raw)
To: Ekansh Gupta
Cc: Oded Gabbay, Jonathan Corbet, Shuah Khan, Joerg Roedel,
Will Deacon, Robin Murphy, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Christian König, Bharath Kumar, Chenna Kesava Raju, srini,
andersson, konradybcio, robin.clark, linux-kernel, dri-devel,
linux-doc, linux-arm-msm, iommu, linux-media, linaro-mm-sig
In-Reply-To: <ba003d7d-03f5-4572-8321-3d1f666c8c27@oss.qualcomm.com>
On Thu, Jun 04, 2026 at 10:39:14AM +0530, Ekansh Gupta wrote:
> On 20-05-2026 19:26, Dmitry Baryshkov wrote:
> > On Tue, May 19, 2026 at 11:46:02AM +0530, Ekansh Gupta via B4 Relay wrote:
> >> From: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
> >>
> >> Implement the FastRPC remote procedure call path, allowing user-space
> >> to invoke methods on the DSP via DRM_IOCTL_QDA_REMOTE_INVOKE.
> >>
> >> qda_fastrpc.c / qda_fastrpc.h
> >> Implements the FastRPC protocol layer: argument marshalling
> >> (qda_fastrpc_invoke_pack), response unmarshalling
> >> (qda_fastrpc_invoke_unpack), and invocation context lifecycle
> >> management. Each invocation allocates a fastrpc_invoke_context
> >> which tracks buffer descriptors, GEM objects, and the completion
> >> used to synchronise with the DSP response.
> >>
> >> Buffer arguments are handled in three ways:
> >> - DMA-BUF fd: imported via PRIME, IOMMU-mapped dma_addr used
> >> - Direct (inline): copied into the GEM-backed message buffer
> >> - DMA handle: fd forwarded to DSP, physical page descriptor computed
> >
> > No. This needs to go away. The QDA should support only one way to pass
> > data - via the GEM buffers. Everything else should be handled by the
> > shim layer, etc.
> each FD passed here is a GEM buffer. The reason to pass fd is that there
> are some APIs on DSP side which takes fd as an argument and the user
> might use the same on their skel implementation. So in this case the
> remote call will take fd to DSP and the skel implementation will use the
> FD.>
Then handle it all on the userspace side. In the end, bad library API is
not a reason to complicate kernel API and kernel driver.
> >> +#define FASTRPC_SCALARS(method, in, out) \
> >> + FASTRPC_BUILD_SCALARS(0, method, in, out, 0, 0)
> >> +
> >> +/**
> >> + * struct fastrpc_buf_overlap - Buffer overlap tracking structure
> >> + *
> >> + * Tracks overlapping buffer regions to optimise memory mapping and avoid
> >> + * redundant mappings of the same physical memory.
> >
> > WHat for? Even if this is a valid optimization, implement it as a
> > subsequent patch. The first goal should be very simple - get GEM buffers
> > from the app, pass them to the DSP, read the results.
> yes, this implementation is mimicking the existing fastrpc design where
> non-FD buffers are also supported. I am currently evaluating the
> maintainance of such buffers from userspace side and trying to
> understand the impacts of the same. I am planning to bring it as a
> future enhancement if there is no regression.>
Other way around. Drop it for now and bring it back if it has any
positive impact.
> >> + */
> >> +struct fastrpc_buf_overlap {
> >
> > Stop clashing the names with the existing fastrpc driver.
> ack.>
> >> + /** @start: Start address of the buffer in user virtual address space */
> >> + u64 start;
> >> + /** @end: End address of the buffer in user virtual address space */
> >> + u64 end;
> >> + /** @raix: Remote argument index associated with this overlap */
> >> + int raix;
> >> + /** @mstart: Start address of the mapped region */
> >> + u64 mstart;
> >> + /** @mend: End address of the mapped region */
> >> + u64 mend;
> >> + /** @offset: Offset within the mapped region */
> >> + u64 offset;
> >> +};
> >> +
> >> +/**
> >> + * struct fastrpc_remote_dmahandle - Remote DMA handle descriptor
> >> + */
> >> +struct fastrpc_remote_dmahandle {
> >> + /** @fd: DMA-BUF file descriptor */
> >> + s32 fd;
> >> + /** @offset: Byte offset within the DMA-BUF */
> >> + u32 offset;
> >> + /** @len: Length of the region in bytes */
> >> + u32 len;
> >> +};
> >> +
> >> +/**
> >> + * struct fastrpc_remote_buf - Remote buffer descriptor
> >> + */
> >> +struct fastrpc_remote_buf {
> >> + /** @pv: Buffer pointer (user virtual address) */
> >> + u64 pv;
> >> + /** @len: Length of the buffer in bytes */
> >> + u64 len;
> >> +};
> >> +
> >> +/**
> >> + * union fastrpc_remote_arg - Remote argument (buffer or DMA handle)
> >> + */
> >> +union fastrpc_remote_arg {
> >> + /** @buf: Inline buffer descriptor */
> >> + struct fastrpc_remote_buf buf;
> >> + /** @dma: DMA-BUF handle descriptor */
> >> + struct fastrpc_remote_dmahandle dma;
> >> +};
> >> +
> >> +/**
> >> + * struct fastrpc_phy_page - Physical page descriptor
> >> + */
> >> +struct fastrpc_phy_page {
> >> + /** @addr: Physical (IOMMU) address of the page */
> >> + u64 addr;
> >> + /** @size: Size of the contiguous region in bytes */
> >> + u64 size;
> >> +};
> >> +
> >> +/**
> >> + * struct fastrpc_invoke_buf - Invoke buffer descriptor
> >> + */
> >> +struct fastrpc_invoke_buf {
> >> + /** @num: Number of contiguous physical regions */
> >> + u32 num;
> >> + /** @pgidx: Index into the physical page array */
> >> + u32 pgidx;
> >> +};
> >> +
> >> +/**
> >> + * struct fastrpc_msg - FastRPC wire message for remote invocations
> >> + *
> >> + * Sent to the remote processor via RPMsg. This is the exact layout
> >> + * the DSP expects; do not reorder or add fields without DSP firmware
> >> + * coordination.
> >> + */
> >> +struct fastrpc_msg {
> >> + /** @remote_session_id: Session identifier on the remote processor */
> >> + int remote_session_id;
> >> + /** @tid: Thread ID of the invoking thread */
> >> + int tid;
> >> + /** @ctx: Context identifier for matching request/response */
> >> + u64 ctx;
> >> + /** @handle: Handle of the remote method to invoke */
> >> + u32 handle;
> >> + /** @sc: Scalars value encoding in/out buffer counts */
> >> + u32 sc;
> >> + /** @addr: Physical address of the message payload buffer */
> >> + u64 addr;
> >> + /** @size: Size of the message payload in bytes */
> >> + u64 size;
> >> +};
> >> +
> >> +/**
> >> + * struct qda_msg - FastRPC message with kernel-internal bookkeeping
> >> + *
> >> + * The wire-format portion is kept in the embedded @fastrpc member (must
> >> + * be first) so that &qda_msg->fastrpc can be passed directly to
> >> + * rpmsg_send() without a copy.
> >> + */
> >> +struct qda_msg {
> >> + /**
> >> + * @fastrpc: Wire-format message sent to the DSP via RPMsg.
> >> + * Must be the first member.
> >> + */
> >> + struct fastrpc_msg fastrpc;
> >> + /** @buf: Kernel virtual address of the payload buffer */
> >> + void *buf;
> >> + /** @phys: Physical/DMA address of the payload buffer */
> >> + u64 phys;
> >> + /** @ret: Return value from the remote processor */
> >> + int ret;
> >> + /** @fastrpc_ctx: Back-pointer to the owning invocation context */
> >> + struct fastrpc_invoke_context *fastrpc_ctx;
> >> + /** @file_priv: DRM file private data for GEM object lookup */
> >> + struct drm_file *file_priv;
> >> +};
> >> +
> >> +/**
> >> + * struct fastrpc_invoke_context - Remote procedure call invocation context
> >> + *
> >> + * Maintains all state for a single remote procedure call, including buffer
> >> + * management, synchronisation, and result handling.
> >> + */
> >> +struct fastrpc_invoke_context {
> >> + /** @node: List node for linking contexts in a queue */
> >> + struct list_head node;
> >> + /** @ctxid: Unique context identifier (XArray key shifted left by 4) */
> >> + u64 ctxid;
> >> + /** @inbufs: Number of input buffers */
> >> + int inbufs;
> >> + /** @outbufs: Number of output buffers */
> >> + int outbufs;
> >> + /** @handles: Number of DMA-BUF handle arguments */
> >> + int handles;
> >> + /** @nscalars: Total number of scalar arguments */
> >> + int nscalars;
> >> + /** @nbufs: Total number of buffer arguments (inbufs + outbufs) */
> >> + int nbufs;
> >
> > If it is inbufs + outbufs, why do you need it here?
> >
> >> + /** @pid: Process ID of the calling process */
> >> + int pid;
> >> + /** @retval: Return value from the remote invocation */
> >> + int retval;
> >> + /** @metalen: Length of the FastRPC metadata header in bytes */
> >> + int metalen;
> >
> > size_t, also why do you need it?
> >
> >> + /** @remote_session_id: Session identifier on the remote processor */
> >> + int remote_session_id;
> >> + /** @pd: Protection domain identifier encoded into the context ID */
> >> + int pd;
> >> + /** @type: Invocation type (e.g. FASTRPC_RMID_INVOKE_DYNAMIC) */
> >> + int type;
> >> + /** @sc: Scalars value encoding in/out buffer counts */
> >> + u32 sc;
> >
> > How is this different from the counts above?
> sc carries the method id and handle counts. The reason to maintain count
> separately is to avoid calculating it again and again.>
Is it just a sum of several values or something more complicated?
> >> + /** @handle: Handle of the remote method being invoked */
> >> + u32 handle;
> >> + /** @crc: Pointer to CRC values for data integrity checking */
> >> + u32 *crc;
> >
> > Add it later. It's unused. Drop all unused fields.
> ack.>
> >> + /** @fdlist: Pointer to array of DMA-BUF file descriptors */
> >> + u64 *fdlist;
> >
> > Why do you need DMA-BUFs in the invocation context? They all should be
> > GEM buffers.
> the reason is that the users are dependent on FDs as they can import
> buffers allocated from anywhere and there are DSP APIs which takes fd as
> an argument, so they might end up using the same in there skel
> implementation.>
No, DSP API can't take FD, they don't quite cross the OS and IOMMU
boundary. It's the userspace library API. Which might be improved,
rewritten, implemented underneath, etc. For the kernel side please,
pass _only_ GEM handles + offsets.
> >> + /** @pkt_size: Total payload size in bytes */
> >> + u64 pkt_size;
> >> + /** @aligned_pkt_size: Page-aligned payload size for GEM allocation */
> >> + u64 aligned_pkt_size;
> >> + /** @list: Array of invoke buffer descriptors */
> >> + struct fastrpc_invoke_buf *list;
> >> + /** @pages: Array of physical page descriptors for all arguments */
> >> + struct fastrpc_phy_page *pages;
> >> + /** @input_pages: Array of physical page descriptors for input buffers */
> >> + struct fastrpc_phy_page *input_pages;
> >
> > I think you are trying to bring all the complexity from the old driver
> > with no added benefit. Please don't. Use the existing memory manager.
> > Let it handle all the gory details. If someting is not there, we should
> > consider extending GEM instead.
> I'm not changing the metadata format as the DSP might not understand the
> messages if we modify it.
Well, it's up to you to know if DSP will understand the message or not.
The probability ("might not") is not suitable here. Anyway, let's get
rid of the various data formats first, then maybe some of the items will
go away on their own.
> Also, the fd is still being used because of
> the client dependency on it. I'll check if there is any other logic that
> needs alteration here.>
If the client keeps on passing FD to the library calls, you can map
FD to GEM handles in the library code.
> >> +
> >> +static int fastrpc_context_get_id(struct fastrpc_invoke_context *ctx, struct qda_dev *qdev)
> >> +{
> >> + int ret;
> >> + u32 id;
> >> +
> >> + if (!qdev)
> >> + return -EINVAL;
> >> +
> >> + ret = xa_alloc(&qdev->ctx_xa, &id, ctx, xa_limit_32b, GFP_KERNEL);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + ctx->ctxid = id << 4;
> >
> > Why is it being shifted?
> this is to accomodate PD type>
Not really an answer.
> >> + return 0;
> >> +}
> >> +
> >
>
--
With best wishes
Dmitry
^ permalink raw reply
* RE: [PATCH net-next v4 16/16] Documentation: networking: Add timestamp related APIs to OA TC6 framework
From: Selvamani Rajagopal @ 2026-06-07 21:10 UTC (permalink / raw)
To: Randy Dunlap, Andrew Lunn, Piergiorgio Beruto, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Andrew Lunn, Parthiban Veerasooran, Richard Cochran,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Simon Horman,
Jonathan Corbet, Shuah Khan
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Jerry Ray
In-Reply-To: <cf3d6937-1ffa-4d81-8e19-b3f607a7e1d1@infradead.org>
>
> Hi,
> These needs a few additional blank lines to avoid docs build warnings:
Will do. My bad that I didn't verify with make htmldocs after editing the file.
>
> Documentation/networking/oa-tc6-framework.rst:554: WARNING: Explicit markup ends
> without a blank line; unexpected unindent. [docutils]
> Documentation/networking/oa-tc6-framework.rst:561: WARNING: Explicit markup ends
> without a blank line; unexpected unindent. [docutils]
> Documentation/networking/oa-tc6-framework.rst:566: WARNING: Explicit markup ends
> without a blank line; unexpected unindent. [docutils]
> Documentation/networking/oa-tc6-framework.rst:573: WARNING: Explicit markup ends
> without a blank line; unexpected unindent. [docutils]
>
> See below.
>
^ permalink raw reply
* Re: [PATCH RESEND] riscv: enable HAVE_CMPXCHG_{DOUBLE,LOCAL}
From: Miquel Sabaté Solà @ 2026-06-07 20:38 UTC (permalink / raw)
To: Paul Walmsley
Cc: linux-riscv, corbet, skhan, palmer, alex, linux-doc, linux-kernel
In-Reply-To: <f63eefc9-769d-409c-4099-274254432129@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3054 bytes --]
Hi,
Paul Walmsley @ 2026-06-06 18:50 -06:
> Hi,
>
> On Fri, 5 Jun 2026, Miquel Sabaté Solà wrote:
>
>> Support for atomic Compare-And-Swap instructions has been in the RISC-V
>> port of the Linux kernel for a long time. That being said, we apparently
>> never bothered to set HAVE_CMPXCHG_DOUBLE and HAVE_CMPXCHG_LOCAL in the
>> Kconfig, despite having all the framework to support them.
>>
>> Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
>> ---
>> This is a resend of [1], rebased on top of the latest commit from the
>> for-next branch.
>>
>> I have built this patch with multiple configurations and ran it with KVM
>> (the VisionFive2 board that I have lacks the needed extensions). All seems
>> to work, but I do wonder if we did not enable these for a reason or this
>> just slipped through. So far in the code I believe everything is in place,
>> and I haven't seen any commit in the git log stating otherwise.
>>
>> [1] https://lore.kernel.org/all/20260220074449.8526-1-mssola@mssola.com/
>
> Thanks for the patch. Your comments above are why I've been hesitant to
> merge it. I'm not aware of any publicly available hardware that supports
> Zacas/Zabha. No one has stepped forward to provide any Tested-by:s on
> hardware that hasn't been released yet. You mention that you tested on
> your VisionFive2 board, but it would not have exercised those code paths.
No, I mention that I ran it _only_ on KVM, as my VisionFive2 board lacks
these extensions and hence I couldn't possible have tested this there :)
>
> Of course, we already have Zacas/Zabha support, merged back in 2024, in
> cmpxchg.h. I assume (?) that it was tested in QEMU, but I don't see any
> comments about that in the patch series. No one sent any Tested-by:s
> then, either.
>
> It would be good if you (and ideally others) could put this patch through
> some testing on QEMU with Zacas and Zabha enabled, before we merge it.
> The affected code paths for HAVE_CMPXCHG_LOCAL seem to primarily involve
> per-CPU counters and MM zone counters, so those would be the areas to
> focus. HAVE_CMPXCHG_DOUBLE seems to do nothing useful other than
> preventing the AMD IOMMU driver from being selected if it's not present,
> so that part of the patch seems fairly useless. In fact I'd suggest
> dropping that from the patch and just sending a separate patch to remove
> HAVE_CMPXCHG_DOUBLE from the kernel completely.
To be fair, on QEMU I only "tested" it by booting it, running a few
things for some time and ensuring that nothing got totally broken in the
process while taking a look at the kernel logs.
In any case, let me double check with QEMU with these extensions enabled
and I'll try to be more thorough about it. I'll do just that whenever I
have some spare time during the following week :)
As for HAVE_CMPXCHG_DOUBLE, removing it makes sense. Let me just take
another look and I will send a separate patch whenever I'm ready for it.
>
>
> - Paul
Thanks for your input!
Miquel
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply
* Re: [PATCH v6 08/12] PCI: liveupdate: Inherit ACS flags in incoming preserved devices
From: Pranjal Shrivastava @ 2026-06-07 20:37 UTC (permalink / raw)
To: David Matlack
Cc: kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Leon Romanovsky,
Lukas Wunner, Mike Rapoport, Parav Pandit, Pasha Tatashin,
Pratyush Yadav, Saeed Mahameed, Samiullah Khawaja, Shuah Khan,
Vipin Sharma, William Tu, Yi Liu
In-Reply-To: <20260522202410.3104264-9-dmatlack@google.com>
On Fri, May 22, 2026 at 08:24:06PM +0000, David Matlack wrote:
> Inherit Access Control Services (ACS) flags on all incoming preserved
> devices (endpoints and upstream bridges) during a Live Update.
>
> Inheriting ACS flags avoids changing routing rules while memory
> transactions are in flight from preserved devices. This is also strictly
> necessary to ensure that IOMMU group assignments do not change across
> a Live Update for preserved devices, as changing ACS configurations can
> split or merge IOMMU groups.
>
> Cache the inherited ACS controls established by the previous kernel in
> struct pci_dev so that ACS controls do not change after a reset
> (pci_restore_state() calls pci_enable_acs()).
>
> To simplify ACS inheritance, reject preserving any devices that require
> quirks to enable ACS as those quirks would also have to take Live Update
> into account.
>
> Signed-off-by: David Matlack <dmatlack@google.com>
> ---
> drivers/pci/liveupdate.c | 68 ++++++++++++++++++++++++++++++++++
> drivers/pci/liveupdate.h | 11 ++++++
> drivers/pci/pci.c | 5 +++
> drivers/pci/pci.h | 5 +++
> drivers/pci/quirks.c | 7 ++++
> include/linux/pci_liveupdate.h | 6 +++
> 6 files changed, 102 insertions(+)
>
[...]
>
> +void pci_liveupdate_init_acs(struct pci_dev *dev)
> +{
> + guard(rwsem_read)(&pci_liveupdate.rwsem);
> +
> + if (!dev->acs_cap || !dev->liveupdate.incoming)
> + return;
> +
> + pci_read_config_word(dev, dev->acs_cap + PCI_ACS_CTRL, &dev->liveupdate.acs_ctrl);
I might be thinking out loud here, but as an attacker, this motivates me
to somehow hack the EP FW to mis-report the PCI_ACS_CTRL register across
a liveupdate to fool the incoming kernel. If the FW feeds a 0, it silently
strips ACS protections.
Should we also serialize ACS state in ser somehow to ensure we aren't
fooled by something like this?
> +}
> +
> +int pci_liveupdate_enable_acs(struct pci_dev *dev)
> +{
> + u16 acs_ctrl = dev->liveupdate.acs_ctrl;
> + u16 acs_cap = dev->acs_cap;
> +
> + /*
> + * Use liveupdate.was_preserved instead of liveupdate.incoming since the
> + * device's ACS controls should not change even after the device is
> + * finished participating in the Live Update.
> + */
> + if (!dev->liveupdate.was_preserved)
> + return -EINVAL;
> +
> + /*
> + * The previous kernel should not have preserved any devices that
> + * require device-specific quirks to enable ACS, but if such a device is
> + * detected, log a big warning and fall back to the normal enable ACS
> + * path.
> + */
Nit: It might be worth adding a note here that this can also happen if a
new device-specific ACS quirk is introduced in the incoming kernel for a
device that was preserved by the old kernel (which didn't have the quirk).
In such cases, the two kernels are essentially non-LUO-compatible..
> + if (pci_need_dev_specific_enable_acs(dev)) {
> + pci_warn(dev, "Device-specific quirk required to enable ACS!\n");
> + WARN_ON_ONCE(true);
> + return -EINVAL;
> + }
> +
> + if (acs_cap)
> + pci_write_config_word(dev, acs_cap + PCI_ACS_CTRL, acs_ctrl);
> +
> + return 0;
> +}
> +
> /**
> * pci_liveupdate_is_incoming() - Check if a device is incoming-preserved
> * @dev: The PCI device to check
[...]
Thanks,
Praan
^ permalink raw reply
* RE: [PATCH net-next v4 13/16] onsemi: s2500: Add driver support for TS2500 MAC-PHY
From: Selvamani Rajagopal @ 2026-06-07 19:25 UTC (permalink / raw)
To: Randy Dunlap, Andrew Lunn, Piergiorgio Beruto, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Andrew Lunn, Parthiban Veerasooran, Richard Cochran,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Simon Horman,
Jonathan Corbet, Shuah Khan
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org, Jerry Ray
In-Reply-To: <7b100b6a-40c5-407d-8de0-7b1edb82a16c@infradead.org>
> Subject: Re: [PATCH net-next v4 13/16] onsemi: s2500: Add driver support for TS2500
> MAC-PHY
>
> > + the questions about onsemi ethernet devices. If you say Y, you
> > + will be asked for your specific card in the following questions.
>
> Above line should be indented with one tab + spaces.
Sorry about that. Will fix the formatting issue in both Kconfig files,
one under onsemi and one under onsemi/s2500.
> > + /**
>
> Use /*
> since this is not a kernel-doc comment.
>
Yes. will fix it.
> > + * Convert unsigned scaled_ppm to atto-seconds per clock cycles.
> > + * The scaled_ppm format is Qx.16 --> 1 lsb = 1/65536 ppm.
> > + * The clock period of the S2500 is 8ns (125 MHz), so 1 lsb of
^ permalink raw reply
* Re: [PATCH v6 07/12] PCI: Refactor matching logic for pci_dev_acs_ops
From: Pranjal Shrivastava @ 2026-06-07 19:01 UTC (permalink / raw)
To: David Matlack
Cc: kexec, linux-doc, linux-kernel, linux-mm, linux-pci,
Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Leon Romanovsky,
Lukas Wunner, Mike Rapoport, Parav Pandit, Pasha Tatashin,
Pratyush Yadav, Saeed Mahameed, Samiullah Khawaja, Shuah Khan,
Vipin Sharma, William Tu, Yi Liu
In-Reply-To: <20260522202410.3104264-8-dmatlack@google.com>
On Fri, May 22, 2026 at 08:24:05PM +0000, David Matlack wrote:
> Refactor the logic to match devices to pci_dev_acs_ops by factoring out
> the loop and device matching into its own routine. This eliminates some
> duplicate code between pci_dev_specific_enable_acs() and
> pci_dev_specific_disable_acs_redir(), and will also be used in a
> subsequent commit to check if a device requires device-specific
> enable_acs() during a Live Update.
>
> No functional change intended.
>
> Signed-off-by: David Matlack <dmatlack@google.com>
> ---
> drivers/pci/quirks.c | 50 ++++++++++++++++++--------------------------
> 1 file changed, 20 insertions(+), 30 deletions(-)
>
[...]
> } pci_dev_acs_ops[] = {
> { PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
> + .match = pci_quirk_intel_pch_acs_match,
> .enable_acs = pci_quirk_enable_intel_pch_acs,
> },
> { PCI_VENDOR_ID_INTEL, PCI_ANY_ID,
> + .match = pci_quirk_intel_spt_pch_acs_match,
> .enable_acs = pci_quirk_enable_intel_spt_pch_acs,
> .disable_acs_redir = pci_quirk_disable_intel_spt_pch_acs_redir,
> },
> };
>
> -int pci_dev_specific_enable_acs(struct pci_dev *dev)
> +static const struct pci_dev_acs_ops *pci_dev_acs_ops_get(struct pci_dev *dev)
> {
> const struct pci_dev_acs_ops *p;
> - int i, ret;
> + int i;
>
> for (i = 0; i < ARRAY_SIZE(pci_dev_acs_ops); i++) {
> p = &pci_dev_acs_ops[i];
> @@ -5481,33 +5475,29 @@ int pci_dev_specific_enable_acs(struct pci_dev *dev)
> p->vendor == (u16)PCI_ANY_ID) &&
> (p->device == dev->device ||
> p->device == (u16)PCI_ANY_ID) &&
> - p->enable_acs) {
> - ret = p->enable_acs(dev);
> - if (ret >= 0)
> - return ret;
> - }
> + p->match(dev))
> + return p;
Nit:
Should we check if (p->match != NULL) like we check for p->enable_acs &
p->disable_acs_redir().
Otherwise, it seems like we're mandating the existence of a match op in
the pci_dev_acs_ops here? Today, we just have two Intel entries in that
array, both of which need the match op. However, AFAICT, it shouldn't be
mandatory for future SoCs that might only need a simple vid + devid match
[...]
with that nit:
Reviewed-by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
^ permalink raw reply
* Re: [RFC v1 1/9] kho: split out radix tree tracker into kho_radix.c
From: Mike Rapoport @ 2026-06-07 17:59 UTC (permalink / raw)
To: Pasha Tatashin
Cc: Mike Rapoport, linux-kselftest, shuah, akpm, linux-mm, skhan,
linux-doc, jasonmiu, linux-kernel, corbet, ran.xiaokai, kexec,
pratyush, graf
In-Reply-To: <aiWYZhoSOAruIIM3@plex>
On 2026-06-07 16:20:50+00:00, Pasha Tatashin wrote:
> On 06-07 14:58, Mike Rapoport wrote:
>
> > On Fri, 05 Jun 2026 03:32:27 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> >
> > It's radix tree data structure implementation, kho memory tracker is it's
> > user. Please rephrase to keep the semantics clear.
>
> Yeap, I will update it.
>
> > I don't see much value in moving kexec_handover.o to a separate line,
> > btw, the same is true for luo_core.o, but it's not important enough to
> > change.
>
> This is purely for consistency. I wanted to use the exact same style in
> the Makefile instead of having two different ways of declaring the
> object lists.
>
> This:
> luo-y := \
> luo_core.o \
> luo_file.o \
> luo_flb.o \
> luo_session.o
>
> kho-y := \
> kexec_handover.o \
> kho_radix.o \
> kho_block.o \
> kho_vmalloc.o
I mean this:
luo-y := luo_core.o \
luo_file.o \
luo_flb.o \
luo_session.o
kho-y := kexec_handover.o \
kho_radix.o \
kho_block.o \
kho_vmalloc.o
^ permalink raw reply
* Re: [PATCH] ata: pata_legacy: remove documentation for removed module parameters
From: Randy Dunlap @ 2026-06-07 17:13 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-doc
Cc: stable, Jonathan Corbet, Shuah Khan, Damien Le Moal
In-Reply-To: <20260607064053.195166-1-enelsonmoore@gmail.com>
On 6/6/26 11:40 PM, Ethan Nelson-Moore wrote:
> Commit 3c4d783f6922 ("ata: pata_legacy: remove VLB support") removed
> several module parameters from the pata_legacy driver, but neglected to
> remove their documentation. Remove it.
>
> Fixes: 3c4d783f6922 ("ata: pata_legacy: remove VLB support")
> Cc: stable@vger.kernel.org # 7.0+
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> .../admin-guide/kernel-parameters.txt | 37 -------------------
> 1 file changed, 37 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 97007f4f69d4..47bccc148a54 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4935,18 +4935,6 @@ Kernel parameters
> Set to non-zero if a chip is present that snoops speed
> changes. Disabled by default.
>
> - pata_legacy.ht6560a= [HW,LIBATA]
> - Format: <int>
> - Set to 1, 2, or 3 for HT 6560A on the primary channel,
> - the secondary channel, or both channels respectively.
> - Disabled by default.
> -
> - pata_legacy.ht6560b= [HW,LIBATA]
> - Format: <int>
> - Set to 1, 2, or 3 for HT 6560B on the primary channel,
> - the secondary channel, or both channels respectively.
> - Disabled by default.
> -
> pata_legacy.iordy_mask= [HW,LIBATA]
> Format: <int>
> IORDY enable mask. Set individual bits to allow IORDY
> @@ -4959,18 +4947,6 @@ Kernel parameters
> with the sequence. By default IORDY is allowed across
> all channels.
>
> - pata_legacy.opti82c46x= [HW,LIBATA]
> - Format: <int>
> - Set to 1, 2, or 3 for Opti 82c611A on the primary
> - channel, the secondary channel, or both channels
> - respectively. Disabled by default.
> -
> - pata_legacy.opti82c611a= [HW,LIBATA]
> - Format: <int>
> - Set to 1, 2, or 3 for Opti 82c465MV on the primary
> - channel, the secondary channel, or both channels
> - respectively. Disabled by default.
> -
> pata_legacy.pio_mask= [HW,LIBATA]
> Format: <int>
> PIO mode mask for autospeed devices. Set individual
> @@ -4994,19 +4970,6 @@ Kernel parameters
> the first port in the list above (0x1f0), and so on.
> By default all supported ports are probed.
>
> - pata_legacy.qdi= [HW,LIBATA]
> - Format: <int>
> - Set to non-zero to probe QDI controllers. By default
> - set to 1 if CONFIG_PATA_QDI_MODULE, 0 otherwise.
> -
> - pata_legacy.winbond= [HW,LIBATA]
> - Format: <int>
> - Set to non-zero to probe Winbond controllers. Use
> - the standard I/O port (0x130) if 1, otherwise the
> - value given is the I/O port to use (typically 0x1b0).
> - By default set to 1 if CONFIG_PATA_WINBOND_VLB_MODULE,
> - 0 otherwise.
> -
> pata_platform.pio_mask= [HW,LIBATA]
> Format: <int>
> Supported PIO mode mask. Set individual bits to allow
--
~Randy
^ permalink raw reply
* [netfilter-nf-next:for-netdev-nf-next-26-06-07 1/15] htmldocs: Documentation/networking/ipvs-sysctl.rst:76: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
From: kernel test robot @ 2026-06-07 17:02 UTC (permalink / raw)
To: Julian Anastasov; +Cc: oe-kbuild-all, Pablo Neira Ayuso, linux-doc
tree: https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git for-netdev-nf-next-26-06-07
head: d3bf9eae486490832bd08fd62ab0ac601f346bd4
commit: 4a15044a2b06748c99a8c8c3c6b3ee0a01f8004d [1/15] ipvs: add conn_max sysctl to limit connections
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project f43d6834093b19baf79beda8c0337ab020ac5f17)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260607/202606071851.Dc1H7hOO-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606071851.Dc1H7hOO-lkp@intel.com/
All warnings (new ones prefixed by >>):
Checksumming on output with GSO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [docutils]
>> Documentation/networking/ipvs-sysctl.rst:76: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Documentation/networking/ipvs-sysctl.rst:76: ERROR: Unexpected section title or transition.
vim +76 Documentation/networking/ipvs-sysctl.rst
9
10 am_droprate - INTEGER
11 default 10
12
13 It sets the always mode drop rate, which is used in the mode 3
14 of the drop_rate defense.
15
16 amemthresh - INTEGER
17 default 1024
18
19 It sets the available memory threshold (in pages), which is
20 used in the automatic modes of defense. When there is no
21 enough available memory, the respective strategy will be
22 enabled and the variable is automatically set to 2, otherwise
23 the strategy is disabled and the variable is set to 1.
24
25 backup_only - BOOLEAN
26 - 0 - disabled (default)
27 - not 0 - enabled
28
29 If set, disable the director function while the server is
30 in backup mode to avoid packet loops for DR/TUN methods.
31
32 conn_lfactor - INTEGER
33 Possible values: -8 (larger table) .. 8 (smaller table)
34
35 Default: -4
36
37 Controls the sizing of the connection hash table based on the
38 load factor (number of connections per table buckets):
39
40 2^conn_lfactor = nodes / buckets
41
42 As result, the table grows if load increases and shrinks when
43 load decreases in the range of 2^8 - 2^conn_tab_bits (module
44 parameter).
45 The value is a shift count where negative values select
46 buckets = (connection hash nodes << -value) while positive
47 values select buckets = (connection hash nodes >> value). The
48 negative values reduce the collisions and reduce the time for
49 lookups but increase the table size. Positive values will
50 tolerate load above 100% when using smaller table is
51 preferred with the cost of more collisions. If using NAT
52 connections consider decreasing the value with one because
53 they add two nodes in the hash table.
54
55 Example:
56 -4: grow if load goes above 6% (buckets = nodes * 16)
57 2: grow if load goes above 400% (buckets = nodes / 4)
58
59 conn_max - INTEGER
60 Limit for number of connections, per netns.
61
62 Controls the soft and hard limit for number of connections.
63 Initially, the platform specific limit is assigned for init_net.
64 The value can be changed and later the soft limit propagated
65 to other networking namespaces.
66
67 Privileged admin can change both limits up to the value of the
68 platform limit while the unprivileged admin can change only the
69 soft limit up to the value of the hard limit.
70
71 For setups using conntrack=1 (CONFIG_IP_VS_NFCT for
72 Netfilter connection tracking) the connections can be
73 limited also by nf_conntrack_max.
74
75 soft limit hard limit
> 76 =====================================================
77 init_net:
78 create netns platform platform
79 priv admin 0 .. platform 0 .. platform
80 =====================================================
81 new netns:
82 create netns init_net:soft init_net:soft
83 priv admin 0 .. platform 0 .. platform
84 unpriv admin 0 .. hard N/A
85
86 Limits per platform:
87 1,073,741,824 (2^30 for 64-bit)
88 16,777,216 (2^24 for 32-bit)
89
90 Possible values: 0 .. platform limit
91
92 Default: platform limit
93
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [RFC v1 1/9] kho: split out radix tree tracker into kho_radix.c
From: Pasha Tatashin @ 2026-06-07 16:20 UTC (permalink / raw)
To: Mike Rapoport
Cc: Pasha Tatashin, linux-kselftest, shuah, akpm, linux-mm, skhan,
linux-doc, jasonmiu, linux-kernel, corbet, ran.xiaokai, kexec,
pratyush, graf
In-Reply-To: <178083348873.1648214.11020626647820932506.b4-review@b4>
On 06-07 14:58, Mike Rapoport wrote:
> On Fri, 05 Jun 2026 03:32:27 +0000, Pasha Tatashin <pasha.tatashin@soleen.com> wrote:
> > Move the radix tree tracker implementation from the core KHO code
>
> It's radix tree data structure implementation, kho memory tracker is it's
> user. Please rephrase to keep the semantics clear.
Yeap, I will update it.
>
> >
> >
> > diff --git a/kernel/liveupdate/Makefile b/kernel/liveupdate/Makefile
> > index eec9d3ae07eb..a3ee8a5c27a2 100644
> > --- a/kernel/liveupdate/Makefile
> > +++ b/kernel/liveupdate/Makefile
> > @@ -7,7 +7,11 @@ luo-y := \
> > luo_flb.o \
> > luo_session.o
> >
> > -obj-$(CONFIG_KEXEC_HANDOVER) += kexec_handover.o
> > +kho-y := \
> > + kexec_handover.o \
>
> I don't see much value in moving kexec_handover.o to a separate line,
> btw, the same is true for luo_core.o, but it's not important enough to
> change.
This is purely for consistency. I wanted to use the exact same style in
the Makefile instead of having two different ways of declaring the
object lists.
This:
luo-y := \
luo_core.o \
luo_file.o \
luo_flb.o \
luo_session.o
kho-y := \
kexec_handover.o \
kho_radix.o \
kho_block.o \
kho_vmalloc.o
Or this:
obj-$(CONFIG_LIVEUPDATE) += luo_core.o
obj-$(CONFIG_LIVEUPDATE) += luo_file.o
obj-$(CONFIG_LIVEUPDATE) += luo_flb.o
obj-$(CONFIG_LIVEUPDATE) += luo_session.o
obj-$(CONFIG_KEXEC_HANDOVER) += kexec_handover.o
obj-$(CONFIG_KEXEC_HANDOVER) += kho_radix.o
obj-$(CONFIG_KEXEC_HANDOVER) += kho_vmalloc.o
obj-$(CONFIG_KEXEC_HANDOVER) += kho_block.o
I do not care which way is chosen as long as it is consistent. Since
this series adds new separate files for KHO, and does not touch LUO, I
used LUO as template, but we can do the other way around.
^ permalink raw reply
* Re: [PATCH v2] docs/mm/slab: document cache isolation with SLAB_NO_MERGE
From: Vishal Moola @ 2026-06-07 16:04 UTC (permalink / raw)
To: Mohammed EL Kadiri
Cc: Jonathan Corbet, Andrew Morton, Vlastimil Babka, Matthew Wilcox,
David Hildenbrand, Lorenzo Stoakes, Kees Cook, linux-mm,
linux-doc, linux-hardening, linux-kernel
In-Reply-To: <20260607070645.9559-1-med08elkadiri@gmail.com>
On Sun, Jun 07, 2026 at 08:06:45AM +0100, Mohammed EL Kadiri wrote:
> Add documentation to slab.rst explaining when and how to use
> SLAB_NO_MERGE to protect security-critical slab caches from
> cross-cache heap exploitation.
Thanks for helping improve the documentation. I haven't looked at the
patch, but have some comments in regards to the process.
We prefer to send new iterations of patches as separate threads,
with the exception being small fixes/cleanups.
Also, I'd recommend waiting a bit longer between versions to let the
maintainers comment since getting documentation is pretty particular.
^ permalink raw reply
* [PATCH 0/3] x86/vdso: improve vdso=/vdso32= boot parameter validation
From: Thorsten Blum @ 2026-06-07 15:16 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andrew Morton, Jonathan Corbet,
Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel, Thorsten Blum
Replace the deprecated simple_strtoul() [1] with kstrtouint() when
parsing the vDSO boot parameters. This provides strict input validation,
rejects partial input, and warns when disabling vDSO for invalid values.
Adjust both warnings for consistency and update the documentation.
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull
Thorsten Blum (3):
x86/vdso: use kstrtouint() to validate vdso= boot parameter
x86/vdso: use kstrtouint() to validate vdso32= boot parameter
Documentation/arch/x86: remove obsolete vdso32=2 compatibility note
Documentation/admin-guide/kernel-parameters.txt | 5 +----
arch/x86/entry/vdso/vdso32-setup.c | 10 ++++------
arch/x86/entry/vdso/vma.c | 6 +++++-
3 files changed, 10 insertions(+), 11 deletions(-)
base-commit: 979c294509f9248fe1e7c358d582fb37dd5ca12d
^ permalink raw reply
* [PATCH 3/3] Documentation/arch/x86: remove obsolete vdso32=2 compatibility note
From: Thorsten Blum @ 2026-06-07 15:16 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andrew Morton, Jonathan Corbet,
Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel, Thorsten Blum
In-Reply-To: <20260607151614.79567-5-thorsten.blum@linux.dev>
Commit b0b49f2673f0 ("x86, vdso: Remove compat vdso support") removed
compat vDSO support and documented vdso32=2 as an alias for vdso32=0.
However, since commit c06989da39cd ("x86/vdso: Ensure vdso32_enabled
gets set to valid values only"), vdso32_setup() accepts only 0 and 1.
Remove the obsolete vdso32=2 compatibility note and document only the
supported values.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Documentation/admin-guide/kernel-parameters.txt | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 97007f4f69d4..ce1c630d6859 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -8249,15 +8249,12 @@ Kernel parameters
vdso32= [X86] Control the 32-bit vDSO
vdso32=1: enable 32-bit VDSO
- vdso32=0 or vdso32=2: disable 32-bit VDSO
+ vdso32=0: disable 32-bit VDSO
See the help text for CONFIG_COMPAT_VDSO for more
details. If CONFIG_COMPAT_VDSO is set, the default is
vdso32=0; otherwise, the default is vdso32=1.
- For compatibility with older kernels, vdso32=2 is an
- alias for vdso32=0.
-
Try vdso32=0 if you encounter an error that says:
dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
^ permalink raw reply related
* [PATCH 2/3] x86/vdso: use kstrtouint() to validate vdso32= boot parameter
From: Thorsten Blum @ 2026-06-07 15:16 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andrew Morton, Jonathan Corbet,
Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel, Thorsten Blum
In-Reply-To: <20260607151614.79567-5-thorsten.blum@linux.dev>
Replace the deprecated simple_strtoul() with kstrtouint() when parsing
the vdso32= boot parameter and its X86_32 vdso= alias.
simple_strtoul() accepts partial input and silently converts invalid
input to 0. Use kstrtouint() for strict input validation instead and
reject malformed input. Accept only 0 and 1; warn and disable vDSO
support otherwise.
kstrtouint() converts the input string directly to an unsigned int,
avoiding an implicit conversion when assigning to vdso32_enabled.
Update the vdso32= handler comment to reflect the supported values.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
arch/x86/entry/vdso/vdso32-setup.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/x86/entry/vdso/vdso32-setup.c b/arch/x86/entry/vdso/vdso32-setup.c
index 8894013eea1d..5f3e548ebf19 100644
--- a/arch/x86/entry/vdso/vdso32-setup.c
+++ b/arch/x86/entry/vdso/vdso32-setup.c
@@ -30,10 +30,8 @@ unsigned int __read_mostly vdso32_enabled = VDSO_DEFAULT;
static int __init vdso32_setup(char *s)
{
- vdso32_enabled = simple_strtoul(s, NULL, 0);
-
- if (vdso32_enabled > 1) {
- pr_warn("vdso32 values other than 0 and 1 are no longer allowed; vdso disabled\n");
+ if (kstrtouint(s, 0, &vdso32_enabled) || vdso32_enabled > 1) {
+ pr_warn("vdso32= values other than 0 and 1 are invalid; vdso disabled\n");
vdso32_enabled = 0;
}
@@ -41,9 +39,9 @@ static int __init vdso32_setup(char *s)
}
/*
- * For consistency, the argument vdso32=[012] affects the 32-bit vDSO
+ * For consistency, the argument vdso32=[01] affects the 32-bit vDSO
* behavior on both 64-bit and 32-bit kernels.
- * On 32-bit kernels, vdso=[012] means the same thing.
+ * On 32-bit kernels, vdso=[01] means the same thing.
*/
__setup("vdso32=", vdso32_setup);
^ permalink raw reply related
* [PATCH 1/3] x86/vdso: use kstrtouint() to validate vdso= boot parameter
From: Thorsten Blum @ 2026-06-07 15:16 UTC (permalink / raw)
To: Andy Lutomirski, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andrew Morton, Jonathan Corbet,
Shuah Khan, Randy Dunlap
Cc: x86, linux-doc, linux-kernel, Thorsten Blum
In-Reply-To: <20260607151614.79567-5-thorsten.blum@linux.dev>
Replace the deprecated simple_strtoul() with kstrtouint() when parsing
the vdso= boot parameter.
simple_strtoul() accepts partial input and silently converts invalid
input to 0. Use kstrtouint() for strict input validation instead and
reject malformed input. Accept only 0 and 1; warn and disable vDSO
support otherwise.
kstrtouint() converts the input string directly to an unsigned int,
avoiding an implicit conversion when assigning to vdso64_enabled.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
arch/x86/entry/vdso/vma.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index d903bce24f15..b45549cd7acf 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -270,7 +270,11 @@ bool arch_syscall_is_vdso_sigreturn(struct pt_regs *regs)
#ifdef CONFIG_X86_64
static __init int vdso_setup(char *s)
{
- vdso64_enabled = simple_strtoul(s, NULL, 0);
+ if (kstrtouint(s, 0, &vdso64_enabled) || vdso64_enabled > 1) {
+ pr_warn("vdso= values other than 0 and 1 are invalid; vdso disabled\n");
+ vdso64_enabled = 0;
+ }
+
return 1;
}
__setup("vdso=", vdso_setup);
^ permalink raw reply related
* Re: [PATCH v1] docs: omap/dss: Fix stale modedb.c path
From: Helge Deller @ 2026-06-07 15:10 UTC (permalink / raw)
To: Costa Shulyupin, Jonathan Corbet, Shuah Khan, Randy Dunlap,
linux-omap, linux-fbdev, linux-doc, linux-kernel
In-Reply-To: <20260531140325.4115024-1-costa.shul@redhat.com>
On 5/31/26 16:03, Costa Shulyupin wrote:
> The modedb.c file was moved from drivers/video/ to
> drivers/video/fbdev/core/. Update the reference.
>
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
> ---
> Documentation/arch/arm/omap/dss.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
applied.
Thanks!
Helge
^ 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