* [PATCH v2 0/8] qcom: display / dts: Few corrections of address spaces.
From: Krzysztof Kozlowski @ 2026-04-05 14:33 UTC (permalink / raw)
To: Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kuogee Hsieh, Neil Armstrong,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
Krzysztof Kozlowski, Dmitry Baryshkov, Krzysztof Kozlowski
Changes in v2:
- Patch #2: Add dai-common.yaml reference (Dmitry)
- Correct subject
- Rb tags
- Re-order Eliza bindings patch
- Link to v1: https://patch.msgid.link/20260402-dts-qcom-display-regs-v1-0-daa54ab448a3@oss.qualcomm.com
These do not have practical impact currently, but make hardware
description correct.
Patchset can go via separate trees, but DTS should wait for bindings to
avoid new dtbs_check warnings.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (8):
dt-bindings: display/msm: dp-controller: Correct SM8650 IO range
dt-bindings: display/msm: dp-controller: Allow DAI on SM8650 and others
dt-bindings: display/msm: sm8650: Correct VBIF range in example
dt-bindings: display/msm: sm8750-mdss: Correct DPU and DP ranges in example
dt-bindings: display/msm: qcom,eliza-mdss: Correct DPU and DP ranges in example
arm64: dts: qcom: sm8650: Correct and complete DP address spaces
arm64: dts: qcom: sm8750: Correct and complete DP address spaces
arm64: dts: qcom: sm8750: Correct DPU VBIF address space size
.../bindings/display/msm/dp-controller.yaml | 20 +++++++++++++++++++-
.../bindings/display/msm/qcom,eliza-mdss.yaml | 20 ++++++++++++--------
.../bindings/display/msm/qcom,sm8650-dpu.yaml | 2 +-
.../bindings/display/msm/qcom,sm8650-mdss.yaml | 2 +-
.../bindings/display/msm/qcom,sm8750-mdss.yaml | 16 ++++++++++------
arch/arm64/boot/dts/qcom/sm8650.dtsi | 14 +++++++++-----
arch/arm64/boot/dts/qcom/sm8750.dtsi | 16 ++++++++++------
7 files changed, 62 insertions(+), 28 deletions(-)
---
base-commit: 36ece9697e89016181e5ae87510e40fb31d86f2b
change-id: 20260402-dts-qcom-display-regs-11d61816e172
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 5/5] arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg warning
From: Krzysztof Kozlowski @ 2026-04-05 13:39 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Abel Vesa, Wesley Cheng,
Maulik Shah, Qiang Yu, Taniya Das, Pankaj Patil,
Jyothi Kumar Seerapu, Dmitry Baryshkov, Varadarajan Narayanan,
Bryan O'Donoghue
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Raviteja Laggyshetty, Kamal Wadhwa, Jishnu Prakash,
David Heidelberg, Krzysztof Kozlowski
In-Reply-To: <20260405-dts-qcom-w-1-fixes-v2-0-1f2c7b74a93f@oss.qualcomm.com>
Add necessary properties for ports node in SDM845 DB845c Navigation
mezzanine overlay to fix W=1 DTC warning:
sdm845-db845c-navigation-mezzanine.dtso:19.10-24.5: Warning (unit_address_vs_reg): /fragment@0/__overlay__/ports/port@0: node has a unit name, but no reg or ranges property
Fixes: 30df676a31b7 ("arm64: dts: qcom: sdm845-db845c-navigation-mezzanine: Convert mezzanine riser to dtso")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sdm845-db845c-navigation-mezzanine.dtso | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c-navigation-mezzanine.dtso b/arch/arm64/boot/dts/qcom/sdm845-db845c-navigation-mezzanine.dtso
index dbe1911d8e47..678a17c805f7 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-db845c-navigation-mezzanine.dtso
+++ b/arch/arm64/boot/dts/qcom/sdm845-db845c-navigation-mezzanine.dtso
@@ -16,7 +16,12 @@ &camss {
status = "okay";
ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
port@0 {
+ reg = <0>;
+
csiphy0_ep: endpoint {
data-lanes = <0 1 2 3>;
remote-endpoint = <&ov8856_ep>;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 4/5] arm64: dts: qcom: sc8180x: Fix phy simple_bus_reg warning
From: Krzysztof Kozlowski @ 2026-04-05 13:39 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Abel Vesa, Wesley Cheng,
Maulik Shah, Qiang Yu, Taniya Das, Pankaj Patil,
Jyothi Kumar Seerapu, Dmitry Baryshkov, Varadarajan Narayanan,
Bryan O'Donoghue
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Raviteja Laggyshetty, Kamal Wadhwa, Jishnu Prakash,
Krzysztof Kozlowski
In-Reply-To: <20260405-dts-qcom-w-1-fixes-v2-0-1f2c7b74a93f@oss.qualcomm.com>
Correct the unit address of phy node in Qualcomm SC8180x SoC DTSI to fix
W=1 DTC warning:
sc8180x.dtsi:2650.31-2695.5: Warning (simple_bus_reg): /soc@0/phy@88ee000: simple-bus unit address format error, expected "88ed000"
Fixes: 35e3a9c1afce ("arm64: dts: qcom: sc8180x: switch USB+DP QMP PHYs to new bindings")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sc8180x.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8180x.dtsi b/arch/arm64/boot/dts/qcom/sc8180x.dtsi
index f45deb188c6c..e87e82fa73e9 100644
--- a/arch/arm64/boot/dts/qcom/sc8180x.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8180x.dtsi
@@ -2647,7 +2647,7 @@ usb_mp_qmpphy1: phy@88ec000 {
status = "disabled";
};
- usb_sec_qmpphy: phy@88ee000 {
+ usb_sec_qmpphy: phy@88ed000 {
compatible = "qcom,sc8180x-qmp-usb3-dp-phy";
reg = <0 0x088ed000 0 0x3000>;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 3/5] arm64: dts: qcom: ipq5424: Fix USB simple_bus_reg warnings
From: Krzysztof Kozlowski @ 2026-04-05 13:39 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Abel Vesa, Wesley Cheng,
Maulik Shah, Qiang Yu, Taniya Das, Pankaj Patil,
Jyothi Kumar Seerapu, Dmitry Baryshkov, Varadarajan Narayanan,
Bryan O'Donoghue
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Raviteja Laggyshetty, Kamal Wadhwa, Jishnu Prakash,
Krzysztof Kozlowski
In-Reply-To: <20260405-dts-qcom-w-1-fixes-v2-0-1f2c7b74a93f@oss.qualcomm.com>
Correct the unit address of USB nodes in Qualcomm IPQ5424 SoC DTSI to
fix W=1 DTC warnings:
ipq5424.dtsi:642.22-693.5: Warning (simple_bus_reg): /soc@0/usb2@1e00000: simple-bus unit address format error, expected "1ef8800"
ipq5424.dtsi:733.22-786.5: Warning (simple_bus_reg): /soc@0/usb3@8a00000: simple-bus unit address format error, expected "8af8800"
Fixes: 113d52bdc820 ("arm64: dts: qcom: ipq5424: Add USB controller and phy nodes")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/ipq5424.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/ipq5424.dtsi b/arch/arm64/boot/dts/qcom/ipq5424.dtsi
index f20cda429094..876bf6a8b8ff 100644
--- a/arch/arm64/boot/dts/qcom/ipq5424.dtsi
+++ b/arch/arm64/boot/dts/qcom/ipq5424.dtsi
@@ -639,7 +639,7 @@ qusb_phy_1: phy@71000 {
status = "disabled";
};
- usb2: usb2@1e00000 {
+ usb2: usb2@1ef8800 {
compatible = "qcom,ipq5424-dwc3", "qcom,dwc3";
reg = <0 0x01ef8800 0 0x400>;
#address-cells = <2>;
@@ -730,7 +730,7 @@ ssphy_0: phy@7d000 {
status = "disabled";
};
- usb3: usb3@8a00000 {
+ usb3: usb3@8af8800 {
compatible = "qcom,ipq5424-dwc3", "qcom,dwc3";
reg = <0 0x08af8800 0 0x400>;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/5] arm64: dts: qcom: glymur: Fix cache and SRAM simple_bus_reg warnings
From: Krzysztof Kozlowski @ 2026-04-05 13:39 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Abel Vesa, Wesley Cheng,
Maulik Shah, Qiang Yu, Taniya Das, Pankaj Patil,
Jyothi Kumar Seerapu, Dmitry Baryshkov, Varadarajan Narayanan,
Bryan O'Donoghue
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Raviteja Laggyshetty, Kamal Wadhwa, Jishnu Prakash,
Krzysztof Kozlowski
In-Reply-To: <20260405-dts-qcom-w-1-fixes-v2-0-1f2c7b74a93f@oss.qualcomm.com>
Correct the unit address of cache controller and SRAM nodes in Qualcomm
Glymur SoC DTSI to fix W=1 DTC warnings:
glymur.dtsi:5876.36-5908.5: Warning (simple_bus_reg): /soc@0/system-cache-controller@20400000: simple-bus unit address format error, expected "21800000"
glymur.dtsi:5917.23-5934.5: Warning (simple_bus_reg): /soc@0/sram@81e08000: simple-bus unit address format error, expected "81e08600"
Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 3389103408b6..0c5cb8532b20 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -5873,7 +5873,7 @@ oobm_ss_noc: interconnect@1f300000 {
#interconnect-cells = <2>;
};
- system-cache-controller@20400000 {
+ system-cache-controller@21800000 {
compatible = "qcom,glymur-llcc";
reg = <0x0 0x21800000 0x0 0x100000>,
<0x0 0x21a00000 0x0 0x100000>,
@@ -5914,7 +5914,7 @@ nsp_noc: interconnect@320c0000 {
#interconnect-cells = <2>;
};
- imem: sram@81e08000 {
+ imem: sram@81e08600 {
compatible = "mmio-sram";
reg = <0x0 0x81e08600 0x0 0x300>;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 1/5] arm64: dts: qcom: glymur: Fix USB simple_bus_reg warning
From: Krzysztof Kozlowski @ 2026-04-05 13:39 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Abel Vesa, Wesley Cheng,
Maulik Shah, Qiang Yu, Taniya Das, Pankaj Patil,
Jyothi Kumar Seerapu, Dmitry Baryshkov, Varadarajan Narayanan,
Bryan O'Donoghue
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Raviteja Laggyshetty, Kamal Wadhwa, Jishnu Prakash,
Krzysztof Kozlowski
In-Reply-To: <20260405-dts-qcom-w-1-fixes-v2-0-1f2c7b74a93f@oss.qualcomm.com>
Correct the unit address of USB node in Qualcomm Glymur SoC DTSI to fix
W=1 DTC warning:
glymur.dtsi:4027.23-4093.5: Warning (simple_bus_reg): /soc@0/usb@a2f8800: simple-bus unit address format error, expected "a200000"
Fixes: 4eee57dd4df9 ("arm64: dts: qcom: glymur: Add USB related nodes")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index f23cf81ddb77..3389103408b6 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -4024,7 +4024,7 @@ usb_2_dwc3_ss: endpoint {
};
};
- usb_hs: usb@a2f8800 {
+ usb_hs: usb@a200000 {
compatible = "qcom,glymur-dwc3", "qcom,snps-dwc3";
reg = <0x0 0x0a200000 0x0 0xfc100>;
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/5] arm64: dts: qcom: Few dtc W=1 warning fixes
From: Krzysztof Kozlowski @ 2026-04-05 13:39 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Abel Vesa, Wesley Cheng,
Maulik Shah, Qiang Yu, Taniya Das, Pankaj Patil,
Jyothi Kumar Seerapu, Dmitry Baryshkov, Varadarajan Narayanan,
Bryan O'Donoghue
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Raviteja Laggyshetty, Kamal Wadhwa, Jishnu Prakash,
Krzysztof Kozlowski, David Heidelberg
Changes in v2:
- Fix patch #3 subject prefix
- Tags
- Link to v1: https://patch.msgid.link/20260404-dts-qcom-w-1-fixes-v1-0-b8a9e6806e0a@oss.qualcomm.com
Not marking stable as these do not have actual impact on user, but still
warnings are not desired.
Best regards,
Krzysztof
---
Krzysztof Kozlowski (5):
arm64: dts: qcom: glymur: Fix USB simple_bus_reg warning
arm64: dts: qcom: glymur: Fix cache and SRAM simple_bus_reg warnings
arm64: dts: qcom: ipq5424: Fix USB simple_bus_reg warnings
arm64: dts: qcom: sc8180x: Fix phy simple_bus_reg warning
arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg warning
arch/arm64/boot/dts/qcom/glymur.dtsi | 6 +++---
arch/arm64/boot/dts/qcom/ipq5424.dtsi | 4 ++--
arch/arm64/boot/dts/qcom/sc8180x.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm845-db845c-navigation-mezzanine.dtso | 5 +++++
4 files changed, 11 insertions(+), 6 deletions(-)
---
base-commit: d0d19917748b2611266a311841231bf635e6d80d
change-id: 20260404-dts-qcom-w-1-fixes-1a25bbd0519a
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 0/5] arm64: dts: qcom: Few dtc W=1 warning fixes
From: Krzysztof Kozlowski @ 2026-04-05 13:28 UTC (permalink / raw)
To: Krishna Kurapati, Krzysztof Kozlowski
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Raviteja Laggyshetty, Kamal Wadhwa, Jishnu Prakash,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Abel Vesa, Wesley Cheng,
Maulik Shah, Qiang Yu, Taniya Das, Pankaj Patil,
Jyothi Kumar Seerapu, Dmitry Baryshkov, Varadarajan Narayanan,
Bryan O'Donoghue
In-Reply-To: <23755291-8b53-4926-899e-8d3d1d8ea91d@oss.qualcomm.com>
On 05/04/2026 12:24, Krishna Kurapati wrote:
>
>
> On 4/4/2026 3:20 PM, Krzysztof Kozlowski wrote:
>> Not marking stable as these do not have actual impact on user, but still
>> warnings are not desired.
>>
>> Best regards,
>> Krzysztof
>>
>> ---
>> Krzysztof Kozlowski (5):
>> arm64: dts: qcom: glymur: Fix USB simple_bus_reg warning
>> arm64: dts: qcom: glymur: Fix cache and SRAM simple_bus_reg warnings
>> arm64: dts: qcom: glymur: Fix USB simple_bus_reg warnings
>
> This third one must be "arm64: dts: qcom: ipq5424". I think its
> mistakenly written as glymur.
>
Indeed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 0/9] driver core: Fix some race conditions
From: Danilo Krummrich @ 2026-04-05 12:02 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Douglas Anderson, Rafael J . Wysocki, Alan Stern, Saravana Kannan,
Christoph Hellwig, Eric Dumazet, Johan Hovold, Leon Romanovsky,
Alexander Lobakin, Alexey Kardashevskiy, Robin Murphy,
Andrew Morton, Frank.Li, Jason Gunthorpe, alex, alexander.stein,
andre.przywara, andrew, andrew, andriy.shevchenko, aou, ardb,
bhelgaas, brgl, broonie, catalin.marinas, chleroy, davem, david,
devicetree, dmaengine, driver-core, gbatra, gregory.clement,
hkallweit1, iommu, jirislaby, joel, joro, kees, kevin.brodsky,
kuba, lenb, lgirdwood, linux-acpi, linux-arm-kernel, linux-aspeed,
linux-cxl, linux-kernel, linux-mips, linux-mm, linux-pci,
linux-riscv, linux-serial, linux-snps-arc, linux-usb, linux,
linuxppc-dev, m.szyprowski, maddy, mani, maz, miko.lenczewski,
mpe, netdev, npiggin, osalvador, oupton, pabeni, palmer,
peter.ujfalusi, peterz, pjw, robh, sebastian.hesselbarth, tglx,
tsbogend, vgupta, vkoul, will, willy, yangyicong, yeoreum.yun
In-Reply-To: <2026040539-sponge-publisher-2b42@gregkh>
On Sun Apr 5, 2026 at 7:27 AM CEST, Greg Kroah-Hartman wrote:
> Anyway, this looks great, unless there are any objections, other than
> the "needs to be undefined", which a follow-on patch can handle, I'll
> queue them up next week for 7.1-rc1.
Sounds good, for the series:
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* [PATCH v2 0/2] arm64: dts: qcom: beryllium compatible ordering and bindings update
From: David Heidelberg via B4 Relay @ 2026-04-05 10:54 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Marijn Suijten, Casey Connolly, Joel Selvaraj,
Jens Reidel, Arnaud Ferraris, Marco Mattiolo, Petr Hodina
Cc: Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel,
phone-devel, David Heidelberg
This series aligns the Xiaomi Poco F1 (beryllium) device tree
compatible strings with DT matching rules by ensuring proper
fallback to the generic device compatible.
Patch 1 updates the dt-bindings documentation to describe
the Tianma panel variant and clarify the expected compatible
string ordering and fallback requirements, aligning the
binding with actual DTS usage.
Patch 2 updates the DTS files to append the generic
"xiaomi,beryllium" compatible after the panel-specific ones.
This enables correct userspace fallback matching (e.g. for
hexagonrpcd), which currently fails when only the variant-
specific compatible is present. This constitutes a DT ABI
change, as additional compatible matches become possible.
Together, these changes fix an incomplete compatible chain
and ensure consistent behavior across panel variants.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Changes in v2:
- To be extra safe, CCed Arnauld and Marco (Mobian), Jens (for pmOS) is
already in the loop, Petr (for NixOS Mobile is already in the loop).
- Improved description and documented that main distributions
already use the patch (thus no API break will not happen to these
projects).
- Link to v1: https://lore.kernel.org/r/20260403-beryllium-compat-string-v1-0-0a6b9cb55a20@ixit.cz
---
David Heidelberg (1):
dt-bindings: arm: qcom: Document Xiaomi Poco F1 Tianma variant
Jens Reidel (1):
arm64: dts: qcom: sdm845-xiaomi-beryllium: Append compatible strings
Documentation/devicetree/bindings/arm/qcom.yaml | 10 ++++++++--
arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts | 2 +-
arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-tianma.dts | 2 +-
3 files changed, 10 insertions(+), 4 deletions(-)
---
base-commit: cc13002a9f984d37906e9476f3e532a8cdd126f5
change-id: 20260403-beryllium-compat-string-cc149b90a29d
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: arm: qcom: Document Xiaomi Poco F1 Tianma variant
From: David Heidelberg via B4 Relay @ 2026-04-05 10:54 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Marijn Suijten, Casey Connolly, Joel Selvaraj,
Jens Reidel, Arnaud Ferraris, Marco Mattiolo, Petr Hodina
Cc: Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel,
phone-devel, David Heidelberg
In-Reply-To: <20260405-beryllium-compat-string-v2-0-91149be07835@ixit.cz>
From: David Heidelberg <david@ixit.cz>
Document the panel-specific compatible string for the Tianma variant
of the Xiaomi Poco F1:
- "xiaomi,beryllium-tianma"
and require the generic fallback compatible:
- "xiaomi,beryllium"
Update the binding to clarify that all panel variants must list the
variant-specific compatible first, followed by the generic device
compatible, in accordance with DT matching rules.
The previous binding documentation did not describe the Tianma variant
and did not clearly specify the required fallback compatible, which
resulted in inconsistent DTS implementations.
No functional differences are currently exposed between Tianma and EBBG
variants at the binding level; both rely on the same generic device
compatibility for software support.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 8c5fdd320cfcf..b412543f0afb8 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -822,6 +822,14 @@ properties:
- const: google,zombie-sku514
- const: qcom,sc7280
+ - description: Xiaomi Poco F1
+ items:
+ - enum:
+ - xiaomi,beryllium-ebbg
+ - xiaomi,beryllium-tianma
+ - const: xiaomi,beryllium
+ - const: qcom,sdm845
+
- items:
- enum:
- lenovo,flex-5g
@@ -971,8 +979,6 @@ properties:
- sony,akatsuki-row
- sony,apollo-row
- thundercomm,db845c
- - xiaomi,beryllium
- - xiaomi,beryllium-ebbg
- xiaomi,polaris
- const: qcom,sdm845
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: qcom: sdm845-xiaomi-beryllium: Append compatible strings
From: David Heidelberg via B4 Relay @ 2026-04-05 10:54 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Marijn Suijten, Casey Connolly, Joel Selvaraj,
Jens Reidel, Arnaud Ferraris, Marco Mattiolo, Petr Hodina
Cc: Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel,
phone-devel, David Heidelberg
In-Reply-To: <20260405-beryllium-compat-string-v2-0-91149be07835@ixit.cz>
From: Jens Reidel <adrian@travitia.xyz>
Add the generic "xiaomi,beryllium" compatible string after the
panel-specific one, so the compatible list follows the required
ordering from most specific to most generic.
This allows userspace to fall back to the generic Poco F1 compatible
when no panel-specific match is present. In particular, hexagonrpcd
relies on trying all compatible entries to derive the HexagonFS path,
and currently fails when the generic device string is missing.
This change modifies the DT ABI: systems describing the EBBG variant
will now also match on "xiaomi,beryllium", whereas previously only
the panel-specific compatible was exposed.
In practice, no upstream userspace distinguishes between Tianma and
EBBG panel variants. All known consumers rely only on the generic
device identification, and no panel-specific handling exists.
Therefore, enabling the generic fallback does not change effective
runtime behavior, but fixes userspace that depends on generic matching.
The previous state was incomplete, as it omitted the generic
device-compatible string required for proper fallback matching.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts | 2 +-
arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-tianma.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts
index 2d6f0e382a6cb..d157622f84d13 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts
@@ -6,7 +6,7 @@
/ {
model = "Xiaomi Pocophone F1 (EBBG)";
- compatible = "xiaomi,beryllium-ebbg", "qcom,sdm845";
+ compatible = "xiaomi,beryllium-ebbg", "xiaomi,beryllium", "qcom,sdm845";
};
&display_panel {
diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-tianma.dts b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-tianma.dts
index b58964cde8342..71816a9f33b48 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-tianma.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-tianma.dts
@@ -6,7 +6,7 @@
/ {
model = "Xiaomi Pocophone F1 (Tianma)";
- compatible = "xiaomi,beryllium", "qcom,sdm845";
+ compatible = "xiaomi,beryllium-tianma", "xiaomi,beryllium", "qcom,sdm845";
};
&display_panel {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/5] arm64: dts: qcom: Few dtc W=1 warning fixes
From: Krishna Kurapati @ 2026-04-05 10:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Konrad Dybcio, linux-arm-msm, devicetree, linux-kernel,
Raviteja Laggyshetty, Kamal Wadhwa, Jishnu Prakash,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Dmitry Baryshkov, Abel Vesa, Wesley Cheng,
Maulik Shah, Qiang Yu, Taniya Das, Pankaj Patil,
Jyothi Kumar Seerapu, Dmitry Baryshkov, Varadarajan Narayanan,
Bryan O'Donoghue
In-Reply-To: <20260404-dts-qcom-w-1-fixes-v1-0-b8a9e6806e0a@oss.qualcomm.com>
On 4/4/2026 3:20 PM, Krzysztof Kozlowski wrote:
> Not marking stable as these do not have actual impact on user, but still
> warnings are not desired.
>
> Best regards,
> Krzysztof
>
> ---
> Krzysztof Kozlowski (5):
> arm64: dts: qcom: glymur: Fix USB simple_bus_reg warning
> arm64: dts: qcom: glymur: Fix cache and SRAM simple_bus_reg warnings
> arm64: dts: qcom: glymur: Fix USB simple_bus_reg warnings
This third one must be "arm64: dts: qcom: ipq5424". I think its
mistakenly written as glymur.
Regards,
Krishna,
> arm64: dts: qcom: sc8180x: Fix phy simple_bus_reg warning
> arm64: dts: qcom: sdm845-mezzanine: Fix camss ports unit_address_vs_reg warning
>
> arch/arm64/boot/dts/qcom/glymur.dtsi | 6 +++---
> arch/arm64/boot/dts/qcom/ipq5424.dtsi | 4 ++--
> arch/arm64/boot/dts/qcom/sc8180x.dtsi | 2 +-
> arch/arm64/boot/dts/qcom/sdm845-db845c-navigation-mezzanine.dtso | 5 +++++
> 4 files changed, 11 insertions(+), 6 deletions(-)
> ---
> base-commit: 36ece9697e89016181e5ae87510e40fb31d86f2b
> change-id: 20260404-dts-qcom-w-1-fixes-1a25bbd0519a
>
> Best regards,
> --
> Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: qcom: Add Xiaomi Poco F1 Tianma variant bindings
From: David Heidelberg @ 2026-04-05 9:19 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Marijn Suijten, Casey Connolly, Joel Selvaraj,
Jens Reidel, Petr Hodina, linux-arm-msm, devicetree, linux-kernel,
phone-devel
In-Reply-To: <8ef78376-87f5-4ad4-8453-c59d6aa1dcb5@kernel.org>
On 05/04/2026 10:55, Krzysztof Kozlowski wrote:
> On 05/04/2026 10:01, David Heidelberg wrote:
>> On 05/04/2026 09:55, Krzysztof Kozlowski wrote:
>>> On Fri, Apr 03, 2026 at 06:55:33PM +0200, David Heidelberg wrote:
>>>> Add documentation for Tianma display and touchscreen variant.
>>>>
>>>> While at it, correct binding documentation expectation.
>>>
>>> What expectation? What exactly did you corrected that you claim this is
>>> a fix?
>>
>> I would say the missing Tianma variant, which been with us for some time. The
>
> Expectation of missing Tianma? We don't have such expectations...
Ok.
>
>> follow up commit fixes the missing compatible and order, thus it would make
>> sense to me have also the dt-bindings part backported and fixed.
>
> You probably should read original discussion why this ended up like that.
All I found is
The compatibility property is
moved to the tianma variant, but it is not updated to avoid any
further conflict with other projects/users that might depend on it.
>
>>
>> I agree I don't have strong case here. Should I drop the tag, keep it or replace
>> it with Cc: stable@vger.kernel.org?
>
> If you cannot explain what you are fixing, then this is not a fix.
Sure, I'll drop the tag.
>
> Best regards,
> Krzysztof
--
David Heidelberg
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: spi: renesas,rzv2h-rspi: Document RZ/G3L SoC
From: Krzysztof Kozlowski @ 2026-04-05 8:58 UTC (permalink / raw)
To: Biju Das, biju.das.au, Fabrizio Castro, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
magnus.damm
Cc: linux-spi@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Prabhakar Mahadev Lad
In-Reply-To: <TY3PR01MB113461341DE0677746358F5BD8651A@TY3PR01MB11346.jpnprd01.prod.outlook.com>
On 02/04/2026 16:10, Biju Das wrote:
>>>>
>>>> So even after my objections here:
>>>> https://lore.kernel.org/all/9d08ddda-403e-458d-95e4-4e76915df85d@kern
>>>> el.org/
>>>>
>>>> this was not fixed and Renesas did not provide actual cross-patch review.
>>>
>>> That patch is not correct. See below.
>>>
>>>>
>>>> This is still probably wrong as pointed out by other patches by Renesas.
>>>> Also, you cannot have flexible names.
>>>
>>> You can have "rx", "tx" in any order and {rx, tx} should be unique dma
>>> specifier
>>
>> No. You cannot. I just told you so. Please read writing-bindings for arguments.
>
> <snippet from writing-bindings >
> - DO define properties in terms of constraints. How many entries? What are
> possible values? What is the order? All these constraints represent the ABI
> as well.
> </snippet>
>
> Is that the reason you're saying we cannot have flexible names for DMAs?
Yes
>
> Are you expecting the RZ/G3L DMA entries to be like below? Please let me know.
>
> This is not flexible — the user always needs to specify RX first, followed by TX.
>
> + dmas:
> + maxItems: 2
> +
> + dma-names:
> + items:
> + - const: rx
> + - const: tx
Yes
>
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 3/4] iio: adc: ad4691: add triggered buffer support
From: Andy Shevchenko @ 2026-04-05 8:57 UTC (permalink / raw)
To: David Lechner
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan, linux-iio, devicetree,
linux-kernel, linux-pwm, linux-gpio, linux-doc
In-Reply-To: <e38e5b97-e90f-4613-a15e-6c3d08cd77f7@baylibre.com>
On Sat, Apr 04, 2026 at 10:12:04AM -0500, David Lechner wrote:
> On 4/3/26 6:03 AM, Radu Sabau via B4 Relay wrote:
> > Add buffered capture support using the IIO triggered buffer framework.
> >
> > CNV Burst Mode: the GP pin identified by interrupt-names in the device
> > tree is configured as DATA_READY output. The IRQ handler stops
> > conversions and fires the IIO trigger; the trigger handler executes a
> > pre-built SPI message that reads all active channels from the AVG_IN
> > accumulator registers and then resets accumulator state and restarts
> > conversions for the next cycle.
> >
> > Manual Mode: CNV is tied to SPI CS so each transfer simultaneously
> > reads the previous result and starts the next conversion (pipelined
> > N+1 scheme). At preenable time a pre-built, optimised SPI message of
> > N+1 transfers is constructed (N channel reads plus one NOOP to drain
> > the pipeline). The trigger handler executes the message in a single
> > spi_sync() call and collects the results. An external trigger (e.g.
> > iio-trig-hrtimer) is required to drive the trigger at the desired
> > sample rate.
> >
> > Both modes share the same trigger handler and push a complete scan —
> > one u16 slot per channel at its scan_index position, followed by a
> > timestamp — to the IIO buffer via iio_push_to_buffers_with_ts().
> >
> > The CNV Burst Mode sampling frequency (PWM period) is exposed as a
> > buffer-level attribute via IIO_DEVICE_ATTR.
Tried my best to avoid clashes with David's review.
...
> > #include <linux/array_size.h>
> > #include <linux/bitfield.h>
> > +#include <linux/bitmap.h>
> > #include <linux/bitops.h>
When bitmap.h is present, it implies bitops.h, hence the latter can be simply
replaced.
> > #include <linux/cleanup.h>
> > #include <linux/delay.h>
> > #include <linux/dev_printk.h>
> > #include <linux/device/devres.h>
> > #include <linux/err.h>
> > +#include <linux/interrupt.h>
> > #include <linux/math.h>
> > #include <linux/module.h>
> > #include <linux/mod_devicetable.h>
> > +#include <linux/property.h>
> > +#include <linux/pwm.h>
> > #include <linux/regmap.h>
> > #include <linux/regulator/consumer.h>
> > #include <linux/reset.h>
...
> > .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) \
> > - | BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> > + | BIT(IIO_CHAN_INFO_SAMP_FREQ) \
> > + | BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
> > .info_mask_separate_available = \
> > - BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> > + BIT(IIO_CHAN_INFO_SAMP_FREQ) \
> > + | BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
You may reduce churn by squeezing a new ones in between existing ones.
Also consider use usual patter of placing the operator on the same line where
left operand is (currently it goes with the right operand).
...
> > struct ad4691_state {
Just to double check, when add a new field or fields into the data structure
check with `pahole` that the new members placed at the best or at least good
enough locations.
> > const struct ad4691_chip_info *info;
> > struct regmap *regmap;
> > +
> > + struct pwm_device *conv_trigger;
> > + int irq;
> > +
> > + bool manual_mode;
> > +
> > int vref_uV;
> > + u8 osr[16];
> > bool refbuf_en;
> > bool ldo_en;
> > + u32 cnv_period_ns;
> > /*
> > * Synchronize access to members of the driver state, and ensure
> > * atomicity of consecutive SPI operations.
> > */
> > struct mutex lock;
> > + /*
> > + * Per-buffer-enable lifetime resources:
> > + * Manual Mode - a pre-built SPI message that clocks out N+1
> > + * transfers in one go.
> > + * CNV Burst Mode - a pre-built SPI message that clocks out 2*N
> > + * transfers in one go.
> > + */
> > + struct spi_message scan_msg;
> > + struct spi_transfer *scan_xfers;
> > + __be16 *scan_tx;
> > + __be16 *scan_rx;
>
> Why not embed these arrays here? Then we don't have to deal with
> alloc/free later.
>
> > + /* Scan buffer: one slot per channel plus timestamp */
> > + struct {
> > + u16 vals[16];
> > + aligned_s64 ts;
> > + } scan __aligned(IIO_DMA_MINALIGN);
>
> Better would be IIO_DECLARE_BUFFER_WITH_TS() since we don't always
> use all vals.
>
> Also, current usage doesn't need to be DMA-safe because scan_tx
> is being used for the actual SPI xfer.
>
> > };
...
> > +static int ad4691_gpio_setup(struct ad4691_state *st, unsigned int gp_num)
> > +{
> > + unsigned int shift = 4 * (gp_num % 2);
> > +
> > + return regmap_update_bits(st->regmap,
> > + AD4691_GPIO_MODE1_REG + gp_num / 2,
> > + AD4691_GP_MODE_MASK << shift,
> > + AD4691_GP_MODE_DATA_READY << shift);
Not sure if compiler will see % and / together, I would go with two more
temporary variables to make it clear to it:
... _bit_off = % 2;
... _reg_off = / 2;
The practical example is described, for example, here:
9b3cd5c7099f ("regmap: place foo / 8 and foo % 8 closer to each other").
> > +}
...
> > +static int ad4691_manual_buffer_preenable(struct iio_dev *indio_dev)
> > +{
> > + struct ad4691_state *st = iio_priv(indio_dev);
> > + struct device *dev = regmap_get_device(st->regmap);
> > + struct spi_device *spi = to_spi_device(dev);
> > + unsigned int n_active = bitmap_weight(indio_dev->active_scan_mask,
> > + iio_get_masklength(indio_dev));
In such cases please split definition and assignment. Will take two lines, but
readability will be better.
> > + unsigned int n_xfers = n_active + 1;
> > + unsigned int k, i;
> > + int ret;
> > +
> > + st->scan_xfers = kcalloc(n_xfers, sizeof(*st->scan_xfers), GFP_KERNEL);
>
> Usually, we make st->scan_xfers a fixed array with the max number of possible
> xfers. Then we don't have to deal with alloc/free.
And please if it's still be required to allocate and possible use kzalloc_objs().
> > + if (!st->scan_xfers)
> > + return -ENOMEM;
> > +
> > + st->scan_tx = kcalloc(n_xfers, sizeof(*st->scan_tx), GFP_KERNEL);
> > + if (!st->scan_tx) {
> > + kfree(st->scan_xfers);
> > + return -ENOMEM;
> > + }
> > +
> > + st->scan_rx = kcalloc(n_xfers, sizeof(*st->scan_rx), GFP_KERNEL);
> > + if (!st->scan_rx) {
> > + kfree(st->scan_tx);
> > + kfree(st->scan_xfers);
> > + return -ENOMEM;
> > + }
> > +
> > + spi_message_init(&st->scan_msg);
> > +
> > + k = 0;
> > + iio_for_each_active_channel(indio_dev, i) {
> > + st->scan_tx[k] = cpu_to_be16(AD4691_ADC_CHAN(i));
> > + st->scan_xfers[k].tx_buf = &st->scan_tx[k];
> > + st->scan_xfers[k].rx_buf = &st->scan_rx[k];
> > + st->scan_xfers[k].len = sizeof(__be16);
> > + st->scan_xfers[k].cs_change = 1;
> > + spi_message_add_tail(&st->scan_xfers[k], &st->scan_msg);
> > + k++;
> > + }
> > +
> > + /* Final NOOP transfer to retrieve last channel's result. */
> > + st->scan_tx[k] = cpu_to_be16(AD4691_NOOP);
> > + st->scan_xfers[k].tx_buf = &st->scan_tx[k];
> > + st->scan_xfers[k].rx_buf = &st->scan_rx[k];
> > + st->scan_xfers[k].len = sizeof(__be16);
> > + spi_message_add_tail(&st->scan_xfers[k], &st->scan_msg);
> > +
> > + st->scan_msg.spi = spi;
>
> This isn't how the SPI framework is intended to be used. We should
> have st->spi = spi in probe instead.
>
> > +
> > + ret = spi_optimize_message(spi, &st->scan_msg);
> > + if (ret) {
> > + ad4691_free_scan_bufs(st);
> > + return ret;
> > + }
> > +
> > + ret = ad4691_enter_conversion_mode(st);
> > + if (ret) {
> > + spi_unoptimize_message(&st->scan_msg);
> > + ad4691_free_scan_bufs(st);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
...
> > +static int ad4691_cnv_burst_buffer_preenable(struct iio_dev *indio_dev)
As per above.
...
> > +static ssize_t sampling_frequency_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> > + struct ad4691_state *st = iio_priv(indio_dev);
> > +
> > + return sysfs_emit(buf, "%u\n", (u32)(NSEC_PER_SEC / st->cnv_period_ns));
Why casting?
> > +}
...
> > +static IIO_DEVICE_ATTR(sampling_frequency, 0644,
> > + sampling_frequency_show,
> > + sampling_frequency_store, 0);
IIO_DEVICE_ATTR_RW().
...
> > +static int ad4691_read_scan(struct iio_dev *indio_dev, s64 timestamp)
> > +{
> > + struct ad4691_state *st = iio_priv(indio_dev);
> > + unsigned int i, k = 0;
> > + int ret;
> > +
> > + guard(mutex)(&st->lock);
> > +
> > + ret = spi_sync(st->scan_msg.spi, &st->scan_msg);
> > + if (ret)
> > + return ret;
> > +
> > + if (st->manual_mode) {
> > + iio_for_each_active_channel(indio_dev, i) {
> > + st->scan.vals[i] = be16_to_cpu(st->scan_rx[k + 1]);
> > + k++;
> > + }
> > + } else {
> > + iio_for_each_active_channel(indio_dev, i) {
> > + st->scan.vals[i] = be16_to_cpu(st->scan_rx[k]);
> > + k++;
> > + }
>
> I suppose this is fine, but we usually try to avoid extra copiying and
> byte swapping of bufferes like this if we can. It seems completly doable
> in both modes. Manual mode will just one extra two-byte buffer for the
> throw-away conversion on the first read xfer (or just write to the same
> element twice).
And in case it's still needed, we may introduce a helper in
include/linux/byteorder/generic.h calling it memcpy_to/from_be16().
> > + ret = regmap_write(st->regmap, AD4691_STATE_RESET_REG,
> > + AD4691_STATE_RESET_ALL);
> > + if (ret)
> > + return ret;
> > +
> > + ret = ad4691_sampling_enable(st, true);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + iio_push_to_buffers_with_ts(indio_dev, &st->scan, sizeof(st->scan),
> > + timestamp);
> > + return 0;
> > +}
...
> > +static int ad4691_setup_triggered_buffer(struct iio_dev *indio_dev,
> > + struct ad4691_state *st)
> > +{
> > + struct device *dev = regmap_get_device(st->regmap);
> > + struct iio_trigger *trig;
> > + unsigned int i;
> > + int irq, ret;
> > +
> > + trig = devm_iio_trigger_alloc(dev, "%s-dev%d",
> > + indio_dev->name,
> > + iio_device_id(indio_dev));
> > + if (!trig)
> > + return -ENOMEM;
> > +
> > + trig->ops = &ad4691_trigger_ops;
> > + iio_trigger_set_drvdata(trig, st);
> > +
> > + ret = devm_iio_trigger_register(dev, trig);
> > + if (ret)
> > + return dev_err_probe(dev, ret, "IIO trigger register failed\n");
> > +
> > + indio_dev->trig = iio_trigger_get(trig);
> > +
> > + if (!st->manual_mode) {
>
> I would invert the if since the other case is shorter.
+1.
> > + /*
> > + * The GP pin named in interrupt-names asserts at end-of-conversion.
> > + * The IRQ handler stops conversions and fires the IIO trigger so
> > + * the trigger handler can read and push the sample to the buffer.
> > + * The IRQ is kept disabled until the buffer is enabled.
> > + */
> > + irq = -ENODEV;
> > + for (i = 0; i < ARRAY_SIZE(ad4691_gp_names); i++) {
> > + irq = fwnode_irq_get_byname(dev_fwnode(dev),
> > + ad4691_gp_names[i]);
> > + if (irq > 0)
> > + break;
> > + }
> > + if (irq <= 0)
> > + return dev_err_probe(dev, irq < 0 ? irq : -ENODEV,
> > + "failed to get GP interrupt\n");
>
> Usually we would usually just use spi->irq since it already
> has been looked up. But I guess it is OK to do it like this.
No, it's not. (Linux) IRQ shouldn't ever be 0, so this check is effectively a
dead code.
irq = -ENXIO; // Note, this is the error code used by core for
// IRQ not found.
...
if (irq < 0)
return dev_err_probe(dev, irq, "failed to get GP interrupt\n");
> > + st->irq = irq;
> > +
> > + ret = ad4691_gpio_setup(st, i);
> > + if (ret)
> > + return ret;
> > +
> > + /*
> > + * IRQ is kept disabled until the buffer is enabled to prevent
> > + * spurious DATA_READY events before the SPI message is set up.
> > + */
> > + ret = devm_request_threaded_irq(dev, irq, NULL,
> > + &ad4691_irq,
> > + IRQF_ONESHOT | IRQF_NO_AUTOEN,
> > + indio_dev->name, indio_dev);
> > + if (ret)
> > + return ret;
> > +
> > + return devm_iio_triggered_buffer_setup_ext(dev, indio_dev,
> > + &iio_pollfunc_store_time,
> > + &ad4691_trigger_handler,
> > + IIO_BUFFER_DIRECTION_IN,
> > + &ad4691_cnv_burst_buffer_setup_ops,
> > + ad4691_buffer_attrs);
> > + }
> > +
> > + return devm_iio_triggered_buffer_setup(dev, indio_dev,
> > + &iio_pollfunc_store_time,
> > + &ad4691_trigger_handler,
> > + &ad4691_manual_buffer_setup_ops);
> > +}
> > +
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: qcom: Add Xiaomi Poco F1 Tianma variant bindings
From: Krzysztof Kozlowski @ 2026-04-05 8:55 UTC (permalink / raw)
To: David Heidelberg
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Marijn Suijten, Casey Connolly, Joel Selvaraj,
Jens Reidel, Petr Hodina, linux-arm-msm, devicetree, linux-kernel,
phone-devel
In-Reply-To: <205d43a0-70aa-4e49-af36-8bc2d5809110@ixit.cz>
On 05/04/2026 10:01, David Heidelberg wrote:
> On 05/04/2026 09:55, Krzysztof Kozlowski wrote:
>> On Fri, Apr 03, 2026 at 06:55:33PM +0200, David Heidelberg wrote:
>>> Add documentation for Tianma display and touchscreen variant.
>>>
>>> While at it, correct binding documentation expectation.
>>
>> What expectation? What exactly did you corrected that you claim this is
>> a fix?
>
> I would say the missing Tianma variant, which been with us for some time. The
Expectation of missing Tianma? We don't have such expectations...
> follow up commit fixes the missing compatible and order, thus it would make
> sense to me have also the dt-bindings part backported and fixed.
You probably should read original discussion why this ended up like that.
>
> I agree I don't have strong case here. Should I drop the tag, keep it or replace
> it with Cc: stable@vger.kernel.org?
If you cannot explain what you are fixing, then this is not a fix.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/5] arm64: dts: qcom: sm8550-hdk: update PCIe port label reference
From: Krzysztof Kozlowski @ 2026-04-05 8:11 UTC (permalink / raw)
To: Joe Sandom
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260404-rb5gen2-dts-v1-2-895f8fc494fc@axon.com>
On Sat, Apr 04, 2026 at 10:50:55AM +0100, Joe Sandom wrote:
> Update the pcieport0 reference to pcie0_port0 to match the label
> rename in sm8550.dtsi.
>
> Signed-off-by: Joe Sandom <jsandom@axon.com>
> ---
> arch/arm64/boot/dts/qcom/sm8550-hdk.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
> index ee13e6136a8259d28540e718851e094f74ead278..e821b731bdc496c872703723df02ae9b9b0233b5 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8550-hdk.dts
> @@ -1012,7 +1012,7 @@ &pcie0 {
> status = "okay";
> };
>
> -&pcieport0 {
> +&pcie0_port0 {
How does this even build?!?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/5] dt-bindings: arm: qcom: document QCS8550 RB5Gen2 board
From: Krzysztof Kozlowski @ 2026-04-05 8:11 UTC (permalink / raw)
To: Joe Sandom
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260404-rb5gen2-dts-v1-4-895f8fc494fc@axon.com>
On Sat, Apr 04, 2026 at 10:50:57AM +0100, Joe Sandom wrote:
> Document the Qualcomm RB5gen2 from Thundercomm based on the
> QCS8550 chipset from Qualcomm.
>
> [1] https://www.thundercomm.com/product/qualcomm-rb5-gen-2-development-kit/
>
> Signed-off-by: Joe Sandom <jsandom@axon.com>
> ---
> Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: ti,tas2552: Add sound-dai-cells
From: Krzysztof Kozlowski @ 2026-04-05 8:09 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Baojun Xu, Conor Dooley, Kevin Lu,
Krzysztof Kozlowski, Liam Girdwood, Mark Brown, Rob Herring,
Shenghao Ding, linux-kernel, linux-sound
In-Reply-To: <20260404033709.340026-1-marex@nabladev.com>
On Sat, Apr 04, 2026 at 05:36:56AM +0200, Marek Vasut wrote:
> For system integration the dt-bindings/sound/tas2552.h header file provides
> @@ -34,6 +34,9 @@ properties:
> maxItems: 1
> description: gpio pin to enable/disable the device
>
> + '#sound-dai-cells':
> + const: 0
> +
missing ref to dai-common and unevaluatedProperties.
> required:
> - compatible
> - reg
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: sdm845-xiaomi-beryllium: Fix compatible strings
From: David Heidelberg @ 2026-04-05 8:09 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Marijn Suijten, Casey Connolly, Joel Selvaraj,
Jens Reidel, Petr Hodina, linux-arm-msm, devicetree, linux-kernel,
phone-devel
In-Reply-To: <20260405-tidy-dancing-albatross-1b1cf4@quoll>
On 05/04/2026 10:02, Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 06:55:34PM +0200, David Heidelberg wrote:
>> From: Jens Reidel <adrian@travitia.xyz>
>>
>> The most specific strings should come first (panel variant included),
>> then the more generic ones (device and SoC).
>>
>> This is necessary for hexagonrpcd to guess the HexagonFS path for the
>> device. It tries all of the compatible entries, but if none for
>> xiaomi,beryllium existed it wouldn't be able to guess it.
>>
>> Fixes: bcf429831ecb ("arm64: dts: qcom: sdm845-xiaomi-beryllium-ebbg: introduce Xiaomi Poco F1 EBBG variant")
>> Fixes: dd6459a0890a ("arm64: dts: qcom: split beryllium dts into common dtsi and tianma dts")
>> Signed-off-by: Jens Reidel <adrian@travitia.xyz>
>> Signed-off-by: David Heidelberg <david@ixit.cz>
>> ---
>> arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts | 2 +-
>> arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-tianma.dts | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts
>> index 2d6f0e382a6cb..d157622f84d13 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts
>> +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts
>> @@ -6,7 +6,7 @@
>>
>> / {
>> model = "Xiaomi Pocophone F1 (EBBG)";
>> - compatible = "xiaomi,beryllium-ebbg", "qcom,sdm845";
>> + compatible = "xiaomi,beryllium-ebbg", "xiaomi,beryllium", "qcom,sdm845";
>
> So now for all users of this ABI, the ebbg variant will be treated like
> it was Tianma. Your commit msg should try to explain the impact of this,
> beside the hexagonrpcd.
Sure, I'll update the commit msg.
>
> Technically this is ABI change.
>
> Best regards,
> Krzysztof
>
--
David Heidelberg
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: net: Add schema for LAN75XX compatible USB Ethernet controllers
From: Krzysztof Kozlowski @ 2026-04-05 8:06 UTC (permalink / raw)
To: Thomas Richard
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Thomas Petazzoni, netdev, devicetree, linux-kernel,
linux-omap
In-Reply-To: <20260403-b4-var-som-om44-lan7500-v1-1-0dadde850143@bootlin.com>
On Fri, Apr 03, 2026 at 09:02:23PM +0200, Thomas Richard wrote:
> Create schema for LAN75XX compatible USB Ethernet controllers. The smsc75xx
> driver only supports LAN7500 and LAN7505 devices.
>
> Signed-off-by: Thomas Richard <thomas.richard@bootlin.com>
> ---
> .../devicetree/bindings/net/microchip,lan75xx.yaml | 52 ++++++++++++++++++++++
> 1 file changed, 52 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..b84022976044ffec2024cff9fc0aa5016723abed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/microchip,lan75xx.yaml
Rather microchip,lan7500.yaml. Wildcards don't really scale when you
have 75yy coming which does not fit into this binding.
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/microchip,lan75xx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip LAN7500/LAN7505 USB Ethernet Controllers
> +
> +maintainers:
> + - Thomas Richard <thomas.richard@bootlin.com>
> +
> +description:
> + Device tree properties for LAN75XX compatible USB Ethernet controller.
> +
> +allOf:
> + - $ref: ethernet-controller.yaml#
> +
> +properties:
> + compatible:
> + items:
Drop items, that's enum directly.
> + - enum:
> + - usb424,7500
> + - usb424,7505
But you should notice that this is exactly the same as 95xx, so why it
cannot go there? Because of the wildcard 95xx naming? That's not a
reason.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: net: qcom,ipa: add Milos compatible
From: Krzysztof Kozlowski @ 2026-04-05 8:03 UTC (permalink / raw)
To: Luca Weiss
Cc: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich,
~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260403-milos-ipa-v1-3-01e9e4e03d3e@fairphone.com>
On Fri, Apr 03, 2026 at 06:43:49PM +0200, Luca Weiss wrote:
> Add support for the Milos SoC, which uses IPA v5.2.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
> Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: sdm845-xiaomi-beryllium: Fix compatible strings
From: Krzysztof Kozlowski @ 2026-04-05 8:02 UTC (permalink / raw)
To: David Heidelberg
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Marijn Suijten, Casey Connolly, Joel Selvaraj,
Jens Reidel, Petr Hodina, linux-arm-msm, devicetree, linux-kernel,
phone-devel
In-Reply-To: <20260403-beryllium-compat-string-v1-2-0a6b9cb55a20@ixit.cz>
On Fri, Apr 03, 2026 at 06:55:34PM +0200, David Heidelberg wrote:
> From: Jens Reidel <adrian@travitia.xyz>
>
> The most specific strings should come first (panel variant included),
> then the more generic ones (device and SoC).
>
> This is necessary for hexagonrpcd to guess the HexagonFS path for the
> device. It tries all of the compatible entries, but if none for
> xiaomi,beryllium existed it wouldn't be able to guess it.
>
> Fixes: bcf429831ecb ("arm64: dts: qcom: sdm845-xiaomi-beryllium-ebbg: introduce Xiaomi Poco F1 EBBG variant")
> Fixes: dd6459a0890a ("arm64: dts: qcom: split beryllium dts into common dtsi and tianma dts")
> Signed-off-by: Jens Reidel <adrian@travitia.xyz>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts | 2 +-
> arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-tianma.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts
> index 2d6f0e382a6cb..d157622f84d13 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium-ebbg.dts
> @@ -6,7 +6,7 @@
>
> / {
> model = "Xiaomi Pocophone F1 (EBBG)";
> - compatible = "xiaomi,beryllium-ebbg", "qcom,sdm845";
> + compatible = "xiaomi,beryllium-ebbg", "xiaomi,beryllium", "qcom,sdm845";
So now for all users of this ABI, the ebbg variant will be treated like
it was Tianma. Your commit msg should try to explain the impact of this,
beside the hexagonrpcd.
Technically this is ABI change.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: qcom: Add Xiaomi Poco F1 Tianma variant bindings
From: David Heidelberg @ 2026-04-05 8:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Marijn Suijten, Casey Connolly, Joel Selvaraj,
Jens Reidel, Petr Hodina, linux-arm-msm, devicetree, linux-kernel,
phone-devel
In-Reply-To: <20260405-truthful-fat-angelfish-ec3e45@quoll>
On 05/04/2026 09:55, Krzysztof Kozlowski wrote:
> On Fri, Apr 03, 2026 at 06:55:33PM +0200, David Heidelberg wrote:
>> Add documentation for Tianma display and touchscreen variant.
>>
>> While at it, correct binding documentation expectation.
>
> What expectation? What exactly did you corrected that you claim this is
> a fix?
I would say the missing Tianma variant, which been with us for some time. The
follow up commit fixes the missing compatible and order, thus it would make
sense to me have also the dt-bindings part backported and fixed.
I agree I don't have strong case here. Should I drop the tag, keep it or replace
it with Cc: stable@vger.kernel.org?
David
>
>>
>> Fixes: 341fdef8ea49 ("dt-bindings: arm: qcom: Add Xiaomi Poco F1 EBBG variant bindings")
>
>
> Best regards,
> Krzysztof
>
--
David Heidelberg
^ 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