* Re: [PATCH v2 2/8] dt-bindings: i2c: amlogic: Add compatible for T7 SOC
From: Rob Herring (Arm) @ 2026-04-15 21:48 UTC (permalink / raw)
To: Ronald Claveau
Cc: Jerome Brunet, Neil Armstrong, linux-i2c, Kevin Hilman, linux-pm,
Lukasz Luba, linux-amlogic, linux-kernel, Zhang Rui, Lee Jones,
devicetree, Conor Dooley, Andi Shyti, Daniel Lezcano,
Martin Blumenstingl, Beniamino Galvani, Krzysztof Kozlowski,
Liam Girdwood, Mark Brown, linux-arm-kernel, Rafael J. Wysocki
In-Reply-To: <20260403-add-mcu-fan-khadas-vim4-v2-2-70536b22439a@aliel.fr>
On Fri, 03 Apr 2026 18:08:35 +0200, Ronald Claveau wrote:
> Add the T7 SOC compatible which fallback to AXG compatible.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../devicetree/bindings/i2c/amlogic,meson6-i2c.yaml | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Rob Herring @ 2026-04-15 21:48 UTC (permalink / raw)
To: Ronald Claveau
Cc: Neil Armstrong, Lee Jones, Krzysztof Kozlowski, Conor Dooley,
Andi Shyti, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Liam Girdwood, Mark Brown, linux-amlogic, devicetree,
linux-kernel, linux-i2c, linux-arm-kernel, linux-pm
In-Reply-To: <20260403-add-mcu-fan-khadas-vim4-v2-1-70536b22439a@aliel.fr>
On Fri, Apr 03, 2026 at 06:08:34PM +0200, Ronald Claveau wrote:
> The Khadas VIM4 MCU register is slightly different
> from previous boards' MCU.
> This board also features a switchable power source for its fan.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> index 084960fd5a1fd..67769ef5d58b1 100644
> --- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> +++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
> @@ -18,6 +18,7 @@ properties:
> compatible:
> enum:
> - khadas,mcu # MCU revision is discoverable
The revision is no longer discoverable as was claimed?
> + - khadas,vim4-mcu
>
> "#cooling-cells": # Only needed for boards having FAN control feature
> const: 2
> @@ -25,6 +26,10 @@ properties:
> reg:
> maxItems: 1
>
> + fan-supply:
> + description: Phandle to the regulator that powers the fan.
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> required:
> - compatible
> - reg
>
> --
> 2.49.0
>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: pm660: add thermal monitor
From: Richard Acayan @ 2026-04-15 21:05 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Amit Kucheria, Thara Gopinath,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Stephen Boyd, Dmitry Baryshkov, linux-arm-msm, devicetree,
linux-pm
In-Reply-To: <4311c618-f084-44c5-86e2-7f97661d887b@oss.qualcomm.com>
On Wed, Apr 15, 2026 at 11:15:57AM +0200, Konrad Dybcio wrote:
> On 3/3/26 3:25 AM, Richard Acayan wrote:
> > On Tue, Feb 10, 2026 at 10:59:20AM +0100, Konrad Dybcio wrote:
> >> On 2/10/26 3:18 AM, Richard Acayan wrote:
> >>> The thermal monitor is used to monitor arbitrary ADC-based thermal
> >>> sensors. It is suitable for use in thermal zones. Add support for it in
> >>> PM660.
> >>>
> >>> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> >>> ---
> >>> arch/arm64/boot/dts/qcom/pm660.dtsi | 10 ++++++++++
> >>> 1 file changed, 10 insertions(+)
> >>>
> >>> diff --git a/arch/arm64/boot/dts/qcom/pm660.dtsi b/arch/arm64/boot/dts/qcom/pm660.dtsi
> >>> index 156b2ddff0dc..7cedf6980b34 100644
> >>> --- a/arch/arm64/boot/dts/qcom/pm660.dtsi
> >>> +++ b/arch/arm64/boot/dts/qcom/pm660.dtsi
> >>> @@ -197,6 +197,16 @@ channel@85 {
> >>> };
> >>> };
> >>>
> >>> + pm660_adc_tm: adc-tm@3400 {
> >>> + compatible = "qcom,spmi-adc-tm-hc";
> >>> + reg = <0x3400>;
> >>> + interrupts = <0x0 0x34 0x0 IRQ_TYPE_EDGE_RISING>;
> >>> + #thermal-sensor-cells = <1>;
> >>> + #address-cells = <1>;
> >>> + #size-cells = <0>;
> >>> + status = "disabled";
> >>
> >> Can we enable it by default?
> >
> > This is for the ADC thermal monitor, and not the ADC itself. I don't see
> > the need to allocate channels just so this can be enabled by default,
> > since the thermal monitor's purpose is mostly to send interrupts when
> > the ADC values go above or below a certain threshold.
>
> Sorry, this fell through the cracks
>
> I see your argument, but at the same time, there are channels that are
> always present (e.g. VPH_PWR) and any way to reduce the boilerplate is
> welcome
If you saw my first sentence in the reply, why are we talking about
VPH_PWR? I don't understand if you're asking for the thermal monitor to
handle a voltage sensor here.
^ permalink raw reply
* Re: [PATCH] power: supply: bd71828: add input current limit property
From: Andreas Kemnade @ 2026-04-15 20:13 UTC (permalink / raw)
To: Matti Vaittinen; +Cc: Sebastian Reichel, linux-pm, linux-kernel
In-Reply-To: <a4c43b29-a1bf-4709-8521-c21ce4ee3e46@gmail.com>
On Tue, 7 Apr 2026 09:33:25 +0300
Matti Vaittinen <mazziesaccount@gmail.com> wrote:
> I am afraid I don't know your use-case for the control of the DCIN input
> limit well enough to decide, if the BD72720 would need something similar
> - or if the VBUS_INLIM should be tied to the same knob. If you have the
> enthusiasm to write some more words ... I am keen on learning! :)
Justification for this patch is mostly: there is a standard interface
for this functionality and the chip has that functionality.
The bigger picture: Attach a power source with changing properties causes
mess. To repreduce issues at my desk, I have played around with a labor power
supply with changeable current limitation, turining it down to zero (so
power is off) then turning it on slowly again, no charging will happen. My
usual way around such a problem is to clear DCIN_ILIM_EN (will add a sysfs
attribute for that) and set some conservative current.
Regards,
Andreas
^ permalink raw reply
* Re: [bug report] power: supply: max77759: add charger driver
From: Amit Sunil Dhamne @ 2026-04-15 19:55 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-pm
In-Reply-To: <adjNgZAaULzTBtJO@stanley.mountain>
Hi Dan,
Thanks for running the static checker.
On 4/10/26 3:14 AM, Dan Carpenter wrote:
> Hello Amit Sunil Dhamne,
>
> Commit 70d7dd27f6dc ("power: supply: max77759: add charger driver")
> from Mar 25, 2026 (linux-next), leads to the following Smatch static
> checker warning:
>
> drivers/power/supply/max77759_charger.c:117 get_online()
> info: return a literal instead of 'ret'
>
> drivers/power/supply/max77759_charger.c
> 97 static int charger_input_valid(struct max77759_charger *chg)
> 98 {
> 99 u32 val;
> 100 int ret;
> 101
> 102 ret = regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_INT_OK, &val);
> 103 if (ret)
> 104 return ret;
> 105
> 106 return (val & MAX77759_CHGR_REG_CHG_INT_CHG) &&
> 107 (val & MAX77759_CHGR_REG_CHG_INT_CHGIN);
> 108 }
> 109
> 110 static int get_online(struct max77759_charger *chg)
> 111 {
> 112 u32 val;
> 113 int ret;
> 114
> 115 ret = charger_input_valid(chg);
> 116 if (ret <= 0)
> 117 return ret;
>
> This needs some comments. From the naming, we would assume
Sure, I can add a comment.
> charger_input_valid() returns true for valid and false for invalid.
>
> Based on reading the code get_online() return true/false as well
> but what does it mean? false means offline and true means online?
> In which sense is this a get_ function? I'm so confused.
You're correct, a value of 0 would mean offline, 1 would mean online and
a failure to read the hardware register would cause it to return with
the appropriate error code.
This is a get_ function because it is a internal helper function to get
the "POWER_SUPPLY_PROP_ONLINE" property.
BR,
Amit
>
> 118
> 119 ret = regmap_read(chg->regmap, MAX77759_CHGR_REG_CHG_DETAILS_02, &val);
> 120 if (ret)
> 121 return ret;
> 122
> 123 guard(mutex)(&chg->lock);
> 124
> 125 return (val & MAX77759_CHGR_REG_CHG_DETAILS_02_CHGIN_STS) &&
> 126 (chg->mode == MAX77759_CHGR_MODE_CHG_BUCK_ON);
> 127 }
>
> This email is a free service from the Smatch-CI project [smatch.sf.net].
>
> regards,
> dan carpenter
^ permalink raw reply
* Re: [PATCH v4 02/13] dt-bindings: leds: document Samsung S2M series PMIC RGB LED device
From: Kaustabh Chakraborty @ 2026-04-15 17:30 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <20260415-sensible-kiwi-of-argument-44d6ed@quoll>
On 2026-04-15 09:03 +02:00, Krzysztof Kozlowski wrote:
> On Tue, Apr 14, 2026 at 12:02:54PM +0530, Kaustabh Chakraborty wrote:
>> +description: |
>> + The Samsung S2M series PMIC RGB LED is a three-channel LED device with
>> + 8-bit brightness control for each channel, typically used as status
>> + indicators in mobile phones.
>> +
>> + This is a part of device tree bindings for S2M and S5M family of Power
>> + Management IC (PMIC).
>> +
>> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>> + additional information and example.
>> +
>> +allOf:
>> + - $ref: common.yaml#
>
> Rob's comment is still valid:
> 1. How do you address one of three LEDs in non-RGB case?
> 2. Where is multi-color?
Yes, multi-color should have been added here.
>
> And based on this alone without other properties, I say this should be
> part of top-level schema. Separate node is fine, but no need for
> separate binding.
BTW, for loading the sub-device driver via platform (as it won't be a
separate binding) the driver *must* be built-in. Although not related to
bindings, this seems counter-intuitive. I see the same problem with the
PMIC charger.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH v1] cpufreq: pcc: fix use-after-free and double free in _OSC evaluation
From: Yuho Choi @ 2026-04-15 16:51 UTC (permalink / raw)
To: Rafael J . Wysocki, Viresh Kumar; +Cc: linux-pm, linux-kernel, Yuho Choi
pcc_cpufreq_do_osc() evaluates _OSC twice with the same output buffer.
The first acpi_evaluate_object() allocates the buffer because output is
initialized with ACPI_ALLOCATE_BUFFER. Freeing output.pointer before the
second evaluation leaves output.length stale, so the next call treats
output as a caller-supplied buffer and performs a use-after-free write
into the freed memory. The final cleanup path then frees the same
pointer again, causing a double free.
Keep the first _OSC result alive until the shared cleanup path and route
the early error exits through out_free. This avoids both the use-after-
free on the second evaluation and the final double free.
Fixes: 0f1d683fb35d ("[CPUFREQ] Processor Clocking Control interface driver")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
---
drivers/cpufreq/pcc-cpufreq.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/pcc-cpufreq.c b/drivers/cpufreq/pcc-cpufreq.c
index ac2e90a65f0c4..165826b5d6844 100644
--- a/drivers/cpufreq/pcc-cpufreq.c
+++ b/drivers/cpufreq/pcc-cpufreq.c
@@ -23,6 +23,7 @@
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*/
+#include "acpi/actypes.h"
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
@@ -351,16 +352,19 @@ static int __init pcc_cpufreq_do_osc(acpi_handle *handle)
goto out_free;
}
- kfree(output.pointer);
capabilities[0] = 0x0;
capabilities[1] = 0x1;
status = acpi_evaluate_object(*handle, "_OSC", &input, &output);
- if (ACPI_FAILURE(status))
- return -ENODEV;
+ if (ACPI_FAILURE(status)) {
+ ret = -ENODEV;
+ goto out_free;
+ }
- if (!output.length)
- return -ENODEV;
+ if (!output.length) {
+ ret = -ENODEV;
+ goto out_free;
+ }
out_obj = output.pointer;
if (out_obj->type != ACPI_TYPE_BUFFER) {
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v4] PM: QoS: Introduce boot parameter pm_qos_resume_latency_us
From: Aaron Tomlin @ 2026-04-15 15:23 UTC (permalink / raw)
To: rafael, dakr, pavel, lenb
Cc: zhongqiu.han, akpm, bp, pmladek, rdunlap, feng.tang,
pawan.kumar.gupta, kees, elver, arnd, fvdl, lirongqing, bhelgaas,
neelx, sean, mproche, chjohnst, nick.lange, linux-kernel,
linux-pm, linux-doc
In-Reply-To: <20260308190421.46657-1-atomlin@atomlin.com>
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]
On Sun, Mar 08, 2026 at 03:04:21PM -0400, Aaron Tomlin wrote:
> Users currently lack a mechanism to define granular, per-CPU PM QoS
> resume latency constraints during the early boot phase.
>
> While the idle=poll boot parameter exists, it enforces a global
> override, forcing all CPUs in the system to "poll". This global approach
> is not suitable for asymmetric workloads where strict latency guarantees
> are required only on specific critical CPUs, while housekeeping or
> non-critical CPUs should be allowed to enter deeper idle states to save
> energy.
>
Hi Rafael, Danilo, Pavel, Len, Zhongqiu,
A gentle ping on this v4 series. I was hoping to see if there is any
further feedback on this approach to introducing the
"pm_qos_resume_latency_us=" boot parameter.
Please let me know if any further adjustments are required, or if you need
me to rebase this against the latest power management tree.
Kind regards,
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] thermal/drivers/sprd: Use for_each_child_of_node_scoped() in probe
From: Felix Gu @ 2026-04-15 15:07 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Orson Zhai, Baolin Wang, Chunyan Zhang
Cc: linux-pm, linux-kernel, Felix Gu
Use for_each_child_of_node_scoped() to avoid manual cleanup
of_node_put() in early exits from the loop, simplify the code.
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/thermal/sprd_thermal.c | 25 ++++++++-----------------
1 file changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/thermal/sprd_thermal.c b/drivers/thermal/sprd_thermal.c
index d683fcb0f8ab..069bc13ffc57 100644
--- a/drivers/thermal/sprd_thermal.c
+++ b/drivers/thermal/sprd_thermal.c
@@ -331,7 +331,6 @@ static void sprd_thm_toggle_sensor(struct sprd_thermal_sensor *sen, bool on)
static int sprd_thm_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- struct device_node *sen_child;
struct sprd_thermal_data *thm;
struct sprd_thermal_sensor *sen;
const struct sprd_thm_variant_data *pdata;
@@ -380,12 +379,10 @@ static int sprd_thm_probe(struct platform_device *pdev)
if (ret)
return ret;
- for_each_child_of_node(np, sen_child) {
+ for_each_child_of_node_scoped(np, sen_child) {
sen = devm_kzalloc(&pdev->dev, sizeof(*sen), GFP_KERNEL);
- if (!sen) {
- ret = -ENOMEM;
- goto of_put;
- }
+ if (!sen)
+ return -ENOMEM;
sen->data = thm;
sen->dev = &pdev->dev;
@@ -393,13 +390,13 @@ static int sprd_thm_probe(struct platform_device *pdev)
ret = of_property_read_u32(sen_child, "reg", &sen->id);
if (ret) {
dev_err(&pdev->dev, "get sensor reg failed");
- goto of_put;
+ return ret;
}
ret = sprd_thm_sensor_calibration(sen_child, thm, sen);
if (ret) {
dev_err(&pdev->dev, "efuse cal analysis failed");
- goto of_put;
+ return ret;
}
sprd_thm_sensor_init(thm, sen);
@@ -411,31 +408,25 @@ static int sprd_thm_probe(struct platform_device *pdev)
if (IS_ERR(sen->tzd)) {
dev_err(&pdev->dev, "register thermal zone failed %d\n",
sen->id);
- ret = PTR_ERR(sen->tzd);
- goto of_put;
+ return PTR_ERR(sen->tzd);
}
thm->sensor[sen->id] = sen;
}
- /* sen_child set to NULL at this point */
ret = sprd_thm_set_ready(thm);
if (ret)
- goto of_put;
+ return ret;
ret = sprd_thm_wait_temp_ready(thm);
if (ret)
- goto of_put;
+ return ret;
for (i = 0; i < thm->nr_sensors; i++)
sprd_thm_toggle_sensor(thm->sensor[i], true);
platform_set_drvdata(pdev, thm);
return 0;
-
-of_put:
- of_node_put(sen_child);
- return ret;
}
#ifdef CONFIG_PM_SLEEP
---
base-commit: 936c21068d7ade00325e40d82bfd2f3f29d9f659
change-id: 20260415-sprd-3034c3aa9649
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Herve Codina @ 2026-04-15 14:56 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Andy Shevchenko, Manivannan Sadhasivam, Manivannan Sadhasivam,
Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi, Hans de Goede, Bartosz Golaszewski, Luca Ceresoli
In-Reply-To: <CAGXv+5EPA29G-fsH=wWOD8AK6TZFezFhsE0NHPYj_Pt3nT+d_w@mail.gmail.com>
Hi Chen, all,
...
>
> I'm not arguing for a even more generic "M.2" connector. The "key" is
> already described in the compatible. I'm saying we should have some way
> of describing the individual interfaces (PCIe, SDIO, USB, UART, I2S, I2C)
> on the connector so further nodes or properties can be attached to them,
> either with overlays or dynamically within the kernel. Right now the
> are only described as individual ports, but we can't actually tie a
> device to a OF graph port.
>
> But maybe I'm overthinking the representation part. AFAICT for Qualcomm's
> UART-based BT bit part, Mani just had the driver create a device node
> under the UART (by traversing the OF graph to find the UART). If that's
> the desired way then the connector binding should mention it. And that
> works for me. But I think it's messier and also we're missing an
> opportunity to make the M.2 connector a standardized attachment point
> for overlays.
>
> Mani, could you also chime in a bit on what you envisioned?
>
> (Added Luca from Bootlin to CC, as I think there are parallels to the
> "Hotplug of Non-discoverable Hardware" work)
>
Related to "Hotplug of Non-discoverable Hardware",
I would add entries for busses in the connector without using an OF graph.
For I2C and later SPI, this was is done.
You already have an i2c-parent property but no node where an i2c device
can be added.
The last discussion related to hotplug, connectors and DT led to the RFC
series [1].
It is a huge series. The last patch give a real example of representation:
https://lore.kernel.org/all/20260112142009.1006236-78-herve.codina@bootlin.com/
In your case I would see some thing like:
connector {
compatible = "pcie-m2-e-connector";
vpcie3v3-supply = <&vreg_wcn_3p3>;
vpcie1v8-supply = <&vreg_l15b_1p8>;
/*
* If those GPIOs have to be used by components available in
* the connected board, a Nexus node should be used.
*/
w-disable1-gpios = <&tlmm 115 GPIO_ACTIVE_LOW>;
w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
viocfg-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
uart-wake-gpios = <&tlmm 118 GPIO_ACTIVE_LOW>;
sdio-wake-gpios = <&tlmm 119 GPIO_ACTIVE_LOW>;
sdio-reset-gpios = <&tlmm 120 GPIO_ACTIVE_LOW>;
conn-i2c {
i2c-parent = <&i2c0>;
/*
* Here i2c devices available on the board
* connected to the connector can be described.
*/
};
/* Same kind to description for other busses */
conn-pcie {
pci-parent = <&xxxxx>;
/*
* The PCIe bus has abilities to discover devices.
* Not sure this node is needed.
*
* If a PCI device need a DT description to describe
* stuffs behind the device, what has been done for LAN966x
* could be re-used [2] and [3]
*/
};
conn_uart {
uart-parent = <&uart-ctrl>;
/* uart child (maybe a serdes) should be describe here
};
...
};
Of course, some DT symbols need to be exported in order to have them usable from
the DT describing the connected board.
This notion of exported symbol is not yet available upstream and is the purpose of
the RFC series [1].
[1] https://lore.kernel.org/all/20260112142009.1006236-1-herve.codina@bootlin.com/
[2] https://elixir.bootlin.com/linux/v7.0/source/drivers/misc/lan966x_pci.c
[3] https://elixir.bootlin.com/linux/v7.0/source/drivers/misc/lan966x_pci.dtso
Feel free to ask for more specific question if needed.
Best regards,
Hervé
>
> Thanks
> ChenYu
>
>
> > > The latter part is solvable, but we likely need child nodes under the
> > > connector for the different interfaces. Properties that make sense for
> > > one type might not make sense for another.
> > >
> > > P.S. We could also just add child device nodes under the controller to
> > > put the generic properties, but that's splitting the description into
> > > multiple parts. Let's not go there if at all possible.
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v4 04/13] dt-bindings: power: supply: document Samsung S2M series PMIC charger device
From: Krzysztof Kozlowski @ 2026-04-15 14:39 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <DHTS9H2EIM2D.2TC17F9WBOOR1@disroot.org>
On 15/04/2026 16:03, Kaustabh Chakraborty wrote:
> On 2026-04-15 09:18 +02:00, Krzysztof Kozlowski wrote:
>> On Tue, Apr 14, 2026 at 12:02:56PM +0530, Kaustabh Chakraborty wrote:
>>> +description: |
>>> + The Samsung S2M series PMIC battery charger manages power interfacing
>>> + of the USB port. It may supply power, as done in USB OTG operation
>>> + mode, or it may accept power and redirect it to the battery fuelgauge
>>> + for charging.
>>> +
>>> + This is a part of device tree bindings for S2M and S5M family of Power
>>> + Management IC (PMIC).
>>> +
>>> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>>> + additional information and example.
>>> +
>>> +allOf:
>>> + - $ref: power-supply.yaml#
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - samsung,s2mu005-charger
>>> +
>>> + port:
>>> + $ref: /schemas/graph.yaml#/properties/port
>>
>> That port is internal part of the device, thus should be dropped which
>> leaves you with only one property - monitored battery - and therefore
>> fold the node into the parent node.
>
> And that monitored-battery belongs to power-supply.yaml. Do I then
> include the allOf block in the mfd/samsung,s2mps11.yaml under the
> s2mu005 compatible?
allOf does not go under the compatible. The entire device schema should
have $ref to power-supply.yaml, just like many other devices have that
or different $ref.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 05/13] dt-bindings: mfd: s2mps11: add documentation for S2MU005 PMIC
From: Krzysztof Kozlowski @ 2026-04-15 14:27 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <DHTSO9L6YZTQ.WYM9ERXBGNGB@disroot.org>
On 15/04/2026 16:22, Kaustabh Chakraborty wrote:
> On 2026-04-15 09:17 +02:00, Krzysztof Kozlowski wrote:
>> On Tue, Apr 14, 2026 at 12:02:57PM +0530, Kaustabh Chakraborty wrote:
>>>
>>> clocks:
>>> $ref: /schemas/clock/samsung,s2mps11.yaml
>>> description:
>>> Child node describing clock provider.
>>>
>>> + charger:
>>> + $ref: /schemas/power/supply/samsung,s2mu005-charger.yaml
>>> + description:
>>> + Child node describing battery charger device.
>>> +
>>> + extcon:
>>
>> You got comment to drop extcon naming. If this stays, it's muic for
>> example.
>>
>>> + $ref: /schemas/extcon/samsung,s2mu005-muic.yaml
>>> + description:
>>> + Child node describing extcon device.
>>> +
>>> + flash:
>>> + $ref: /schemas/leds/samsung,s2mu005-flash.yaml
>>> + description:
>>> + Child node describing flash LEDs.
>>> +
>>
>> Please make it a separate binding file.
>
> What do you mean by that?
I mean, S2MU005 should go to its own file.
>
>>
>>> interrupts:
>>> maxItems: 1
>>>
>>> @@ -43,6 +59,11 @@ properties:
>>> description:
>>> List of child nodes that specify the regulators.
>>>
>>> + rgb:
>>
>> led
>
> Well flash ones are also LEDs. Would you rather have `flash { ... }` and
> `rgb { ... }` under `led { ... }` instead?
There is no approved name "rgb" for LEDs. What is the name for flash LEDs?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 05/13] dt-bindings: mfd: s2mps11: add documentation for S2MU005 PMIC
From: Kaustabh Chakraborty @ 2026-04-15 14:22 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <20260415-notorious-dainty-starfish-58a13c@quoll>
On 2026-04-15 09:17 +02:00, Krzysztof Kozlowski wrote:
> On Tue, Apr 14, 2026 at 12:02:57PM +0530, Kaustabh Chakraborty wrote:
>>
>> clocks:
>> $ref: /schemas/clock/samsung,s2mps11.yaml
>> description:
>> Child node describing clock provider.
>>
>> + charger:
>> + $ref: /schemas/power/supply/samsung,s2mu005-charger.yaml
>> + description:
>> + Child node describing battery charger device.
>> +
>> + extcon:
>
> You got comment to drop extcon naming. If this stays, it's muic for
> example.
>
>> + $ref: /schemas/extcon/samsung,s2mu005-muic.yaml
>> + description:
>> + Child node describing extcon device.
>> +
>> + flash:
>> + $ref: /schemas/leds/samsung,s2mu005-flash.yaml
>> + description:
>> + Child node describing flash LEDs.
>> +
>
> Please make it a separate binding file.
What do you mean by that?
>
>> interrupts:
>> maxItems: 1
>>
>> @@ -43,6 +59,11 @@ properties:
>> description:
>> List of child nodes that specify the regulators.
>>
>> + rgb:
>
> led
Well flash ones are also LEDs. Would you rather have `flash { ... }` and
`rgb { ... }` under `led { ... }` instead?
>
>> + $ref: /schemas/leds/samsung,s2mu005-rgb.yaml
>> + description:
>> + Child node describing RGB LEDs.
>> +
^ permalink raw reply
* Re: [PATCH v4 04/13] dt-bindings: power: supply: document Samsung S2M series PMIC charger device
From: Kaustabh Chakraborty @ 2026-04-15 14:03 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <20260415-swinging-radical-junglefowl-85dcf7@quoll>
On 2026-04-15 09:18 +02:00, Krzysztof Kozlowski wrote:
> On Tue, Apr 14, 2026 at 12:02:56PM +0530, Kaustabh Chakraborty wrote:
>> +description: |
>> + The Samsung S2M series PMIC battery charger manages power interfacing
>> + of the USB port. It may supply power, as done in USB OTG operation
>> + mode, or it may accept power and redirect it to the battery fuelgauge
>> + for charging.
>> +
>> + This is a part of device tree bindings for S2M and S5M family of Power
>> + Management IC (PMIC).
>> +
>> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>> + additional information and example.
>> +
>> +allOf:
>> + - $ref: power-supply.yaml#
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - samsung,s2mu005-charger
>> +
>> + port:
>> + $ref: /schemas/graph.yaml#/properties/port
>
> That port is internal part of the device, thus should be dropped which
> leaves you with only one property - monitored battery - and therefore
> fold the node into the parent node.
And that monitored-battery belongs to power-supply.yaml. Do I then
include the allOf block in the mfd/samsung,s2mps11.yaml under the
s2mu005 compatible?
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: The "clockevents: Prevent timer interrupt starvation" patch causes lockups
From: Eric Naim @ 2026-04-15 13:51 UTC (permalink / raw)
To: Hanabishi, Thomas Gleixner
Cc: Frederic Weisbecker, LKML, Calvin Owens, Peter Zijlstra,
Anna-Maria Behnsen, 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: <e6d3dc64-1714-4105-8a38-3942c62d159a@gmail.com>
On 4/15/26 5:35 AM, Hanabishi wrote:
> On 14/04/2026 20:55, Thomas Gleixner wrote:
>> The one below should cover all possible holes.
>>
>> Thanks,
>>
>> tglx
>> ---
>> diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
>> index b4d730604972..5e22697b098d 100644
>> --- a/kernel/time/clockevents.c
>> +++ b/kernel/time/clockevents.c
>> @@ -94,6 +94,9 @@ static int __clockevents_switch_state(struct
>> clock_event_device *dev,
>> if (dev->features & CLOCK_EVT_FEAT_DUMMY)
>> return 0;
>> + /* On state transitions clear the forced flag unconditionally */
>> + dev->next_event_forced = 0;
>> +
>> /* Transition with new state-specific callbacks */
>> switch (state) {
>> case CLOCK_EVT_STATE_DETACHED:
>> @@ -366,8 +369,10 @@ int clockevents_program_event(struct clock_event_device
>> *dev, ktime_t expires, b
>> if (delta > (int64_t)dev->min_delta_ns) {
>> delta = min(delta, (int64_t) dev->max_delta_ns);
>> cycles = ((u64)delta * dev->mult) >> dev->shift;
>> - if (!dev->set_next_event((unsigned long) cycles, dev))
>> + if (!dev->set_next_event((unsigned long) cycles, dev)) {
>> + dev->next_event_forced = 0;
>> return 0;
>> + }
>> }
>> if (dev->next_event_forced)
>> diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
>> index 7e57fa31ee26..115e0bf01276 100644
>> --- a/kernel/time/tick-broadcast.c
>> +++ b/kernel/time/tick-broadcast.c
>> @@ -108,6 +108,7 @@ static struct clock_event_device
>> *tick_get_oneshot_wakeup_device(int cpu)
>> static void tick_oneshot_wakeup_handler(struct clock_event_device *wd)
>> {
>> + wd->next_event_forced = 0;
>> /*
>> * If we woke up early and the tick was reprogrammed in the
>> * meantime then this may be spurious but harmless.
>
> Ok, it does fix the problem! Thank you.
> The patch itself does not apply cleanly for 7.0 though and I had to adapt it a
> bit.
>
Sorry for the delay folks! This patch fixes the regression and a user recently
confirmed it as well.
Feel free to add:
Tested-by: Eric Naim <dnaim@cachyos.org>
--
Regards,
Eric
^ permalink raw reply
* [PATCH v2 2/2] thermal/drivers/imxl:Fix runtime PM handling on early returns
From: Felix Gu @ 2026-04-15 13:10 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: <20260415-imx-v2-0-aeacff9e72b2@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")
Reviewed-by: Frank Li <Frank.Li@nxp.com>
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 3729c3eac748..057dbab70266 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -274,8 +274,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);
@@ -316,8 +317,6 @@ static int imx_get_temp(struct thermal_zone_device *tz, int *temp)
enable_irq(data->irq);
}
- pm_runtime_put(data->dev);
-
return 0;
}
@@ -351,8 +350,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 */
@@ -362,8 +362,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 v2 1/2] thermal/drivers/imx: Fix thermal zone leak on probe error path
From: Felix Gu @ 2026-04-15 13:10 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: <20260415-imx-v2-0-aeacff9e72b2@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.
Switch to use devm_thermal_of_zone_register() to fix the problem.
Fixes: 4cf2ddf16e17 ("thermal/drivers/imx: Implement runtime PM support")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/thermal/imx_thermal.c | 35 +++++++++++++++++++----------------
1 file changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 38c993d1bcb3..3729c3eac748 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -216,6 +216,20 @@ struct imx_thermal_data {
const char *temp_grade;
};
+static int imx_thermal_sync_zone_trip(struct thermal_trip *trip, void *arg)
+{
+ struct imx_thermal_data *data = arg;
+ int temp;
+
+ if (trip->type != THERMAL_TRIP_PASSIVE && trip->type != THERMAL_TRIP_CRITICAL)
+ return 0;
+
+ temp = trips[trip->type].temperature;
+ thermal_zone_set_trip_temp(data->tz, trip, temp);
+
+ return 0;
+}
+
static void imx_set_panic_temp(struct imx_thermal_data *data,
int panic_temp)
{
@@ -679,13 +693,8 @@ static int imx_thermal_probe(struct platform_device *pdev)
goto legacy_cleanup;
}
- data->tz = thermal_zone_device_register_with_trips("imx_thermal_zone",
- trips,
- ARRAY_SIZE(trips),
- data,
- &imx_tz_ops, NULL,
- IMX_PASSIVE_DELAY,
- IMX_POLLING_DELAY);
+ data->irq_enabled = true;
+ data->tz = devm_thermal_of_zone_register(dev, 0, data, &imx_tz_ops);
if (IS_ERR(data->tz)) {
ret = PTR_ERR(data->tz);
dev_err(dev, "failed to register thermal zone device %d\n",
@@ -693,6 +702,8 @@ static int imx_thermal_probe(struct platform_device *pdev)
goto clk_disable;
}
+ thermal_zone_for_each_trip(data->tz, imx_thermal_sync_zone_trip, data);
+
dev_info(dev, "%s CPU temperature grade - max:%dC"
" critical:%dC passive:%dC\n", data->temp_grade,
data->temp_max / 1000, trips[IMX_TRIP_CRITICAL].temperature / 1000,
@@ -724,25 +735,18 @@ static int imx_thermal_probe(struct platform_device *pdev)
if (ret < 0)
goto disable_runtime_pm;
- data->irq_enabled = true;
- ret = thermal_zone_device_enable(data->tz);
- if (ret)
- goto thermal_zone_unregister;
-
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);
@@ -761,7 +765,6 @@ static void imx_thermal_remove(struct platform_device *pdev)
pm_runtime_put_noidle(data->dev);
pm_runtime_disable(data->dev);
- thermal_zone_device_unregister(data->tz);
imx_thermal_unregister_legacy_cooling(data);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] thermal/drivers/imx: two fixes
From: Felix Gu @ 2026-04-15 13:10 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>
---
Changes in v2:
- Switch to use devm_thermal_of_zone_register() to fix Frank and Daniel's comment.
- Collect Frank's Reviewed-by tag for patch 2.
- Link to v1: https://lore.kernel.org/r/20260412-imx-v1-0-cc3b45d63811@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 | 49 ++++++++++++++++++++++---------------------
1 file changed, 25 insertions(+), 24 deletions(-)
---
base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
change-id: 20260411-imx-b022791ea1b9
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: pm660: add thermal monitor
From: Konrad Dybcio @ 2026-04-15 9:15 UTC (permalink / raw)
To: Richard Acayan
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Amit Kucheria, Thara Gopinath,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Stephen Boyd, Dmitry Baryshkov, linux-arm-msm, devicetree,
linux-pm
In-Reply-To: <aaXKyIJQA9SFqt41@rdacayan>
On 3/3/26 3:25 AM, Richard Acayan wrote:
> On Tue, Feb 10, 2026 at 10:59:20AM +0100, Konrad Dybcio wrote:
>> On 2/10/26 3:18 AM, Richard Acayan wrote:
>>> The thermal monitor is used to monitor arbitrary ADC-based thermal
>>> sensors. It is suitable for use in thermal zones. Add support for it in
>>> PM660.
>>>
>>> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/pm660.dtsi | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/pm660.dtsi b/arch/arm64/boot/dts/qcom/pm660.dtsi
>>> index 156b2ddff0dc..7cedf6980b34 100644
>>> --- a/arch/arm64/boot/dts/qcom/pm660.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/pm660.dtsi
>>> @@ -197,6 +197,16 @@ channel@85 {
>>> };
>>> };
>>>
>>> + pm660_adc_tm: adc-tm@3400 {
>>> + compatible = "qcom,spmi-adc-tm-hc";
>>> + reg = <0x3400>;
>>> + interrupts = <0x0 0x34 0x0 IRQ_TYPE_EDGE_RISING>;
>>> + #thermal-sensor-cells = <1>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + status = "disabled";
>>
>> Can we enable it by default?
>
> This is for the ADC thermal monitor, and not the ADC itself. I don't see
> the need to allocate channels just so this can be enabled by default,
> since the thermal monitor's purpose is mostly to send interrupts when
> the ADC values go above or below a certain threshold.
Sorry, this fell through the cracks
I see your argument, but at the same time, there are channels that are
always present (e.g. VPH_PWR) and any way to reduce the boilerplate is
welcome
Konrad
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Andy Shevchenko @ 2026-04-15 9:07 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Manivannan Sadhasivam, Manivannan Sadhasivam, Rob Herring,
Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor, Nicolas Schier,
Hans de Goede, Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski, Luca Ceresoli
In-Reply-To: <CAGXv+5EPA29G-fsH=wWOD8AK6TZFezFhsE0NHPYj_Pt3nT+d_w@mail.gmail.com>
On Wed, Apr 15, 2026 at 04:31:24PM +0800, Chen-Yu Tsai wrote:
> On Tue, Apr 14, 2026 at 8:03 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Apr 14, 2026 at 06:29:02PM +0800, Chen-Yu Tsai wrote:
> > > On Tue, Apr 14, 2026 at 4:28 PM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
> > > > On Tue, Apr 14, 2026 at 01:03:19PM +0800, Chen-Yu Tsai wrote:
> > > > > On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > > On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
...
> > > > > > > > - Given that this connector actually represents two devices, how do I
> > > > > > > > say I want the BT part to be a wakeup source, but not the WiFi part?
> > > > > > > > Does wakeup-source even work at this point?
> > > > > > >
> > > > > > > You can't use the DT property since the devices are not described in DT
> > > > > > > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > > > > > > wakeup.
> > > > >
> > > > > I see. I think not being able to specify generic properties for the devices
> > > > > on the connector is going to be a bit problematic.
> > > >
> > > > This is nature of the open-connectors, especially on the busses that are
> > > > hotpluggable, like PCIe. We never know what is connected there _ahead_.
> > >
> > > I believe what you mean by "hotpluggable" is "user replaceable".
> >
> > From the OS perspective it's the same. From platform perspective
> > there is a difference, granted.
>
> Yes. I just wanted to clarify.
>
> > > > In other words you can't describe in DT something that may not exist.
> > >
> > > But this is actually doable with the PCIe slot representation. The
> > > properties are put in the device node for the slot. If no card is
> > > actually inserted in the slot, then no device is created, and the
> > > device node is left as not associated with anything.
> >
> > But you need to list all devices in the world if you want to support this
>
> Why would I need to? The PCIe slot representation just describes a
> PCIe bridge. Granted this might not be entirely correct, but it's
> what we currently have.
>
> And even then, there are properties like memory-region or wakeup-source
> that are generic and aren't tied to specific devices.
Yes, see below what I replied...
> > somehow. Yes, probably many of them (or majority) will be enumerated as is,
^^^ "the majority" will work without any assistance.
> > but some may need an assistance via (dynamic) properties or similar mechanisms.
> Even if we wanted to add dynamic properties, there is currently no proper
> device node to attach them to.
Isn't that's node created dynamically as well and attached to the PCI bus?
> > > It's just that for this new M.2 E-key connector, there aren't separate
> > > nodes for each interface. And the system doesn't associate the device
> > > node with the device, because it's no longer a child node of the
> > > controller or hierarchy, but connected over the OF graph.
> > >
> > > Moving over to the E-key connector representation seems like one step
> > > forward and one step backward in descriptive ability. We gain proper
> > > power sequencing, but lose generic properties.
> >
> > The "key" is property of the connector. Hence if you have an idea what can be
> > common for ALL "key":s, that's probably can be abstracted. Note, I'm not
> > familiar with the connector framework in the Linux kernel, perhaps it's already
> > that kind of abstraction.
>
> I'm not arguing for a even more generic "M.2" connector. The "key" is
> already described in the compatible. I'm saying we should have some way
> of describing the individual interfaces (PCIe, SDIO, USB, UART, I2S, I2C)
> on the connector so further nodes or properties can be attached to them,
> either with overlays or dynamically within the kernel. Right now the
> are only described as individual ports, but we can't actually tie a
> device to a OF graph port.
Shouldn't it be described as a DT subtree? Sorry, I am not familiar with DT
enough to understand the issue you have.
> But maybe I'm overthinking the representation part. AFAICT for Qualcomm's
> UART-based BT bit part, Mani just had the driver create a device node
> under the UART (by traversing the OF graph to find the UART). If that's
> the desired way then the connector binding should mention it. And that
> works for me. But I think it's messier and also we're missing an
> opportunity to make the M.2 connector a standardized attachment point
> for overlays.
Okay, now it might get clearer to me, but still, I am not an expert.
> Mani, could you also chime in a bit on what you envisioned?
+1, please elaborate to me as well.
> (Added Luca from Bootlin to CC, as I think there are parallels to the
> "Hotplug of Non-discoverable Hardware" work)
>
> > > The latter part is solvable, but we likely need child nodes under the
> > > connector for the different interfaces. Properties that make sense for
> > > one type might not make sense for another.
> > >
> > > P.S. We could also just add child device nodes under the controller to
> > > put the generic properties, but that's splitting the description into
> > > multiple parts. Let's not go there if at all possible.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Chen-Yu Tsai @ 2026-04-15 8:31 UTC (permalink / raw)
To: Andy Shevchenko, Manivannan Sadhasivam
Cc: Manivannan Sadhasivam, Rob Herring, Greg Kroah-Hartman,
Jiri Slaby, Nathan Chancellor, Nicolas Schier, Hans de Goede,
Ilpo Järvinen, Mark Pearson, Derek J. Clark,
Krzysztof Kozlowski, Conor Dooley, Marcel Holtmann,
Luiz Augusto von Dentz, Bartosz Golaszewski, Bartosz Golaszewski,
linux-serial, linux-kernel, linux-kbuild, platform-driver-x86,
linux-pci, devicetree, linux-arm-msm, linux-bluetooth, linux-pm,
Stephan Gerhold, Dmitry Baryshkov, linux-acpi, Hans de Goede,
Bartosz Golaszewski, Luca Ceresoli
In-Reply-To: <ad4tJN27opdEooA7@ashevche-desk.local>
On Tue, Apr 14, 2026 at 8:03 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Apr 14, 2026 at 06:29:02PM +0800, Chen-Yu Tsai wrote:
> > On Tue, Apr 14, 2026 at 4:28 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:
> > > On Tue, Apr 14, 2026 at 01:03:19PM +0800, Chen-Yu Tsai wrote:
> > > > On Tue, Apr 14, 2026 at 12:08 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > On Mon, Apr 13, 2026 at 07:33:12PM +0530, Manivannan Sadhasivam wrote:
> > > > > > On Mon, Apr 13, 2026 at 03:54:59PM +0800, Chen-Yu Tsai wrote:
> > > > > > > On Thu, Mar 26, 2026 at 01:36:28PM +0530, Manivannan Sadhasivam wrote:
>
> ...
>
> > > > > > > - Given that this connector actually represents two devices, how do I
> > > > > > > say I want the BT part to be a wakeup source, but not the WiFi part?
> > > > > > > Does wakeup-source even work at this point?
> > > > > >
> > > > > > You can't use the DT property since the devices are not described in DT
> > > > > > statically. But you can still use the per-device 'wakeup' sysfs knob to enable
> > > > > > wakeup.
> > > >
> > > > I see. I think not being able to specify generic properties for the devices
> > > > on the connector is going to be a bit problematic.
> > >
> > > This is nature of the open-connectors, especially on the busses that are
> > > hotpluggable, like PCIe. We never know what is connected there _ahead_.
> >
> > I believe what you mean by "hotpluggable" is "user replaceable".
>
> From the OS perspective it's the same. From platform perspective
> there is a difference, granted.
Yes. I just wanted to clarify.
> > > In other words you can't describe in DT something that may not exist.
> >
> > But this is actually doable with the PCIe slot representation. The
> > properties are put in the device node for the slot. If no card is
> > actually inserted in the slot, then no device is created, and the
> > device node is left as not associated with anything.
>
> But you need to list all devices in the world if you want to support this
Why would I need to? The PCIe slot representation just describes a
PCIe bridge. Granted this might not be entirely correct, but it's
what we currently have.
And even then, there are properties like memory-region or wakeup-source
that are generic and aren't tied to specific devices.
> somehow. Yes, probably many of them (or majority) will be enumerated as is,
> but some may need an assistance via (dynamic) properties or similar mechanisms.
Even if we wanted to add dynamic properties, there is currently no proper
device node to attach them to.
> > It's just that for this new M.2 E-key connector, there aren't separate
> > nodes for each interface. And the system doesn't associate the device
> > node with the device, because it's no longer a child node of the
> > controller or hierarchy, but connected over the OF graph.
> >
> > Moving over to the E-key connector representation seems like one step
> > forward and one step backward in descriptive ability. We gain proper
> > power sequencing, but lose generic properties.
>
> The "key" is property of the connector. Hence if you have an idea what can be
> common for ALL "key":s, that's probably can be abstracted. Note, I'm not
> familiar with the connector framework in the Linux kernel, perhaps it's already
> that kind of abstraction.
I'm not arguing for a even more generic "M.2" connector. The "key" is
already described in the compatible. I'm saying we should have some way
of describing the individual interfaces (PCIe, SDIO, USB, UART, I2S, I2C)
on the connector so further nodes or properties can be attached to them,
either with overlays or dynamically within the kernel. Right now the
are only described as individual ports, but we can't actually tie a
device to a OF graph port.
But maybe I'm overthinking the representation part. AFAICT for Qualcomm's
UART-based BT bit part, Mani just had the driver create a device node
under the UART (by traversing the OF graph to find the UART). If that's
the desired way then the connector binding should mention it. And that
works for me. But I think it's messier and also we're missing an
opportunity to make the M.2 connector a standardized attachment point
for overlays.
Mani, could you also chime in a bit on what you envisioned?
(Added Luca from Bootlin to CC, as I think there are parallels to the
"Hotplug of Non-discoverable Hardware" work)
Thanks
ChenYu
> > The latter part is solvable, but we likely need child nodes under the
> > connector for the different interfaces. Properties that make sense for
> > one type might not make sense for another.
> >
> > P.S. We could also just add child device nodes under the controller to
> > put the generic properties, but that's splitting the description into
> > multiple parts. Let's not go there if at all possible.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* [PATCH] PM: hibernate: align default resume swap with image-device checks
From: DaeMyung Kang @ 2026-04-15 8:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Len Brown, Pavel Machek, Youngjun Park, Andrew Morton, linux-pm,
linux-kernel, DaeMyung Kang
snapshot_open(O_RDONLY) pins the configured default resume swap area for
hibernation image writes, but it does not fully propagate that choice to
the image-device checks used by the block layer.
In particular, snapshot_open() uses swsusp_resume_device without
swsusp_resume_block when pinning the default resume swap area, and it
leaves snapshot_state.dev unset even after the pin succeeds. As a
result, the default resume swap selected at open time is not kept
aligned with is_hibernate_resume_dev() and can still be rejected by the
block layer in blkdev_write_iter() with -ETXTBSY until user space
explicitly selects the same area via SNAPSHOT_SET_SWAP_AREA.
Use swsusp_resume_block when pinning the default resume swap area and
record the device immediately after a successful pin so that the
hibernation image-device bookkeeping matches the configured resume
area. Also clear snapshot_state.dev on the open-time error path so it
never advertises a session that failed to fully open.
uswsusp itself is not affected because it always calls
SNAPSHOT_SET_SWAP_AREA right after open, which immediately overrides
snapshot_state.dev and re-pins the swap area. The user-visible change
is for minimal hibernation user space that relies on resume= and
resume_offset= alone: such tools no longer have to restate the resume
area via SNAPSHOT_SET_SWAP_AREA just to satisfy blkdev_write_iter()'s
IS_SWAPFILE gate or to obtain SWP_HIBERNATION swapoff protection. This
also matches the intent of the existing "The image device should be
accessible" comment in snapshot_open(). For the configured default
resume area, this gives snapshot_open() the same pin and
recorded-device state that SNAPSHOT_SET_SWAP_AREA would establish for
that same area, so user space relying on resume= and resume_offset=
does not need a follow-up SNAPSHOT_SET_SWAP_AREA just to satisfy the
IS_SWAPFILE gate and obtain swapoff protection.
Signed-off-by: DaeMyung Kang <charsyam@gmail.com>
---
Based on linux-next/master at commit e6efabc0afca ("Add linux-next
specific files for 20260414").
Tested in QEMU: with swap on a block device pointed to by
/sys/power/resume, opening /dev/snapshot O_RDONLY and then writing to
the swap block device returned -ETXTBSY before this change and -ENOSPC
(i.e. no longer rejected by the IS_SWAPFILE gate) after.
kernel/power/user.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/power/user.c b/kernel/power/user.c
index d0fcfba7ac23..c51b8185de4b 100644
--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -69,9 +69,13 @@ static int snapshot_open(struct inode *inode, struct file *filp)
data = &snapshot_state;
filp->private_data = data;
memset(&data->handle, 0, sizeof(struct snapshot_handle));
+ data->dev = 0;
if ((filp->f_flags & O_ACCMODE) == O_RDONLY) {
/* Hibernating. The image device should be accessible. */
- data->swap = pin_hibernation_swap_type(swsusp_resume_device, 0);
+ data->swap = pin_hibernation_swap_type(swsusp_resume_device,
+ swsusp_resume_block);
+ if (data->swap >= 0)
+ data->dev = swsusp_resume_device;
data->mode = O_RDONLY;
data->free_bitmaps = false;
error = pm_notifier_call_chain_robust(PM_HIBERNATION_PREPARE, PM_POST_HIBERNATION);
@@ -92,13 +96,13 @@ static int snapshot_open(struct inode *inode, struct file *filp)
}
if (error) {
unpin_hibernation_swap_type(data->swap);
+ data->dev = 0;
hibernate_release();
}
data->frozen = false;
data->ready = false;
data->platform_support = false;
- data->dev = 0;
Unlock:
unlock_system_sleep(sleep_flags);
--
2.43.0
^ permalink raw reply related
* Re: [RFC PATCH 1/2] kernel/notifier: replace single-linked list with double-linked list for reverse traversal
From: Christoph Hellwig @ 2026-04-15 7:40 UTC (permalink / raw)
To: chensong_2000
Cc: rafael, lenb, mturquette, sboyd, viresh.kumar, agk, snitzer,
mpatocka, bmarzins, song, yukuai, linan122, jason.wessel, danielt,
dianders, horms, davem, edumazet, kuba, pabeni, paulmck, frederic,
mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin, jpoimboe,
jikos, mbenes, pmladek, joe.lawrence, rostedt, mhiramat,
mark.rutland, mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <20260415070137.17860-1-chensong_2000@189.cn>
On Wed, Apr 15, 2026 at 03:01:37PM +0800, chensong_2000@189.cn wrote:
> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
> index 132a9df98471..b776dbd5a382 100644
> --- a/drivers/acpi/sleep.c
> +++ b/drivers/acpi/sleep.c
> @@ -56,7 +56,6 @@ static int tts_notify_reboot(struct notifier_block *this,
>
> static struct notifier_block tts_notifier = {
> .notifier_call = tts_notify_reboot,
> - .next = NULL,
> .priority = 0,
IFF this becomes important for some reason (and right now I don't see
it), please start by using proper wrappers for notifiers so that the
implementation details don't leak into the users. That would actually
be useful on it's own even.
^ permalink raw reply
* Re: [RFC PATCH 0/2] Decouple ftrace/livepatch from module loader via notifier priority and reverse traversal
From: Christoph Hellwig @ 2026-04-15 7:38 UTC (permalink / raw)
To: chensong_2000
Cc: rafael, lenb, mturquette, sboyd, viresh.kumar, agk, snitzer,
mpatocka, bmarzins, song, yukuai, linan122, jason.wessel, danielt,
dianders, horms, davem, edumazet, kuba, pabeni, paulmck, frederic,
mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin, jpoimboe,
jikos, mbenes, pmladek, joe.lawrence, rostedt, mhiramat,
mark.rutland, mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <20260413080140.180616-1-chensong_2000@189.cn>
On Mon, Apr 13, 2026 at 04:01:40PM +0800, chensong_2000@189.cn wrote:
> From: Song Chen <chensong_2000@189.cn>
>
> This patchset addresses a long-standing tight coupling between the
> module loader and two of its key consumers: ftrace and livepatch.
>
> Background:
>
> The module loader currently hard-codes direct calls to
> ftrace_module_enable(), klp_module_coming(), klp_module_going() and
> ftrace_release_mod() inside prepare_coming_module() and the module
> unload path.
And that is bad why?
> 13 files changed, 290 insertions(+), 74 deletions(-)
This is a lot of new complex code touching a lot of places for no obvious
gain. What is the reason for this series? Does it prepare for something
else?
^ permalink raw reply
* Re: [PATCH v4 07/13] mfd: sec: set DMA coherent mask
From: Krzysztof Kozlowski @ 2026-04-15 7:19 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <20260414-s2mu005-pmic-v4-7-7fe7480577e6@disroot.org>
On Tue, Apr 14, 2026 at 12:02:59PM +0530, Kaustabh Chakraborty wrote:
> Kernel logs are filled with "DMA mask not set" messages for every
> sub-device. The device does not use DMA for communication, so these
> messages are useless. Disable the coherent DMA mask for the PMIC device,
> which is also propagated to sub-devices.
>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> ---
> Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml | 3 +++
> drivers/mfd/sec-common.c | 3 +++
> 2 files changed, 6 insertions(+)
>
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox