* [PATCH 01/10] dt-bindings: clock: qcom,rpmcc: add msm8960 compatible
From: Antony Kurniawan Soemardi via B4 Relay @ 2026-04-13 18:55 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
In-Reply-To: <20260414-msm8960-wifi-v1-0-007fda9d6134@smankusors.com>
From: Antony Kurniawan Soemardi <linux@smankusors.com>
Document the qcom,rpmcc-msm8960 compatible.
The MSM8960 platform shares the same RPM clock definitions as
APQ8064, so extend the existing conditional schema to treat
qcom,rpmcc-msm8960 the same as qcom,rpmcc-apq8064.
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
index ab97d4b7dba8..f84d08199e47 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
@@ -36,6 +36,7 @@ properties:
- qcom,rpmcc-msm8937
- qcom,rpmcc-msm8940
- qcom,rpmcc-msm8953
+ - qcom,rpmcc-msm8960
- qcom,rpmcc-msm8974
- qcom,rpmcc-msm8976
- qcom,rpmcc-msm8992
@@ -90,7 +91,9 @@ allOf:
properties:
compatible:
contains:
- const: qcom,rpmcc-apq8064
+ enum:
+ - qcom,rpmcc-apq8064
+ - qcom,rpmcc-msm8960
then:
properties:
clocks:
--
2.34.1
^ permalink raw reply related
* [PATCH 02/10] dt-bindings: mfd: syscon: add qcom,msm8960-sps-sic
From: Antony Kurniawan Soemardi via B4 Relay @ 2026-04-13 18:55 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
In-Reply-To: <20260414-msm8960-wifi-v1-0-007fda9d6134@smankusors.com>
From: Antony Kurniawan Soemardi <linux@smankusors.com>
Add compat for Smart Peripheral System (SPS) Interrupt Controller (SIC)
present on Qualcomm MSM8960 SoC.
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml
index e57add2bacd3..39a24c3ff9cf 100644
--- a/Documentation/devicetree/bindings/mfd/syscon.yaml
+++ b/Documentation/devicetree/bindings/mfd/syscon.yaml
@@ -106,6 +106,7 @@ select:
- nxp,s32g3-gpr
- qcom,apq8064-mmss-sfpb
- qcom,apq8064-sps-sic
+ - qcom,msm8960-sps-sic
- rockchip,px30-qos
- rockchip,rk3036-qos
- rockchip,rk3066-qos
@@ -219,6 +220,7 @@ properties:
- nxp,s32g3-gpr
- qcom,apq8064-mmss-sfpb
- qcom,apq8064-sps-sic
+ - qcom,msm8960-sps-sic
- rockchip,px30-qos
- rockchip,rk3036-qos
- rockchip,rk3066-qos
--
2.34.1
^ permalink raw reply related
* [PATCH 00/10] ARM: qcom: msm8960: enable WCNSS (Bluetooth & Wi-Fi)
From: Antony Kurniawan Soemardi via B4 Relay @ 2026-04-13 18:55 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
Enable the WCNSS (Riva) subsystem on MSM8960-based devices to support
Bluetooth and Wi-Fi.
Add the required device tree nodes and resources, including memory
regions, clocks, interconnects, and communication interfaces used by
the WCNSS firmware and drivers.
Changes:
- Add Riva (WCNSS) nodes: firmware memory, WCN3660 iris radio,
Bluetooth and Wi-Fi subdevices, and pinctrl states
- Add SMSM and SPS nodes for coordination with the WCNSS subsystem
- Add shared memory and hardware mutex for inter-processor communication
- Add SCM node for secure channel manager interaction
- Add RPM clock controller and required QDSS clock resource
- Add bindings for SPS interrupt controller and RPM clocks
Known limitations (not addressed in this series):
The wcn36xx driver appears to misclassify 2.4 GHz networks as 5 GHz
during hardware scanning, preventing association with 2.4 GHz networks.
This issue has also been observed on MSM8916 and MSM8953 platforms
using WCN3620 [1][2].
Tested on:
- Sony Xperia SP
- Samsung Galaxy Express (SGH-I437) - secure firmware loading not yet
functional (separate series pending)
[1] https://github.com/msm8916-mainline/linux/commit/cc4abc694fcf2c942410136bc58a61e79bf21e83
[2] https://github.com/msm8953-mainline/linux/commit/779c9627ec0b971bf466588e64fe530cf78a414d
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
Antony Kurniawan Soemardi (10):
dt-bindings: clock: qcom,rpmcc: add msm8960 compatible
dt-bindings: mfd: syscon: add qcom,msm8960-sps-sic
mfd: qcom_rpm: add msm8960 QDSS clock resource
clk: qcom: clk-rpm: add msm8960 compatible
ARM: dts: qcom: msm8960: add RPM clock controller and fix USB clocks
ARM: dts: qcom: msm8960: add SCM
ARM: dts: qcom: msm8960: add SMEM & hwmutex
ARM: dts: qcom: msm8960: add SMSM & SPS
ARM: dts: qcom: msm8960: add Riva
ARM: dts: qcom: msm8960: huashan: enable Wi-Fi and Bluetooth
.../devicetree/bindings/clock/qcom,rpmcc.yaml | 5 +-
Documentation/devicetree/bindings/mfd/syscon.yaml | 2 +
.../boot/dts/qcom/qcom-msm8960-sony-huashan.dts | 19 +++
arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 157 ++++++++++++++++++++-
drivers/clk/qcom/clk-rpm.c | 1 +
drivers/mfd/qcom_rpm.c | 1 +
6 files changed, 182 insertions(+), 3 deletions(-)
---
base-commit: 978e0d8216cae014f10326c9a257890cf98a6398
change-id: 20251226-msm8960-wifi-beecd96c6646
Best regards,
--
Antony Kurniawan Soemardi <linux@smankusors.com>
^ permalink raw reply
* [PATCH 03/10] mfd: qcom_rpm: add msm8960 QDSS clock resource
From: Antony Kurniawan Soemardi via B4 Relay @ 2026-04-13 18:55 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
In-Reply-To: <20260414-msm8960-wifi-v1-0-007fda9d6134@smankusors.com>
From: Antony Kurniawan Soemardi <linux@smankusors.com>
msm8960 uses the same clock descriptor as apq8064 but lacked the
corresponding QDSS resource definition in its resource table. Add
resource ID 209 to msm8960_rpm_resource_table to match apq8064's
implementation.
Without this entry, RPM clock initialization fails on msm8960,
preventing Bluetooth/Wi-Fi/USB from being enabled.
Tested-by: Rudraksha Gupta <guptarud@gmail.com>
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
drivers/mfd/qcom_rpm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/qcom_rpm.c b/drivers/mfd/qcom_rpm.c
index 27446f43e3f3..0defb3279af1 100644
--- a/drivers/mfd/qcom_rpm.c
+++ b/drivers/mfd/qcom_rpm.c
@@ -324,6 +324,7 @@ static const struct qcom_rpm_resource msm8960_rpm_resource_table[] = {
[QCOM_RPM_USB_OTG_SWITCH] = { 205, 119, 82, 1 },
[QCOM_RPM_HDMI_SWITCH] = { 206, 120, 83, 1 },
[QCOM_RPM_DDR_DMM] = { 207, 121, 84, 2 },
+ [QCOM_RPM_QDSS_CLK] = { 209, ~0, 7, 1 },
};
static const struct qcom_rpm_data msm8960_template = {
--
2.34.1
^ permalink raw reply related
* [PATCH 04/10] clk: qcom: clk-rpm: add msm8960 compatible
From: Antony Kurniawan Soemardi via B4 Relay @ 2026-04-13 18:55 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
In-Reply-To: <20260414-msm8960-wifi-v1-0-007fda9d6134@smankusors.com>
From: Antony Kurniawan Soemardi <linux@smankusors.com>
Add support for the "qcom,rpmcc-msm8960" compatible string to the
RPM clock driver.
msm8960 uses the same RPM clock descriptions as apq8064, so reuse
rpm_clk_apq8064 for this compatible.
Tested-by: Rudraksha Gupta <guptarud@gmail.com>
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
drivers/clk/qcom/clk-rpm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/qcom/clk-rpm.c b/drivers/clk/qcom/clk-rpm.c
index be0145631197..601f60274113 100644
--- a/drivers/clk/qcom/clk-rpm.c
+++ b/drivers/clk/qcom/clk-rpm.c
@@ -502,6 +502,7 @@ static const struct rpm_clk_desc rpm_clk_ipq806x = {
static const struct of_device_id rpm_clk_match_table[] = {
{ .compatible = "qcom,rpmcc-msm8660", .data = &rpm_clk_msm8660 },
{ .compatible = "qcom,rpmcc-apq8060", .data = &rpm_clk_msm8660 },
+ { .compatible = "qcom,rpmcc-msm8960", .data = &rpm_clk_apq8064 },
{ .compatible = "qcom,rpmcc-apq8064", .data = &rpm_clk_apq8064 },
{ .compatible = "qcom,rpmcc-ipq806x", .data = &rpm_clk_ipq806x },
{ }
--
2.34.1
^ permalink raw reply related
* [PATCH 06/10] ARM: dts: qcom: msm8960: add SCM
From: Antony Kurniawan Soemardi via B4 Relay @ 2026-04-13 18:55 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
In-Reply-To: <20260414-msm8960-wifi-v1-0-007fda9d6134@smankusors.com>
From: Antony Kurniawan Soemardi <linux@smankusors.com>
Add the Secure Channel Manager firmware device node to the MSM8960
device tree. The SCM is required for secure communication between the
application processor and other subsystems.
Tested-by: Rudraksha Gupta <guptarud@gmail.com>
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
index 1d5e97b6aa4b..bc3fd55e524a 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
@@ -77,6 +77,15 @@ l2: l2-cache {
};
};
+ firmware {
+ scm {
+ compatible = "qcom,scm-msm8960", "qcom,scm";
+
+ clocks = <&rpmcc RPM_DAYTONA_FABRIC_CLK>;
+ clock-names = "core";
+ };
+ };
+
memory@80000000 {
device_type = "memory";
reg = <0x80000000 0>;
--
2.34.1
^ permalink raw reply related
* [PATCH 05/10] ARM: dts: qcom: msm8960: add RPM clock controller and fix USB clocks
From: Antony Kurniawan Soemardi via B4 Relay @ 2026-04-13 18:55 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
In-Reply-To: <20260414-msm8960-wifi-v1-0-007fda9d6134@smankusors.com>
From: Antony Kurniawan Soemardi <linux@smankusors.com>
The RPM clock controller manages clocks shared between the application
processor and the RPM firmware, including fabric and bus clocks required
by several peripherals.
With the RPM clock controller now available in the device tree, the USB
controller must explicitly declare its dependency on
RPM_DAYTONA_FABRIC_CLK. Without this declaration, the clock framework
would consider it unused and disable it, breaking USB functionality.
This also corrects the previous misuse of USB_HS1_XCVR_CLK as the core
clock. The XCVR clock is in fact used for PHY/reset handling rather than
as the main core clock.
A similar issue has been observed on APQ8064, where missing the RPM
fabric clock dependency leads to broken USB.
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
index fd28401cebb5..1d5e97b6aa4b 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
@@ -5,6 +5,7 @@
#include <dt-bindings/clock/qcom,gcc-msm8960.h>
#include <dt-bindings/reset/qcom,gcc-msm8960.h>
#include <dt-bindings/clock/qcom,lcc-msm8960.h>
+#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/mfd/qcom-rpm.h>
#include <dt-bindings/soc/qcom,gsbi.h>
@@ -98,6 +99,13 @@ rpm: rpm@108000 {
interrupt-names = "ack",
"err",
"wakeup";
+
+ rpmcc: clock-controller {
+ compatible = "qcom,rpmcc-msm8960", "qcom,rpmcc";
+ #clock-cells = <1>;
+ clocks = <&pxo_board>, <&cxo_board>;
+ clock-names = "pxo", "cxo";
+ };
};
ssbi: ssbi@500000 {
@@ -507,8 +515,12 @@ usb1: usb@12500000 {
reg = <0x12500000 0x200>,
<0x12500200 0x200>;
interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&gcc USB_HS1_XCVR_CLK>, <&gcc USB_HS1_H_CLK>;
- clock-names = "core", "iface";
+ clocks = <&rpmcc RPM_DAYTONA_FABRIC_CLK>,
+ <&gcc USB_HS1_H_CLK>,
+ <&gcc USB_HS1_XCVR_CLK>;
+ clock-names = "core",
+ "iface",
+ "fs";
assigned-clocks = <&gcc USB_HS1_XCVR_CLK>;
assigned-clock-rates = <60000000>;
resets = <&gcc USB_HS1_RESET>;
--
2.34.1
^ permalink raw reply related
* [PATCH 07/10] ARM: dts: qcom: msm8960: add SMEM & hwmutex
From: Antony Kurniawan Soemardi via B4 Relay @ 2026-04-13 18:55 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
In-Reply-To: <20260414-msm8960-wifi-v1-0-007fda9d6134@smankusors.com>
From: Antony Kurniawan Soemardi <linux@smankusors.com>
Enable shared memory communication and add the SFPB mutex for MSM8960.
These provide the foundation for inter-processor communication with the
Riva (BT + Wi-Fi) subsystem.
Tested-by: Rudraksha Gupta <guptarud@gmail.com>
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
index bc3fd55e524a..218cf3158dfb 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
@@ -91,6 +91,24 @@ memory@80000000 {
reg = <0x80000000 0>;
};
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ smem_region: smem@80000000 {
+ reg = <0x80000000 0x200000>;
+ no-map;
+ };
+ };
+
+ smem {
+ compatible = "qcom,smem";
+ memory-region = <&smem_region>;
+
+ hwlocks = <&sfpb_mutex 3>;
+ };
+
soc: soc {
compatible = "simple-bus";
ranges;
@@ -340,6 +358,12 @@ tsens: thermal-sensor {
};
};
+ sfpb_mutex: hwmutex@1200600 {
+ compatible = "qcom,sfpb-mutex";
+ reg = <0x01200600 0x100>;
+ #hwlock-cells = <1>;
+ };
+
intc: interrupt-controller@2000000 {
compatible = "qcom,msm-qgic2";
reg = <0x02000000 0x1000>,
--
2.34.1
^ permalink raw reply related
* [PATCH 08/10] ARM: dts: qcom: msm8960: add SMSM & SPS
From: Antony Kurniawan Soemardi via B4 Relay @ 2026-04-13 18:55 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
In-Reply-To: <20260414-msm8960-wifi-v1-0-007fda9d6134@smankusors.com>
From: Antony Kurniawan Soemardi <linux@smankusors.com>
Add the Shared Memory State Machine node to coordinate state transitions
between the Applications processor and the Riva subsystem.
Tested-by: Rudraksha Gupta <guptarud@gmail.com>
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
index 218cf3158dfb..107c5613aa4a 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
@@ -109,6 +109,31 @@ smem {
hwlocks = <&sfpb_mutex 3>;
};
+ smsm {
+ compatible = "qcom,smsm";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ qcom,ipc-1 = <&l2cc 8 4>;
+ qcom,ipc-2 = <&l2cc 8 14>;
+ qcom,ipc-3 = <&l2cc 8 23>;
+ qcom,ipc-4 = <&sps_sic_non_secure 0x4094 0>;
+
+ apps_smsm: apps@0 {
+ reg = <0>;
+ #qcom,smem-state-cells = <1>;
+ };
+
+ wcnss_smsm: wcnss@3 {
+ reg = <3>;
+ interrupts = <GIC_SPI 204 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
soc: soc {
compatible = "simple-bus";
ranges;
@@ -455,6 +480,11 @@ clock-controller@4000000 {
"hdmipll";
};
+ sps_sic_non_secure: interrupt-controller@12100000 {
+ compatible = "qcom,msm8960-sps-sic", "syscon";
+ reg = <0x12100000 0x10000>;
+ };
+
sdcc3: mmc@12180000 {
compatible = "arm,pl18x", "arm,primecell";
reg = <0x12180000 0x2000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 09/10] ARM: dts: qcom: msm8960: add Riva
From: Antony Kurniawan Soemardi via B4 Relay @ 2026-04-13 18:55 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
In-Reply-To: <20260414-msm8960-wifi-v1-0-007fda9d6134@smankusors.com>
From: Antony Kurniawan Soemardi <linux@smankusors.com>
Add the Riva Peripheral Image Loader node to support the Wireless
Connectivity and Networking Subsystem on MSM8960. This includes:
- Reserved memory region for WCNSS firmware
- WCN3660 iris radio controller
- Bluetooth and Wi-Fi sub-devices exposed via the SMD edge
- Pinctrl states for Bluetooth and Wi-Fi power management
Tested-by: Rudraksha Gupta <guptarud@gmail.com>
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 78 ++++++++++++++++++++++++++++++++
1 file changed, 78 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
index 107c5613aa4a..6bf36f35e5e3 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
@@ -100,6 +100,11 @@ smem_region: smem@80000000 {
reg = <0x80000000 0x200000>;
no-map;
};
+
+ wcnss_mem: wcnss@8f000000 {
+ reg = <0x8f000000 0x700000>;
+ no-map;
+ };
};
smem {
@@ -317,6 +322,34 @@ i2c12-pins {
};
};
+ riva_bt_default_state: riva-bt-active-state {
+ pins = "gpio28", "gpio29";
+ function = "bt";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ riva_bt_sleep_state: riva-bt-sleep-state {
+ pins = "gpio28", "gpio29";
+ function = "bt";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ riva_wlan_default_state: riva-wlan-active-state {
+ pins = "gpio84", "gpio85", "gpio86", "gpio87", "gpio88";
+ function = "wlan";
+ drive-strength = <6>;
+ bias-pull-down;
+ };
+
+ riva_wlan_sleep_state: riva-wlan-sleep-state {
+ pins = "gpio84", "gpio85", "gpio86", "gpio87", "gpio88";
+ function = "wlan";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
sdcc3_default_state: sdcc3-default-state {
clk-pins {
pins = "sdc3_clk";
@@ -456,6 +489,51 @@ saw1_vreg: regulator {
};
};
+ riva: riva-pil@3200800 {
+ compatible = "qcom,riva-pil";
+ reg = <0x03200800 0x1000>, <0x03202000 0x2000>, <0x03204000 0x100>;
+ reg-names = "ccu", "dxe", "pmu";
+ interrupts-extended = <&intc GIC_SPI 199 IRQ_TYPE_EDGE_RISING>,
+ <&wcnss_smsm 6 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal";
+ memory-region = <&wcnss_mem>;
+
+ status = "disabled";
+
+ iris {
+ compatible = "qcom,wcn3660";
+ clocks = <&cxo_board>;
+ clock-names = "xo";
+ };
+
+ smd-edge {
+ interrupts = <GIC_SPI 198 IRQ_TYPE_EDGE_RISING>;
+ label = "riva";
+ qcom,ipc = <&l2cc 8 25>;
+ qcom,smd-edge = <6>;
+
+ wcnss {
+ compatible = "qcom,wcnss";
+ qcom,smd-channels = "WCNSS_CTRL";
+ qcom,mmio = <&riva>;
+
+ bluetooth {
+ compatible = "qcom,wcnss-bt";
+ };
+
+ wifi {
+ compatible = "qcom,wcnss-wlan";
+ interrupts = <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "tx", "rx";
+ qcom,smem-states = <&apps_smsm 10>, <&apps_smsm 9>;
+ qcom,smem-state-names = "tx-enable",
+ "tx-rings-empty";
+ };
+ };
+ };
+ };
+
clock-controller@4000000 {
compatible = "qcom,mmcc-msm8960";
reg = <0x4000000 0x1000>;
--
2.34.1
^ permalink raw reply related
* [PATCH 10/10] ARM: dts: qcom: msm8960: huashan: enable Wi-Fi and Bluetooth
From: Antony Kurniawan Soemardi via B4 Relay @ 2026-04-13 18:55 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
In-Reply-To: <20260414-msm8960-wifi-v1-0-007fda9d6134@smankusors.com>
From: Antony Kurniawan Soemardi <linux@smankusors.com>
Add Wi-Fi and Bluetooth support for Sony Xperia SP.
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
arch/arm/boot/dts/qcom/qcom-msm8960-sony-huashan.dts | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960-sony-huashan.dts b/arch/arm/boot/dts/qcom/qcom-msm8960-sony-huashan.dts
index 591dc837e600..79fa9bd038f2 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960-sony-huashan.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960-sony-huashan.dts
@@ -95,6 +95,25 @@ MATRIX_KEY(1, 1, KEY_CAMERA)
status = "okay";
};
+&riva {
+ pinctrl-0 = <&riva_wlan_default_state>, <&riva_bt_default_state>;
+ pinctrl-1 = <&riva_wlan_sleep_state>, <&riva_bt_sleep_state>;
+ pinctrl-names = "default", "sleep";
+
+ vddcx-supply = <&pm8921_s3>;
+ vddmx-supply = <&pm8921_l24>;
+ vddpx-supply = <&pm8921_s4>;
+
+ status = "okay";
+
+ iris {
+ vdddig-supply = <&pm8921_lvs2>;
+ vddpa-supply = <&pm8921_l10>;
+ vddrfa-supply = <&pm8921_s2>;
+ vddxo-supply = <&pm8921_l4>;
+ };
+};
+
&rpm {
regulators {
compatible = "qcom,rpm-pm8921-regulators";
--
2.34.1
^ permalink raw reply related
* Re: [PATCH V3 2/9] iio: imu: inv_icm42607: Add Core for inv_icm42607 Driver
From: Jonathan Cameron @ 2026-04-13 19:06 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260330195853.392877-3-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:46 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add the core component of a new inv_icm42607 driver. This includes
> a few setup functions and the full register definition in the
> header file.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Hi Chris,
I've avoided repeating a few things David raised, but there may
well be overlap on some things. I'm not particularly keen on code
that doesn't build at the end of a patch or even provide the Kconfig
and makefile stuff to do so. Maybe it's too much effort given how you have
this structured.
Thanks,
Jonathan
> ---
> drivers/iio/imu/inv_icm42607/inv_icm42607.h | 424 ++++++++++++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_core.c | 300 +++++++++++++
> 2 files changed, 724 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
>
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> new file mode 100644
> index 000000000000..609188c40ffc
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> @@ -0,0 +1,424 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#ifndef INV_ICM42607_H_
> +#define INV_ICM42607_H_
> +
> +#include <linux/bitops.h>
> +#include <linux/bitfield.h>
> +#include <linux/regmap.h>
> +#include <linux/mutex.h>
> +#include <linux/regulator/consumer.h>
Alphabetical order. Though fine to have an IIO specific block at the end.
> +#include <linux/iio/iio.h>
> +#include <linux/iio/common/inv_sensors_timestamp.h>
> +/* ODR values */
> +enum inv_icm42607_odr {
> + INV_ICM42607_ODR_1600HZ = 5,
> + INV_ICM42607_ODR_800HZ,
> + INV_ICM42607_ODR_400HZ,
> + INV_ICM42607_ODR_200HZ,
> + INV_ICM42607_ODR_100HZ,
> + INV_ICM42607_ODR_50HZ,
> + INV_ICM42607_ODR_25HZ,
> + INV_ICM42607_ODR_12_5HZ,
> + INV_ICM42607_ODR_6_25HZ_LP,
> + INV_ICM42607_ODR_3_125HZ_LP,
> + INV_ICM42607_ODR_1_5625HZ_LP,
> + INV_ICM42607_ODR_NB,
If just here as number, then no terminating comma as
we don't want to imply something might come after it.
Same for all the other enums.
> +};
> +
> +enum inv_icm42607_filter {
> + /* Low-Noise mode sensor data filter */
> + INV_ICM42607_FILTER_BYPASS,
> + INV_ICM42607_FILTER_BW_180HZ,
> + INV_ICM42607_FILTER_BW_121HZ,
> + INV_ICM42607_FILTER_BW_73HZ,
> + INV_ICM42607_FILTER_BW_53HZ,
> + INV_ICM42607_FILTER_BW_34HZ,
> + INV_ICM42607_FILTER_BW_25HZ,
> + INV_ICM42607_FILTER_BW_16HZ,
> +
> + /* Low-Power mode sensor data filter (averaging) */
> + INV_ICM42607_FILTER_AVG_2X = 0,
> + INV_ICM42607_FILTER_AVG_4X,
> + INV_ICM42607_FILTER_AVG_8X,
> + INV_ICM42607_FILTER_AVG_16X,
> + INV_ICM42607_FILTER_AVG_32X,
> + INV_ICM42607_FILTER_AVG_64X,
Bring these in when used. For now these to me look like they should be broken
into two separate enums. I can't see how the will be used though so hard
to tell.
> +};
>
> +#define INV_ICM42607_INTF_CONFIG1_CLKSEL_MASK GENMASK(1, 0)
> +#define INV_ICM42607_INTF_CONFIG1_CLKSEL_PLL \
> + FIELD_PREP(INV_ICM42607_INTF_CONFIG1_CLKSEL_MASK, 1)
Define the value of the field to give that a name and use FIELD_PREP() inline.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> new file mode 100644
> index 000000000000..6b7078387568
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> @@ -0,0 +1,300 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/device.h>
Most likely this should be more specific headers like
dev_printk.h etc It is pretty rare it makes sense to include
device.h if following IWYU approach (which we do for IIO drivers
and is generally accepted across the kernel).
> +#include <linux/module.h>
Alphabetical order.
> +#include <linux/slab.h>
> +#include <linux/delay.h>
> +#include <linux/mutex.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/property.h>
> +#include <linux/regmap.h>
> +#include <linux/iio/iio.h>
> +u32 inv_icm42607_odr_to_period(enum inv_icm42607_odr odr)
> +{
> + static u32 odr_periods[INV_ICM42607_ODR_NB] = {
Hopefully the compiler can figure it out, but better
as explicit const.
> + /* Reserved values */
> + 0, 0, 0, 0, 0,
> + /* 1600Hz */
> + 625000,
> + /* 800Hz */
> + 1250000,
> + /* 400Hz */
> + 2500000,
> + /* 200Hz */
> + 5000000,
> + /* 100 Hz */
> + 10000000,
> + /* 50Hz */
> + 20000000,
> + /* 25Hz */
> + 40000000,
> + /* 12.5Hz */
> + 80000000,
> + /* 6.25Hz */
> + 160000000,
> + /* 3.125Hz */
> + 320000000,
> + /* 1.5625Hz */
> + 640000000,
> + };
> +
> + return odr_periods[odr];
> +}
> +
> +static int inv_icm42607_set_conf(struct inv_icm42607_state *st,
> + const struct inv_icm42607_conf *conf)
> +{
> + unsigned int val;
> + int ret;
> +
> + val = INV_ICM42607_PWR_MGMT0_GYRO(conf->gyro.mode) |
> + INV_ICM42607_PWR_MGMT0_ACCEL(conf->accel.mode);
Align as
val = INV_ICM42607_PWR_MGMT0_GYRO(conf->gyro.mode) |
INV_ICM42607_PWR_MGMT0_ACCEL(conf->accel.mode);
Though as mentioned in David's review, prefer to see the FIELD_PREP()
inline.
> + /*
> + * No temperature enable reg in datasheet, but BSP driver
> + * selected RC oscillator clock in LP mode when temperature
> + * was disabled.
> + */
> + if (!conf->temp_en)
> + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
Could make this
val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL,
!conf->temp_en);
Not particularly important though if you prefer the if.
> + ret = regmap_write(st->map, INV_ICM42607_REG_PWR_MGMT0, val);
> + if (ret)
> + return ret;
> +
> + val = INV_ICM42607_GYRO_CONFIG0_FS_SEL(conf->gyro.fs) |
> + INV_ICM42607_GYRO_CONFIG0_ODR(conf->gyro.odr);
As above. If it's the second line of a statement, it must be indented
to avoid readability issues. Fix all examples of this.
> + ret = regmap_write(st->map, INV_ICM42607_REG_GYRO_CONFIG0, val);
> + if (ret)
> + return ret;
> +
> + val = INV_ICM42607_ACCEL_CONFIG0_FS_SEL(conf->accel.fs) |
> + INV_ICM42607_ACCEL_CONFIG0_ODR(conf->accel.odr);
> + ret = regmap_write(st->map, INV_ICM42607_REG_ACCEL_CONFIG0, val);
> + if (ret)
> + return ret;
> +
> + val = INV_ICM42607_GYRO_CONFIG1_FILTER(conf->gyro.filter);
> + ret = regmap_write(st->map, INV_ICM42607_REG_GYRO_CONFIG1, val);
> + if (ret)
> + return ret;
> +
> + val = INV_ICM42607_ACCEL_CONFIG1_FILTER(conf->accel.filter);
> + ret = regmap_write(st->map, INV_ICM42607_REG_ACCEL_CONFIG1, val);
> + if (ret)
> + return ret;
> +
> + st->conf = *conf;
> +
> + return 0;
> +}
> +
> +/**
> + * inv_icm42607_setup() - check and setup chip
> + * @st: driver internal state
> + * @bus_setup: callback for setting up bus specific registers
> + *
> + * Returns 0 on success, a negative error code otherwise.
> + */
> +static int inv_icm42607_setup(struct inv_icm42607_state *st,
> + inv_icm42607_bus_setup bus_setup)
> +{
> + const struct inv_icm42607_hw *hw = &inv_icm42607_hw[st->chip];
> + const struct device *dev = regmap_get_device(st->map);
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(st->map, INV_ICM42607_REG_WHOAMI, &val);
> + if (ret)
> + return ret;
> +
> + if (val != hw->whoami)
> + dev_warn_probe(dev, -ENODEV,
> + "invalid whoami %#02x expected %#02x (%s)\n",
> + val, hw->whoami, hw->name);
> +
> + st->name = hw->name;
> +
> + ret = regmap_write(st->map, INV_ICM42607_REG_SIGNAL_PATH_RESET,
> + INV_ICM42607_SIGNAL_PATH_RESET_SOFT_RESET);
> + if (ret)
> + return ret;
> + msleep(INV_ICM42607_RESET_TIME_MS);
fsleep() here as sleeping longer is probably fine and that function will
apply appropriate slack on the times.
> +
> + ret = regmap_read(st->map, INV_ICM42607_REG_INT_STATUS, &val);
> + if (ret)
> + return ret;
> + if (!(val & INV_ICM42607_INT_STATUS_RESET_DONE))
> + return dev_err_probe(dev, -ENODEV,
> + "reset error, reset done bit not set\n");
> +
> + ret = bus_setup(st);
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
> + INV_ICM42607_INTF_CONFIG0_SENSOR_DATA_ENDIAN,
> + INV_ICM42607_INTF_CONFIG0_SENSOR_DATA_ENDIAN);
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG1,
> + INV_ICM42607_INTF_CONFIG1_CLKSEL_MASK,
> + INV_ICM42607_INTF_CONFIG1_CLKSEL_PLL);
> + if (ret)
> + return ret;
> +
> + return inv_icm42607_set_conf(st, hw->conf);
> +}
> +
> +static int inv_icm42607_enable_vddio_reg(struct inv_icm42607_state *st)
> +{
> + int ret;
> +
> + ret = regulator_enable(st->vddio_supply);
> + if (ret)
> + return ret;
> +
> + usleep_range(3000, 4000);
David covered this, fsleep() preferred.
> +
> + return 0;
> +}
> +
> +int inv_icm42607_core_probe(struct regmap *regmap, int chip,
> + inv_icm42607_bus_setup bus_setup)
> +{
> + struct device *dev = regmap_get_device(regmap);
> + struct fwnode_handle *fwnode = dev_fwnode(dev);
> + struct inv_icm42607_state *st;
> + int irq, irq_type;
> + bool open_drain;
> + int ret;
> +
> + if (chip < INV_CHIP_INVALID || chip >= INV_CHIP_NB)
> + dev_warn_probe(dev, -ENODEV,
> + "Invalid chip = %d\n", chip);
Easily fits on one line shorter than 80 chars.
> +
> + /* get INT1 only supported interrupt or fallback to first interrupt */
Why the fallback? I suspect this is copied from a driver
that didn't (bug) support named interrupts from the start. Given you are
doing so here, just insist on named one to simplify things. I'd imagine
that if INT2 is ever supported, the device configuration will need to be
different.
> + irq = fwnode_irq_get_byname(fwnode, "INT1");
> + if (irq < 0 && irq != -EPROBE_DEFER) {
> + dev_info(dev, "no INT1 interrupt defined, fallback to first interrupt\n");
> + irq = fwnode_irq_get(fwnode, 0);
> + }
> + if (irq < 0)
> + return dev_err_probe(dev, irq, "error missing INT1 interrupt\n");
> +
> + irq_type = irq_get_trigger_type(irq);
> + if (!irq_type)
> + irq_type = IRQF_TRIGGER_FALLING;
Not used at this point. Bring it in when you use it so we can understand
the default setting.
> +
> + open_drain = device_property_read_bool(dev, "drive-open-drain");
> +
> + st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
> + if (!st)
> + return -ENOMEM;
> +
> + dev_set_drvdata(dev, st);
> + mutex_init(&st->lock);
For new code
ret = devm_mutex_init(&st->lock);
if (ret)
return ret;
Brings a very small advantage if someone is debugging locks.
> + st->chip = chip;
> + st->map = regmap;
> + st->irq = irq;
> +
> + ret = iio_read_mount_matrix(dev, &st->orientation);
> + if (ret) {
> + dev_err(dev, "failed to retrieve mounting matrix %d\n", ret);
> + return ret;
return dev_err_probe();
> + }
> +
> + ret = devm_regulator_get_enable(dev, "vdd");
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Failed to get vdd regulator\n");
> +
> + msleep(INV_ICM42607_POWER_UP_TIME_MS);
> +
> + st->vddio_supply = devm_regulator_get(dev, "vddio");
> + if (IS_ERR(st->vddio_supply))
> + return PTR_ERR(st->vddio_supply);
> +
> + ret = inv_icm42607_enable_vddio_reg(st);
> + if (ret)
> + return ret;
> +
> + ret = devm_add_action_or_reset(dev, inv_icm42607_disable_vddio_reg, st);
> + if (ret)
> + return ret;
> +
> + /* Setup chip registers (includes WHOAMI check, reset check, bus setup) */
> + ret = inv_icm42607_setup(st, bus_setup);
> +
> + return ret;
Looking forwards I would instead do:
if (ret)
return ret;
return 0;
I think that makes it easier to add the additional pm stuff in later patches.
> +}
> +EXPORT_SYMBOL_NS_GPL(inv_icm42607_core_probe, "IIO_ICM42607");
^ permalink raw reply
* Re: [PATCH 00/10] ARM: qcom: msm8960: enable WCNSS (Bluetooth & Wi-Fi)
From: Antony Kurniawan Soemardi @ 2026-04-13 19:05 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta
In-Reply-To: <20260414-msm8960-wifi-v1-0-01c081e54610@smankusors.com>
On 4/14/2026 1:32 AM, Antony Kurniawan Soemardi wrote:
> Enable the WCNSS (Riva) subsystem on MSM8960-based devices to support
> Bluetooth and Wi-Fi.
Sorry, please disregard this partial patch series. I encountered a rate
limit on my SMTP provider, and have now resent the full patch series via
B4 Relay.
Thanks,
Antony K. S.
^ permalink raw reply
* Re: [PATCH v21 2/6] pwm: driver for qualcomm ipq6018 pwm block
From: George Moussalem @ 2026-04-13 19:17 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-pwm, devicetree, linux-kernel,
Devi Priya
In-Reply-To: <ady2pLwiNT9FffF7@monoceros>
Hello
On 4/13/2026 1:35 PM, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Apr 06, 2026 at 10:24:39PM +0200, George Moussalem via B4 Relay wrote:
>> From: Devi Priya <quic_devipriy@quicinc.com>
>>
>> Driver for the PWM block in Qualcomm IPQ6018 line of SoCs. Based on
>> driver from downstream Codeaurora kernel tree. Removed support for older
>> (V1) variants because I have no access to that hardware.
>>
>> Tested on IPQ5018 and IPQ6010 based hardware.
>>
>> Co-developed-by: Baruch Siach <baruch.siach@siklu.com>
>> Signed-off-by: Baruch Siach <baruch.siach@siklu.com>
>> Signed-off-by: Devi Priya <quic_devipriy@quicinc.com>
>> Reviewed-by: Bjorn Andersson <andersson@kernel.org>
>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>
> I have a few remaining nitpicks. If you're ok I'll squash the following
> diff into this patch and apply it:
Just applied it to my own branch, all okay from my side. Thanks for your
guidance and support!
>
> diff --git a/drivers/pwm/pwm-ipq.c b/drivers/pwm/pwm-ipq.c
> index b79e5e457d1a..65af19ded72c 100644
> --- a/drivers/pwm/pwm-ipq.c
> +++ b/drivers/pwm/pwm-ipq.c
> @@ -2,7 +2,7 @@
> /*
> * Copyright (c) 2016-2017, 2020 The Linux Foundation. All rights reserved.
> *
> - * Hardware notes / Limitations:
> + * Limitations:
> * - The PWM controller has no publicly available datasheet.
> * - Each of the four channels is programmed via two 32-bit registers
> * (REG0 and REG1 at 8-byte stride).
>
> This is to make
>
> sed -rn '/Limitations:/,/\*\/?$/p' drivers/pwm/*.c
>
> do the right thing. I know "Limitations" isn't a good subject for this,
> but until I come around to pick a better marker, doing the same in all
> drivers is good.
>
> @@ -44,13 +44,6 @@
>
> #define IPQ_PWM_REG1 4
> #define IPQ_PWM_REG1_PRE_DIV GENMASK(15, 0)
> -
> -/*
> - * The max value specified for each field is based on the number of bits
> - * in the pwm control register for that field (16-bit)
> - */
> -#define IPQ_PWM_MAX_DIV FIELD_MAX(IPQ_PWM_REG0_PWM_DIV)
> -
> /*
> * Enable bit is set to enable output toggling in pwm device.
> * Update bit is set to trigger the change and is unset automatically
> @@ -59,6 +52,12 @@
> #define IPQ_PWM_REG1_UPDATE BIT(30)
> #define IPQ_PWM_REG1_ENABLE BIT(31)
>
> +/*
> + * The max value specified for each field is based on the number of bits
> + * in the pwm control register for that field (16-bit)
> + */
> +#define IPQ_PWM_MAX_DIV FIELD_MAX(IPQ_PWM_REG0_PWM_DIV)
> +
> struct ipq_pwm_chip {
> void __iomem *mem;
> unsigned long clk_rate;
>
> This is just about ordering definitions taken 1:1 from the manual before
> driver specific stuff.
>
> @@ -95,6 +94,12 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> unsigned long val = 0;
> unsigned long hi_dur;
>
> + if (!state->enabled) {
> + /* clear IPQ_PWM_REG1_ENABLE */
> + ipq_pwm_reg_write(pwm, IPQ_PWM_REG1, IPQ_PWM_REG1_UPDATE);
> + return 0;
> + }
> +
> if (state->polarity != PWM_POLARITY_NORMAL)
> return -EINVAL;
>
> This ensures that the PWM can be disabled even if state->polarity is
> bogus or period and duty_cycle are out of range.
>
> @@ -102,7 +107,8 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> * Check the upper and lower bounds for the period as per
> * hardware limits
> */
> - period_ns = max(state->period, IPQ_PWM_MIN_PERIOD_NS);
> + if (state->period < IPQ_PWM_MIN_PERIOD_NS)
> + return -ERANGE;
> period_ns = min(state->period, IPQ_PWM_MAX_PERIOD_NS);
> duty_ns = min(state->duty_cycle, period_ns);
>
> This is about correctness. A driver is expected to never configure a
> higher value than requested. (And otherwise I would have converted that
> to clamp().)
>
> @@ -134,7 +140,7 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>
> /* pwm duty = HI_DUR * (PRE_DIV + 1) / clk_rate */
> hi_dur = mul_u64_u64_div_u64(duty_ns, ipq_chip->clk_rate,
> - (u64)(pre_div + 1) * NSEC_PER_SEC);
> + (u64)NSEC_PER_SEC * (pre_div + 1));
>
> val = FIELD_PREP(IPQ_PWM_REG0_HI_DURATION, hi_dur) |
> FIELD_PREP(IPQ_PWM_REG0_PWM_DIV, pwm_div);
>
> Just consistency with the period calculation
>
> @@ -144,9 +150,7 @@ static int ipq_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> ipq_pwm_reg_write(pwm, IPQ_PWM_REG1, val);
>
> /* PWM enable toggle needs a separate write to REG1 */
> - val |= IPQ_PWM_REG1_UPDATE;
> - if (state->enabled)
> - val |= IPQ_PWM_REG1_ENABLE;
> + val |= IPQ_PWM_REG1_UPDATE | IPQ_PWM_REG1_ENABLE;
> ipq_pwm_reg_write(pwm, IPQ_PWM_REG1, val);
>
> return 0;
>
> Simplification that is possible after checking for state->enabled early.
>
> @@ -174,7 +178,7 @@ static int ipq_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
> hi_dur = FIELD_GET(IPQ_PWM_REG0_HI_DURATION, reg0);
> pre_div = FIELD_GET(IPQ_PWM_REG1_PRE_DIV, reg1);
>
> - effective_div = (u64)(pre_div + 1) * (pwm_div + 1);
> + effective_div = (u64)(pwm_div + 1) * (pre_div + 1)
>
> /*
> * effective_div <= 0x100000000, so the multiplication doesn't overflow.
>
> Again consistency.
>
> A nice followup for this patch would be the conversion to the waveform
> API; just in case you're still motivated to work on this driver :-)
>
> Best regards
> Uwe
Best regards,
George
^ permalink raw reply
* Re: [PATCH V3 4/9] iio: imu: inv_icm42607: Add Buffer support functions to icm42607
From: Jonathan Cameron @ 2026-04-13 19:23 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260330195853.392877-5-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:48 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add all FIFO parsing and reading functions to support
> inv_icm42607 hardware.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
A few minor things inline.
Thanks,
Jonathan
> ---
> drivers/iio/imu/inv_icm42607/inv_icm42607.h | 4 +
> .../imu/inv_icm42607/inv_icm42607_buffer.c | 496 ++++++++++++++++++
> .../imu/inv_icm42607/inv_icm42607_buffer.h | 98 ++++
> .../iio/imu/inv_icm42607/inv_icm42607_core.c | 25 +
> 4 files changed, 623 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.h
>
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> index 7d13091aa8df..5530fd3bc03f 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c
> new file mode 100644
> index 000000000000..4f5f199586fc
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c
> @@ -0,0 +1,496 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/minmax.h>
> +#include <linux/mutex.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/delay.h>
> +
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/common/inv_sensors_timestamp.h>
> +#include <linux/iio/iio.h>
Alphabetical order (+ a block for IIO) for headers.
> +
> +static unsigned int inv_icm42607_wm_truncate(unsigned int watermark,
> + size_t packet_size)
> +{
> + size_t wm_size;
> + unsigned int wm;
> +
> + wm_size = watermark * packet_size;
> + if (wm_size > INV_ICM42607_FIFO_WATERMARK_MAX)
> + wm_size = INV_ICM42607_FIFO_WATERMARK_MAX;
> +
> + wm = wm_size / packet_size;
> +
> + return wm;
Why not
return wm_size / packet_size;
> +}
> +int inv_icm42607_buffer_hwfifo_flush(struct inv_icm42607_state *st,
> + unsigned int count)
> +{
> + s64 gyro_ts, accel_ts;
> + int ret;
> +
> + gyro_ts = iio_get_time_ns(st->indio_gyro);
> + accel_ts = iio_get_time_ns(st->indio_accel);
> +
> + ret = inv_icm42607_buffer_fifo_read(st, count);
> +
> + return ret;
Either
return inv_...
or
ret =
if (ret)
return ret;
return 0;
2nd one only if this is going to get more complex in later patches.
> +}
> +
> +int inv_icm42607_buffer_init(struct inv_icm42607_state *st)
> +{
> + unsigned int val;
> + int ret;
> +
> + st->fifo.watermark.eff_gyro = 1;
> + st->fifo.watermark.eff_accel = 1;
> +
> + /* Configure FIFO_COUNT format in bytes and big endian */
> + val = INV_ICM42607_INTF_CONFIG0_FIFO_COUNT_ENDIAN;
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
> + val, val);
regmap_set_bits();
> + if (ret)
> + return ret;
> +
> + /* Initialize FIFO in bypass mode */
> + return regmap_write(st->map, INV_ICM42607_REG_FIFO_CONFIG1,
> + INV_ICM42607_FIFO_CONFIG1_BYPASS);
> +}
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.h b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.h
> new file mode 100644
> index 000000000000..64a66c00a861
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.h
...
> +/* FIFO data packet */
> +struct inv_icm42607_fifo_sensor_data {
> + __be16 x;
> + __be16 y;
> + __be16 z;
> +} __packed;
Why packed? It will be anyway unless I'm missing something.
> +#define INV_ICM42607_FIFO_DATA_INVALID -32768
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index da04c820dab2..344071089042 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
...
> @@ -436,6 +449,8 @@ static int inv_icm42607_suspend(struct device *dev)
> static int inv_icm42607_resume(struct device *dev)
> {
> struct inv_icm42607_state *st = dev_get_drvdata(dev);
> + struct inv_icm42607_sensor_state *gyro_st = iio_priv(st->indio_gyro);
> + struct inv_icm42607_sensor_state *accel_st = iio_priv(st->indio_accel);
> struct device *accel_dev;
> bool wakeup;
> int ret;
> @@ -462,6 +477,16 @@ static int inv_icm42607_resume(struct device *dev)
> ret = inv_icm42607_set_pwr_mgmt0(st, st->suspended.gyro,
> st->suspended.accel,
> st->suspended.temp, NULL);
> + if (ret)
> + return ret;
> +
> + if (st->fifo.on) {
I've not checked, but if this doesn't get more complex you can do
if (!st->fifo.on)
return 0;
inv_....
return regmap_write();
> + inv_sensors_timestamp_reset(&gyro_st->ts);
> + inv_sensors_timestamp_reset(&accel_st->ts);
> + ret = regmap_write(st->map, INV_ICM42607_REG_FIFO_CONFIG1,
> + INV_ICM42607_FIFO_CONFIG1_MODE);
> + }
> +
> return ret;
> }
>
^ permalink raw reply
* Re: [PATCH] ARM: dts: bcm4709: fix bus range assignment
From: Rosen Penev @ 2026-04-13 19:28 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Florian Fainelli, Hauke Mehrtens, Rafał Miłecki,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, soc,
Arnd Bergmann, Broadcom internal kernel review list,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260413092148.3870746-1-arnd@kernel.org>
On Mon, Apr 13, 2026 at 2:21 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> The netgear r8000 dts file limits the bus range for the first host
> bridge to exclude bus 0, but the two devices on the first bus are
> explicitly assigned to bus 0, causing a build time warning:
>
> /home/arnd/arm-soc/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts:142.3-27: Warning (pci_device_bus_num): /axi@18000000/pcie@13000/pcie@0/pcie@0,0/pcie@1,0:bus-range: PCI bus number 0 out of range, expected (1 - 255)
> /home/arnd/arm-soc/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts:142.3-27: Warning (pci_device_bus_num): /axi@18000000/pcie@13000/pcie@0/pcie@0,0/pcie@2,0:bus-range: PCI bus number 0 out of range, expected (1 - 255)
>
> I could not find any reason why this is done in the first place, but
> this can be easily addressed by reassigning the two devices to
> bus 1, or by dropping the bus-range property in order to allow
> secondary bus 0 to be assigned.
>
> Assuming the bus-range is intentional, fix this by moving the
> devices to the first valid secondary bus number.
No, bus-range is not intentional. It should be removed instead.
>
> Fixes: 893faf67438c ("ARM: dts: BCM5301X: add root pcie bridges")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
> index d170c71cbd76..355be5014943 100644
> --- a/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
> +++ b/arch/arm/boot/dts/broadcom/bcm4709-netgear-r8000.dts
> @@ -147,7 +147,7 @@ pcie@0,0 {
>
> pcie@1,0 {
> device_type = "pci";
> - reg = <0x800 0 0 0 0>;
> + reg = <0x10800 0 0 0 0>;
>
> #address-cells = <3>;
> #size-cells = <2>;
> @@ -162,7 +162,7 @@ wifi@0,0 {
>
> pcie@2,0 {
> device_type = "pci";
> - reg = <0x1000 0 0 0 0>;
> + reg = <0x11000 0 0 0 0>;
>
> #address-cells = <3>;
> #size-cells = <2>;
> --
> 2.39.5
>
^ permalink raw reply
* Re: [PATCH V3 6/9] iio: imu: inv_icm42607: Add Accelerometer for icm42607
From: Jonathan Cameron @ 2026-04-13 19:32 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260330195853.392877-7-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:50 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add icm42607 accelerometer sensor for icm42607.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
A few more things below.
thanks
Jonathan
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> new file mode 100644
> index 000000000000..58754af31100
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> +
> +static const struct iio_enum inv_icm42607_accel_power_mode_enum = {
> + .items = inv_icm42607_accel_power_mode_items,
> + .num_items = ARRAY_SIZE(inv_icm42607_accel_power_mode_items),
> + .set = inv_icm42607_accel_power_mode_set,
> + .get = inv_icm42607_accel_power_mode_get,
> +};
> +
> +static const struct iio_chan_spec_ext_info inv_icm42607_accel_ext_infos[] = {
> + IIO_MOUNT_MATRIX(IIO_SHARED_BY_ALL, inv_icm42607_get_mount_matrix),
> + IIO_ENUM_AVAILABLE("power_mode", IIO_SHARED_BY_TYPE,
> + &inv_icm42607_accel_power_mode_enum),
> + IIO_ENUM("power_mode", IIO_SHARED_BY_TYPE,
> + &inv_icm42607_accel_power_mode_enum),
> + { },
No comma.
> +};
> +static int inv_icm42607_accel_read_odr(struct inv_icm42607_state *st,
> + int *val, int *val2)
> +{
> + unsigned int odr;
> + unsigned int i;
> +
> + odr = st->conf.accel.odr;
> +
> + for (i = 0; i < ARRAY_SIZE(inv_icm42607_accel_odr_conv); ++i) {
> + if (inv_icm42607_accel_odr_conv[i] == odr)
> + break;
> + }
> + if (i >= ARRAY_SIZE(inv_icm42607_accel_odr_conv))
> + return -EINVAL;
> +
> + *val = inv_icm42607_accel_odr[2 * i];
> + *val2 = inv_icm42607_accel_odr[2 * i + 1];
> +
> + return IIO_VAL_INT_PLUS_MICRO;
> +}
> +
> +static int inv_icm42607_accel_write_odr(struct iio_dev *indio_dev,
> + int val, int val2)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + struct inv_icm42607_sensor_state *accel_st = iio_priv(indio_dev);
> + struct inv_sensors_timestamp *ts = &accel_st->ts;
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int idx;
> + struct inv_icm42607_sensor_conf conf = INV_ICM42607_SENSOR_CONF_INIT;
> + int ret;
> +
> + for (idx = 0; idx < ARRAY_SIZE(inv_icm42607_accel_odr); idx += 2) {
> + if (val == inv_icm42607_accel_odr[idx] &&
> + val2 == inv_icm42607_accel_odr[idx + 1])
> + break;
> + }
> + if (idx >= ARRAY_SIZE(inv_icm42607_accel_odr))
> + return -EINVAL;
> +
> + conf.odr = inv_icm42607_accel_odr_conv[idx / 2];
> +
> + PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
> + if (PM_RUNTIME_ACQUIRE_ERR(&pm))
> + return -ENXIO;
> +
> + guard(mutex)(&st->lock);
> +
> + ret = inv_sensors_timestamp_update_odr(ts, inv_icm42607_odr_to_period(conf.odr),
> + iio_buffer_enabled(indio_dev));
> + if (ret)
> + return ret;
> +
> + ret = inv_icm42607_set_accel_conf(st, &conf, NULL);
> + if (ret)
> + return ret;
> +
> + inv_icm42607_buffer_update_fifo_period(st);
> + inv_icm42607_buffer_update_watermark(st);
> +
> + return ret;
> +}
> +
> +/*
> + * Calibration bias values, IIO range format int + micro.
> + * Not actually supported in the ICM-42607P registers.
> + */
> +static int inv_icm42607_accel_write_calibbias(struct inv_icm42607_state *st,
> + struct iio_chan_spec const *chan,
> + int val, int val2)
> +{
> + /* Not actually supported in the ICM-42607P registers */
> + return -EOPNOTSUPP;
> +}
> +
> +static int inv_icm42607_accel_read_calibbias(struct inv_icm42607_state *st,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2)
> +{
> + /* Not actually supported in the ICM-42607P registers */
> + return -EOPNOTSUPP;
> +}
> +
> +static int inv_icm42607_accel_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + s16 data;
> + int ret;
> +
> + switch (chan->type) {
> + case IIO_ACCEL:
> + break;
> + case IIO_TEMP:
> + return inv_icm42607_temp_read_raw(indio_dev, chan, val, val2, mask);
> + default:
> + return -EINVAL;
> + }
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (!iio_device_claim_direct(indio_dev))
> + return -EBUSY;
> + ret = inv_icm42607_accel_read_sensor(indio_dev, chan, &data);
> + iio_device_release_direct(indio_dev);
> + if (ret)
> + return ret;
> + *val = data;
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + return inv_icm42607_accel_read_scale(indio_dev, val, val2);
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + return inv_icm42607_accel_read_odr(st, val, val2);
> + case IIO_CHAN_INFO_CALIBBIAS:
> + return inv_icm42607_accel_read_calibbias(st, chan, val, val2);
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +int inv_icm42607_accel_parse_fifo(struct iio_dev *indio_dev)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + struct inv_icm42607_sensor_state *accel_st = iio_priv(indio_dev);
> + struct inv_sensors_timestamp *ts = &accel_st->ts;
> + ssize_t i, size;
> + unsigned int no;
> + const void *accel, *gyro, *timestamp;
> + const int8_t *temp;
> + unsigned int odr;
> + int64_t ts_val;
> + struct inv_icm42607_accel_buffer buffer = { };
> +
> + /* parse all fifo packets */
> + for (i = 0, no = 0; i < st->fifo.count; i += size, ++no) {
> + size = inv_icm42607_fifo_decode_packet(&st->fifo.data[i],
> + &accel, &gyro, &temp, ×tamp, &odr);
> + /* quit if error or FIFO is empty */
> + if (size <= 0)
> + return size;
> +
> + /* skip packet if no accel data or data is invalid */
> + if (accel == NULL || !inv_icm42607_fifo_is_data_valid(accel))
> + continue;
> +
> + /* update odr */
> + if (odr & INV_ICM42607_SENSOR_ACCEL) {
> + inv_sensors_timestamp_apply_odr(ts, st->fifo.period,
> + st->fifo.nb.total, no);
> + }
> +
> + memcpy(&buffer.accel, accel, sizeof(buffer.accel));
> + /* convert 8 bits FIFO temperature in high resolution format */
> + buffer.temp = temp ? (*temp * 64) : 0;
> + ts_val = inv_sensors_timestamp_pop(ts);
> + iio_push_to_buffers_with_timestamp(indio_dev, &buffer, ts_val);
For new code, always use iio_push_to_buffers_with_ts()
This one is going away in near future.
> + }
> +
> + return 0;
> +}
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index 735a262dc103..62a1371b0c4a 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +int inv_icm42607_set_accel_conf(struct inv_icm42607_state *st,
> + struct inv_icm42607_sensor_conf *conf,
> + unsigned int *sleep_ms)
> +{
> + struct inv_icm42607_sensor_conf *oldconf = &st->conf.accel;
> + unsigned int val;
> + int ret;
> +
> + if (conf->mode < 0)
> + conf->mode = oldconf->mode;
> + if (conf->fs < 0)
> + conf->fs = oldconf->fs;
> + if (conf->odr < 0)
> + conf->odr = oldconf->odr;
> + if (conf->filter < 0)
> + conf->filter = oldconf->filter;
> +
> + if (conf->fs != oldconf->fs || conf->odr != oldconf->odr) {
> + val = INV_ICM42607_ACCEL_CONFIG0_FS_SEL(conf->fs) |
> + INV_ICM42607_ACCEL_CONFIG0_ODR(conf->odr);
Another indent case that needs fixing.
> + ret = regmap_write(st->map, INV_ICM42607_REG_ACCEL_CONFIG0, val);
> + if (ret)
> + return ret;
> + oldconf->fs = conf->fs;
> + oldconf->odr = conf->odr;
> + }
> +
> + if (conf->filter != oldconf->filter) {
> + if (conf->mode == INV_ICM42607_SENSOR_MODE_LOW_POWER) {
> + val = INV_ICM42607_ACCEL_CONFIG1_AVG(conf->filter);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_ACCEL_CONFIG1,
> + INV_ICM42607_ACCEL_CONFIG1_AVG_MASK, val);
> + } else {
> + val = INV_ICM42607_ACCEL_CONFIG1_FILTER(conf->filter);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_ACCEL_CONFIG1,
> + INV_ICM42607_ACCEL_CONFIG1_FILTER_MASK, val);
> + }
> + if (ret)
> + return ret;
> + oldconf->filter = conf->filter;
> + }
> +
> + return inv_icm42607_set_pwr_mgmt0(st, st->conf.gyro.mode, conf->mode,
> + st->conf.temp_en, sleep_ms);
> +}
^ permalink raw reply
* Re: [PATCH RESEND] arm64: dts: apple: fix spelling error
From: Sven Peter @ 2026-04-13 19:36 UTC (permalink / raw)
To: Axel Flordal
Cc: Janne Grunau, asahi, Neal Gompa, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-kernel, devicetree, linux-arm-kernel
In-Reply-To: <2338500.vFx2qVVIhK@fedora>
On 08.04.26 09:21, Axel Flordal wrote:
> Change "configiguration" to "configuration".
>
> Reviewed-by: Neal Gompa <neal@gompa.dev>
> Signed-off-by: Axel Flordal <axel@flordal.net>
> ---
> Original patch: https://lore.kernel.org/asahi/CAEg-Je-KwNNGoi3mpPeNq3Jmtzj_5seuj1Qeh2_1dt994iCJSA@mail.gmail.com/T/#t
> If this is unwanted I of course won't send again.
No, this is perfectly fine. I just totally missed the patch, sorry about
that.
I'm going to pick it up after the merge window since it doesn't fix an
urgent bug!
Sven
^ permalink raw reply
* Re: [PATCH V3 7/9] iio: imu: inv_icm42607: Add Interrupt and Wake on Movement for icm42607
From: Jonathan Cameron @ 2026-04-13 19:37 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260330195853.392877-8-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:51 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add support for wake on movement for the icm42607 driver.
>
> At this point the driver is usable as an accelerometer/temperature
> driver, so add the necessary Makefile and Kconfig changes as well.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>l
A few comments on this one.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> index 56bb09e2c304..f5f1b5fea183 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
...
>
> struct iio_dev *inv_icm42607_accel_init(struct inv_icm42607_state *st)
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index 62a1371b0c4a..4ac3af52c1b8 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +
> +int inv_icm42607_disable_wom(struct inv_icm42607_state *st)
> +{
> + int ret;
> +
> + /* disable WoM interrupt */
> + ret = regmap_clear_bits(st->map, INV_ICM42607_REG_INT_SOURCE1,
> + INV_ICM42607_INT_SOURCE1_WOM_INT1_EN);
> + if (ret)
> + return ret;
> +
> + /* disable WoM hardware */
> + return regmap_clear_bits(st->map, INV_ICM42607_REG_WOM_CONFIG,
> + INV_ICM42607_WOM_CONFIG_EN);
regmap_set_bits()
> +}
> +
> +
As below.
> int inv_icm42607_debugfs_reg(struct iio_dev *indio_dev, unsigned int reg,
> +
> +/**
> + * inv_icm42607_irq_init() - initialize int pin and interrupt handler
> + * @st: driver internal state
> + * @irq: irq number
> + * @irq_type: irq trigger type
> + * @open_drain: true if irq is open drain, false for push-pull
> + *
> + * Returns 0 on success, a negative error code otherwise.
> + */
> +static int inv_icm42607_irq_init(struct inv_icm42607_state *st, int irq,
> + int irq_type, bool open_drain)
> +{
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int val = 0;
> + int ret;
> +
> + switch (irq_type) {
> + case IRQF_TRIGGER_RISING:
> + case IRQF_TRIGGER_HIGH:
> + val = INV_ICM42607_INT_CONFIG_INT1_ACTIVE_HIGH;
> + break;
> + default:
> + val = INV_ICM42607_INT_CONFIG_INT1_ACTIVE_LOW;
> + break;
> + }
> +
> + switch (irq_type) {
> + case IRQF_TRIGGER_LOW:
> + case IRQF_TRIGGER_HIGH:
> + val |= INV_ICM42607_INT_CONFIG_INT1_LATCHED;
> + break;
> + default:
> + break;
> + }
> +
> + if (!open_drain)
> + val |= INV_ICM42607_INT_CONFIG_INT1_PUSH_PULL;
> +
> + ret = regmap_write(st->map, INV_ICM42607_REG_INT_CONFIG, val);
> + if (ret)
> + return ret;
> +
> + irq_type |= IRQF_ONESHOT;
> + return devm_request_threaded_irq(dev, irq, inv_icm42607_irq_timestamp,
> + inv_icm42607_irq_handler, irq_type,
> + st->name, st);
> +}
> +
> +
Trivial but single line is always enough (in IIO anyway)
> static int inv_icm42607_enable_vddio_reg(struct inv_icm42607_state *st)
^ permalink raw reply
* Re: [PATCH V3 8/9] iio: imu: inv_icm42607: Add Gyroscope to icm42607
From: Jonathan Cameron @ 2026-04-13 19:39 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260330195853.392877-9-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:52 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add gyroscope functions to the icm42607 driver.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
One very minor comment.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> new file mode 100644
> index 000000000000..80473c07c6a4
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> +
> +static const struct iio_chan_spec_ext_info inv_icm42607_gyro_ext_infos[] = {
> + IIO_MOUNT_MATRIX(IIO_SHARED_BY_ALL, inv_icm42607_get_mount_matrix),
> + {},
{ }
> +};
^ permalink raw reply
* Re: Phandles
From: Kyle Bonnici @ 2026-04-13 20:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herve Codina, devicetree-compiler@vger.kernel.org, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree@vger.kernel.org
In-Reply-To: <c0b93231-9337-42f9-83c3-e657e5f017ec@kernel.org>
> The "&foo" used in the property defines that it is phandle, no?
yes &foo is a phandle and must resolve to some node.
>
>>
>>> You asked why phandle has to be the first entry in phandle-value type? I
>>> responded that DT spec makes it.
>>
>> Which section in DTS 0.4 spec?
>
> 2.2.4.2. Property Values
> "That number is used for the value of properties with a phandle value type.
>
> The properties having phandle value must have proper, well, value :)
For a property to have type <phandle> it must either be of that types as
Defined dts spec 0.4 or a binding mandates that type.
>
>>
>>> We discuss DTC here, yes? Whether it has or has not a bug? Please help
>>> me to understand the topic. Why would we care about Zephyr's
>>> implementation? It's Zephyr's problem and I am not a Zephyr developer. I
>>> am not saying that it is not important, just saying that I am not the
>>> audience to discuss it.
>>
>> I am arguing that the DTC Spec 0.4 does NOT mandate any of these any of these
>> “cooling_device”, “dmas”, “hwlocks”, “io_channels”, “iommus”, “mboxes”,
>> “msi_parent”, “mux_controls”, “phys”, “power_domains”, “pwms”, “resets”,
>> “clocks”, “sound_dai” and “thermal_sensors”
>> must follow <phandle cell …>.
>>
>> This is only mandated by the dt-schema as far as I understand, that is a used by
>> Linux, but not Zephyr and the DTC Making the assumption that this is true for
>> all systems
>
> No, dtschema is irrelevant here and DTC was validating it since 2017, so
> years before dtschema.
My point it that the DTC is overreaching IMO and validating property using
WARNING_PROPERTY_PHANDLE_CELLS that are not mandated by the
DTS Spec 0.4. This is leaking warnings into Zephyr and can lead a user to
believe, that Zephyr also interprets that property in the same way as the DTC
>
> DT spec indeed does not mandate it as pwms, but replacing that check in
> DTC with something only validating phandles would not solve your
> problem. Your 'pwm' is a phandle-value type, because you use phandle
> there, and still is has wrong value.
Do not take my code in the example too critically, that is just code to show
how to generate the warnings.
My point has been that in zephyr non of these properties should generate
Warnings generated by WARNING_PROPERTY_PHANDLE_CELLS
^ permalink raw reply
* Re: [PATCH v21 2/6] pwm: driver for qualcomm ipq6018 pwm block
From: Uwe Kleine-König @ 2026-04-13 20:27 UTC (permalink / raw)
To: George Moussalem
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, linux-arm-msm, linux-pwm, devicetree, linux-kernel,
Devi Priya
In-Reply-To: <DS7PR19MB888389B41E784995F064EE0B9D242@DS7PR19MB8883.namprd19.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
Hello George,
On Mon, Apr 13, 2026 at 11:17:18PM +0400, George Moussalem wrote:
> On 4/13/2026 1:35 PM, Uwe Kleine-König wrote:
> > On Mon, Apr 06, 2026 at 10:24:39PM +0200, George Moussalem via B4 Relay wrote:
> >> From: Devi Priya <quic_devipriy@quicinc.com>
> >>
> >> Driver for the PWM block in Qualcomm IPQ6018 line of SoCs. Based on
> >> driver from downstream Codeaurora kernel tree. Removed support for older
> >> (V1) variants because I have no access to that hardware.
> >>
> >> Tested on IPQ5018 and IPQ6010 based hardware.
> >>
> >> Co-developed-by: Baruch Siach <baruch.siach@siklu.com>
> >> Signed-off-by: Baruch Siach <baruch.siach@siklu.com>
> >> Signed-off-by: Devi Priya <quic_devipriy@quicinc.com>
> >> Reviewed-by: Bjorn Andersson <andersson@kernel.org>
> >> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> >
> > I have a few remaining nitpicks. If you're ok I'll squash the following
> > diff into this patch and apply it:
>
> Just applied it to my own branch, all okay from my side. Thanks for your
> guidance and support!
I did that and added a ; to make the compiler happy. It is now contained
at
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/for-nexxt
as 7.2-rc1 material. I'll push it into next after the merge window
closes in ~ two weeks.
Best regards and thanks for work
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 01/10] dt-bindings: clock: qcom,rpmcc: add msm8960 compatible
From: Antony Kurniawan Soemardi @ 2026-04-13 18:32 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Konrad Dybcio
Cc: Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel, phone-devel, Rudraksha Gupta,
Antony Kurniawan Soemardi
In-Reply-To: <20260414-msm8960-wifi-v1-0-01c081e54610@smankusors.com>
Document the qcom,rpmcc-msm8960 compatible.
The MSM8960 platform shares the same RPM clock definitions as
APQ8064, so extend the existing conditional schema to treat
qcom,rpmcc-msm8960 the same as qcom,rpmcc-apq8064.
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
---
Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
index ab97d4b7dba8bc8d38903b399d2bd4bda087db8a..f84d08199e47f45ecb176d350eeb7df8c3ff506b 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
@@ -36,6 +36,7 @@ properties:
- qcom,rpmcc-msm8937
- qcom,rpmcc-msm8940
- qcom,rpmcc-msm8953
+ - qcom,rpmcc-msm8960
- qcom,rpmcc-msm8974
- qcom,rpmcc-msm8976
- qcom,rpmcc-msm8992
@@ -90,7 +91,9 @@ allOf:
properties:
compatible:
contains:
- const: qcom,rpmcc-apq8064
+ enum:
+ - qcom,rpmcc-apq8064
+ - qcom,rpmcc-msm8960
then:
properties:
clocks:
--
2.34.1
^ permalink raw reply related
* [PATCH] arm64: dts: rockchip: Enable the NPU on rk3588-rock-5-itx
From: Sten-Silver Ots @ 2026-04-13 21:52 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sten-Silver Ots, FUKAUMI Naoki, Torsten Duwe, Dmitry Baryshkov,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
This commit enables the NPU on Radxa Rock 5 ITX board.
The regulator vdd_npu_s0 was already in place and since the NPUs
power domain supply is now described remove the always-on property
from the regulator.
Signed-off-by: Sten-Silver Ots <stensilver@gmail.com>
---
.../boot/dts/rockchip/rk3588-rock-5-itx.dts | 35 ++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
index de154adb1497..d3ab6c68a60b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
@@ -421,7 +421,6 @@ vdd_npu_s0: regulator@42 {
reg = <0x42>;
fcs,suspend-voltage-selector = <1>;
regulator-name = "vdd_npu_s0";
- regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <550000>;
regulator-max-microvolt = <950000>;
@@ -683,6 +682,10 @@ &pd_gpu {
domain-supply = <&vdd_gpu_s0>;
};
+&pd_npu {
+ domain-supply = <&vdd_npu_s0>;
+};
+
&pinctrl {
hym8563 {
rtc_int: rtc-int {
@@ -802,6 +805,36 @@ dp1_hpd: dp1-hpd {
};
};
+&rknn_core_0 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_core_1 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_core_2 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_mmu_0 {
+ status = "okay";
+};
+
+&rknn_mmu_1 {
+ status = "okay";
+};
+
+&rknn_mmu_2 {
+ status = "okay";
+};
+
&pwm14 {
pinctrl-names = "default";
pinctrl-0 = <&pwm14m1_pins>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] of/platform: Don't include reserved memory compatibles that aren't needed
From: Rob Herring @ 2026-04-13 22:00 UTC (permalink / raw)
To: Daniel Palmer; +Cc: Krzysztof Kozlowski, saravanak, devicetree, linux-kernel
In-Reply-To: <CAFr9PX=F3Qvyo25HwB139Jk4_+5Rw50GBg=3BJb6bcsk58tL=Q@mail.gmail.com>
On Sat, Apr 04, 2026 at 11:22:32AM +0900, Daniel Palmer wrote:
> Hi Krzysztof,
>
> On Wed, 1 Apr 2026 at 19:54, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > On Wed, Apr 01, 2026 at 06:57:35AM +0900, Daniel Palmer wrote:
> > > There are a number of very platform specific compatibles for reserved
> > > memory that the vast majority of people don't need and they waste
> > > 196/200 bytes each.
> >
> > We don't want #ifdefs in the code because they are more difficult to
> > maintain and review. Following your approach we would need to add such
> > ifdefs in multiple other places, so I am not convinced it is worth.
>
> I sort of disagree here. At the moment these compatibles are not
> coupled to the code that uses them at all.
> If that code gets deleted or moved for some reason, the Kconfig symbol
> they belong to will disappear but since these compatibles aren't
> coupled to them and are in a file on the other side of the kernel
> it'll be easy to miss them.
> If they are wrapped in something that links them back to where they
> are used grep or whatever indexer can spot them.
>
> > And this file should not be having different rules than rest of drivers.
>
> There are other places with #ifdefs in match tables. It would be nice
> if there was a nicer way to do it in C but there doesn't seem to be.
> It would be nice if vendor specific stuff wasn't in the core code but
> I don't see a nice way of fixing that either.
> And if you want to see some of the more crazy examples of match tables
> take a look here:
> https://elixir.bootlin.com/linux/v7.0-rc6/source/drivers/cpufreq/cpufreq-dt-platdev.c
>
> Since these matches are not the size of the compatible string but
> actually 200 bytes on 64 bit machines the two megatables in that
> driver will consume about 40K. It doesn't seem like much but DT is
> being used by systems that have megabytes of RAM like a RISC-V
> softcore on an FPGA. I think they might prefer to have a 40K of usable
> memory over 40K of tables that don't contain any values that are
> actually used on their machine ever... and it could be cleaned up
> easily by wrapping each of the vendor specific chunks in the Kconfig
> symbol for their platform.
40K is more convincing, but the case here isn't 40K.
Maybe we would be better off just creating a device for every reserved
memory node with a compatible which is what we do for the rest of the
DT. Then there's never any of these strings. It would only cost memory
if you have nodes with compatibles and you don't want a device created.
Looks like the only ones we have are the 2 NVIDIA ones.
Rob
^ 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