* [PATCH v8 09/15] arm64: dts: qcom: sdm845-lg-judyln: Add lab/ibb
From: Paul Sajna @ 2026-04-02 6:38 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown,
Paul Sajna, Konrad Dybcio
In-Reply-To: <20260401-judyln-dts-v8-0-7677cfafbc78@postmarketos.org>
These regulators are required for the LCD
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
index 6b837da4ef21..2c024b32c00c 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
@@ -71,6 +71,23 @@ &ipa {
firmware-name = "qcom/sdm845/LG/judyln/ipa_fws.mbn";
};
+&ibb {
+ regulator-min-microvolt = <5500000>;
+ regulator-max-microvolt = <5500000>;
+ regulator-over-current-protection;
+ regulator-pull-down;
+ regulator-soft-start;
+ qcom,discharge-resistor-kohms = <300>;
+};
+
+&lab {
+ regulator-min-microvolt = <5500000>;
+ regulator-max-microvolt = <5500000>;
+ regulator-over-current-protection;
+ regulator-pull-down;
+ regulator-soft-start;
+};
+
&mss_pil {
firmware-name = "qcom/sdm845/LG/judyln/mba.mbn", "qcom/sdm845/LG/judyln/modem.mbn";
};
--
2.53.0
^ permalink raw reply related
* [PATCH v8 10/15] arm64: dts: qcom: sdm845-lg-judyln: Add display panel
From: Paul Sajna @ 2026-04-02 6:38 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown,
Paul Sajna, Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260401-judyln-dts-v8-0-7677cfafbc78@postmarketos.org>
Also include other supporting msm drm nodes, gpio and backlight
Co-developed-by: Amir Dahan <system64fumo@tuta.io>
Signed-off-by: Amir Dahan <system64fumo@tuta.io>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 13 +++--
arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts | 68 +++++++++++++++++++++++++-
2 files changed, 75 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 51cd930488a9..552d9719bede 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -450,10 +450,6 @@ &cdsp_pas {
status = "okay";
};
-&dispcc {
- status = "disabled";
-};
-
&gcc {
protected-clocks = <GCC_QSPI_CORE_CLK>,
<GCC_QSPI_CORE_CLK_SRC>,
@@ -525,6 +521,15 @@ led@5 {
};
};
+&pmi8998_wled {
+ qcom,current-limit-microamp = <20000>;
+ qcom,ovp-millivolt = <29600>;
+ qcom,switching-freq = <800>;
+ qcom,num-strings = <3>;
+ qcom,cabc;
+ status = "okay";
+};
+
&qupv3_id_0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
index 2c024b32c00c..7948fe3dbaa2 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
@@ -21,8 +21,6 @@ framebuffer@9d400000 {
height = <3120>;
stride = <(1440 * 4)>;
format = "a8r8g8b8";
- lab-supply = <&lab>;
- ibb-supply = <&ibb>;
};
};
@@ -71,6 +69,51 @@ &ipa {
firmware-name = "qcom/sdm845/LG/judyln/ipa_fws.mbn";
};
+&mdss {
+ status = "okay";
+};
+
+&mdss_dsi0 {
+ vdda-supply = <&vdda_mipi_dsi0_1p2>;
+
+ status = "okay";
+
+ display_panel: panel@0 {
+ reg = <0>;
+ compatible = "lg,sw49410-lh609qh1", "lg,sw49410";
+
+ backlight = <&pmi8998_wled>;
+ reset-gpios = <&tlmm 6 GPIO_ACTIVE_LOW>;
+ width-mm = <65>;
+ height-mm = <140>;
+
+ vsp-supply = <&lab>;
+ vsn-supply = <&ibb>;
+
+ pinctrl-0 = <&sde_dsi_active &sde_te_active_sleep>;
+ pinctrl-1 = <&sde_dsi_sleep &sde_te_active_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&mdss_dsi0_out>;
+ };
+ };
+ };
+};
+
+&mdss_dsi0_phy {
+ vdds-supply = <&vdda_mipi_dsi0_pll>;
+
+ status = "okay";
+};
+
+&mdss_dsi0_out {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&panel_in>;
+ qcom,te-source = "mdp_vsync_e";
+};
+
&ibb {
regulator-min-microvolt = <5500000>;
regulator-max-microvolt = <5500000>;
@@ -106,6 +149,27 @@ thinq_key_default: thinq-key-default-state {
drive-strength = <2>;
bias-pull-up;
};
+
+ sde_dsi_active: sde-dsi-active-state {
+ pins = "gpio6";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+
+ sde_dsi_sleep: sde-dsi-sleep-state {
+ pins = "gpio6";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ sde_te_active_sleep: sde-te-active-sleep-state {
+ pins = "gpio10";
+ function = "mdp_vsync";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
};
&venus {
--
2.53.0
^ permalink raw reply related
* [PATCH v8 11/15] arm64: dts: qcom: sdm845-lg: Add wifi nodes
From: Paul Sajna @ 2026-04-02 6:38 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown,
Paul Sajna, Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260401-judyln-dts-v8-0-7677cfafbc78@postmarketos.org>
Wi-Fi now works with this patch, relevant firmware and
qcom,snoc-host-cap-skip-quirk
qcom,snoc-host-cap-skip-quirk has not been approved/merged in mainline,
so it is not included here.
ath10k_snoc 18800000.wifi: qmi chip_id 0x30214 chip_family 0x4001 board_id 0xff soc_id 0x40030001
ath10k_snoc 18800000.wifi: qmi fw_version 0x20060285 fw_build_timestamp 2020-10-12 23:35 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c4-00645-QCAHLSWMTPLZ-1.336037.2
ath10k_snoc 18800000.wifi: wcn3990 hw1.0 target 0x00000008 chip_id 0x00000000 sub 0000:0000
ath10k_snoc 18800000.wifi: kconfig debug 1 debugfs 1 tracing 0 dfs 0 testmode 0
ath10k_snoc 18800000.wifi: firmware ver api 5 features wowlan,mgmt-tx-by-reference,non-bmi crc32 b3d4b790
ath10k_snoc 18800000.wifi: htt-ver 3.83 wmi-op 4 htt-op 3 cal file max-sta 32 raw 0 hwcrypto 1
ath10k_snoc 18800000.wifi: invalid MAC address; choosing random
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 10 ++++++++++
arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts | 4 ++++
arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts | 4 ++++
3 files changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 552d9719bede..8481f0cce974 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -670,3 +670,13 @@ &usb_1_qmpphy {
&venus {
status = "okay";
};
+
+&wifi {
+ vdd-0.8-cx-mx-supply = <&vreg_l5a_0p8>;
+ vdd-1.8-xo-supply = <&vreg_l7a_1p8>;
+ vdd-1.3-rfa-supply = <&vreg_l17a_1p3>;
+ vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
+ vdd-3.3-ch1-supply = <&vreg_l23a_3p3>;
+
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
index 7948fe3dbaa2..adf41aa0146a 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
@@ -175,3 +175,7 @@ sde_te_active_sleep: sde-te-active-sleep-state {
&venus {
firmware-name = "qcom/sdm845/LG/judyln/venus.mbn";
};
+
+&wifi {
+ qcom,calibration-variant = "lg_judyln";
+};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts b/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts
index efca260c3dcf..d244ebdd17be 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts
@@ -56,3 +56,7 @@ &mss_pil {
&venus {
firmware-name = "qcom/sdm845/LG/judyp/venus.mbn";
};
+
+&wifi {
+ qcom,calibration-variant = "lg_judyp";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v8 12/15] arm64: dts: qcom: sdm845-lg-common: Add chassis-type
From: Paul Sajna @ 2026-04-02 6:38 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown,
Paul Sajna, Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260401-judyln-dts-v8-0-7677cfafbc78@postmarketos.org>
The sdm845-lg devices are all phones, therefore handset chassis
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 8481f0cce974..71d070619ad7 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -28,6 +28,8 @@
/delete-node/ &wlan_msa_mem;
/ {
+ chassis-type = "handset";
+
aliases {
serial0 = &uart9;
serial1 = &uart6;
--
2.53.0
^ permalink raw reply related
* [PATCH v8 13/15] arm64: dts: qcom: sdm845-lg-common: Add camera flash
From: Paul Sajna @ 2026-04-02 6:41 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Heidelberg
Cc: Paul Sajna, linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown,
Konrad Dybcio
In-Reply-To: <20260401-judyln-dts-v8-0-cf13065e52ab@postmarketos.org>
Camera doesn't work yet (imx351), but we can use the flash as a flashlight.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 71d070619ad7..9d82961d527e 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -496,6 +496,19 @@ &pm8998_resin {
status = "okay";
};
+&pmi8998_flash {
+ status = "okay";
+
+ led-0 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <1>, <2>;
+ led-max-microamp = <100000>;
+ flash-max-microamp = <500000>;
+ flash-max-timeout-us = <500000>;
+ };
+};
+
&pmi8998_lpg {
status = "okay";
--
2.53.0
^ permalink raw reply related
* [PATCH v8 14/15] arm64: dts: qcom: sdm845-lg-common: Change ipa gsi-loader to 'self', add memory-region
From: Paul Sajna @ 2026-04-02 6:42 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Heidelberg
Cc: Paul Sajna, linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown,
Konrad Dybcio
In-Reply-To: <20260401-judyln-dts-v8-0-cf13065e52ab@postmarketos.org>
The modem firmware for this device doesn't preload the IPA firmware
and requires the OS handles that instead. Set qcom,gsi-loader = "self"
to reflect that.
Ensure the ipa uses the correct memory.
ipa 1e40000.ipa: channel 4 limited to 256 TREs
ipa 1e40000.ipa: IPA driver initialized
ipa 1e40000.ipa: received modem starting event
ipa 1e40000.ipa: received modem running event
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 9d82961d527e..85dc4468b6c4 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -473,7 +473,9 @@ &gpu {
};
&ipa {
- qcom,gsi-loader = "modem";
+ qcom,gsi-loader = "self";
+ memory-region = <&ipa_fw_mem>;
+
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/5] Exynos850 APM-to-AP mailbox support
From: Krzysztof Kozlowski @ 2026-04-02 6:43 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <DHIB5E66SP7A.110YA5R1OOQHS@linaro.org>
On 02/04/2026 04:19, Alexey Klimov wrote:
> On Sat Mar 21, 2026 at 10:44 AM GMT, Krzysztof Kozlowski wrote:
>> On Fri, Mar 20, 2026 at 09:15:12PM +0000, Alexey Klimov wrote:
>>> Hi all,
>>>
>>> This patch series introduces support for the APM-to-AP mailbox on the
>>> Exynos850 SoC. This mailbox is required for communicating with the APM
>>> co-processor using ACPM.
>>>
>>> The Exynos850 mailbox operates similarly to the existing gs101
>>> implementation, but the register offsets and IRQ mask bits differ.
>>> This series abstracts these differences into platform-specific data
>>> structures matched via the device tree.
>>>
>>> Also, it requires APM-to-AP mailbox clock in CMU_APM block.
>>>
>>> In theory this can be split into two series with correct dependecies:
>>> device tree node requires clock changes to be merged. The suggestion
>>> is to let this go through Samsung SoC tree with corresponding acks
>>> if it is okay.
>>
>> I don't understand why this cannot be split into two seris
>> *practically*. What is exactly the dependency between mailbox and DTS,
>> that it had to be combined here?
>
> Do you suggest to send 3 single patches with proper dependencies
> description? DT bindings change first, then mailbox change that specifically
> depends on dt-bindings change and then dts update (which will depend on both)?
>
> I thought that mbox driver change depends implicitly on bindings update?
Please don't answer to a question with a question. Actually three
questions. If you cannot give argument why there is a dependency, feels
to me like you send something you do not understand.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v8 15/15] arm64: dts: qcom: sdm845-lg-{judyln, judyp}: Reference memory region in fb
From: Paul Sajna @ 2026-04-02 6:43 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Heidelberg
Cc: Paul Sajna, linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown
In-Reply-To: <20260401-judyln-dts-v8-0-cf13065e52ab@postmarketos.org>
To prevent duplicating the framebuffer address and size point out the
existing framebuffer memory region instead of specifying the address
manually.
Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
---
arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 3 +--
arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts | 4 ++--
arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts | 4 ++--
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
index 85dc4468b6c4..86cf4eb44084 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
@@ -98,8 +98,7 @@ spss_mem: memory@99000000 {
no-map;
};
- /* Framebuffer region */
- memory@9d400000 {
+ framebuffer_mem: memory@9d400000 {
reg = <0x0 0x9d400000 0x0 0x2400000>;
no-map;
};
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
index adf41aa0146a..349faa123ff1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyln.dts
@@ -14,9 +14,9 @@ / {
compatible = "lg,judyln", "qcom,sdm845";
chosen {
- framebuffer@9d400000 {
+ framebuffer {
compatible = "simple-framebuffer";
- reg = <0x0 0x9d400000 0x0 (1440 * 3120 * 4)>;
+ memory-region = <&framebuffer_mem>;
width = <1440>;
height = <3120>;
stride = <(1440 * 4)>;
diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts b/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts
index d244ebdd17be..44e762f78e95 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-lg-judyp.dts
@@ -14,9 +14,9 @@ / {
compatible = "lg,judyp", "qcom,sdm845";
chosen {
- framebuffer@9d400000 {
+ framebuffer {
compatible = "simple-framebuffer";
- reg = <0x0 0x9d400000 0x0 (1440 * 2880 * 4)>;
+ memory-region = <&framebuffer_mem>;
width = <1440>;
height = <2880>;
stride = <(1440 * 4)>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 5/6] dma-buf: heaps: Add Coherent heap to dmabuf heaps
From: Marek Szyprowski @ 2026-04-02 6:52 UTC (permalink / raw)
To: Maxime Ripard, Andrew Davis
Cc: Albert Esteve, Sumit Semwal, Benjamin Gaignard, Brian Starkey,
John Stultz, T.J. Mercier, Christian König, Robin Murphy,
Rob Herring, Saravana Kannan, linux-kernel, linux-media,
dri-devel, linaro-mm-sig, iommu, devicetree, echanude
In-Reply-To: <20260316-cherubic-eel-of-philosophy-10ef2b@houat>
On 16.03.2026 13:08, Maxime Ripard wrote:
> On Wed, Mar 11, 2026 at 08:18:28AM -0500, Andrew Davis wrote:
>> On 3/11/26 5:19 AM, Albert Esteve wrote:
>>> On Tue, Mar 10, 2026 at 4:34 PM Andrew Davis <afd@ti.com> wrote:
>>>> On 3/6/26 4:36 AM, Albert Esteve wrote:
>>>>> Expose DT coherent reserved-memory pools ("shared-dma-pool"
>>>>> without "reusable") as dma-buf heaps, creating one heap per
>>>>> region so userspace can allocate from the exact device-local
>>>>> pool intended for coherent DMA.
>>>>>
>>>>> This is a missing backend in the long-term effort to steer
>>>>> userspace buffer allocations (DRM, v4l2, dma-buf heaps)
>>>>> through heaps for clearer cgroup accounting. CMA and system
>>>>> heaps already exist; non-reusable coherent reserved memory
>>>>> did not.
>>>>>
>>>>> The heap binds the heap device to each memory region so
>>>>> coherent allocations use the correct dev->dma_mem, and
>>>>> it defers registration until module_init when normal
>>>>> allocators are available.
>>>>>
>>>>> Signed-off-by: Albert Esteve <aesteve@redhat.com>
>>>>> ---
>>>>> drivers/dma-buf/heaps/Kconfig | 9 +
>>>>> drivers/dma-buf/heaps/Makefile | 1 +
>>>>> drivers/dma-buf/heaps/coherent_heap.c | 414 ++++++++++++++++++++++++++++++++++
>>>>> 3 files changed, 424 insertions(+)
>>>>>
>>>>> (...)
>>>> You are doing this DMA allocation using a non-DMA pseudo-device (heap_dev).
>>>> This is why you need to do that dma_coerce_mask_and_coherent(64) nonsense, you
>>>> are doing a DMA alloc for the CPU itself. This might still work, but only if
>>>> dma_map_sgtable() can handle swiotlb/iommu for all attaching devices at map
>>>> time.
>>> The concern is valid. We're allocating via a synthetic device, which
>>> ties the allocation to that device's DMA domain. I looked deeper into
>>> this trying to address the concern.
>>>
>>> The approach works because dma_map_sgtable() handles both
>>> dma_map_direct and use_dma_iommu cases in __dma_map_sg_attrs(). For
>>> each physical address in the sg_table (extracted via sg_phys()), it
>>> creates device-specific DMA mappings:
>>> - For direct mapping: it checks if the address is directly accessible
>>> (dma_capable()), and if not, it falls back to swiotlb.
>>> - For IOMMU: it creates mappings that allow the device to access
>>> physical addresses.
>>>
>>> This means every attached device gets its own device-specific DMA
>>> mapping, properly handling cases where the physical addresses are
>>> inaccessible or have DMA constraints.
>>>
>> While this means it might still "work" it won't always be ideal. Take
>> the case where the consuming device(s) have a 32bit address restriction,
>> if the allocation was done using the real devices then the backing buffer
>> itself would be allocated in <32bit mem. Whereas here the allocation
>> could end up in >32bit mem, as the CPU/synthetic device supports that.
>> Then each mapping device would instead get a bounce buffer.
>>
>> (this example might not be great as we usually know the address of
>> carveout/reserved memory regions, but substitute in whatever restriction
>> makes more sense)
>>
>> These non-reusable carveouts tend to be made for some specific device, and
>> they are made specifically because that device has some memory restriction.
>> So we might run into the situation above more than one would expect.
>>
>> Not a blocker here, but just something worth thinking on.
> As I detailed in the previous version [1] the main idea behind that work
> is to allow to get rid of dma_alloc_attrs for framework and drivers to
> allocate from the heaps instead.
>
> Robin was saying he wasn't comfortable with exposing this heap to
> userspace, and we're saying here that maybe this might not always work
> anyway (or at least that we couldn't test it fully).
>
> Maybe the best thing is to defer this series until we are at a point
> where we can start enabling the "heap allocations" in frameworks then?
> Hopefully we will have hardware to test it with by then, and we might
> not even need to expose it to userspace at all but only to the kernel.
>
> What do you think?
IMHO a good idea. Maybe in-kernel heap for the coherent allocations will
be just enough.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH v3 3/3] input: touchscreen: st1232: add system wakeup support
From: Geert Uytterhoeven @ 2026-04-02 6:56 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: phucduc.bui, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Wolfram Sang, Jeff LaBundy, Bastian Hecht,
Javier Carrasco, linux-input, devicetree, linux-renesas-soc,
linux-kernel
In-Reply-To: <ac37o-N5lqFMwDCC@google.com>
Hi Dmitry,
On Thu, 2 Apr 2026 at 07:17, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On Fri, Mar 06, 2026 at 06:19:12PM +0700, phucduc.bui@gmail.com wrote:
> > From: bui duc phuc <phucduc.bui@gmail.com>
> >
> > The ST1232 touchscreen controller can generate an interrupt when the
> > panel is touched, which may be used as a wakeup source for the system.
> >
> > Add support for system wakeup by initializing the device wakeup
> > capability in probe() based on the "wakeup-source" device property.
> > When wakeup is enabled, the driver enables IRQ wake during suspend
> > so that touch events can wake the system.
> >
> > If wakeup is not enabled, the driver retains the existing behavior of
> > disabling the IRQ and powering down the controller during suspend.
>
> I do not believe this patch is needed: i2c core already handles
> "wakeup-source" property and manages wakeup IRQ.
No, it is not needed, as mentioned in the cover letter of v4[1],
and as tested by me[2].
[1] https://lore.kernel.org/20260309000319.74880-1-phucduc.bui@gmail.com
[2] https://lore.kernel.org/CAMuHMdUqiaP=COTkKU_jK6Hdii+YJ5+zXnxFkOOnhLri5NakTw@mail.gmail.com
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: iio: dac: Add ADI AD5706R
From: Krzysztof Kozlowski @ 2026-04-02 7:00 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260401-dev_ad5706r-v4-1-a785184a8d53@analog.com>
On Wed, Apr 01, 2026 at 06:20:03PM +0800, Alexis Czezar Torreno wrote:
> + vref-supply:
> + description:
> + Optional external 2.5V voltage reference. If not provided, the
> + internal 2.5V reference is used.
> +
> + pwms:
> + maxItems: 1
> + description:
> + Optional PWM connected to the LDAC/TGP/DCK pin for hardware
> + triggered DAC updates, toggle, or dither clock generation.
> +
> + reset-gpios:
> + maxItems: 1
> + description:
> + GPIO connected to the active low RESET pin. If not provided,
> + software reset is used.
> +
> + out-en-gpios:
Isn't this just enable-gpios from gpio-consumer-common? Does the device
have more enable-like GPIOs?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v12 0/7] i2c: xiic: use generic device property accessors
From: Abdurrahman Hussain @ 2026-04-02 7:01 UTC (permalink / raw)
To: Andi Shyti, abdurrahman
Cc: Michal Simek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Shevchenko, linux-arm-kernel, linux-i2c, linux-kernel,
devicetree, Andrew Lunn, Jonathan Cameron
In-Reply-To: <ac2r9m9mSMZxgHwN@zenone.zhora.eu>
On Wed Apr 1, 2026 at 4:41 PM PDT, Andi Shyti wrote:
>> Abdurrahman Hussain (7):
>> i2c: xiic: switch to devres managed APIs
>> i2c: xiic: remove duplicate error message
>> i2c: xiic: switch to generic device property accessors
>> i2c: xiic: cosmetic cleanup
>> i2c: xiic: cosmetic: use resource format specifier in debug log
>> i2c: xiic: use numbered adapter registration
>> i2c: xiic: skip input clock setup on non-OF systems
>
> Good job Abdurrahman, thanks for following up in all the rounds
> of reviews. I finally merged your patch in i2c/i2c-host.
>
> Thanks,
> Andi
Thank you for merging the changes, Andi. I would also like to express my
appreciation to all reviewers for their valuable feedback and patience
throughout the review process.
Best regards,
Abdurrahman
^ permalink raw reply
* Re: [PATCH 3/3] pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
From: Taniya Das @ 2026-04-02 7:02 UTC (permalink / raw)
To: Fenglin Wu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel
In-Reply-To: <20260401-haw-rpmhpd-v1-3-c830c79ed8f9@oss.qualcomm.com>
On 4/1/2026 2:45 PM, Fenglin Wu wrote:
> Add the RPMh power domains required for the Hawi SoC. This includes
> new definitions for domains supplying specific hardware components:
> - DCX: supplies VDD_DISP
> - GBX: supplies VDD_GFX_BX
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> drivers/pmdomain/qcom/rpmhpd.c | 38 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c
> index 19849703be4a..f5ae2a63765d 100644
> --- a/drivers/pmdomain/qcom/rpmhpd.c
> +++ b/drivers/pmdomain/qcom/rpmhpd.c
> @@ -102,11 +102,21 @@ static struct rpmhpd cx_ao_w_mx_parent = {
> .res_name = "cx.lvl",
> };
>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: media: qcom,sm8550-iris: Add X1P42100 compatible
From: Krzysztof Kozlowski @ 2026-04-02 7:05 UTC (permalink / raw)
To: Wangao Wang
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260401-enable_iris_on_purwa-v4-1-ca784552a3e9@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 06:24:38PM +0800, Wangao Wang wrote:
> Document the new compatible string "qcom,x1p42100-iris".
>
> The x1p42100 SoC integrates the same IRIS video hardware block as SM8550,
> but represents a distinct hardware instance.
Full stop, as I asked last time.
> and therefore uses its own
> compatible string.
Drop, redundant. X1P42100 is not the same soc as SM8550, thus you cannot
have the same compatible. This is explicitly written in bindings. Each
different device needs own compatible string.
Adding obvious explanation from documentation to commit msg is
redundant.
Explain why devices are not compatible.
>
> The x1p42100 variant includes an additional Bitstream Engine (BSE) clock
> that is not present on SM8550.
Presence of additional clock does not indicate that devices are
compatible. Look at other qcom bindings - many are compatible even
though they have different clocks.
So say that you need to do something with that clock differently.
> This clock is described explicitly in the
> binding.
Last sentence - again, redundant. Write concise but informative
messages.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/5] media: iris: Add hardware power on/off ops for X1P42100
From: Krzysztof Kozlowski @ 2026-04-02 7:08 UTC (permalink / raw)
To: Wangao Wang
Cc: Bryan O'Donoghue, Vikash Garodia, Dikshita Agarwal,
Abhinav Kumar, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260401-enable_iris_on_purwa-v4-2-ca784552a3e9@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 06:24:39PM +0800, Wangao Wang wrote:
> On X1P42100 the Iris block has an extra BSE clock. Wire this clock into
> the power on/off sequence.
>
> The BSE clock is used to drive the Bin Stream Engine, which is a sub-block
> of the video codec hardware responsible for bitstream-level processing. It
> is required to be enabled separately from the core clock to ensure proper
> codec operation.
>
> Signed-off-by: Wangao Wang <wangao.wang@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_vpu3x.c | 46 ++++++++++++++++++++++
> drivers/media/platform/qcom/iris/iris_vpu_common.h | 1 +
> 2 files changed, 47 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu3x.c b/drivers/media/platform/qcom/iris/iris_vpu3x.c
> index fe4423b951b1e9e31d06dffc69d18071cc985731..e6a62b3ca78efeefa2eed267636789a6b405689f 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu3x.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu3x.c
> @@ -71,6 +71,44 @@ static void iris_vpu3_power_off_hardware(struct iris_core *core)
> iris_vpu_power_off_hw(core);
> }
>
> +static int iris_vpu3_purwa_power_on_hw(struct iris_core *core)
> +{
> + int ret;
> +
> + ret = iris_enable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
> + if (ret)
> + return ret;
> +
> + ret = iris_prepare_enable_clock(core, IRIS_HW_CLK);
> + if (ret)
> + goto err_disable_power;
> +
> + ret = iris_prepare_enable_clock(core, IRIS_BSE_HW_CLK);
> + if (ret)
> + goto err_disable_hw_clock;
> +
> + ret = dev_pm_genpd_set_hwmode(core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN], true);
> + if (ret)
> + goto err_disable_bse_hw_clock;
> +
> + return 0;
> +
> +err_disable_bse_hw_clock:
> + iris_disable_unprepare_clock(core, IRIS_BSE_HW_CLK);
> +err_disable_hw_clock:
> + iris_disable_unprepare_clock(core, IRIS_HW_CLK);
> +err_disable_power:
> + iris_disable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_HW_POWER_DOMAIN]);
> +
> + return ret;
> +}
Why no IRIS_HW_AHB_CLK in power on sequence?
So if you rewrite the code that you have list of clocks for hw power on
(IRIS_HW_CLK + IRIS_HW_AHB_CLK for all variants, +IRIS_BSE_HW_CLK on
this variant) you could have just one function for all of them and
devices will be fully compatible.
No?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v1] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: karthik.s @ 2026-04-02 7:08 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, linux-sound, devicetree, linux-kernel, karthik.s
Add has_always_on_supplies for managing regulators. Indicates that
the codec supply regulators are always enabled by the system and
must not be requested or enabled by the codec driver.
Signed-off-by: karthik.s <karthik.s@oss.qualcomm.com>
---
.../devicetree/bindings/sound/qcom,wcd937x.yaml | 6 ++++++
sound/soc/codecs/wcd937x.c | 13 +++++++++----
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
index f94203798f24..d89fff1f7171 100644
--- a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
@@ -28,6 +28,12 @@ properties:
vdd-px-supply:
description: A reference to the 1.8V I/O supply
+ qcom,always-on-supply:
+ type: boolean
+ description: Indicates that the codec supply regulators are always enabled
+ by the system and must not be requested or enabled by the codec
+ driver.
+
required:
- compatible
- vdd-px-supply
diff --git a/sound/soc/codecs/wcd937x.c b/sound/soc/codecs/wcd937x.c
index 10a2d598caa7..1514ceb7d790 100644
--- a/sound/soc/codecs/wcd937x.c
+++ b/sound/soc/codecs/wcd937x.c
@@ -100,6 +100,7 @@ struct wcd937x_priv {
int aux_pdm_wd_int;
bool comp1_enable;
bool comp2_enable;
+ bool has_always_on_supplies;
struct gpio_desc *us_euro_gpio;
struct gpio_desc *reset_gpio;
@@ -2907,10 +2908,14 @@ static int wcd937x_probe(struct platform_device *pdev)
cfg = &wcd937x->mbhc_cfg;
cfg->swap_gnd_mic = wcd937x_swap_gnd_mic;
- ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(wcd937x_supplies),
- wcd937x_supplies);
- if (ret)
- return dev_err_probe(dev, ret, "Failed to get and enable supplies\n");
+ wcd937x->has_always_on_supplies = of_property_read_bool(dev->of_node,
+ "qcom,always-on-supply");
+ if (!wcd937x->has_always_on_supplies) {
+ ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(wcd937x_supplies),
+ wcd937x_supplies);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to get and enable supplies\n");
+ }
ret = wcd_dt_parse_micbias_info(&wcd937x->common);
if (ret)
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 5/5] arm64: dts: qcom: purwa-iot-som: enable video
From: Krzysztof Kozlowski @ 2026-04-02 7:11 UTC (permalink / raw)
To: Dikshita Agarwal
Cc: Wangao Wang, Bryan O'Donoghue, Vikash Garodia, Abhinav Kumar,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-media,
linux-arm-msm, devicetree, linux-kernel, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <9f94af36-6460-c227-2735-628e45819a03@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 06:12:24PM +0530, Dikshita Agarwal wrote:
> On 4/1/2026 3:54 PM, Wangao Wang wrote:
> > Enable video nodes on the purwa-iot-som board.
> >
> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > Signed-off-by: Wangao Wang <wangao.wang@oss.qualcomm.com>
> > ---
> > arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi b/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
> > index 394e65518ac5037e5c7c50583acefc0dbc8ebb47..ff8621f8750584636ad781467f9c35ace2354e4c 100644
> > --- a/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/purwa-iot-som.dtsi
> > @@ -389,6 +389,10 @@ &gpu_zap_shader {
> > firmware-name = "qcom/x1p42100/gen71500_zap.mbn";
> > };
> >
> > +&iris {
> > + status = "okay";
> > +};
> > +
> > &pcie3 {
> > pinctrl-0 = <&pcie3_default>;
> > pinctrl-names = "default";
> >
>
> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>
I wonder how many reviews from qcom are needed for such trivial one
liners which are 100% obvious. Let's go for more - please everyone,
let's provide here review:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Does it make any sense? Are we making the process just ridicilous?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: Krzysztof Kozlowski @ 2026-04-02 7:13 UTC (permalink / raw)
To: karthik.s, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, linux-sound, devicetree, linux-kernel
In-Reply-To: <20260402070854.2804291-1-karthik.s@oss.qualcomm.com>
On 02/04/2026 09:08, karthik.s wrote:
> Add has_always_on_supplies for managing regulators. Indicates that
> the codec supply regulators are always enabled by the system and
> must not be requested or enabled by the codec driver.
>
> Signed-off-by: karthik.s <karthik.s@oss.qualcomm.com>
Please configure your Git.
> ---
> .../devicetree/bindings/sound/qcom,wcd937x.yaml | 6 ++++++
> sound/soc/codecs/wcd937x.c | 13 +++++++++----
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.
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
> index f94203798f24..d89fff1f7171 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
> +++ b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
> @@ -28,6 +28,12 @@ properties:
> vdd-px-supply:
> description: A reference to the 1.8V I/O supply
>
> + qcom,always-on-supply:
You described the desired Linux feature or behavior, not the actual
hardware. The bindings are about the latter, so instead you need to
rephrase the property and its description to match actual hardware
capabilities/features/configuration etc.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: perf: marvell: Document CN20K DDR PMU
From: Krzysztof Kozlowski @ 2026-04-02 7:16 UTC (permalink / raw)
To: Geetha sowjanya
Cc: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree,
mark.rutland, will, krzk+dt
In-Reply-To: <20260401081640.23740-2-gakula@marvell.com>
On Wed, Apr 01, 2026 at 01:46:39PM +0530, Geetha sowjanya wrote:
> Add a devicetree binding for the Marvell CN20K DDR performance
> monitor block, including the marvell,cn20k-ddr-pmu compatible
> string and the required MMIO reg region.
You just repeated the diff. No need, we can read the diff, but what we
cannot read is the hardware you are here describing.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
> .../bindings/perf/marvell-cn20k-ddr.yaml | 39 +++++++++++++++++++
So you did not test v1. You did not test v2.
Did you finally test this one before sending?
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
>
> diff --git a/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
> new file mode 100644
> index 000000000000..fa757017d66e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/perf/marvell-cn20k-ddr.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Marvell CN20K DDR performance monitor
> +
> +description:
> + Performance Monitoring Unit (PMU) for the DDR controller
> + in Marvell CN20K SoCs.
> +
> +maintainers:
> + - Geetha sowjanya <gakula@marvell.com>
> +
> +properties:
> + compatible:
> + const: marvell,cn20k-ddr-pmu
There is no such thing as marvell,cn20k in upstream. What's that?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: perf: marvell: Document CN20K DDR PMU
From: Krzysztof Kozlowski @ 2026-04-02 7:17 UTC (permalink / raw)
To: Geetha sowjanya
Cc: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree,
mark.rutland, will, krzk+dt
In-Reply-To: <20260401081640.23740-2-gakula@marvell.com>
On Wed, Apr 01, 2026 at 01:46:39PM +0530, Geetha sowjanya wrote:
> Add a devicetree binding for the Marvell CN20K DDR performance
> monitor block, including the marvell,cn20k-ddr-pmu compatible
> string and the required MMIO reg region.
>
> Signed-off-by: Geetha sowjanya <gakula@marvell.com>
> ---
> .../bindings/perf/marvell-cn20k-ddr.yaml | 39 +++++++++++++++++++
> 1 file changed, 39 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
I forgot:
Filename must match compatible.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: karthik.s @ 2026-04-02 7:22 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel, karthik.s
Add has_always_on_supplies for managing regulators. Indicates that the
codec power supplies are provided by the board as always-on rails and
are not switchable by the codec or its associated regulators. This implies
that the codec supply regulators are always enabled by the system and
must not be requested or enabled by the codec driver.
Signed-off-by: karthik.s <karthik.s@oss.qualcomm.com>
---
.../devicetree/bindings/sound/qcom,wcd937x.yaml | 8 ++++++++
sound/soc/codecs/wcd937x.c | 13 +++++++++----
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
index f94203798f24..38b3452788e9 100644
--- a/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml
@@ -28,6 +28,14 @@ properties:
vdd-px-supply:
description: A reference to the 1.8V I/O supply
+ qcom,always-on-supply:
+ type: boolean
+ description: Indicates that the codec power supplies are provided by the board
+ as always-on rails and are not switchable by the codec or its
+ associated regulators. This implies that the codec supply regulators
+ are always enabled by the system and must not be requested or enabled
+ by the codec driver.
+
required:
- compatible
- vdd-px-supply
diff --git a/sound/soc/codecs/wcd937x.c b/sound/soc/codecs/wcd937x.c
index 10a2d598caa7..1514ceb7d790 100644
--- a/sound/soc/codecs/wcd937x.c
+++ b/sound/soc/codecs/wcd937x.c
@@ -100,6 +100,7 @@ struct wcd937x_priv {
int aux_pdm_wd_int;
bool comp1_enable;
bool comp2_enable;
+ bool has_always_on_supplies;
struct gpio_desc *us_euro_gpio;
struct gpio_desc *reset_gpio;
@@ -2907,10 +2908,14 @@ static int wcd937x_probe(struct platform_device *pdev)
cfg = &wcd937x->mbhc_cfg;
cfg->swap_gnd_mic = wcd937x_swap_gnd_mic;
- ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(wcd937x_supplies),
- wcd937x_supplies);
- if (ret)
- return dev_err_probe(dev, ret, "Failed to get and enable supplies\n");
+ wcd937x->has_always_on_supplies = of_property_read_bool(dev->of_node,
+ "qcom,always-on-supply");
+ if (!wcd937x->has_always_on_supplies) {
+ ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(wcd937x_supplies),
+ wcd937x_supplies);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to get and enable supplies\n");
+ }
ret = wcd_dt_parse_micbias_info(&wcd937x->common);
if (ret)
--
2.34.1
^ permalink raw reply related
* [PATCH v12 00/15] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-04-02 7:26 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
The crash memory allocation, and the exclude of crashk_res, crashk_low_res
and crashk_cma memory are almost identical across different architectures,
This patch set handle them in crash core in a general way, which eliminate
a lot of duplication code.
And add support for crashkernel CMA reservation for arm64 and riscv.
Rebased on v7.0-rc1.
Basic second kernel boot test were performed on QEMU platforms for x86,
ARM64, and RISC-V architectures with the following parameters:
"cma=256M crashkernel=256M crashkernel=64M,cma"
Changes in v12:
- Remove the unused "nr_mem_ranges" for x86.
- Add "Fix crashk_low_res not exclude bug" test log.
- Provide a separate patch for each architecture for using
crash_prepare_headers(), which will make the review more convenient.
- Add Reviewed-by and Tested-by.
- Link to v11: https://lore.kernel.org/all/20260328074013.3589544-1-ruanjinjie@huawei.com/
Changes in v11:
- Avoid silently drop crash memory if the crash kernel is built without
CONFIG_CMA.
- Remove unnecessary "cmem->nr_ranges = 0" for arch_crash_populate_cmem()
as we use kvzalloc().
- Provide a separate patch for each architecture to fix the existing
buffer overflow issue.
- Add Acked-bys for arm64.
Changes in v10:
- Fix crashk_low_res not excluded bug in the existing
RISC-V code.
- Fix an existing memory leak issue in the existing PowerPC code.
- Fix the ordering issue of adding CMA ranges to
"linux,usable-memory-range".
- Fix an existing concurrency issue. A Concurrent memory hotplug may occur
between reading memblock and attempting to fill cmem during kexec_load()
for almost all existing architectures.
- Link to v9: https://lore.kernel.org/all/20260323072745.2481719-1-ruanjinjie@huawei.com/
Changes in v9:
- Collect Reviewed-by and Acked-by, and prepare for Sashiko AI review.
- Link to v8: https://lore.kernel.org/all/20260302035315.3892241-1-ruanjinjie@huawei.com/
Changes in v8:
- Fix the build issues reported by kernel test robot and Sourabh.
- Link to v7: https://lore.kernel.org/all/20260226130437.1867658-1-ruanjinjie@huawei.com/
Changes in v7:
- Correct the inclusion of CMA-reserved ranges for kdump kernel in of/kexec
for arm64 and riscv.
- Add Acked-by.
- Link to v6: https://lore.kernel.org/all/20260224085342.387996-1-ruanjinjie@huawei.com/
Changes in v6:
- Update the crash core exclude code as Mike suggested.
- Rebased on v7.0-rc1.
- Add acked-by.
- Link to v5: https://lore.kernel.org/all/20260212101001.343158-1-ruanjinjie@huawei.com/
Jinjie Ruan (14):
riscv: kexec_file: Fix crashk_low_res not exclude bug
powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
x86/kexec: Fix potential buffer overflow in prepare_elf_headers()
arm64: kexec_file: Fix potential buffer overflow in
prepare_elf_headers()
riscv: kexec_file: Fix potential buffer overflow in
prepare_elf_headers()
LoongArch: kexec: Fix potential buffer overflow in
prepare_elf_headers()
crash: Add crash_prepare_headers() to exclude crash kernel memory
arm64: kexec_file: Use crash_prepare_headers() helper to simplify code
x86/kexec: Use crash_prepare_headers() helper to simplify code
riscv: kexec_file: Use crash_prepare_headers() helper to simplify code
LoongArch: kexec: Use crash_prepare_headers() helper to simplify code
crash: Use crash_exclude_core_ranges() on powerpc
arm64: kexec: Add support for crashkernel CMA reservation
riscv: kexec: Add support for crashkernel CMA reservation
Sourabh Jain (1):
powerpc/crash: sort crash memory ranges before preparing elfcorehdr
.../admin-guide/kernel-parameters.txt | 16 +--
arch/arm64/kernel/machine_kexec_file.c | 43 +++-----
arch/arm64/mm/init.c | 5 +-
arch/loongarch/kernel/machine_kexec_file.c | 43 +++-----
arch/powerpc/include/asm/kexec_ranges.h | 1 -
arch/powerpc/kexec/crash.c | 7 +-
arch/powerpc/kexec/ranges.c | 101 +-----------------
arch/riscv/kernel/machine_kexec_file.c | 42 +++-----
arch/riscv/mm/init.c | 5 +-
arch/x86/kernel/crash.c | 92 +++-------------
drivers/of/fdt.c | 9 +-
drivers/of/kexec.c | 9 ++
include/linux/crash_core.h | 9 ++
include/linux/crash_reserve.h | 4 +-
kernel/crash_core.c | 89 ++++++++++++++-
15 files changed, 193 insertions(+), 282 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v12 01/15] riscv: kexec_file: Fix crashk_low_res not exclude bug
From: Jinjie Ruan @ 2026-04-02 7:26 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260402072701.628293-1-ruanjinjie@huawei.com>
As done in commit 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X")
and commit 4831be702b95 ("arm64/kexec: Fix missing extra range for
crashkres_low.") for arm64, while implementing crashkernel=X,[high,low],
riscv should have excluded the "crashk_low_res" reserved ranges from
the crash kernel memory to prevent them from being exported through
/proc/vmcore, and the exclusion would need an extra crash_mem range.
Just simply tested on qemu with crashkernel=4G with kexec in [1] mentioned
in [2]. And the second kernel can be started normally.
# dmesg | grep crash
[ 0.000000] crashkernel low memory reserved: 0xf8000000 - 0x100000000 (128 MB)
[ 0.000000] crashkernel reserved: 0x000000017fe00000 - 0x000000027fe00000 (4096 MB)
Cc: Guo Ren <guoren@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
[1]: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2
[2]: https://lore.kernel.org/all/20230726175000.2536220-1-chenjiahao16@huawei.com/
Fixes: 5882e5acf18d ("riscv: kdump: Implement crashkernel=X,[high,low]")
Reviewed-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/riscv/kernel/machine_kexec_file.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/kernel/machine_kexec_file.c b/arch/riscv/kernel/machine_kexec_file.c
index 54e2d9552e93..3f7766057cac 100644
--- a/arch/riscv/kernel/machine_kexec_file.c
+++ b/arch/riscv/kernel/machine_kexec_file.c
@@ -61,7 +61,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
unsigned int nr_ranges;
int ret;
- nr_ranges = 1; /* For exclusion of crashkernel region */
+ nr_ranges = 2; /* For exclusion of crashkernel region */
walk_system_ram_res(0, -1, &nr_ranges, get_nr_ram_ranges_callback);
cmem = kmalloc_flex(*cmem, ranges, nr_ranges);
@@ -76,8 +76,16 @@ static int prepare_elf_headers(void **addr, unsigned long *sz)
/* Exclude crashkernel region */
ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
- if (!ret)
- ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
+ if (ret)
+ goto out;
+
+ if (crashk_low_res.end) {
+ ret = crash_exclude_mem_range(cmem, crashk_low_res.start, crashk_low_res.end);
+ if (ret)
+ goto out;
+ }
+
+ ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
out:
kfree(cmem);
--
2.34.1
^ permalink raw reply related
* [PATCH v12 02/15] powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr()
From: Jinjie Ruan @ 2026-04-02 7:26 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260402072701.628293-1-ruanjinjie@huawei.com>
In get_crash_memory_ranges(), if crash_exclude_mem_range() failed
after realloc_mem_ranges() has successfully allocated the cmem
memory, it just returns an error but leaves cmem pointing to
the allocated memory, nor is it freed in the caller
update_crash_elfcorehdr(), which cause a memory leak, goto out
to free the cmem.
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: Hari Bathini <hbathini@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Fixes: 849599b702ef ("powerpc/crash: add crash memory hotplug support")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/powerpc/kexec/crash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kexec/crash.c b/arch/powerpc/kexec/crash.c
index a325c1c02f96..1d12cef8e1e0 100644
--- a/arch/powerpc/kexec/crash.c
+++ b/arch/powerpc/kexec/crash.c
@@ -440,7 +440,7 @@ static void update_crash_elfcorehdr(struct kimage *image, struct memory_notify *
ret = get_crash_memory_ranges(&cmem);
if (ret) {
pr_err("Failed to get crash mem range\n");
- return;
+ goto out;
}
/*
--
2.34.1
^ permalink raw reply related
* [PATCH v12 03/15] x86/kexec: Fix potential buffer overflow in prepare_elf_headers()
From: Jinjie Ruan @ 2026-04-02 7:26 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, peterz, pawan.kumar.gupta, feng.tang, dapeng1.mi, kees,
elver, paulmck, lirongqing, rppt, leitao, ardb, jbohac, cfsworks,
tangyouling, sourabhjain, ritesh.list, hbathini, eajames, guoren,
songshuaishuai, kevin.brodsky, vishal.moola, junhui.liu, coxu,
fuqiang.wang, liaoyuanhong, takahiro.akashi, james.morse,
lizhengyu3, x86, linux-doc, linux-kernel, linux-arm-kernel,
loongarch, linuxppc-dev, linux-riscv, devicetree, kexec
Cc: ruanjinjie
In-Reply-To: <20260402072701.628293-1-ruanjinjie@huawei.com>
There is a race condition between the kexec_load() system call
(crash kernel loading path) and memory hotplug operations that can lead
to buffer overflow and potential kernel crash.
During prepare_elf_headers(), the following steps occur:
1. get_nr_ram_ranges_callback() queries current System RAM memory ranges
2. Allocates buffer based on queried count
3. prepare_elf64_ram_headers_callback() populates ranges from memblock
If memory hotplug occurs between step 1 and step 3, the number of ranges
can increase, causing out-of-bounds write when populating cmem->ranges[].
This happens because kexec_load() uses kexec_trylock (atomic_t) while
memory hotplug uses device_hotplug_lock (mutex), so they don't serialize
with each other.
Just add bounds checking in prepare_elf64_ram_headers_callback() to
prevent out-of-bounds (OOB) access,
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Baoquan He <bhe@redhat.com>
Fixes: 8d5f894a3108 ("x86: kexec_file: lift CRASH_MAX_RANGES limit on crash_mem buffer")
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
arch/x86/kernel/crash.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 335fd2ee9766..7fa6d45ebe3f 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -225,6 +225,9 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
{
struct crash_mem *cmem = arg;
+ if (cmem->nr_ranges >= cmem->max_nr_ranges)
+ return -ENOMEM;
+
cmem->ranges[cmem->nr_ranges].start = res->start;
cmem->ranges[cmem->nr_ranges].end = res->end;
cmem->nr_ranges++;
--
2.34.1
^ 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