* Re: [PATCH v5 00/21] Virtual Swap Space
From: Nhat Pham @ 2026-04-12 1:03 UTC (permalink / raw)
To: YoungJun Park
Cc: Kairui Song, Liam.Howlett, akpm, apopple, axelrasmussen, baohua,
baolin.wang, bhe, byungchul, cgroups, chengming.zhou, chrisl,
corbet, david, dev.jain, gourry, hannes, hughd, jannh,
joshua.hahnjy, lance.yang, lenb, linux-doc, linux-kernel,
linux-mm, linux-pm, lorenzo.stoakes, matthew.brost, mhocko,
muchun.song, npache, pavel, peterx, peterz, pfalcato, rafael,
rakie.kim, roman.gushchin, rppt, ryan.roberts, shakeel.butt,
shikemeng, surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed,
yuanchu, zhengqi.arch, ziy, kernel-team, riel
In-Reply-To: <acQvNRLpHwnHt7i+@yjaykim-PowerEdge-T330>
On Wed, Mar 25, 2026 at 11:53 AM YoungJun Park <youngjun.park@lge.com> wrote:
>
> On Mon, Mar 23, 2026 at 11:32:57AM -0400, Nhat Pham wrote:
>
> > Interesting. Normally "lots of zero-filled page" is a very beneficial
> > case for vswap. You don't need a swapfile, or any zram/zswap metadata
> > overhead - it's a native swap backend. If production workload has this
> > many zero-filled pages, I think the numbers of vswap would be much
> > less alarming - perhaps even matching memory overhead because you
> > don't need to maintain a zram entry metadata (it's at least 2 words
> > per zram entry right?), while there's no reverse map overhead induced
> > (so it's 24 bytes on both side), and no need to do zram-side locking
> > :)
> >
> > So I was surprised to see that it's not working out very well here. I
> > checked the implementation of memhog - let me know if this is wrong
> > place to look:
> >
> > https://man7.org/linux/man-pages/man8/memhog.8.html
> > https://github.com/numactl/numactl/blob/master/memhog.c#L52
> >
> > I think this is what happened here: memhog was populating the memory
> > 0xff, which triggers the full overhead of a swapfile-backed swap entry
> > because even though it's "same-filled" it's not zero-filled! I was
> > following Usama's observation - "less than 1% of the same-filled pages
> > were non-zero" - and so I only handled the zero-filled case here:
> >
> > https://lore.kernel.org/all/20240530102126.357438-1-usamaarif642@gmail.com/
> >
> > This sounds a bit artificial IMHO - as Usama pointed out above, I
> > think most samefilled pages are zero pages, in real production
> > workloads. However, if you think there are real use cases with a lot
> > of non-zero samefilled pages, please let me know I can fix this real
> > quick. We can support this in vswap with zero extra metadata overhead
> > - change the VSWAP_ZERO swap entry type to VSWAP_SAME_FILLED, then use
> > the backend field to store that value. I can send you a patch if
> > you're interested.
>
> This brings back memories -- I'm pretty sure we talked about
> exactly this at LPC. Our custom swap device already handles both
> zero-filled and same-filled pages on its own, so what we really
> wanted was a way to tell the swap layer "just skip the detection
> and let it through."
>
> I looked at two approaches back then but never submitted either:
>
> - A per-swap_info flag to opt out of zero/same-filled handling.
> But this felt wrong from vswap's perspective -- if even one
> device opts out of the zeromap, the model gets messy.
>
> - Revisiting Usama's patch 2 approach.
> Sounded good in theory, but as you said,
> it's not as simple to verify in practice. And it is more clean design
> swapout time zero check as I see. So, I gave up on it.
>
> Seeing this come up again is actually kind of nice :)
>
> One thought -- maybe a compile-time CONFIG or a boot param to
> control the scope? e.g. zero-only, same-filled, or disabled.
> That way vendors like us just turn it off, and setups like
> Kairui's can opt into broader detection. Just an idea though --
> open to other approaches if you have something in mind.
Yeah for vswap it's probably going to be a CONFIG or boot param.
But in the status quo, we can always add a swapfile flag. That one
should work already, right?
Thanks for thinking about it :) FWIW I think zero check is really
cheap, but yeah it's just wasted work.
(ZRAM folks - do you feel the overhead here?)
>
> Thanks,
> Youngjun Park
>
^ permalink raw reply
* Re: [PATCH 2/2] thermal/drivers/imxl:Fix runtime PM handling on early returns
From: Frank Li @ 2026-04-12 1:00 UTC (permalink / raw)
To: Felix Gu
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel, linux-pm, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260412-imx-v1-2-cc3b45d63811@gmail.com>
On Sun, Apr 12, 2026 at 03:03:04AM +0800, Felix Gu wrote:
> Use PM_RUNTIME_ACQUIRE() in imx_get_temp() and imx_set_trip_temp() so
> runtime PM references are released correctly even when the functions
> return early on errors.
>
> Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support")
> Signed-off-by: Felix Gu <ustc.gu@gmail.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/thermal/imx_thermal.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
> index 68f9ce41a670..9d9ae7871068 100644
> --- a/drivers/thermal/imx_thermal.c
> +++ b/drivers/thermal/imx_thermal.c
> @@ -260,8 +260,9 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
> u32 val;
> int ret;
>
> - ret = pm_runtime_resume_and_get(data->dev);
> - if (ret < 0)
> + PM_RUNTIME_ACQUIRE(data->dev, pm);
> + ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
> + if (ret)
> return ret;
>
> regmap_read(map, soc_data->temp_data, &val);
> @@ -302,8 +303,6 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
> enable_irq(data->irq);
> }
>
> - pm_runtime_put(data->dev);
> -
> return 0;
> }
>
> @@ -337,8 +336,9 @@ static int imx_set_trip_temp(struct thermal_zone_device *tz,
> struct imx_thermal_data *data = thermal_zone_device_priv(tz);
> int ret;
>
> - ret = pm_runtime_resume_and_get(data->dev);
> - if (ret < 0)
> + PM_RUNTIME_ACQUIRE(data->dev, pm);
> + ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
> + if (ret)
> return ret;
>
> /* do not allow passive to be set higher than critical */
> @@ -348,8 +348,6 @@ static int imx_set_trip_temp(struct thermal_zone_device *tz,
> imx_set_alarm_temp(data, temp);
> trips[IMX_TRIP_PASSIVE].temperature = temp;
>
> - pm_runtime_put(data->dev);
> -
> return 0;
> }
>
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH 1/2] thermal/drivers/imx: Fix thermal zone leak on probe error path
From: Frank Li @ 2026-04-12 0:58 UTC (permalink / raw)
To: Felix Gu
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel, linux-pm, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260412-imx-v1-1-cc3b45d63811@gmail.com>
On Sun, Apr 12, 2026 at 03:03:03AM +0800, Felix Gu wrote:
> If pm_runtime_resume_and_get() fails after the thermal zone has been
> registered, the probe error path cleans up runtime PM but skips
> thermal_zone_device_unregister(), leaking the thermal zone device.
>
> Move thermal_zone_device_unregister() into disable_runtime_pm so all
Use devm_thermal_of_zone_register() to fix this problem
Frank
^ permalink raw reply
* [PATCH 2/2] thermal/drivers/imxl:Fix runtime PM handling on early returns
From: Felix Gu @ 2026-04-11 19:03 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Felix Gu
In-Reply-To: <20260412-imx-v1-0-cc3b45d63811@gmail.com>
Use PM_RUNTIME_ACQUIRE() in imx_get_temp() and imx_set_trip_temp() so
runtime PM references are released correctly even when the functions
return early on errors.
Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/thermal/imx_thermal.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 68f9ce41a670..9d9ae7871068 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -260,8 +260,9 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
u32 val;
int ret;
- ret = pm_runtime_resume_and_get(data->dev);
- if (ret < 0)
+ PM_RUNTIME_ACQUIRE(data->dev, pm);
+ ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+ if (ret)
return ret;
regmap_read(map, soc_data->temp_data, &val);
@@ -302,8 +303,6 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
enable_irq(data->irq);
}
- pm_runtime_put(data->dev);
-
return 0;
}
@@ -337,8 +336,9 @@ static int imx_set_trip_temp(struct thermal_zone_device *tz,
struct imx_thermal_data *data = thermal_zone_device_priv(tz);
int ret;
- ret = pm_runtime_resume_and_get(data->dev);
- if (ret < 0)
+ PM_RUNTIME_ACQUIRE(data->dev, pm);
+ ret = PM_RUNTIME_ACQUIRE_ERR(&pm);
+ if (ret)
return ret;
/* do not allow passive to be set higher than critical */
@@ -348,8 +348,6 @@ static int imx_set_trip_temp(struct thermal_zone_device *tz,
imx_set_alarm_temp(data, temp);
trips[IMX_TRIP_PASSIVE].temperature = temp;
- pm_runtime_put(data->dev);
-
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] thermal/drivers/imx: Fix thermal zone leak on probe error path
From: Felix Gu @ 2026-04-11 19:03 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Felix Gu
In-Reply-To: <20260412-imx-v1-0-cc3b45d63811@gmail.com>
If pm_runtime_resume_and_get() fails after the thermal zone has been
registered, the probe error path cleans up runtime PM but skips
thermal_zone_device_unregister(), leaking the thermal zone device.
Move thermal_zone_device_unregister() into disable_runtime_pm so all
failures after thermal zone registration unwind the probe path
correctly.
Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/thermal/imx_thermal.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 38c993d1bcb3..68f9ce41a670 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -727,25 +727,24 @@ static int imx_thermal_probe(struct platform_device *pdev)
data->irq_enabled = true;
ret = thermal_zone_device_enable(data->tz);
if (ret)
- goto thermal_zone_unregister;
+ goto disable_runtime_pm;
ret = devm_request_threaded_irq(dev, data->irq,
imx_thermal_alarm_irq, imx_thermal_alarm_irq_thread,
0, "imx_thermal", data);
if (ret < 0) {
dev_err(dev, "failed to request alarm irq: %d\n", ret);
- goto thermal_zone_unregister;
+ goto disable_runtime_pm;
}
pm_runtime_put(data->dev);
return 0;
-thermal_zone_unregister:
- thermal_zone_device_unregister(data->tz);
disable_runtime_pm:
pm_runtime_put_noidle(data->dev);
pm_runtime_disable(data->dev);
+ thermal_zone_device_unregister(data->tz);
clk_disable:
clk_disable_unprepare(data->thermal_clk);
legacy_cleanup:
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] thermal/drivers/imx: two fixes
From: Felix Gu @ 2026-04-11 19:03 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel
Cc: linux-pm, imx, linux-arm-kernel, linux-kernel, Felix Gu
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
Felix Gu (2):
thermal/drivers/imx: Fix thermal zone leak on probe error path
thermal/drivers/imxl:Fix runtime PM handling on early returns
drivers/thermal/imx_thermal.c | 21 +++++++++------------
1 file changed, 9 insertions(+), 12 deletions(-)
---
base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
change-id: 20260411-imx-b022791ea1b9
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply
* [PATCH v4 2/4] serdev: add rust private data to serdev_device
From: Markus Probst via B4 Relay @ 2026-04-11 15:10 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Miguel Ojeda,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Kari Argillander,
Rafael J. Wysocki, Viresh Kumar, Boqun Feng, David Airlie,
Simona Vetter, Boqun Feng
Cc: linux-serial, linux-kernel, rust-for-linux, linux-pm, driver-core,
dri-devel, Markus Probst
In-Reply-To: <20260411-rust_serdev-v4-0-845e960c6627@posteo.de>
From: Markus Probst <markus.probst@posteo.de>
Add rust private data to `struct serdev_device`, as it is required by the
rust abstraction added in the following commit
(rust: add basic serial device bus abstractions).
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
include/linux/serdev.h | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/include/linux/serdev.h b/include/linux/serdev.h
index 5654c58eb73c..c74c345d60ae 100644
--- a/include/linux/serdev.h
+++ b/include/linux/serdev.h
@@ -33,12 +33,14 @@ struct serdev_device_ops {
/**
* struct serdev_device - Basic representation of an serdev device
- * @dev: Driver model representation of the device.
- * @nr: Device number on serdev bus.
- * @ctrl: serdev controller managing this device.
- * @ops: Device operations.
- * @write_comp Completion used by serdev_device_write() internally
- * @write_lock Lock to serialize access when writing data
+ * @dev: Driver model representation of the device.
+ * @nr: Device number on serdev bus.
+ * @ctrl: serdev controller managing this device.
+ * @ops: Device operations.
+ * @write_comp: Completion used by serdev_device_write() internally
+ * @write_lock: Lock to serialize access when writing data
+ * @rust_private_data: Private data for the rust abstraction. This should
+ * not be used by the C drivers.
*/
struct serdev_device {
struct device dev;
@@ -47,6 +49,7 @@ struct serdev_device {
const struct serdev_device_ops *ops;
struct completion write_comp;
struct mutex write_lock;
+ void *rust_private_data;
};
static inline struct serdev_device *to_serdev_device(struct device *d)
--
2.52.0
^ permalink raw reply related
* [PATCH v4 1/4] rust: devres: return reference in `devres::register`
From: Markus Probst via B4 Relay @ 2026-04-11 15:10 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Miguel Ojeda,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Kari Argillander,
Rafael J. Wysocki, Viresh Kumar, Boqun Feng, David Airlie,
Simona Vetter, Boqun Feng
Cc: linux-serial, linux-kernel, rust-for-linux, linux-pm, driver-core,
dri-devel, Markus Probst
In-Reply-To: <20260411-rust_serdev-v4-0-845e960c6627@posteo.de>
From: Markus Probst <markus.probst@posteo.de>
Return the reference to the initialized data in the `devres::register`
function.
This is needed in a following commit (rust: add basic serial device bus
abstractions).
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
rust/kernel/cpufreq.rs | 3 ++-
rust/kernel/devres.rs | 15 +++++++++++++--
rust/kernel/drm/driver.rs | 3 ++-
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
index f5adee48d40c..31bf7e685097 100644
--- a/rust/kernel/cpufreq.rs
+++ b/rust/kernel/cpufreq.rs
@@ -1052,7 +1052,8 @@ pub fn new_foreign_owned(dev: &Device<Bound>) -> Result
where
T: 'static,
{
- devres::register(dev, Self::new()?, GFP_KERNEL)
+ devres::register(dev, Self::new()?, GFP_KERNEL)?;
+ Ok(())
}
}
diff --git a/rust/kernel/devres.rs b/rust/kernel/devres.rs
index 6afe196be42c..f882bace8601 100644
--- a/rust/kernel/devres.rs
+++ b/rust/kernel/devres.rs
@@ -326,15 +326,26 @@ fn register_foreign<P>(dev: &Device<Bound>, data: P) -> Result
/// }
///
/// fn from_bound_context(dev: &Device<Bound>) -> Result {
-/// devres::register(dev, Registration::new(), GFP_KERNEL)
+/// devres::register(dev, Registration::new(), GFP_KERNEL)?;
+/// Ok(())
/// }
/// ```
-pub fn register<T, E>(dev: &Device<Bound>, data: impl PinInit<T, E>, flags: Flags) -> Result
+pub fn register<'a, T, E>(
+ dev: &'a Device<Bound>,
+ data: impl PinInit<T, E>,
+ flags: Flags,
+) -> Result<&'a T>
where
T: Send + 'static,
Error: From<E>,
{
let data = KBox::pin_init(data, flags)?;
+ let data_ptr = &raw const *data;
+
register_foreign(dev, data)
+ // SAFETY: `dev` is valid for the lifetime of 'a. As long as there is a reference to
+ // `Device<Bound>`, it is guaranteed that the device is not unbound and data has not been
+ // dropped. Thus `data_ptr` is also valid for the lifetime of 'a.
+ .map(|()| unsafe { &*data_ptr })
}
diff --git a/rust/kernel/drm/driver.rs b/rust/kernel/drm/driver.rs
index e09f977b5b51..51e0c7e30cc2 100644
--- a/rust/kernel/drm/driver.rs
+++ b/rust/kernel/drm/driver.rs
@@ -145,7 +145,8 @@ pub fn new_foreign_owned(
let reg = Registration::<T>::new(drm, flags)?;
- devres::register(dev, reg, GFP_KERNEL)
+ devres::register(dev, reg, GFP_KERNEL)?;
+ Ok(())
}
/// Returns a reference to the `Device` instance for this registration.
--
2.52.0
^ permalink raw reply related
* [PATCH v4 4/4] samples: rust: add Rust serial device bus sample device driver
From: Markus Probst via B4 Relay @ 2026-04-11 15:10 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Miguel Ojeda,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Kari Argillander,
Rafael J. Wysocki, Viresh Kumar, Boqun Feng, David Airlie,
Simona Vetter, Boqun Feng
Cc: linux-serial, linux-kernel, rust-for-linux, linux-pm, driver-core,
dri-devel, Markus Probst
In-Reply-To: <20260411-rust_serdev-v4-0-845e960c6627@posteo.de>
From: Markus Probst <markus.probst@posteo.de>
Add a sample Rust serial device bus device driver illustrating the usage
of the serial device bus abstractions.
This drivers probes through either a match of device / driver name or a
match within the OF ID table.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
samples/rust/Kconfig | 11 +++++
samples/rust/Makefile | 1 +
samples/rust/rust_driver_serdev.rs | 86 ++++++++++++++++++++++++++++++++++++++
3 files changed, 98 insertions(+)
diff --git a/samples/rust/Kconfig b/samples/rust/Kconfig
index c49ab9106345..31d62533ef25 100644
--- a/samples/rust/Kconfig
+++ b/samples/rust/Kconfig
@@ -161,6 +161,17 @@ config SAMPLE_RUST_DRIVER_AUXILIARY
If unsure, say N.
+config SAMPLE_RUST_DRIVER_SERDEV
+ tristate "Serial Device Bus Device Driver"
+ select RUST_SERIAL_DEV_BUS_ABSTRACTIONS
+ help
+ This option builds the Rust serial device bus driver sample.
+
+ To compile this as a module, choose M here:
+ the module will be called rust_driver_serdev.
+
+ If unsure, say N.
+
config SAMPLE_RUST_SOC
tristate "SoC Driver"
select SOC_BUS
diff --git a/samples/rust/Makefile b/samples/rust/Makefile
index 6c0aaa58cccc..b986b681cde5 100644
--- a/samples/rust/Makefile
+++ b/samples/rust/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_SAMPLE_RUST_DRIVER_PLATFORM) += rust_driver_platform.o
obj-$(CONFIG_SAMPLE_RUST_DRIVER_USB) += rust_driver_usb.o
obj-$(CONFIG_SAMPLE_RUST_DRIVER_FAUX) += rust_driver_faux.o
obj-$(CONFIG_SAMPLE_RUST_DRIVER_AUXILIARY) += rust_driver_auxiliary.o
+obj-$(CONFIG_SAMPLE_RUST_DRIVER_SERDEV) += rust_driver_serdev.o
obj-$(CONFIG_SAMPLE_RUST_CONFIGFS) += rust_configfs.o
obj-$(CONFIG_SAMPLE_RUST_SOC) += rust_soc.o
diff --git a/samples/rust/rust_driver_serdev.rs b/samples/rust/rust_driver_serdev.rs
new file mode 100644
index 000000000000..8cf3fb451b22
--- /dev/null
+++ b/samples/rust/rust_driver_serdev.rs
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Rust Serial device bus device driver sample.
+
+use kernel::{
+ acpi,
+ device::{
+ Bound,
+ Core, //
+ },
+ of,
+ prelude::*,
+ serdev,
+ sync::aref::ARef, //
+};
+
+struct SampleDriver {
+ sdev: ARef<serdev::Device>,
+}
+
+kernel::of_device_table!(
+ OF_TABLE,
+ MODULE_OF_TABLE,
+ <SampleDriver as serdev::Driver>::IdInfo,
+ [(of::DeviceId::new(c"test,rust_driver_serdev"), ())]
+);
+
+kernel::acpi_device_table!(
+ ACPI_TABLE,
+ MODULE_ACPI_TABLE,
+ <SampleDriver as serdev::Driver>::IdInfo,
+ [(acpi::DeviceId::new(c"LNUXBEEF"), ())]
+);
+
+#[vtable]
+impl serdev::Driver for SampleDriver {
+ type IdInfo = ();
+ const OF_ID_TABLE: Option<of::IdTable<Self::IdInfo>> = Some(&OF_TABLE);
+ const ACPI_ID_TABLE: Option<acpi::IdTable<Self::IdInfo>> = Some(&ACPI_TABLE);
+
+ fn probe(
+ sdev: &serdev::Device<Core>,
+ _info: Option<&Self::IdInfo>,
+ ) -> impl PinInit<Self, Error> {
+ let dev = sdev.as_ref();
+
+ dev_dbg!(dev, "Probe Rust Serial device bus device driver sample.\n");
+
+ if sdev
+ .set_baudrate(
+ dev.fwnode()
+ .and_then(|fwnode| fwnode.property_read(c"baudrate").optional())
+ .unwrap_or(115200),
+ )
+ .is_err()
+ {
+ return Err(EINVAL);
+ }
+ sdev.set_flow_control(false);
+ sdev.set_parity(serdev::Parity::None)?;
+
+ Ok(Self { sdev: sdev.into() })
+ }
+
+ fn receive(sdev: &serdev::Device<Bound>, _this: Pin<&Self>, data: &[u8]) -> usize {
+ let _ = sdev.write_all(data, serdev::Timeout::Max);
+ data.len()
+ }
+}
+
+impl Drop for SampleDriver {
+ fn drop(&mut self) {
+ dev_dbg!(
+ self.sdev.as_ref(),
+ "Remove Rust Serial device bus device driver sample.\n"
+ );
+ }
+}
+
+kernel::module_serdev_device_driver! {
+ type: SampleDriver,
+ name: "rust_driver_serdev",
+ authors: ["Markus Probst"],
+ description: "Rust Serial device bus device driver",
+ license: "GPL v2",
+}
--
2.52.0
^ permalink raw reply related
* [PATCH v4 3/4] rust: add basic serial device bus abstractions
From: Markus Probst via B4 Relay @ 2026-04-11 15:10 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Miguel Ojeda,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Kari Argillander,
Rafael J. Wysocki, Viresh Kumar, Boqun Feng, David Airlie,
Simona Vetter, Boqun Feng
Cc: linux-serial, linux-kernel, rust-for-linux, linux-pm, driver-core,
dri-devel, Markus Probst
In-Reply-To: <20260411-rust_serdev-v4-0-845e960c6627@posteo.de>
From: Markus Probst <markus.probst@posteo.de>
Implement the basic serial device bus abstractions required to write a
serial device bus device driver with or without the need for initial device
data. This includes the following data structures:
The `serdev::Driver` trait represents the interface to the driver.
The `serdev::Device` abstraction represents a `struct serdev_device`.
In order to provide the Serdev specific parts to a generic
`driver::Registration` the `driver::RegistrationOps` trait is
implemented by `serdev::Adapter`.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
drivers/tty/serdev/Kconfig | 7 +
rust/bindings/bindings_helper.h | 1 +
rust/helpers/helpers.c | 1 +
rust/helpers/serdev.c | 22 ++
rust/kernel/lib.rs | 2 +
rust/kernel/serdev.rs | 536 ++++++++++++++++++++++++++++++++++++++++
6 files changed, 569 insertions(+)
diff --git a/drivers/tty/serdev/Kconfig b/drivers/tty/serdev/Kconfig
index 46ae732bfc68..e6dfe949ad01 100644
--- a/drivers/tty/serdev/Kconfig
+++ b/drivers/tty/serdev/Kconfig
@@ -9,6 +9,13 @@ menuconfig SERIAL_DEV_BUS
Note that you typically also want to enable TTY port controller support.
+config RUST_SERIAL_DEV_BUS_ABSTRACTIONS
+ bool "Rust Serial device bus abstractions"
+ depends on RUST
+ select SERIAL_DEV_BUS
+ help
+ This enables the Rust abstraction for the serial device bus API.
+
if SERIAL_DEV_BUS
config SERIAL_DEV_CTRL_TTYPORT
diff --git a/rust/bindings/bindings_helper.h b/rust/bindings/bindings_helper.h
index 083cc44aa952..ab521ba42673 100644
--- a/rust/bindings/bindings_helper.h
+++ b/rust/bindings/bindings_helper.h
@@ -80,6 +80,7 @@
#include <linux/regulator/consumer.h>
#include <linux/sched.h>
#include <linux/security.h>
+#include <linux/serdev.h>
#include <linux/slab.h>
#include <linux/sys_soc.h>
#include <linux/task_work.h>
diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c
index a3c42e51f00a..9b87e9591cfd 100644
--- a/rust/helpers/helpers.c
+++ b/rust/helpers/helpers.c
@@ -53,6 +53,7 @@
#include "regulator.c"
#include "scatterlist.c"
#include "security.c"
+#include "serdev.c"
#include "signal.c"
#include "slab.c"
#include "spinlock.c"
diff --git a/rust/helpers/serdev.c b/rust/helpers/serdev.c
new file mode 100644
index 000000000000..c52b78ca3fc7
--- /dev/null
+++ b/rust/helpers/serdev.c
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/serdev.h>
+
+__rust_helper
+void rust_helper_serdev_device_driver_unregister(struct serdev_device_driver *sdrv)
+{
+ serdev_device_driver_unregister(sdrv);
+}
+
+__rust_helper
+void rust_helper_serdev_device_put(struct serdev_device *serdev)
+{
+ serdev_device_put(serdev);
+}
+
+__rust_helper
+void rust_helper_serdev_device_set_client_ops(struct serdev_device *serdev,
+ const struct serdev_device_ops *ops)
+{
+ serdev_device_set_client_ops(serdev, ops);
+}
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index d93292d47420..5107c9c1be07 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -144,6 +144,8 @@
pub mod scatterlist;
pub mod security;
pub mod seq_file;
+#[cfg(CONFIG_RUST_SERIAL_DEV_BUS_ABSTRACTIONS)]
+pub mod serdev;
pub mod sizes;
pub mod slice;
#[cfg(CONFIG_SOC_BUS)]
diff --git a/rust/kernel/serdev.rs b/rust/kernel/serdev.rs
new file mode 100644
index 000000000000..d9fea4bd4439
--- /dev/null
+++ b/rust/kernel/serdev.rs
@@ -0,0 +1,536 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Abstractions for the serial device bus.
+//!
+//! C header: [`include/linux/serdev.h`](srctree/include/linux/serdev.h)
+
+use crate::{
+ acpi,
+ device,
+ devres,
+ driver,
+ error::{
+ from_result,
+ to_result,
+ VTABLE_DEFAULT_ERROR, //
+ },
+ of,
+ prelude::*,
+ sync::Completion,
+ time::{
+ msecs_to_jiffies,
+ Jiffies,
+ Msecs, //
+ },
+ types::{
+ AlwaysRefCounted,
+ Opaque, //
+ }, //
+};
+
+use core::{
+ cell::UnsafeCell,
+ marker::PhantomData,
+ mem::offset_of,
+ num::NonZero,
+ ptr::NonNull, //
+};
+
+/// Parity bit to use with a serial device.
+#[repr(u32)]
+pub enum Parity {
+ /// No parity bit.
+ None = bindings::serdev_parity_SERDEV_PARITY_NONE,
+ /// Even partiy.
+ Even = bindings::serdev_parity_SERDEV_PARITY_EVEN,
+ /// Odd parity.
+ Odd = bindings::serdev_parity_SERDEV_PARITY_ODD,
+}
+
+/// Timeout in Jiffies.
+pub enum Timeout {
+ /// Wait for a specific amount of [`Jiffies`].
+ Jiffies(NonZero<Jiffies>),
+ /// Wait for a specific amount of [`Msecs`].
+ Milliseconds(NonZero<Msecs>),
+ /// Wait as long as possible.
+ ///
+ /// This is equivalent to [`kernel::task::MAX_SCHEDULE_TIMEOUT`].
+ Max,
+}
+
+impl Timeout {
+ fn into_jiffies(self) -> isize {
+ match self {
+ Self::Jiffies(value) => value.get().try_into().unwrap_or_default(),
+ Self::Milliseconds(value) => {
+ msecs_to_jiffies(value.get()).try_into().unwrap_or_default()
+ }
+ Self::Max => 0,
+ }
+ }
+}
+
+/// An adapter for the registration of serial device bus device drivers.
+pub struct Adapter<T: Driver>(T);
+
+// SAFETY:
+// - `bindings::serdev_device_driver` is a C type declared as `repr(C)`.
+// - `Drvdata<T>` is the type of the driver's device private data.
+// - `struct serdev_device_driver` embeds a `struct device_driver`.
+// - `DEVICE_DRIVER_OFFSET` is the correct byte offset to the embedded `struct device_driver`.
+unsafe impl<T: Driver + 'static> driver::DriverLayout for Adapter<T> {
+ type DriverType = bindings::serdev_device_driver;
+ type DriverData = T;
+ const DEVICE_DRIVER_OFFSET: usize = core::mem::offset_of!(Self::DriverType, driver);
+}
+
+// SAFETY: A call to `unregister` for a given instance of `DriverType` is guaranteed to be valid if
+// a preceding call to `register` has been successful.
+unsafe impl<T: Driver + 'static> driver::RegistrationOps for Adapter<T> {
+ unsafe fn register(
+ sdrv: &Opaque<Self::DriverType>,
+ name: &'static CStr,
+ module: &'static ThisModule,
+ ) -> Result {
+ let of_table = match T::OF_ID_TABLE {
+ Some(table) => table.as_ptr(),
+ None => core::ptr::null(),
+ };
+
+ let acpi_table = match T::ACPI_ID_TABLE {
+ Some(table) => table.as_ptr(),
+ None => core::ptr::null(),
+ };
+
+ // SAFETY: It's safe to set the fields of `struct serdev_device_driver` on initialization.
+ unsafe {
+ (*sdrv.get()).driver.name = name.as_char_ptr();
+ (*sdrv.get()).probe = Some(Self::probe_callback);
+ (*sdrv.get()).remove = Some(Self::remove_callback);
+ (*sdrv.get()).driver.of_match_table = of_table;
+ (*sdrv.get()).driver.acpi_match_table = acpi_table;
+ }
+
+ // SAFETY: `sdrv` is guaranteed to be a valid `DriverType`.
+ to_result(unsafe { bindings::__serdev_device_driver_register(sdrv.get(), module.0) })
+ }
+
+ unsafe fn unregister(sdrv: &Opaque<Self::DriverType>) {
+ // SAFETY: `sdrv` is guaranteed to be a valid `DriverType`.
+ unsafe { bindings::serdev_device_driver_unregister(sdrv.get()) };
+ }
+}
+
+#[pin_data]
+struct PrivateData {
+ #[pin]
+ probe_complete: Completion,
+ error: UnsafeCell<bool>,
+}
+
+impl<T: Driver + 'static> Adapter<T> {
+ const OPS: &'static bindings::serdev_device_ops = &bindings::serdev_device_ops {
+ receive_buf: if T::HAS_RECEIVE {
+ Some(Self::receive_buf_callback)
+ } else {
+ None
+ },
+ write_wakeup: Some(bindings::serdev_device_write_wakeup),
+ };
+
+ extern "C" fn probe_callback(sdev: *mut bindings::serdev_device) -> kernel::ffi::c_int {
+ // SAFETY: The serial device bus only ever calls the probe callback with a valid pointer to
+ // a `struct serdev_device`.
+ //
+ // INVARIANT: `sdev` is valid for the duration of `probe_callback()`.
+ let sdev = unsafe { &*sdev.cast::<Device<device::CoreInternal>>() };
+ let id_info = <Self as driver::Adapter>::id_info(sdev.as_ref());
+
+ from_result(|| {
+ let private_data = devres::register(
+ sdev.as_ref(),
+ try_pin_init!(PrivateData {
+ probe_complete <- Completion::new(),
+ error: false.into(),
+ }),
+ GFP_KERNEL,
+ )?;
+
+ // SAFETY: `sdev.as_raw()` is guaranteed to be a valid pointer to `serdev_device`.
+ unsafe {
+ (*sdev.as_raw()).rust_private_data =
+ (&raw const *private_data).cast::<c_void>().cast_mut()
+ };
+
+ // SAFETY: `sdev.as_raw()` is guaranteed to be a valid pointer to `serdev_device`.
+ unsafe { bindings::serdev_device_set_client_ops(sdev.as_raw(), Self::OPS) };
+
+ // SAFETY: The serial device bus only ever calls the probe callback with a valid pointer
+ // to a `serdev_device`.
+ to_result(unsafe {
+ bindings::devm_serdev_device_open(sdev.as_ref().as_raw(), sdev.as_raw())
+ })?;
+
+ let data = T::probe(sdev, id_info);
+ let result = sdev.as_ref().set_drvdata(data);
+
+ // SAFETY: We have exclusive access to `private_data.error`.
+ unsafe { *private_data.error.get() = result.is_err() };
+
+ private_data.probe_complete.complete_all();
+
+ result.map(|()| 0)
+ })
+ }
+
+ extern "C" fn remove_callback(sdev: *mut bindings::serdev_device) {
+ // SAFETY: The serial device bus only ever calls the remove callback with a valid pointer
+ // to a `struct serdev_device`.
+ //
+ // INVARIANT: `sdev` is valid for the duration of `remove_callback()`.
+ let sdev = unsafe { &*sdev.cast::<Device<device::CoreInternal>>() };
+
+ // SAFETY: `remove_callback` is only ever called after a successful call to
+ // `probe_callback`, hence it's guaranteed that `Device::set_drvdata()` has been called
+ // and stored a `Pin<KBox<T>>`.
+ let data = unsafe { sdev.as_ref().drvdata_borrow::<T>() };
+
+ T::unbind(sdev, data);
+ }
+
+ extern "C" fn receive_buf_callback(
+ sdev: *mut bindings::serdev_device,
+ buf: *const u8,
+ length: usize,
+ ) -> usize {
+ // SAFETY: The serial device bus only ever calls the receive buf callback with a valid
+ // pointer to a `struct serdev_device`.
+ //
+ // INVARIANT: `sdev` is valid for the duration of `receive_buf_callback()`.
+ let sdev = unsafe { &*sdev.cast::<Device<device::CoreInternal>>() };
+
+ // SAFETY:
+ // - The serial device bus only ever calls the receive buf callback with a valid pointer to
+ // a `struct serdev_device`.
+ // - `receive_buf_callback` is only ever called after a successful call to
+ // `probe_callback`, hence it's guaranteed that `sdev.private_data` is a pointer
+ // to a valid `PrivateData`.
+ let private_data = unsafe { &*(*sdev.as_raw()).rust_private_data.cast::<PrivateData>() };
+
+ private_data.probe_complete.wait_for_completion();
+
+ // SAFETY: No one has exclusive access to `private_data.error`.
+ if unsafe { *private_data.error.get() } {
+ return length;
+ }
+
+ // SAFETY: `receive_buf_callback` is only ever called after a successful call to
+ // `probe_callback`, hence it's guaranteed that `Device::set_drvdata()` has been called
+ // and stored a `Pin<KBox<T>>`.
+ let data = unsafe { sdev.as_ref().drvdata_borrow::<T>() };
+
+ // SAFETY: `buf` is guaranteed to be non-null and has the size of `length`.
+ let buf = unsafe { core::slice::from_raw_parts(buf, length) };
+
+ T::receive(sdev, data, buf)
+ }
+}
+
+impl<T: Driver + 'static> driver::Adapter for Adapter<T> {
+ type IdInfo = T::IdInfo;
+
+ fn of_id_table() -> Option<of::IdTable<Self::IdInfo>> {
+ T::OF_ID_TABLE
+ }
+
+ fn acpi_id_table() -> Option<acpi::IdTable<Self::IdInfo>> {
+ T::ACPI_ID_TABLE
+ }
+}
+
+/// Declares a kernel module that exposes a single serial device bus device driver.
+///
+/// # Examples
+///
+/// ```ignore
+/// kernel::module_serdev_device_driver! {
+/// type: MyDriver,
+/// name: "Module name",
+/// authors: ["Author name"],
+/// description: "Description",
+/// license: "GPL v2",
+/// }
+/// ```
+#[macro_export]
+macro_rules! module_serdev_device_driver {
+ ($($f:tt)*) => {
+ $crate::module_driver!(<T>, $crate::serdev::Adapter<T>, { $($f)* });
+ };
+}
+
+/// The serial device bus device driver trait.
+///
+/// Drivers must implement this trait in order to get a serial device bus device driver registered.
+///
+/// # Examples
+///
+///```
+/// # use kernel::{
+/// acpi,
+/// bindings,
+/// device::{
+/// Bound,
+/// Core, //
+/// },
+/// of,
+/// serdev, //
+/// };
+///
+/// struct MyDriver;
+///
+/// kernel::of_device_table!(
+/// OF_TABLE,
+/// MODULE_OF_TABLE,
+/// <MyDriver as serdev::Driver>::IdInfo,
+/// [
+/// (of::DeviceId::new(c"test,device"), ())
+/// ]
+/// );
+///
+/// kernel::acpi_device_table!(
+/// ACPI_TABLE,
+/// MODULE_ACPI_TABLE,
+/// <MyDriver as serdev::Driver>::IdInfo,
+/// [
+/// (acpi::DeviceId::new(c"LNUXBEEF"), ())
+/// ]
+/// );
+///
+/// #[vtable]
+/// impl serdev::Driver for MyDriver {
+/// type IdInfo = ();
+/// const OF_ID_TABLE: Option<of::IdTable<Self::IdInfo>> = Some(&OF_TABLE);
+/// const ACPI_ID_TABLE: Option<acpi::IdTable<Self::IdInfo>> = Some(&ACPI_TABLE);
+///
+/// fn probe(
+/// sdev: &serdev::Device<Core>,
+/// _id_info: Option<&Self::IdInfo>,
+/// ) -> impl PinInit<Self, Error> {
+/// sdev.set_baudrate(115200);
+/// sdev.write_all(b"Hello\n", serdev::Timeout::Max)?;
+/// Ok(MyDriver)
+/// }
+/// }
+///```
+#[vtable]
+pub trait Driver: Send {
+ /// The type holding driver private data about each device id supported by the driver.
+ // TODO: Use associated_type_defaults once stabilized:
+ //
+ // ```
+ // type IdInfo: 'static = ();
+ // ```
+ type IdInfo: 'static;
+
+ /// The table of OF device ids supported by the driver.
+ const OF_ID_TABLE: Option<of::IdTable<Self::IdInfo>> = None;
+
+ /// The table of ACPI device ids supported by the driver.
+ const ACPI_ID_TABLE: Option<acpi::IdTable<Self::IdInfo>> = None;
+
+ /// Serial device bus device driver probe.
+ ///
+ /// Called when a new serial device bus device is added or discovered.
+ /// Implementers should attempt to initialize the device here.
+ fn probe(
+ sdev: &Device<device::Core>,
+ id_info: Option<&Self::IdInfo>,
+ ) -> impl PinInit<Self, Error>;
+
+ /// Serial device bus device driver unbind.
+ ///
+ /// Called when a [`Device`] is unbound from its bound [`Driver`]. Implementing this callback
+ /// is optional.
+ ///
+ /// This callback serves as a place for drivers to perform teardown operations that require a
+ /// `&Device<Core>` or `&Device<Bound>` reference. For instance.
+ ///
+ /// Otherwise, release operations for driver resources should be performed in `Self::drop`.
+ fn unbind(sdev: &Device<device::Core>, this: Pin<&Self>) {
+ let _ = (sdev, this);
+ }
+
+ /// Serial device bus device data receive callback.
+ ///
+ /// Called when data got received from device.
+ ///
+ /// Returns the number of bytes accepted.
+ fn receive(sdev: &Device<device::Bound>, this: Pin<&Self>, data: &[u8]) -> usize {
+ let _ = (sdev, this, data);
+ build_error!(VTABLE_DEFAULT_ERROR)
+ }
+}
+
+/// The serial device bus device representation.
+///
+/// This structure represents the Rust abstraction for a C `struct serdev_device`. The
+/// implementation abstracts the usage of an already existing C `struct serdev_device` within Rust
+/// code that we get passed from the C side.
+///
+/// # Invariants
+///
+/// A [`Device`] instance represents a valid `struct serdev_device` created by the C portion of
+/// the kernel.
+#[repr(transparent)]
+pub struct Device<Ctx: device::DeviceContext = device::Normal>(
+ Opaque<bindings::serdev_device>,
+ PhantomData<Ctx>,
+);
+
+impl<Ctx: device::DeviceContext> Device<Ctx> {
+ fn as_raw(&self) -> *mut bindings::serdev_device {
+ self.0.get()
+ }
+}
+
+impl Device<device::Bound> {
+ /// Set the baudrate in bits per second.
+ ///
+ /// Common baudrates are 115200, 9600, 19200, 57600, 4800.
+ ///
+ /// Use [`Device::write_flush`] before calling this if you have written data prior to this call.
+ pub fn set_baudrate(&self, speed: u32) -> Result<(), u32> {
+ // SAFETY: `self.as_raw()` is guaranteed to be a pointer to a valid `serdev_device`.
+ let ret = unsafe { bindings::serdev_device_set_baudrate(self.as_raw(), speed) };
+ if ret == speed {
+ Ok(())
+ } else {
+ Err(ret)
+ }
+ }
+
+ /// Set if flow control should be enabled.
+ ///
+ /// Use [`Device::write_flush`] before calling this if you have written data prior to this call.
+ pub fn set_flow_control(&self, enable: bool) {
+ // SAFETY: `self.as_raw()` is guaranteed to be a pointer to a valid `serdev_device`.
+ unsafe { bindings::serdev_device_set_flow_control(self.as_raw(), enable) };
+ }
+
+ /// Set parity to use.
+ ///
+ /// Use [`Device::write_flush`] before calling this if you have written data prior to this call.
+ pub fn set_parity(&self, parity: Parity) -> Result {
+ // SAFETY: `self.as_raw()` is guaranteed to be a pointer to a valid `serdev_device`.
+ to_result(unsafe { bindings::serdev_device_set_parity(self.as_raw(), parity as u32) })
+ }
+
+ /// Write data to the serial device until the controller has accepted all the data or has
+ /// been interrupted by a timeout or signal.
+ ///
+ /// Note that any accepted data has only been buffered by the controller. Use
+ /// [ Device::wait_until_sent`] to make sure the controller write buffer has actually been
+ /// emptied.
+ ///
+ /// Returns the number of bytes written (less than `data.len()` if interrupted).
+ /// [`kernel::error::code::ETIMEDOUT`] or [`kernel::error::code::ERESTARTSYS`] if interrupted
+ /// before any bytes were written.
+ pub fn write_all(&self, data: &[u8], timeout: Timeout) -> Result<usize> {
+ // SAFETY:
+ // - `self.as_raw()` is guaranteed to be a pointer to a valid `serdev_device`.
+ // - `data.as_ptr()` is guaranteed to be a valid array pointer with the size of
+ // `data.len()`.
+ let ret = unsafe {
+ bindings::serdev_device_write(
+ self.as_raw(),
+ data.as_ptr(),
+ data.len(),
+ timeout.into_jiffies(),
+ )
+ };
+ // CAST: negative return values are guaranteed to be between `-MAX_ERRNO` and `-1`,
+ // which always fit into a `i32`.
+ to_result(ret as i32).map(|()| ret.unsigned_abs())
+ }
+
+ /// Write data to the serial device.
+ ///
+ /// If you want to write until the controller has accepted all the data, use
+ /// [`Device::write_all`].
+ ///
+ /// Note that any accepted data has only been buffered by the controller. Use
+ /// [ Device::wait_until_sent`] to make sure the controller write buffer has actually been
+ /// emptied.
+ ///
+ /// Returns the number of bytes written (less than `data.len()` if not enough room in the
+ /// write buffer).
+ pub fn write(&self, data: &[u8]) -> Result<u32> {
+ // SAFETY:
+ // - `self.as_raw()` is guaranteed to be a pointer to a valid `serdev_device`.
+ // - `data.as_ptr()` is guaranteed to be a valid array pointer with the size of
+ // `data.len()`.
+ let ret =
+ unsafe { bindings::serdev_device_write_buf(self.as_raw(), data.as_ptr(), data.len()) };
+
+ to_result(ret as i32).map(|()| ret.unsigned_abs())
+ }
+
+ /// Send data to the serial device immediately.
+ ///
+ /// Note that this doesn't guarantee that the data has been transmitted.
+ /// Use [`Device::wait_until_sent`] for this purpose.
+ pub fn write_flush(&self) {
+ // SAFETY: `self.as_raw()` is guaranteed to be a pointer to a valid `serdev_device`.
+ unsafe { bindings::serdev_device_write_flush(self.as_raw()) };
+ }
+
+ /// Wait for the data to be sent.
+ ///
+ /// After this function, the write buffer of the controller should be empty.
+ pub fn wait_until_sent(&self, timeout: Timeout) {
+ // SAFETY: `self.as_raw()` is guaranteed to be a pointer to a valid `serdev_device`.
+ unsafe { bindings::serdev_device_wait_until_sent(self.as_raw(), timeout.into_jiffies()) };
+ }
+}
+
+// SAFETY: `serdev::Device` is a transparent wrapper of `struct serdev_device`.
+// The offset is guaranteed to point to a valid device field inside `serdev::Device`.
+unsafe impl<Ctx: device::DeviceContext> device::AsBusDevice<Ctx> for Device<Ctx> {
+ const OFFSET: usize = offset_of!(bindings::serdev_device, dev);
+}
+
+// SAFETY: `Device` is a transparent wrapper of a type that doesn't depend on `Device`'s generic
+// argument.
+kernel::impl_device_context_deref!(unsafe { Device });
+kernel::impl_device_context_into_aref!(Device);
+
+// SAFETY: Instances of `Device` are always reference-counted.
+unsafe impl AlwaysRefCounted for Device {
+ fn inc_ref(&self) {
+ self.as_ref().inc_ref();
+ }
+
+ unsafe fn dec_ref(obj: NonNull<Self>) {
+ // SAFETY: The safety requirements guarantee that the refcount is non-zero.
+ unsafe { bindings::serdev_device_put(obj.cast().as_ptr()) }
+ }
+}
+
+impl<Ctx: device::DeviceContext> AsRef<device::Device<Ctx>> for Device<Ctx> {
+ fn as_ref(&self) -> &device::Device<Ctx> {
+ // SAFETY: By the type invariant of `Self`, `self.as_raw()` is a pointer to a valid
+ // `struct serdev_device`.
+ let dev = unsafe { &raw mut (*self.as_raw()).dev };
+
+ // SAFETY: `dev` points to a valid `struct device`.
+ unsafe { device::Device::from_raw(dev) }
+ }
+}
+
+// SAFETY: A `Device` is always reference-counted and can be released from any thread.
+unsafe impl Send for Device {}
+
+// SAFETY: `Device` can be shared among threads because all methods of `Device`
+// (i.e. `Device<Normal>) are thread safe.
+unsafe impl Sync for Device {}
--
2.52.0
^ permalink raw reply related
* [PATCH v4 0/4] rust: add basic serial device bus abstractions
From: Markus Probst via B4 Relay @ 2026-04-11 15:10 UTC (permalink / raw)
To: Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Miguel Ojeda,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Danilo Krummrich, Kari Argillander,
Rafael J. Wysocki, Viresh Kumar, Boqun Feng, David Airlie,
Simona Vetter, Boqun Feng
Cc: linux-serial, linux-kernel, rust-for-linux, linux-pm, driver-core,
dri-devel, Markus Probst
This patch series adds the serdev device bus rust abstraction into the
kernel.
This abstraction will be used by a driver,
which targets the MCU devices in Synology devices.
Kari Argillander also messaged me, stating that he wants to write a
watchdog driver with this abstraction (needing initial device data).
@Rob: Are you willing to maintain these rust abstractions yourself,
as you are the expert on this subsystem, otherwise I would take care of
it with a "SERIAL DEVICE BUS [RUST]" section in the MAINTAINERS file. In
the second case, I assume you are going to pick those patches as-is into
your tree, after they have been reviewed?
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
Changes in v4:
- fixed not selecting rust serdev abstraction in sample
- Link to v3: https://lore.kernel.org/r/20260313-rust_serdev-v3-0-c9a3af214f7f@posteo.de
Changes in v3:
- fix vertical import style
- add Kconfig entry for the rust abstraction
- fix documentation in include/linux/serdev.h
- rename private_data to rust_private_data
- fix `complete_all` <-> `wait_for_completion` typo
- move drvdata_borrow call after the completion
- Link to v2: https://lore.kernel.org/r/20260306-rust_serdev-v2-0-e9b23b42b255@posteo.de
Changes in v2:
- fix documentation in `serdev::Driver::write` and
`serdev::Driver::write_all`
- remove use of `dev_info` in probe from the sample
- remove `properties_parse` from the sample
- add optional `baudrate` property to the sample
- remove 1. patch
- remove `TryFrom<&device::Device<Ctx>> for &serdev::Device<Ctx>`
implementation
- fix import style
- add patch to return reference in `devres::register` to fix safety
issue
- add patch to add private data to serdev_device, to fix
`Device.drvdata()` from failing
- simplify abstraction by removing ability to receive the initial
transmission. It may be added later in a separate patch series if
needed.
- Link to v1: https://lore.kernel.org/r/20251220-rust_serdev-v1-0-e44645767621@posteo.de
---
Markus Probst (4):
rust: devres: return reference in `devres::register`
serdev: add rust private data to serdev_device
rust: add basic serial device bus abstractions
samples: rust: add Rust serial device bus sample device driver
drivers/tty/serdev/Kconfig | 7 +
include/linux/serdev.h | 15 +-
rust/bindings/bindings_helper.h | 1 +
rust/helpers/helpers.c | 1 +
rust/helpers/serdev.c | 22 ++
rust/kernel/cpufreq.rs | 3 +-
rust/kernel/devres.rs | 15 +-
rust/kernel/drm/driver.rs | 3 +-
rust/kernel/lib.rs | 2 +
rust/kernel/serdev.rs | 536 +++++++++++++++++++++++++++++++++++++
samples/rust/Kconfig | 11 +
samples/rust/Makefile | 1 +
samples/rust/rust_driver_serdev.rs | 86 ++++++
13 files changed, 693 insertions(+), 10 deletions(-)
---
base-commit: c369299895a591d96745d6492d4888259b004a9e
change-id: 20251217-rust_serdev-ee5481e9085c
^ permalink raw reply
* [rafael-pm:bleeding-edge] BUILD SUCCESS 78d494b2959512914fdfc4f6261363642040151f
From: kernel test robot @ 2026-04-11 12:17 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-acpi, linux-pm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge
branch HEAD: 78d494b2959512914fdfc4f6261363642040151f Merge branch 'experimental/acpi-driver-conversion' into bleeding-edge
elapsed time: 1134m
configs tested: 152
configs skipped: 6
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig gcc-15.2.0
arc allnoconfig gcc-15.2.0
arc allyesconfig gcc-15.2.0
arc defconfig gcc-15.2.0
arc randconfig-001-20260411 gcc-12.5.0
arc randconfig-002-20260411 gcc-8.5.0
arm allnoconfig clang-23
arm allyesconfig gcc-15.2.0
arm randconfig-001-20260411 gcc-14.3.0
arm randconfig-002-20260411 clang-23
arm randconfig-003-20260411 clang-23
arm randconfig-004-20260411 clang-23
arm64 allnoconfig gcc-15.2.0
arm64 randconfig-001-20260411 clang-23
arm64 randconfig-002-20260411 clang-23
arm64 randconfig-003-20260411 clang-16
arm64 randconfig-004-20260411 clang-19
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky randconfig-001-20260411 gcc-12.5.0
csky randconfig-002-20260411 gcc-15.2.0
hexagon allmodconfig clang-17
hexagon allnoconfig clang-23
hexagon randconfig-001-20260411 clang-23
hexagon randconfig-002-20260411 clang-23
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allyesconfig gcc-14
i386 buildonly-randconfig-001-20260411 clang-20
i386 buildonly-randconfig-002-20260411 clang-20
i386 buildonly-randconfig-003-20260411 clang-20
i386 buildonly-randconfig-004-20260411 clang-20
i386 buildonly-randconfig-005-20260411 gcc-14
i386 buildonly-randconfig-006-20260411 gcc-14
i386 randconfig-001-20260411 clang-20
i386 randconfig-002-20260411 clang-20
i386 randconfig-003-20260411 clang-20
i386 randconfig-004-20260411 clang-20
i386 randconfig-005-20260411 gcc-14
i386 randconfig-006-20260411 gcc-13
i386 randconfig-007-20260411 clang-20
i386 randconfig-011-20260411 clang-20
i386 randconfig-012-20260411 gcc-14
i386 randconfig-013-20260411 gcc-14
i386 randconfig-014-20260411 gcc-14
i386 randconfig-015-20260411 clang-20
i386 randconfig-016-20260411 gcc-14
i386 randconfig-017-20260411 gcc-14
loongarch allnoconfig clang-23
loongarch defconfig clang-19
loongarch randconfig-001-20260411 gcc-14.3.0
loongarch randconfig-002-20260411 clang-18
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig gcc-15.2.0
m68k defconfig gcc-15.2.0
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig gcc-15.2.0
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig gcc-11.5.0
nios2 defconfig gcc-11.5.0
nios2 randconfig-001-20260411 gcc-9.5.0
nios2 randconfig-002-20260411 gcc-11.5.0
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig gcc-15.2.0
parisc allyesconfig gcc-15.2.0
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260411 gcc-10.5.0
parisc randconfig-002-20260411 gcc-11.5.0
parisc64 defconfig gcc-15.2.0
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig gcc-15.2.0
powerpc randconfig-001-20260411 clang-17
powerpc randconfig-002-20260411 clang-17
powerpc64 randconfig-001-20260411 clang-16
powerpc64 randconfig-002-20260411 gcc-11.5.0
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig clang-23
riscv randconfig-001-20260411 clang-17
riscv randconfig-002-20260411 gcc-10.5.0
s390 allmodconfig clang-18
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig clang-23
s390 randconfig-001-20260411 gcc-8.5.0
s390 randconfig-002-20260411 gcc-8.5.0
sh allmodconfig gcc-15.2.0
sh allnoconfig gcc-15.2.0
sh allyesconfig gcc-15.2.0
sh defconfig gcc-15.2.0
sh randconfig-001-20260411 gcc-12.5.0
sh randconfig-002-20260411 gcc-12.5.0
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260411 gcc-8.5.0
sparc randconfig-002-20260411 gcc-15.2.0
sparc64 allmodconfig clang-23
sparc64 defconfig clang-20
sparc64 randconfig-001-20260411 gcc-15.2.0
sparc64 randconfig-002-20260411 gcc-11.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-14
um defconfig clang-23
um i386_defconfig gcc-14
um randconfig-001-20260411 gcc-14
um randconfig-002-20260411 gcc-14
um x86_64_defconfig clang-23
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260411 gcc-14
x86_64 buildonly-randconfig-002-20260411 clang-20
x86_64 buildonly-randconfig-003-20260411 gcc-13
x86_64 buildonly-randconfig-004-20260411 gcc-14
x86_64 buildonly-randconfig-005-20260411 gcc-14
x86_64 buildonly-randconfig-006-20260411 gcc-14
x86_64 defconfig gcc-14
x86_64 randconfig-001-20260411 gcc-12
x86_64 randconfig-002-20260411 gcc-14
x86_64 randconfig-003-20260411 gcc-14
x86_64 randconfig-004-20260411 clang-20
x86_64 randconfig-005-20260411 clang-20
x86_64 randconfig-006-20260411 gcc-12
x86_64 randconfig-011-20260411 gcc-14
x86_64 randconfig-012-20260411 clang-20
x86_64 randconfig-013-20260411 gcc-14
x86_64 randconfig-014-20260411 clang-20
x86_64 randconfig-015-20260411 gcc-14
x86_64 randconfig-016-20260411 clang-20
x86_64 randconfig-071-20260411 clang-20
x86_64 randconfig-072-20260411 clang-20
x86_64 randconfig-073-20260411 gcc-14
x86_64 randconfig-074-20260411 clang-20
x86_64 randconfig-075-20260411 gcc-14
x86_64 randconfig-076-20260411 gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig gcc-15.2.0
xtensa generic_kc705_defconfig gcc-15.2.0
xtensa randconfig-001-20260411 gcc-15.2.0
xtensa randconfig-002-20260411 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v4 2/3] thermal: spacemit: k1: Add thermal sensor support
From: Shuwei Wu @ 2026-04-11 1:56 UTC (permalink / raw)
To: Jie Gan, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti
Cc: linux-pm, devicetree, linux-riscv, spacemit, linux-kernel,
Anand Moon, Troy Mitchell, Yao Zi, Vincent Legoll, Gong Shuai
In-Reply-To: <38088fd6-1db6-4591-b489-33b52f727549@oss.qualcomm.com>
On Fri Apr 10, 2026 at 4:25 PM CST, Jie Gan wrote:
>
>
> On 4/10/2026 11:31 AM, Shuwei Wu wrote:
>> The thermal sensor on K1 supports monitoring five temperature zones.
>> The driver registers these sensors with the thermal framework
>> and supports standard operations:
>> - Reading temperature (millidegree Celsius)
>> - Setting high/low thresholds for interrupts
>>
>> Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
>> Reviewed-by: Anand Moon <linux.amoon@gmail.com>
>> Tested-by: Anand Moon <linux.amoon@gmail.com>
>> Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
>> Reviewed-by: Yao Zi <me@ziyao.cc>
>> Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
>> Tested-by: Gong Shuai <gsh517025@gmail.com>
>>
>> ---
>> Changes in v4:
>> - Add 'depends on THERMAL_OF' in drivers/thermal/spacemit/Kconfig
>>
>> Changes in v3:
>> - Align multi-line assignments as suggested by reviewer
>> - Remove unnecessary variable definitions
>>
>> Changes in v2:
>> - Rename k1_thermal.c to k1_tsensor.c for better hardware alignment
>> - Move driver to drivers/thermal/spacemit/
>> - Add Kconfig/Makefile for spacemit and update top-level build files
>> - Refactor names, style, code alignment, and comments
>> - Simplify probe and error handling
>> ---
>> drivers/thermal/Kconfig | 2 +
>> drivers/thermal/Makefile | 1 +
>> drivers/thermal/spacemit/Kconfig | 19 +++
>> drivers/thermal/spacemit/Makefile | 3 +
>> drivers/thermal/spacemit/k1_tsensor.c | 281 ++++++++++++++++++++++++++++++++++
>> 5 files changed, 306 insertions(+)
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index b10080d61860..1c4a5cd5a23e 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -472,6 +472,8 @@ endmenu
>>
>> source "drivers/thermal/renesas/Kconfig"
>>
>> +source "drivers/thermal/spacemit/Kconfig"
>> +
>> source "drivers/thermal/tegra/Kconfig"
>>
>> config GENERIC_ADC_THERMAL
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index bb21e7ea7fc6..3b249195c088 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -65,6 +65,7 @@ obj-y += mediatek/
>> obj-$(CONFIG_GENERIC_ADC_THERMAL) += thermal-generic-adc.o
>> obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
>> obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
>> +obj-y += spacemit/
>> obj-$(CONFIG_SPRD_THERMAL) += sprd_thermal.o
>> obj-$(CONFIG_KHADAS_MCU_FAN_THERMAL) += khadas_mcu_fan.o
>> obj-$(CONFIG_LOONGSON2_THERMAL) += loongson2_thermal.o
>> diff --git a/drivers/thermal/spacemit/Kconfig b/drivers/thermal/spacemit/Kconfig
>> new file mode 100644
>> index 000000000000..de7b5ece5af2
>> --- /dev/null
>> +++ b/drivers/thermal/spacemit/Kconfig
>> @@ -0,0 +1,19 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +menu "SpacemiT thermal drivers"
>> +depends on ARCH_SPACEMIT || COMPILE_TEST
>> +
>> +config SPACEMIT_K1_TSENSOR
>> + tristate "SpacemiT K1 thermal sensor driver"
>> + depends on THERMAL_OF
>> + help
>> + This driver provides support for the thermal sensor
>> + integrated in the SpacemiT K1 SoC.
>> +
>> + The thermal sensor monitors temperatures for five thermal zones:
>> + soc, package, gpu, cluster0, and cluster1. It supports reporting
>> + temperature values and handling high/low threshold interrupts.
>> +
>> + Say Y here if you want to enable thermal monitoring on SpacemiT K1.
>> + If compiled as a module, it will be called k1_tsensor.
>> +
>> +endmenu
>> diff --git a/drivers/thermal/spacemit/Makefile b/drivers/thermal/spacemit/Makefile
>> new file mode 100644
>> index 000000000000..82b30741e4ec
>> --- /dev/null
>> +++ b/drivers/thermal/spacemit/Makefile
>> @@ -0,0 +1,3 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +
>> +obj-$(CONFIG_SPACEMIT_K1_TSENSOR) += k1_tsensor.o
>> diff --git a/drivers/thermal/spacemit/k1_tsensor.c b/drivers/thermal/spacemit/k1_tsensor.c
>> new file mode 100644
>> index 000000000000..b742739e9019
>> --- /dev/null
>> +++ b/drivers/thermal/spacemit/k1_tsensor.c
>> @@ -0,0 +1,281 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Thermal sensor driver for SpacemiT K1 SoC
>> + *
>> + * Copyright (C) 2026 Shuwei Wu <shuwei.wu@mailbox.org>
>> + */
>> +#include <linux/bitfield.h>
>> +#include <linux/clk.h>
>> +#include <linux/err.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/reset.h>
>> +#include <linux/slab.h>
>> +#include <linux/thermal.h>
>> +
>> +#include "../thermal_hwmon.h"
>> +
>> +#define K1_TSENSOR_PCTRL_REG 0x00
>> +#define K1_TSENSOR_PCTRL_ENABLE BIT(0)
>> +#define K1_TSENSOR_PCTRL_TEMP_MODE BIT(3)
>> +#define K1_TSENSOR_PCTRL_RAW_SEL BIT(7)
>> +
>> +#define K1_TSENSOR_PCTRL_CTUNE GENMASK(11, 8)
>> +#define K1_TSENSOR_PCTRL_SW_CTRL GENMASK(21, 18)
>> +#define K1_TSENSOR_PCTRL_HW_AUTO_MODE BIT(23)
>> +
>> +#define K1_TSENSOR_EN_REG 0x08
>> +#define K1_TSENSOR_EN_ALL GENMASK(MAX_SENSOR_NUMBER - 1, 0)
>> +
>> +#define K1_TSENSOR_TIME_REG 0x0C
>> +#define K1_TSENSOR_TIME_WAIT_REF_CNT GENMASK(3, 0)
>> +#define K1_TSENSOR_TIME_ADC_CNT_RST GENMASK(7, 4)
>> +#define K1_TSENSOR_TIME_FILTER_PERIOD GENMASK(21, 20)
>> +#define K1_TSENSOR_TIME_MASK GENMASK(23, 0)
>> +
>> +#define K1_TSENSOR_INT_CLR_REG 0x10
>> +#define K1_TSENSOR_INT_EN_REG 0x14
>> +#define K1_TSENSOR_INT_STA_REG 0x18
>> +
>> +#define K1_TSENSOR_INT_EN_MASK BIT(0)
>> +#define K1_TSENSOR_INT_MASK(x) (GENMASK(2, 1) << ((x) * 2))
>> +
>> +#define K1_TSENSOR_DATA_BASE_REG 0x20
>> +#define K1_TSENSOR_DATA_REG(x) (K1_TSENSOR_DATA_BASE_REG + ((x) / 2) * 4)
>> +#define K1_TSENSOR_DATA_LOW_MASK GENMASK(15, 0)
>> +#define K1_TSENSOR_DATA_HIGH_MASK GENMASK(31, 16)
>> +
>> +#define K1_TSENSOR_THRSH_BASE_REG 0x40
>> +#define K1_TSENSOR_THRSH_REG(x) (K1_TSENSOR_THRSH_BASE_REG + ((x) * 4))
>> +#define K1_TSENSOR_THRSH_LOW_MASK GENMASK(15, 0)
>> +#define K1_TSENSOR_THRSH_HIGH_MASK GENMASK(31, 16)
>> +
>> +#define MAX_SENSOR_NUMBER 5
>> +
>> +/* Hardware offset value required for temperature calculation */
>> +#define TEMPERATURE_OFFSET 278
>> +
>> +struct k1_tsensor_channel {
>> + struct k1_tsensor *ts;
>> + struct thermal_zone_device *tzd;
>> + int id;
>> +};
>> +
>> +struct k1_tsensor {
>> + void __iomem *base;
>> + struct k1_tsensor_channel ch[MAX_SENSOR_NUMBER];
>> +};
>> +
>> +static void k1_tsensor_init(struct k1_tsensor *ts)
>> +{
>> + u32 val;
>> +
>> + /* Disable all the interrupts */
>> + writel(0xffffffff, ts->base + K1_TSENSOR_INT_EN_REG);
>> +
>> + /* Configure ADC sampling time and filter period */
>> + val = readl(ts->base + K1_TSENSOR_TIME_REG);
>> + val &= ~K1_TSENSOR_TIME_MASK;
>> + val |= K1_TSENSOR_TIME_FILTER_PERIOD |
>> + K1_TSENSOR_TIME_ADC_CNT_RST |
>> + K1_TSENSOR_TIME_WAIT_REF_CNT;
>> + writel(val, ts->base + K1_TSENSOR_TIME_REG);
>> +
>> + /*
>> + * Enable all sensors' auto mode, enable dither control,
>> + * consecutive mode, and power up sensor.
>> + */
>> + val = readl(ts->base + K1_TSENSOR_PCTRL_REG);
>> + val &= ~K1_TSENSOR_PCTRL_SW_CTRL;
>> + val &= ~K1_TSENSOR_PCTRL_CTUNE;
>> + val |= K1_TSENSOR_PCTRL_RAW_SEL |
>> + K1_TSENSOR_PCTRL_TEMP_MODE |
>> + K1_TSENSOR_PCTRL_HW_AUTO_MODE |
>> + K1_TSENSOR_PCTRL_ENABLE;
>> + writel(val, ts->base + K1_TSENSOR_PCTRL_REG);
>> +
>> + /* Enable thermal interrupt */
>> + val = readl(ts->base + K1_TSENSOR_INT_EN_REG);
>> + val |= K1_TSENSOR_INT_EN_MASK;
>> + writel(val, ts->base + K1_TSENSOR_INT_EN_REG);
>> +
>> + /* Enable each sensor */
>> + val = readl(ts->base + K1_TSENSOR_EN_REG);
>> + val |= K1_TSENSOR_EN_ALL;
>> + writel(val, ts->base + K1_TSENSOR_EN_REG);
>> +}
>> +
>> +static void k1_tsensor_enable_irq(struct k1_tsensor_channel *ch)
>> +{
>> + struct k1_tsensor *ts = ch->ts;
>> + u32 val;
>> +
>> + val = readl(ts->base + K1_TSENSOR_INT_CLR_REG);
>> + val |= K1_TSENSOR_INT_MASK(ch->id);
>> + writel(val, ts->base + K1_TSENSOR_INT_CLR_REG);
>> +
>> + val = readl(ts->base + K1_TSENSOR_INT_EN_REG);
>> + val &= ~K1_TSENSOR_INT_MASK(ch->id);
>> + writel(val, ts->base + K1_TSENSOR_INT_EN_REG);
>> +}
>> +
>> +/*
>> + * The conversion formula used is:
>> + * T(m°C) = (((raw_value & mask) >> shift) - TEMPERATURE_OFFSET) * 1000
>> + */
>> +static int k1_tsensor_get_temp(struct thermal_zone_device *tz, int *temp)
>> +{
>> + struct k1_tsensor_channel *ch = thermal_zone_device_priv(tz);
>> + struct k1_tsensor *ts = ch->ts;
>> + u32 val;
>> +
>> + val = readl(ts->base + K1_TSENSOR_DATA_REG(ch->id));
>> + if (ch->id % 2)
>> + *temp = FIELD_GET(K1_TSENSOR_DATA_HIGH_MASK, val);
>> + else
>> + *temp = FIELD_GET(K1_TSENSOR_DATA_LOW_MASK, val);
>> +
>> + *temp -= TEMPERATURE_OFFSET;
>> + *temp *= 1000;
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> + * For each sensor, the hardware threshold register is 32 bits:
>> + * - Lower 16 bits [15:0] configure the low threshold temperature.
>> + * - Upper 16 bits [31:16] configure the high threshold temperature.
>> + */
>> +static int k1_tsensor_set_trips(struct thermal_zone_device *tz, int low, int high)
>> +{
>> + struct k1_tsensor_channel *ch = thermal_zone_device_priv(tz);
>> + struct k1_tsensor *ts = ch->ts;
>> + u32 val;
>> +
>> + if (low >= high)
>> + return -EINVAL;
>> +
>> + if (low < 0)
>> + low = 0;
>> +
>> + high = high / 1000 + TEMPERATURE_OFFSET;
>
> Consider passes high = INT_MAX here:
>
> high = INT/1000 + TEMPERATURE_OFFSET == 2147761;
>
>> + low = low / 1000 + TEMPERATURE_OFFSET;
>> +
>> + val = readl(ts->base + K1_TSENSOR_THRSH_REG(ch->id));
>> + val &= ~K1_TSENSOR_THRSH_HIGH_MASK;
>> + val |= FIELD_PREP(K1_TSENSOR_THRSH_HIGH_MASK, high);
>
> K1_TSENSOR_THRSH_HIGH_MASK is a 16-bit MASK:
> FIELD_PREP(K1_TSENSOR_THRSH_HIGH_MASK, 2147761); <- overflow happened
>
> the maximum value here will be changed to 50609 from 65536.
>
> We should add a check here and limit the 'high' value here to avoid
> overflow:
>
> if (high > (int)((0xFFFF - TEMPERATURE_OFFSET) * 1000))
> high = (0Xffff - TEMPERATURE_OFFSET) * 1000;
>
> high = high / 1000 + TEMPERATURE_OFFSET;
>
> ...
Got it. I'll add a check to handle the overflow.
>
>> +
>> + val &= ~K1_TSENSOR_THRSH_LOW_MASK;
>> + val |= FIELD_PREP(K1_TSENSOR_THRSH_LOW_MASK, low);
>> + writel(val, ts->base + K1_TSENSOR_THRSH_REG(ch->id));
>> +
>> + return 0;
>> +}
>> +
>> +static const struct thermal_zone_device_ops k1_tsensor_ops = {
>> + .get_temp = k1_tsensor_get_temp,
>> + .set_trips = k1_tsensor_set_trips,
>> +};
>> +
>> +static irqreturn_t k1_tsensor_irq_thread(int irq, void *data)
>> +{
>> + struct k1_tsensor *ts = (struct k1_tsensor *)data;
>> + int mask, status, i;
>> +
>> + status = readl(ts->base + K1_TSENSOR_INT_STA_REG);
>> +
>> + for (i = 0; i < MAX_SENSOR_NUMBER; i++) {
>> + if (status & K1_TSENSOR_INT_MASK(i)) {
>> + mask = readl(ts->base + K1_TSENSOR_INT_CLR_REG);
>> + mask |= K1_TSENSOR_INT_MASK(i);
>> + writel(mask, ts->base + K1_TSENSOR_INT_CLR_REG);
>> + thermal_zone_device_update(ts->ch[i].tzd, THERMAL_EVENT_UNSPECIFIED);
>> + }
>> + }
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int k1_tsensor_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct k1_tsensor *ts;
>> + struct reset_control *reset;
>> + struct clk *clk;
>> + int i, irq, ret;
>> +
>> + ts = devm_kzalloc(dev, sizeof(*ts), GFP_KERNEL);
>> + if (!ts)
>> + return -ENOMEM;
>> +
>> + ts->base = devm_platform_ioremap_resource(pdev, 0);
>> + if (IS_ERR(ts->base))
>> + return dev_err_probe(dev, PTR_ERR(ts->base), "Failed to get reg\n");
>> +
>> + reset = devm_reset_control_get_exclusive_deasserted(dev, NULL);
>> + if (IS_ERR(reset))
>> + return dev_err_probe(dev, PTR_ERR(reset), "Failed to get/deassert reset control\n");
>> +
>> + clk = devm_clk_get_enabled(dev, "core");
>> + if (IS_ERR(clk))
>> + return dev_err_probe(dev, PTR_ERR(clk), "Failed to get core clock\n");
>> +
>> + clk = devm_clk_get_enabled(dev, "bus");
>> + if (IS_ERR(clk))
>> + return dev_err_probe(dev, PTR_ERR(clk), "Failed to get bus clock\n");
>> +
>> + k1_tsensor_init(ts);
>> +
>> + for (i = 0; i < MAX_SENSOR_NUMBER; ++i) {
>> + ts->ch[i].id = i;
>> + ts->ch[i].ts = ts;
>> + ts->ch[i].tzd = devm_thermal_of_zone_register(dev, i, ts->ch + i, &k1_tsensor_ops);
>> + if (IS_ERR(ts->ch[i].tzd))
>> + return PTR_ERR(ts->ch[i].tzd);
>> +
>> + /* Attach sysfs hwmon attributes for userspace monitoring */
>> + ret = devm_thermal_add_hwmon_sysfs(dev, ts->ch[i].tzd);
>> + if (ret)
>> + dev_warn(dev, "Failed to add hwmon sysfs attributes\n");
>> +
>> + k1_tsensor_enable_irq(ts->ch + i);
>
> should call after the devm_request_threaded_irq succeeds;
I'll reorder this in v5.
Thanks for catching that.
>
> Thanks,
> Jie
>
>> + }
>> +
>> + irq = platform_get_irq(pdev, 0);
>> + if (irq < 0)
>> + return irq;
>> +
>> + ret = devm_request_threaded_irq(dev, irq, NULL,
>> + k1_tsensor_irq_thread,
>> + IRQF_ONESHOT, "k1_tsensor", ts);
>> + if (ret < 0)
>> + return ret;
>> +
>> + platform_set_drvdata(pdev, ts);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id k1_tsensor_dt_ids[] = {
>> + { .compatible = "spacemit,k1-tsensor" },
>> + { /* sentinel */ }
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, k1_tsensor_dt_ids);
>> +
>> +static struct platform_driver k1_tsensor_driver = {
>> + .driver = {
>> + .name = "k1_tsensor",
>> + .of_match_table = k1_tsensor_dt_ids,
>> + },
>> + .probe = k1_tsensor_probe,
>> +};
>> +module_platform_driver(k1_tsensor_driver);
>> +
>> +MODULE_DESCRIPTION("SpacemiT K1 Thermal Sensor Driver");
>> +MODULE_AUTHOR("Shuwei Wu <shuwei.wu@mailbox.org>");
>> +MODULE_LICENSE("GPL");
>>
--
Best regards,
Shuwei Wu
^ permalink raw reply
* Re: [PATCH v4 1/3] dt-bindings: thermal: Add SpacemiT K1 thermal sensor
From: Shuwei Wu @ 2026-04-11 1:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Yixun Lan,
Philipp Zabel, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, linux-pm, devicetree, linux-riscv, spacemit,
linux-kernel, Krzysztof Kozlowski, Vincent Legoll, Gong Shuai
In-Reply-To: <20260410-inescapable-glossy-cobra-da4bf4@quoll>
On Fri Apr 10, 2026 at 3:22 PM CST, Krzysztof Kozlowski wrote:
> On Fri, Apr 10, 2026 at 11:31:36AM +0800, Shuwei Wu wrote:
>> Document the SpacemiT K1 Thermal Sensor, which supports
>> monitoring temperatures for five zones: soc, package, gpu, cluster0,
>> and cluster1.
>>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
>> Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
>> Tested-by: Gong Shuai <gsh517025@gmail.com>
>
> No, not possible. Otherwise explain me how your device tested a YAML
> file.
>
> Drop all of such tags.
Sorry for the noise. I will drop it.
Thanks for pointing out.
>
> Best regards,
> Krzysztof
--
Best regards,
Shuwei Wu
^ permalink raw reply
* [PATCH v2 3/3] pmdomain: arm_scmi: add support for domain hierarchies
From: Kevin Hilman (TI) @ 2026-04-10 23:44 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: Geert Uytterhoeven, linux-pm, devicetree, linux-kernel, arm-scmi,
linux-arm-kernel
In-Reply-To: <20260410-topic-lpm-pmdomain-child-ids-v2-0-83396e4b5f8b@baylibre.com>
After primary SCMI pmdomain is created, use new of_genpd helper which
checks for child domain mappings defined in power-domains-child-ids.
Also remove any child domain mappings when SCMI domain is removed.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
drivers/pmdomain/arm/scmi_pm_domain.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/arm/scmi_pm_domain.c b/drivers/pmdomain/arm/scmi_pm_domain.c
index b5e2ffd5ea64..6d33b3d62ef3 100644
--- a/drivers/pmdomain/arm/scmi_pm_domain.c
+++ b/drivers/pmdomain/arm/scmi_pm_domain.c
@@ -114,6 +114,14 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
dev_set_drvdata(dev, scmi_pd_data);
+ /*
+ * Parse (optional) power-domains-child-ids property to
+ * establish parent-child relationships
+ */
+ ret = of_genpd_add_child_ids(np, scmi_pd_data);
+ if (ret < 0 && ret != -ENOENT)
+ dev_err(dev, "Failed to add child domain hierarchy: %d\n", ret);
+
return 0;
err_rm_genpds:
for (i = num_domains - 1; i >= 0; i--)
@@ -129,9 +137,13 @@ static void scmi_pm_domain_remove(struct scmi_device *sdev)
struct device *dev = &sdev->dev;
struct device_node *np = dev->of_node;
+ scmi_pd_data = dev_get_drvdata(dev);
+
+ /* Remove any parent-child relationships established at probe time */
+ of_genpd_remove_child_ids(np, scmi_pd_data);
+
of_genpd_del_provider(np);
- scmi_pd_data = dev_get_drvdata(dev);
for (i = 0; i < scmi_pd_data->num_domains; i++) {
if (!scmi_pd_data->domains[i])
continue;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/3] pmdomain: core: add support for power-domains-child-ids
From: Kevin Hilman (TI) @ 2026-04-10 23:44 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: Geert Uytterhoeven, linux-pm, devicetree, linux-kernel, arm-scmi,
linux-arm-kernel
In-Reply-To: <20260410-topic-lpm-pmdomain-child-ids-v2-0-83396e4b5f8b@baylibre.com>
Currently, PM domains can only support hierarchy for simple
providers (e.g. ones with #power-domain-cells = 0).
Add support for oncell providers as well by adding a new property
`power-domains-child-ids` to describe the parent/child relationship.
For example, an SCMI PM domain provider has multiple domains, each of
which might be a child of diffeent parent domains. In this example,
the parent domains are MAIN_PD and WKUP_PD:
scmi_pds: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
power-domains = <&MAIN_PD>, <&WKUP_PD>;
power-domains-child-ids = <15>, <19>;
};
With this example using the new property, SCMI PM domain 15 becomes a
child domain of MAIN_PD, and SCMI domain 19 becomes a child domain of
WKUP_PD.
To support this feature, add two new core functions
- of_genpd_add_child_ids()
- of_genpd_remove_child_ids()
which can be called by pmdomain providers to add/remove child domains
if they support the new property power-domains-child-ids.
The add function is "all or nothing". If it cannot add all of the
child domains in the list, it will unwind any additions already made
and report a failure.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
drivers/pmdomain/core.c | 166 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 16 ++++++++++++++++
2 files changed, 182 insertions(+)
diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 61c2277c9ce3..f978477dd546 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -2909,6 +2909,172 @@ static struct generic_pm_domain *genpd_get_from_provider(
return genpd;
}
+/**
+ * of_genpd_add_child_ids() - Parse power-domains-child-ids property
+ * @np: Device node pointer associated with the PM domain provider.
+ * @data: Pointer to the onecell data associated with the PM domain provider.
+ *
+ * Parse the power-domains and power-domains-child-ids properties to establish
+ * parent-child relationships for PM domains. The power-domains property lists
+ * parent domains, and power-domains-child-ids lists which child domain IDs
+ * should be associated with each parent.
+ *
+ * Uses "all or nothing" semantics: either all relationships are established
+ * successfully, or none are (any partially-added relationships are unwound
+ * on error).
+ *
+ * Returns 0 on success, -ENOENT if properties don't exist, or negative error code.
+ */
+int of_genpd_add_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data)
+{
+ struct of_phandle_args parent_args;
+ struct generic_pm_domain *parent_genpd, *child_genpd;
+ struct generic_pm_domain **pairs; /* pairs[2*i]=parent, pairs[2*i+1]=child */
+ u32 child_id;
+ int i, ret, count, child_count, added = 0;
+
+ /* Check if both properties exist */
+ count = of_count_phandle_with_args(np, "power-domains", "#power-domain-cells");
+ if (count <= 0)
+ return -ENOENT;
+
+ child_count = of_property_count_u32_elems(np, "power-domains-child-ids");
+ if (child_count < 0)
+ return -ENOENT;
+ if (child_count != count)
+ return -EINVAL;
+
+ /* Allocate tracking array for error unwind (parent/child pairs) */
+ pairs = kmalloc_array(count * 2, sizeof(*pairs), GFP_KERNEL);
+ if (!pairs)
+ return -ENOMEM;
+
+ for (i = 0; i < count; i++) {
+ ret = of_property_read_u32_index(np, "power-domains-child-ids",
+ i, &child_id);
+ if (ret)
+ goto err_unwind;
+
+ /* Validate child ID is within bounds */
+ if (child_id >= data->num_domains) {
+ pr_err("Child ID %u out of bounds (max %u) for %pOF\n",
+ child_id, data->num_domains - 1, np);
+ ret = -EINVAL;
+ goto err_unwind;
+ }
+
+ /* Get the child domain */
+ child_genpd = data->domains[child_id];
+ if (!child_genpd) {
+ pr_err("Child domain %u is NULL for %pOF\n", child_id, np);
+ ret = -EINVAL;
+ goto err_unwind;
+ }
+
+ ret = of_parse_phandle_with_args(np, "power-domains",
+ "#power-domain-cells", i,
+ &parent_args);
+ if (ret)
+ goto err_unwind;
+
+ /* Get the parent domain */
+ parent_genpd = genpd_get_from_provider(&parent_args);
+ of_node_put(parent_args.np);
+ if (IS_ERR(parent_genpd)) {
+ pr_err("Failed to get parent domain for %pOF: %ld\n",
+ np, PTR_ERR(parent_genpd));
+ ret = PTR_ERR(parent_genpd);
+ goto err_unwind;
+ }
+
+ /* Establish parent-child relationship */
+ ret = pm_genpd_add_subdomain(parent_genpd, child_genpd);
+ if (ret) {
+ pr_err("Failed to add child domain %u to parent in %pOF: %d\n",
+ child_id, np, ret);
+ goto err_unwind;
+ }
+
+ /* Track for potential unwind */
+ pairs[2 * added] = parent_genpd;
+ pairs[2 * added + 1] = child_genpd;
+ added++;
+
+ pr_debug("Added child domain %u (%s) to parent %s for %pOF\n",
+ child_id, child_genpd->name, parent_genpd->name, np);
+ }
+
+ kfree(pairs);
+ return 0;
+
+err_unwind:
+ /* Reverse all previously established relationships */
+ while (added-- > 0)
+ pm_genpd_remove_subdomain(pairs[2 * added], pairs[2 * added + 1]);
+ kfree(pairs);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_genpd_add_child_ids);
+
+/**
+ * of_genpd_remove_child_ids() - Remove parent-child PM domain relationships
+ * @np: Device node pointer associated with the PM domain provider.
+ * @data: Pointer to the onecell data associated with the PM domain provider.
+ *
+ * Reverses the effect of of_genpd_add_child_ids() by parsing the same
+ * power-domains and power-domains-child-ids properties and calling
+ * pm_genpd_remove_subdomain() for each established relationship.
+ *
+ * Returns 0 on success, -ENOENT if properties don't exist, or negative error
+ * code on failure.
+ */
+int of_genpd_remove_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data)
+{
+ struct of_phandle_args parent_args;
+ struct generic_pm_domain *parent_genpd, *child_genpd;
+ u32 child_id;
+ int i, ret, count, child_count;
+
+ /* Check if both properties exist */
+ count = of_count_phandle_with_args(np, "power-domains", "#power-domain-cells");
+ if (count <= 0)
+ return -ENOENT;
+
+ child_count = of_property_count_u32_elems(np, "power-domains-child-ids");
+ if (child_count < 0)
+ return -ENOENT;
+ if (child_count != count)
+ return -EINVAL;
+
+ for (i = 0; i < count; i++) {
+ if (of_property_read_u32_index(np, "power-domains-child-ids",
+ i, &child_id))
+ continue;
+
+ if (child_id >= data->num_domains || !data->domains[child_id])
+ continue;
+
+ ret = of_parse_phandle_with_args(np, "power-domains",
+ "#power-domain-cells", i,
+ &parent_args);
+ if (ret)
+ continue;
+
+ parent_genpd = genpd_get_from_provider(&parent_args);
+ of_node_put(parent_args.np);
+ if (IS_ERR(parent_genpd))
+ continue;
+
+ child_genpd = data->domains[child_id];
+ pm_genpd_remove_subdomain(parent_genpd, child_genpd);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_genpd_remove_child_ids);
+
/**
* of_genpd_add_device() - Add a device to an I/O PM domain
* @genpdspec: OF phandle args to use for look-up PM domain
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index f67a2cb7d781..b44615d79af6 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -465,6 +465,10 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
int of_genpd_parse_idle_states(struct device_node *dn,
struct genpd_power_state **states, int *n);
void of_genpd_sync_state(struct device_node *np);
+int of_genpd_add_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data);
+int of_genpd_remove_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data);
int genpd_dev_pm_attach(struct device *dev);
struct device *genpd_dev_pm_attach_by_id(struct device *dev,
@@ -534,6 +538,18 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
{
return ERR_PTR(-EOPNOTSUPP);
}
+
+static inline int of_genpd_add_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int of_genpd_remove_child_ids(struct device_node *np,
+ struct genpd_onecell_data *data)
+{
+ return -EOPNOTSUPP;
+}
#endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
#ifdef CONFIG_PM
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/3] pmdomain: core: add support for domain hierarchies in DT
From: Kevin Hilman (TI) @ 2026-04-10 23:44 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: Geert Uytterhoeven, linux-pm, devicetree, linux-kernel, arm-scmi,
linux-arm-kernel
Currently, PM domains can only support hierarchy for simple
providers (e.g. ones with #power-domain-cells = 0).
Add support for oncell providers as well by adding a new property
`power-domains-child-ids` to describe the parent/child relationship.
Also adds the first user of the new API: the Arm SCMI PM domain driver.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
This idea was previously discussed on the arm-scmi mailing list[1]
where this approach was proposed by Ulf, and then an initial RFC[2]
implementation was made. From there, it was suggested by Rob[3] to
use a nexus node map instead, which led to several more versions
attempting to implement that, culminating in v5[4], where Rob and
Geert then had second thoughts about the power-domain-map approach.
Therefore, I've gone back to the approach in the initial RFC[2] to use
the child-ids approach.
Changes compared to initial RFC[2]
- dropped RFC
- rewrote the parse/add function to use iterators/helpers from of.h
- add a remove function for cleanup
- use child domain language instead of subdomain
[1] https://lore.kernel.org/arm-scmi/CAPDyKFo_P129sVirHHYjOQT+QUmpymcRJme9obzKJeRgO7B-1A@mail.gmail.com/
[2] https://lore.kernel.org/all/20250528-pmdomain-hierarchy-onecell-v1-1-851780700c68@baylibre.com/
[3] https://lore.kernel.org/all/20250528203532.GA704342-robh@kernel.org/
[4] https://lore.kernel.org/r/20260122-pmdomain-hierarchy-onecell-v5-0-76855ec856bd@baylibre.com
Changes in v2:
- dt-bindings: fix warinings from make dt_binding_check
- scmi_pm_domain: switch to dev_err()
- pmdomain: core: fix locking around add/remove domains
- pmdomain: error unwind if any children fail to be added
- pmdomain: fix node reference leak
- pmdomain: ensure power-domains and child-ids properties are same
length before iterating
- Link to v1: https://patch.msgid.link/20260310-topic-lpm-pmdomain-child-ids-v1-0-5361687a18ff@baylibre.com
---
Kevin Hilman (TI) (3):
dt-bindings: power: Add power-domains-child-ids property
pmdomain: core: add support for power-domains-child-ids
pmdomain: arm_scmi: add support for domain hierarchies
Documentation/devicetree/bindings/power/power-domain.yaml | 34 ++++++++++++++++++++++++++++++++++
drivers/pmdomain/arm/scmi_pm_domain.c | 14 +++++++++++++-
drivers/pmdomain/core.c | 166 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/pm_domain.h | 16 ++++++++++++++++
4 files changed, 229 insertions(+), 1 deletion(-)
---
base-commit: f7b88edb52c8dd01b7e576390d658ae6eef0e134
change-id: 20260310-topic-lpm-pmdomain-child-ids-e3d57ae57040
Best regards,
--
Kevin Hilman (TI) <khilman@baylibre.com>
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: power: Add power-domains-child-ids property
From: Kevin Hilman (TI) @ 2026-04-10 23:44 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: Geert Uytterhoeven, linux-pm, devicetree, linux-kernel, arm-scmi,
linux-arm-kernel
In-Reply-To: <20260410-topic-lpm-pmdomain-child-ids-v2-0-83396e4b5f8b@baylibre.com>
Add binding documentation for the new power-domains-child-ids property,
which works in conjunction with the existing power-domains property to
establish parent-child relationships between a multi-domain power domain
provider and external parent domains.
Each element in the uint32 array identifies the child domain
ID (index) within the provider that should be made a child domain of
the corresponding phandle entry in power-domains. The two arrays must
have the same number of elements.
Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
---
Documentation/devicetree/bindings/power/power-domain.yaml | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
index b1147dbf2e73..163b0af158fd 100644
--- a/Documentation/devicetree/bindings/power/power-domain.yaml
+++ b/Documentation/devicetree/bindings/power/power-domain.yaml
@@ -68,6 +68,21 @@ properties:
by the given provider should be subdomains of the domain specified
by this binding.
+ power-domains-child-ids:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ An array of child domain IDs that correspond to the power-domains
+ property. This property is only applicable to power domain providers
+ with "#power-domain-cells" > 0 (i.e., providers that supply multiple
+ power domains). It specifies which of the provider's child domains
+ should be associated with each parent domain listed in the power-domains
+ property. The number of elements in this array must match the number of
+ phandles in the power-domains property. Each element specifies the child
+ domain ID (index) that should be made a child domain of the corresponding
+ parent domain. This enables hierarchical power domain structures where
+ different child domains from the same provider can have different
+ parent domains.
+
required:
- "#power-domain-cells"
@@ -133,3 +148,22 @@ examples:
min-residency-us = <7000>;
};
};
+
+ - |
+ // Example: SCMI domain 15 -> MAIN_PD, SCMI domain 19 -> WKUP_PD
+ MAIN_PD: power-controller-main {
+ compatible = "foo,power-controller";
+ #power-domain-cells = <0>;
+ };
+
+ WKUP_PD: power-controller-wkup {
+ compatible = "foo,power-controller";
+ #power-domain-cells = <0>;
+ };
+
+ scmi_pds: power-controller-scmi {
+ compatible = "foo,power-controller";
+ #power-domain-cells = <1>;
+ power-domains = <&MAIN_PD>, <&WKUP_PD>;
+ power-domains-child-ids = <15>, <19>;
+ };
--
2.51.0
^ permalink raw reply related
* [PATCH] dt-bindings: thermal: Fix false warning with 'phandle' in trips nodes
From: Rob Herring (Arm) @ 2026-04-10 22:36 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-pm, devicetree, linux-kernel
A pattern property matching essentially anything doesn't work if there
are implicit properties such as 'phandle' which can occur on any node.
One such example popped up recently:
arch/arm64/boot/dts/qcom/sm8650-hdk.dtb: thermal-zones: gpuss0-thermal:trips:phandle: 531 is not of type 'object'
from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml
Instead of a pattern property, use an "additionalProperties" schema
instead which is the fallback in case of no matching property.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
---
Daniel, Please pick this up for v7.1 as the above warning is in next. Or
if you prefer, I can take it.
.../bindings/thermal/thermal-zones.yaml | 111 +++++++++---------
1 file changed, 54 insertions(+), 57 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
index 0de0a9757ccc..07d9f576ffe7 100644
--- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
+++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
@@ -129,63 +129,60 @@ patternProperties:
which the thermal framework needs to take action. The actions to
be taken are defined in another node called cooling-maps.
- patternProperties:
- "^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$":
- type: object
-
- properties:
- temperature:
- $ref: /schemas/types.yaml#/definitions/int32
- minimum: -273000
- maximum: 200000
- description:
- An integer expressing the trip temperature in millicelsius.
-
- hysteresis:
- $ref: /schemas/types.yaml#/definitions/uint32
- description:
- An unsigned integer expressing the hysteresis delta with
- respect to the trip temperature property above, also in
- millicelsius. Any cooling action initiated by the framework is
- maintained until the temperature falls below
- (trip temperature - hysteresis). This potentially prevents a
- situation where the trip gets constantly triggered soon after
- cooling action is removed.
-
- type:
- $ref: /schemas/types.yaml#/definitions/string
- enum:
- - active # enable active cooling e.g. fans
- - passive # enable passive cooling e.g. throttling cpu
- - hot # send notification to driver
- - critical # send notification to driver, trigger shutdown
- description: |
- There are four valid trip types: active, passive, hot,
- critical.
-
- The critical trip type is used to set the maximum
- temperature threshold above which the HW becomes
- unstable and underlying firmware might even trigger a
- reboot. Hitting the critical threshold triggers a system
- shutdown.
-
- The hot trip type can be used to send a notification to
- the thermal driver (if a .notify callback is registered).
- The action to be taken is left to the driver.
-
- The passive trip type can be used to slow down HW e.g. run
- the CPU, GPU, bus at a lower frequency.
-
- The active trip type can be used to control other HW to
- help in cooling e.g. fans can be sped up or slowed down
-
- required:
- - temperature
- - hysteresis
- - type
- additionalProperties: false
-
- additionalProperties: false
+ additionalProperties:
+ type: object
+ additionalProperties: false
+
+ properties:
+ temperature:
+ $ref: /schemas/types.yaml#/definitions/int32
+ minimum: -273000
+ maximum: 200000
+ description:
+ An integer expressing the trip temperature in millicelsius.
+
+ hysteresis:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ An unsigned integer expressing the hysteresis delta with
+ respect to the trip temperature property above, also in
+ millicelsius. Any cooling action initiated by the framework is
+ maintained until the temperature falls below
+ (trip temperature - hysteresis). This potentially prevents a
+ situation where the trip gets constantly triggered soon after
+ cooling action is removed.
+
+ type:
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - active # enable active cooling e.g. fans
+ - passive # enable passive cooling e.g. throttling cpu
+ - hot # send notification to driver
+ - critical # send notification to driver, trigger shutdown
+ description: |
+ There are four valid trip types: active, passive, hot,
+ critical.
+
+ The critical trip type is used to set the maximum
+ temperature threshold above which the HW becomes
+ unstable and underlying firmware might even trigger a
+ reboot. Hitting the critical threshold triggers a system
+ shutdown.
+
+ The hot trip type can be used to send a notification to
+ the thermal driver (if a .notify callback is registered).
+ The action to be taken is left to the driver.
+
+ The passive trip type can be used to slow down HW e.g. run
+ the CPU, GPU, bus at a lower frequency.
+
+ The active trip type can be used to control other HW to
+ help in cooling e.g. fans can be sped up or slowed down
+
+ required:
+ - temperature
+ - hysteresis
+ - type
cooling-maps:
type: object
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 2/3] pmdomain: core: add support for power-domains-child-ids
From: Kevin Hilman @ 2026-04-10 22:25 UTC (permalink / raw)
To: Ulf Hansson
Cc: Rob Herring, Geert Uytterhoeven, linux-pm, devicetree,
linux-kernel, arm-scmi, linux-arm-kernel
In-Reply-To: <CAPDyKFrR2zyMFXTAkKs1XRgB-u5jSP256g730s=7SLuOZKsKVg@mail.gmail.com>
Ulf Hansson <ulf.hansson@linaro.org> writes:
> On Fri, 10 Apr 2026 at 02:45, Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> Ulf Hansson <ulf.hansson@linaro.org> writes:
>>
>> > On Wed, 11 Mar 2026 at 01:19, Kevin Hilman (TI) <khilman@baylibre.com> wrote:
>> >>
>> >> Currently, PM domains can only support hierarchy for simple
>> >> providers (e.g. ones with #power-domain-cells = 0).
>> >>
>> >> Add support for oncell providers as well by adding a new property
>> >> `power-domains-child-ids` to describe the parent/child relationship.
>> >>
>> >> For example, an SCMI PM domain provider has multiple domains, each of
>> >> which might be a child of diffeent parent domains. In this example,
>> >> the parent domains are MAIN_PD and WKUP_PD:
>> >>
>> >> scmi_pds: protocol@11 {
>> >> reg = <0x11>;
>> >> #power-domain-cells = <1>;
>> >> power-domains = <&MAIN_PD>, <&WKUP_PD>;
>> >> power-domains-child-ids = <15>, <19>;
>> >> };
>> >>
>> >> With this example using the new property, SCMI PM domain 15 becomes a
>> >> child domain of MAIN_PD, and SCMI domain 19 becomes a child domain of
>> >> WKUP_PD.
>> >>
>> >> To support this feature, add two new core functions
>> >>
>> >> - of_genpd_add_child_ids()
>> >> - of_genpd_remove_child_ids()
>> >>
>> >> which can be called by pmdomain providers to add/remove child domains
>> >> if they support the new property power-domains-child-ids.
>> >>
>> >> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
>> >
>> > Thanks for working on this! It certainly is a missing feature!
>>
>> You're welcome, thanks for the detailed review.
>>
>> >> ---
>> >> drivers/pmdomain/core.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> >> include/linux/pm_domain.h | 16 ++++++++++++++++
>> >> 2 files changed, 185 insertions(+)
>> >>
>> >> diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
>> >> index 61c2277c9ce3..acb45dd540b7 100644
>> >> --- a/drivers/pmdomain/core.c
>> >> +++ b/drivers/pmdomain/core.c
>> >> @@ -2909,6 +2909,175 @@ static struct generic_pm_domain *genpd_get_from_provider(
>> >> return genpd;
>> >> }
>> >>
>> >> +/**
>> >> + * of_genpd_add_child_ids() - Parse power-domains-child-ids property
>> >> + * @np: Device node pointer associated with the PM domain provider.
>> >> + * @data: Pointer to the onecell data associated with the PM domain provider.
>> >> + *
>> >> + * Parse the power-domains and power-domains-child-ids properties to establish
>> >> + * parent-child relationships for PM domains. The power-domains property lists
>> >> + * parent domains, and power-domains-child-ids lists which child domain IDs
>> >> + * should be associated with each parent.
>> >> + *
>> >> + * Returns 0 on success, -ENOENT if properties don't exist, or negative error code.
>> >
>> > I think we should avoid returning specific error codes for specific
>> > errors, simply because it usually becomes messy.
>> >
>> > If I understand correctly the intent here is to allow the caller to
>> > check for -ENOENT and potentially avoid bailing out as it may not
>> > really be an error, right?
>>
>> Right, -ENOENT is not an error of parsing, it's to indicate that there
>> are no child-ids to be parsed.
>>
>> > Perhaps a better option is to return the number of children for whom
>> > we successfully assigned parents. Hence 0 or a positive value allows
>> > the caller to understand what happened. More importantly, a negative
>> > error code then really becomes an error for the caller to consider.
>>
>> I explored this a bit, but it gets messy quick. It means we have to
>> track cases where only some of the children were added as well as when
>> all children were added. Personally, I think this should be an "all or
>> nothing" thing. If all the children cannot be parsed/added, then none
>> of them should be added.
>>
>> This also allows the remove to not have to care about how many were
>> added, and just remove them all, with the additional benefit of not
>> having to track the state of how many children were successfully added.
>>
>
> I fully agree, it should be all or nothing. Failing with one
> child/parent should end up with an error code being returned.
>
> That said, it still seems to make perfect sense to return the number
> of children for whom we assigned parents for, no?
No, because what will the caller use that number for? If we are
assuming "all or nothing", what would we use it for (other than a debug print?)
It also makes it a bit confusing what a zero return value means. Does
that mean success? Or that zero children were added (which would be
fail.)
I prefer to keep it as is.
Kevin
^ permalink raw reply
* Re: [patch 01/12] clockevents: Prevent timer interrupt starvation
From: Nathan Chancellor @ 2026-04-10 21:13 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Calvin Owens, Peter Zijlstra, Anna-Maria Behnsen,
Frederic Weisbecker, Ingo Molnar, John Stultz, Stephen Boyd,
Alexander Viro, Christian Brauner, Jan Kara, linux-fsdevel,
Sebastian Reichel, linux-pm, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, netfilter-devel, coreteam
In-Reply-To: <87fr52zfze.ffs@tglx>
On Fri, Apr 10, 2026 at 11:02:13PM +0200, Thomas Gleixner wrote:
> On Fri, Apr 10 2026 at 13:52, Nathan Chancellor wrote:
> >> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/
> >
> > This change in -next as commit 1c2eabb8805d ("clockevents: Prevent timer
> > interrupt starvation") appears to make one of my test machines
> > consistently lock up on boot (at least I never get to userspace). Most
> > of the time I get stall messages such as
>
> Can you please retest the changes I just pushed out into:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/urgent
>
> namely: d6e152d905bd ("clockevents: Prevent timer interrupt starvation")
Hah, funny timing. I can confirm that the following diff against the
version in -next appears to fix the issue for me. Thanks for the quick
response!
Cheers,
Nathan
diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index f63c65881364..7e57fa31ee26 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -76,8 +76,10 @@ const struct clock_event_device *tick_get_wakeup_device(int cpu)
*/
static void tick_broadcast_start_periodic(struct clock_event_device *bc)
{
- if (bc)
+ if (bc) {
+ bc->next_event_forced = 0;
tick_setup_periodic(bc, 1);
+ }
}
/*
@@ -403,6 +405,7 @@ static void tick_handle_periodic_broadcast(struct clock_event_device *dev)
bool bc_local;
raw_spin_lock(&tick_broadcast_lock);
+ tick_broadcast_device.evtdev->next_event_forced = 0;
/* Handle spurious interrupts gracefully */
if (clockevent_state_shutdown(tick_broadcast_device.evtdev)) {
@@ -696,6 +699,7 @@ static void tick_handle_oneshot_broadcast(struct clock_event_device *dev)
raw_spin_lock(&tick_broadcast_lock);
dev->next_event = KTIME_MAX;
+ tick_broadcast_device.evtdev->next_event_forced = 0;
next_event = KTIME_MAX;
cpumask_clear(tmpmask);
now = ktime_get();
@@ -1063,6 +1067,7 @@ static void tick_broadcast_setup_oneshot(struct clock_event_device *bc,
bc->event_handler = tick_handle_oneshot_broadcast;
+ bc->next_event_forced = 0;
bc->next_event = KTIME_MAX;
/*
@@ -1175,6 +1180,7 @@ void hotplug_cpu__broadcast_tick_pull(int deadcpu)
}
/* This moves the broadcast assignment to this CPU: */
+ bc->next_event_forced = 0;
clockevents_program_event(bc, bc->next_event, 1);
}
raw_spin_unlock_irqrestore(&tick_broadcast_lock, flags);
^ permalink raw reply related
* Re: [patch 01/12] clockevents: Prevent timer interrupt starvation
From: Thomas Gleixner @ 2026-04-10 21:02 UTC (permalink / raw)
To: Nathan Chancellor
Cc: LKML, Calvin Owens, Peter Zijlstra, Anna-Maria Behnsen,
Frederic Weisbecker, Ingo Molnar, John Stultz, Stephen Boyd,
Alexander Viro, Christian Brauner, Jan Kara, linux-fsdevel,
Sebastian Reichel, linux-pm, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, netfilter-devel, coreteam
In-Reply-To: <20260410205203.GA3922321@ax162>
On Fri, Apr 10 2026 at 13:52, Nathan Chancellor wrote:
>> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/
>
> This change in -next as commit 1c2eabb8805d ("clockevents: Prevent timer
> interrupt starvation") appears to make one of my test machines
> consistently lock up on boot (at least I never get to userspace). Most
> of the time I get stall messages such as
Can you please retest the changes I just pushed out into:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/urgent
namely: d6e152d905bd ("clockevents: Prevent timer interrupt starvation")
Thanks,
tglx
^ permalink raw reply
* Re: [patch 01/12] clockevents: Prevent timer interrupt starvation
From: Nathan Chancellor @ 2026-04-10 20:52 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Calvin Owens, Peter Zijlstra, Anna-Maria Behnsen,
Frederic Weisbecker, Ingo Molnar, John Stultz, Stephen Boyd,
Alexander Viro, Christian Brauner, Jan Kara, linux-fsdevel,
Sebastian Reichel, linux-pm, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, netfilter-devel, coreteam
In-Reply-To: <20260407083247.562657657@kernel.org>
Hi Thomas,
On Tue, Apr 07, 2026 at 10:54:17AM +0200, Thomas Gleixner wrote:
> From: Thomas Gleixner <tglx@kernel.org>
>
> Calvin reported an odd NMI watchdog lockup which claims that the CPU locked
> up in user space. He provided a reproducer, which sets up a timerfd based
> timer and then rearms it in a loop with an absolute expiry time of 1ns.
>
> As the expiry time is in the past, the timer ends up as the first expiring
> timer in the per CPU hrtimer base and the clockevent device is programmed
> with the minimum delta value. If the machine is fast enough, this ends up
> in a endless loop of programming the delta value to the minimum value
> defined by the clock event device, before the timer interrupt can fire,
> which starves the interrupt and consequently triggers the lockup detector
> because the hrtimer callback of the lockup mechanism is never invoked.
>
> As a first step to prevent this, avoid reprogramming the clock event device
> when:
> - a forced minimum delta event is pending
> - the new expiry delta is less then or equal to the minimum delta
>
> Thanks to Calvin for providing the reproducer and to Borislav for testing
> and providing data from his Zen5 machine.
>
> The problem is not limited to Zen5, but depending on the underlying
> clock event device (e.g. TSC deadline timer on Intel) and the CPU speed
> not necessarily observable.
>
> This change serves only as the last resort and further changes will be made
> to prevent this scenario earlier in the call chain as far as possible.
>
> Fixes: d316c57ff6bf ("[PATCH] clockevents: add core functionality")
> Reported-by: Calvin Owens <calvin@wbinvd.org>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de>
> Cc: Frederic Weisbecker <frederic@kernel.org>
> Cc: Ingo Molnar <mingo@kernel.org>
> Link: https://lore.kernel.org/lkml/acMe-QZUel-bBYUh@mozart.vkv.me/
This change in -next as commit 1c2eabb8805d ("clockevents: Prevent timer
interrupt starvation") appears to make one of my test machines
consistently lock up on boot (at least I never get to userspace). Most
of the time I get stall messages such as
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: 14-...!: (20 GPs behind) idle=f380/0/0x0 softirq=1272/1273 fqs=4 (false positive?)
rcu: (detected by 2, t=60002 jiffies, g=3673, q=12382 ncpus=16)
Sending NMI from CPU 2 to CPUs 14:
NMI backtrace for cpu 14 skipped: idling at cpu_idle_poll.isra.0+0x50/0x170
rcu: rcu_preempt kthread timer wakeup didn't happen for 59984 jiffies! g3673 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
rcu: Possible timer handling issue on cpu=4 timer-softirq=170
rcu: rcu_preempt kthread starved for 59987 jiffies! g3673 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=4
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:I stack:0 pid:16 tgid:16 ppid:2 task_flags:0x208040 flags:0x00000010
Call trace:
__switch_to+0x100/0x1c8 (T)
__schedule+0x2b0/0x710
schedule+0x3c/0xc0
schedule_timeout+0x88/0x128
rcu_gp_fqs_loop+0x12c/0x640
rcu_gp_kthread+0x308/0x350
kthread+0x10c/0x128
ret_from_fork+0x10/0x20
rcu: Stack dump where RCU GP kthread last ran:
Sending NMI from CPU 2 to CPUs 4:
NMI backtrace for cpu 4 skipped: idling at cpu_idle_poll.isra.0+0x50/0x170
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: 0-...!: (21 GPs behind) idle=a4a0/0/0x0 softirq=1775/1776 fqs=0 (false positive?)
rcu: 3-...!: (28 GPs behind) idle=5b00/0/0x0 softirq=1437/1438 fqs=0 (false positive?)
rcu: 7-...!: (21 GPs behind) idle=0c18/0/0x0 softirq=1658/1659 fqs=0 (false positive?)
rcu: 8-...!: (21 GPs behind) idle=1418/0/0x0 softirq=1231/1231 fqs=0 (false positive?)
rcu: 9-...!: (18 GPs behind) idle=1288/0/0x0 softirq=1440/1440 fqs=0 (false positive?)
rcu: 12-...!: (21 GPs behind) idle=ae70/0/0x0 softirq=1339/1339 fqs=0 (false positive?)
rcu: 13-...!: (28 GPs behind) idle=02c8/0/0x0 softirq=1785/1787 fqs=0 (false positive?)
rcu: 14-...!: (21 GPs behind) idle=f428/0/0x0 softirq=1272/1273 fqs=0 (false positive?)
rcu: 15-...!: (21 GPs behind) idle=0fb8/0/0x0 softirq=1562/1562 fqs=0 (false positive?)
rcu: (detected by 5, t=60002 jiffies, g=3677, q=12637 ncpus=16)
Sending NMI from CPU 5 to CPUs 0:
NMI backtrace for cpu 0 skipped: idling at cpu_idle_poll.isra.0+0x38/0x170
Sending NMI from CPU 5 to CPUs 3:
NMI backtrace for cpu 3 skipped: idling at cpu_idle_poll.isra.0+0x38/0x170
Sending NMI from CPU 5 to CPUs 7:
NMI backtrace for cpu 7 skipped: idling at cpu_idle_poll.isra.0+0x40/0x170
Sending NMI from CPU 5 to CPUs 8:
NMI backtrace for cpu 8 skipped: idling at cpu_idle_poll.isra.0+0x40/0x170
Sending NMI from CPU 5 to CPUs 9:
NMI backtrace for cpu 9 skipped: idling at cpu_idle_poll.isra.0+0x40/0x170
Sending NMI from CPU 5 to CPUs 12:
NMI backtrace for cpu 12 skipped: idling at cpu_idle_poll.isra.0+0x40/0x170
Sending NMI from CPU 5 to CPUs 13:
NMI backtrace for cpu 13 skipped: idling at cpu_idle_poll.isra.0+0x50/0x170
Sending NMI from CPU 5 to CPUs 14:
NMI backtrace for cpu 14 skipped: idling at cpu_idle_poll.isra.0+0x50/0x170
Sending NMI from CPU 5 to CPUs 15:
NMI backtrace for cpu 15 skipped: idling at cpu_idle_poll.isra.0+0x38/0x170
rcu: rcu_preempt kthread timer wakeup didn't happen for 60008 jiffies! g3677 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
rcu: Possible timer handling issue on cpu=4 timer-softirq=170
rcu: rcu_preempt kthread starved for 60011 jiffies! g3677 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=4
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:I stack:0 pid:16 tgid:16 ppid:2 task_flags:0x208040 flags:0x00000010
Call trace:
__switch_to+0x100/0x1c8 (T)
__schedule+0x2b0/0x710
schedule+0x3c/0xc0
schedule_timeout+0x88/0x128
rcu_gp_fqs_loop+0x12c/0x640
rcu_gp_kthread+0x308/0x350
kthread+0x10c/0x128
ret_from_fork+0x10/0x20
rcu: Stack dump where RCU GP kthread last ran:
Sending NMI from CPU 5 to CPUs 4:
NMI backtrace for cpu 4
CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 7.0.0-rc7-next-20260409 #1 PREEMPT(lazy)
Hardware name: SolidRun Ltd. SolidRun CEX7 Platform, BIOS EDK II Jun 21 2022
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : tick_check_broadcast_expired+0x4/0x40
lr : cpu_idle_poll.isra.0+0x54/0x170
sp : ffff80008017be20
x29: ffff80008017be20 x28: 0000000000000000 x27: 0000000000000000
x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
x23: 00000000000000c0 x22: ffffb3ce21fad000 x21: 0000000000000004
x20: ffffb3ce21fadd50 x19: ffffb3ce21fad000 x18: 0000000000000004
x17: 0000000000000000 x16: 0000000000000000 x15: ffffb3ce21fb3b98
x14: ffffb3ce21788180 x13: 0000000000000000 x12: 000000124d69be59
x11: 00000000000000c0 x10: 0000000000001c80 x9 : ffffb3ce1f8a6e68
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000004
x5 : ffff00275c3682c8 x4 : 0000000000020a3c x3 : 0000000000000000
x2 : 0000000000000004 x1 : ffffb3ce223ca0c0 x0 : ffff002020da2140
Call trace:
tick_check_broadcast_expired+0x4/0x40 (P)
do_idle+0x64/0x130
cpu_startup_entry+0x40/0x50
secondary_start_kernel+0xe4/0x128
__secondary_switched+0xc0/0xc8
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: 0-...!: (22 GPs behind) idle=ae48/0/0x0 softirq=1775/1776 fqs=0 (false positive?)
rcu: 3-...!: (29 GPs behind) idle=7ce8/0/0x0 softirq=1437/1438 fqs=0 (false positive?)
rcu: 7-...!: (22 GPs behind) idle=0df8/0/0x0 softirq=1658/1659 fqs=0 (false positive?)
rcu: 8-...!: (22 GPs behind) idle=1548/0/0x0 softirq=1231/1231 fqs=0 (false positive?)
rcu: 9-...!: (19 GPs behind) idle=1360/0/0x0 softirq=1440/1440 fqs=0 (false positive?)
rcu: 12-...!: (22 GPs behind) idle=af40/0/0x0 softirq=1339/1339 fqs=0 (false positive?)
rcu: 13-...!: (29 GPs behind) idle=04e0/0/0x0 softirq=1785/1787 fqs=0 (false positive?)
rcu: 14-...!: (22 GPs behind) idle=f528/0/0x0 softirq=1272/1273 fqs=0 (false positive?)
rcu: 15-...!: (22 GPs behind) idle=0fd8/0/0x0 softirq=1562/1562 fqs=0 (false positive?)
rcu: (detected by 5, t=60002 jiffies, g=3681, q=13149 ncpus=16)
but other times, there is no output after it locks up. Is there any
initial information I can provide to help debug this? Reverting the
change on top of next-20260409 avoids the issue.
Cheers,
Nathan
# bad: [3fa7d958829eb9bc3b469ed07f11de3d2804ef71] Add linux-next specific files for 20260409
# good: [7f87a5ea75f011d2c9bc8ac0167e5e2d1adb1594] Merge tag 'hid-for-linus-2026040801' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
git bisect start '3fa7d958829eb9bc3b469ed07f11de3d2804ef71' '7f87a5ea75f011d2c9bc8ac0167e5e2d1adb1594'
# bad: [443e04732ac2cdc17e3b90aa2345730a298fab37] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
git bisect bad 443e04732ac2cdc17e3b90aa2345730a298fab37
# bad: [ea33e83d9fa24b34e79c8df57b8927a8d94deb15] Merge branch 'xtensa-for-next' of https://github.com/jcmvbkbc/linux-xtensa.git
git bisect bad ea33e83d9fa24b34e79c8df57b8927a8d94deb15
# bad: [429057750b3d3a7477df48d17aa605dc47bc2344] Merge branch 'for-next/perf' of https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
git bisect bad 429057750b3d3a7477df48d17aa605dc47bc2344
# bad: [e98894f89da72f392141d9eecf1c7a8f13faa67f] Merge branch 'mm-stable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
git bisect bad e98894f89da72f392141d9eecf1c7a8f13faa67f
# good: [668937b7b2256f4b2a982e8f69b07d9ee8f81d36] mm: allow handling of stacked mmap_prepare hooks in more drivers
git bisect good 668937b7b2256f4b2a982e8f69b07d9ee8f81d36
# good: [a0fbc8dd44a27011537268e2a974b1180b848796] Merge branch 'dma-mapping-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux.git
git bisect good a0fbc8dd44a27011537268e2a974b1180b848796
# good: [8a23051ed8584215b22368e9501f771ef98f0c1d] Merge tag 'pin-init-v7.1' of https://github.com/Rust-for-Linux/linux into rust-next
git bisect good 8a23051ed8584215b22368e9501f771ef98f0c1d
# good: [716b25a9dc20f4fb94d521581331a0565a43f3bb] Merge branch 'urgent' of https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git
git bisect good 716b25a9dc20f4fb94d521581331a0565a43f3bb
# bad: [1a49dc272e25dae6cbb506a02bb70e0201a1498e] Merge branch 'tip/urgent' of https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
git bisect bad 1a49dc272e25dae6cbb506a02bb70e0201a1498e
# good: [30023353b2171cd36b10615a788a985f5caa29e3] Merge branch into tip/master: 'sched/urgent'
git bisect good 30023353b2171cd36b10615a788a985f5caa29e3
# good: [34ef164adaf00982d5f45037a7e37689c4555271] Merge branch 'i2c/i2c-host-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git
git bisect good 34ef164adaf00982d5f45037a7e37689c4555271
# bad: [4fc7108ff756267ad53ecdeaa1e847d378887511] Merge branch into tip/master: 'timers/urgent'
git bisect bad 4fc7108ff756267ad53ecdeaa1e847d378887511
# bad: [1c2eabb8805d9fd79a19de5c76d4a64c9ad3cdf4] clockevents: Prevent timer interrupt starvation
git bisect bad 1c2eabb8805d9fd79a19de5c76d4a64c9ad3cdf4
# good: [82b915051d32a68ea3bbe261c93f5620699ff047] tick/nohz: Fix inverted return value in check_tick_dependency() fast path
git bisect good 82b915051d32a68ea3bbe261c93f5620699ff047
# first bad commit: [1c2eabb8805d9fd79a19de5c76d4a64c9ad3cdf4] clockevents: Prevent timer interrupt starvation
^ permalink raw reply
* Re: [PATCH] tools/power turbostat: Allow execution to continue after perf_l2_init() failure
From: Len Brown @ 2026-04-10 18:09 UTC (permalink / raw)
To: David Arcari, dapeng1.mi; +Cc: Linux PM list, Linux Kernel Mailing List
In-Reply-To: <5ec684ae-b778-40ba-8a10-dfbf274da7dd@redhat.com>
On Fri, Apr 10, 2026 at 12:06 PM David Arcari <darcari@redhat.com> wrote:
> I'm using a Fedora kernel:
>
> vmlinuz-7.0.0-0.rc4.260320g0e4f8f1a3d08.40.eln155.x86_64
>
> And turbostat is:
>
> # turbostat -v
> turbostat version 2026.02.14 - Len Brown <lenb@kernel.org>
>
> >
> > You can poke with "perf stat" as well, but this will depend on what
> > .json counter list is compiled into
> > your version of perf.
> >
> > probably a first sanity check would be if these commands for the LLC
> > and the L2 work:
> >
> > sudo perf stat -e cache-misses sleep 1
> > sudo perf stat -e L2_REQUEST.ALL sleep 1
>
> # sudo perf stat -e cache-misses sleep 1
>
> Performance counter stats for 'sleep 1':
>
> <not supported> cpu_atom/cache-misses/
I think this should work. There may be an issue either with
the perf utility or the perf kernel support on that system.
I'll cc Dapeng. Already the weekend where he is, but maybe he
can give us some perf insight next week.
thx,
-Len
^ permalink raw reply
* [PATCH 6/8] arm64: dts: amlogic: t7: Add thermal sensor nodes
From: Ronald Claveau @ 2026-04-10 16:48 UTC (permalink / raw)
To: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel, Ronald Claveau
In-Reply-To: <20260410-add-thermal-t7-vim4-v1-0-19f2b8da74d7@aliel.fr>
Add six temperature sensor nodes using the amlogic,t7-thermal compatible:
a73, a53, gpu, nna, vpu, and hevc. Each sensor retrieves its calibration
data from the secure monitor via the amlogic,secure-monitor phandle with
the corresponding tsensor_id argument.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 58 +++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7aec65f036a9c..62f259b2b17d2 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -656,6 +656,24 @@ sec_ao: ao-secure@10220 {
amlogic,has-chip-id;
};
+ a73_tsensor: temperature-sensor@20000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x20000 0x0 0x50>;
+ interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 1>;
+ };
+
+ a53_tsensor: temperature-sensor@22000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x22000 0x0 0x50>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 2>;
+ };
+
pwm_ao_ef: pwm@30000 {
compatible = "amlogic,t7-pwm", "amlogic,meson-s4-pwm";
reg = <0x0 0x30000 0x0 0x24>;
@@ -770,6 +788,46 @@ sd_emmc_c: mmc@8c000 {
assigned-clock-parents = <&xtal>;
status = "disabled";
};
+
+ gpu_tsensor: temperature-sensor@94000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x94000 0x0 0x50>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_MALI_TOP_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 3>;
+ };
+
+ nna_tsensor: temperature-sensor@96000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x96000 0x0 0x50>;
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_NNA_TOP_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 4>;
+ };
+
+ vpu_tsensor: temperature-sensor@98000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x98000 0x0 0x50>;
+ interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_VPU_HDMI_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 6>;
+ };
+
+ hevc_tsensor: temperature-sensor@9a000 {
+ compatible = "amlogic,t7-thermal";
+ reg = <0x0 0x9a000 0x0 0x50>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clkc_periphs CLKID_TS>;
+ power-domains = <&pwrc PWRC_T7_DOS_HEVC_ID>;
+ #thermal-sensor-cells = <0>;
+ amlogic,secure-monitor = <&sm 5>;
+ };
};
};
--
2.49.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox