* [PATCH v6 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
From: David Heidelberg via B4 Relay @ 2026-07-20 10:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Konrad Dybcio, Petr Hodina, Richard Acayan, linux-arm-msm,
devicetree, linux-kernel, phone-devel, David Heidelberg
In-Reply-To: <20260720-pixel3-camera-v6-0-afe419bef476@ixit.cz>
From: David Heidelberg <david@ixit.cz>
The Pixel 3 features two front-facing Sony IMX355 sensors with
different focal lengths (standard and wide-angle).
Sensors are connected via CSIPHY port 1 and 2 and controlled over CCI
I2C1, using MCLK2 as the clock source.
This enables support for the dual front camera configuration.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 171 ++++++++++++++++++++-
1 file changed, 170 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
index 9368fd6b87515..267dcd6eddaee 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
@@ -1,16 +1,17 @@
// SPDX-License-Identifier: GPL-2.0-only
/dts-v1/;
#include <dt-bindings/arm/qcom,ids.h>
#include <dt-bindings/dma/qcom-gpi.h>
#include <dt-bindings/input/linux-event-codes.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "sdm845.dtsi"
#include "pm8998.dtsi"
#include "pmi8998.dtsi"
/delete-node/ &mpss_region;
/delete-node/ &venus_mem;
@@ -127,16 +128,48 @@ vreg_s4a_1p8: regulator-vreg-s4a-1p8 {
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-boot-on;
vin-supply = <&vph_pwr>;
};
+ camera_front_avdd: regulator-front-cam-avdd {
+ compatible = "regulator-fixed";
+ regulator-name = "front_cam_avdd";
+
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+
+ gpios = <&tlmm 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam_front_avdd_default>;
+ pinctrl-names = "default";
+
+ vin-supply = <&vreg_bob>;
+ };
+
+ camera_front_aux_avdd: regulator-front-cam-aux-avdd {
+ compatible = "regulator-fixed";
+ regulator-name = "front_cam_aux_avdd";
+
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <2800000>;
+
+ gpios = <&tlmm 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam_front_aux_avdd_default>;
+ pinctrl-names = "default";
+
+ vin-supply = <&vreg_bob>;
+ };
+
wcn3990-pmu {
compatible = "qcom,wcn3990-pmu";
vddio-supply = <&vreg_s4a_1p8>;
vddxo-supply = <&vreg_l7a_1p8>;
vddrf-supply = <&vreg_l17a_1p3>;
vddch0-supply = <&vreg_l25a_3p3>;
@@ -314,16 +347,21 @@ vreg_l28a_3p0: ldo28 {
regulator-initial-mode = <RPMH_REGULATOR_MODE_LPM>;
regulator-boot-on;
/*
* We can't properly bring the panel back if it gets turned off
* so keep it's regulators always on for now.
*/
regulator-always-on;
};
+
+ vreg_lvs1_1p8: lvs1 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
};
regulators-1 {
compatible = "qcom,pmi8998-rpmh-regulators";
qcom,pmic-id = "b";
vdd-bob-supply = <&vph_pwr>;
@@ -346,24 +384,127 @@ regulators-2 {
vreg_s3c_0p6: smps3 {
regulator-min-microvolt = <600000>;
regulator-max-microvolt = <600000>;
};
};
};
+&camss {
+ vdda-phy-supply = <&vreg_l1a_0p875>;
+ vdda-pll-supply = <&vreg_l26a_1p2>;
+
+ /*
+ * MCLK2 (GPIO15) is shared between both front camera sensors.
+ * The clock is generated by CAMCC, therefore the pin is
+ * configured here rather than in individual sensor nodes.
+ */
+ pinctrl-0 = <&cam_mclk2_default>;
+ pinctrl-1 = <&cam_mclk2_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ camss_endpoint1: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&cam_aux_front_endpoint>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ camss_endpoint2: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&cam_front_endpoint>;
+ };
+ };
+ };
+};
+
+&cci0_sleep {
+ /* bus has external pull-up */
+ /delete-property/ bias-pull-down;
+ bias-disable;
+};
+
&cci {
status = "okay";
};
&cci_i2c1 {
/* actuator @0c */
- /* front camera, imx355 @1a */
+ front_cam: camera@10 {
+ compatible = "sony,imx355";
+ reg = <0x10>;
+
+ clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
+ assigned-clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
+ assigned-clock-rates = <24000000>;
+
+ reset-gpios = <&tlmm 21 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&camera_front_avdd>;
+ dvdd-supply = <&vreg_s3a_1p35>;
+ dovdd-supply = <&vreg_lvs1_1p8>;
+
+ pinctrl-0 = <&cam_front_reset_default>;
+ pinctrl-names = "default";
+
+ rotation = <270>;
+ orientation = <0>;
+
+ port {
+ cam_front_endpoint: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <360000000>;
+ remote-endpoint = <&camss_endpoint2>;
+ };
+ };
+ };
+
+ front_aux_cam: camera@1a {
+ compatible = "sony,imx355";
+ reg = <0x1a>;
+
+ clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
+ assigned-clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
+ assigned-clock-rates = <24000000>;
+
+ reset-gpios = <&tlmm 9 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&camera_front_aux_avdd>;
+ dvdd-supply = <&vreg_s3a_1p35>;
+ dovdd-supply = <&vreg_lvs1_1p8>;
+
+ pinctrl-0 = <&cam_front_aux_reset_default>;
+ pinctrl-names = "default";
+
+ rotation = <270>;
+ orientation = <0>;
+
+ port {
+ cam_aux_front_endpoint: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <360000000>;
+ remote-endpoint = <&camss_endpoint1>;
+ };
+ };
+ };
/* eeprom @50, at24 driver says 8K */
};
&cdsp_pas {
firmware-name = "qcom/sdm845/Google/blueline/cdsp.mbn";
status = "okay";
@@ -485,16 +626,44 @@ nfc_int_default: nfc-int-default-state {
nfc_enable_default: nfc-enable-default-state {
pins = "gpio25", "gpio79";
function = "gpio";
drive-strength = <2>;
bias-pull-down;
};
+ cam_front_avdd_default: cam-avdd-default-state {
+ pins = "gpio8";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_front_aux_reset_default: cam-front-aux-reset-default-state {
+ pins = "gpio9";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_front_aux_avdd_default: cam-avdd-aux-default-state {
+ pins = "gpio14";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_front_reset_default: cam-front-reset-default-state {
+ pins = "gpio21";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
touchscreen_reset: ts-reset-state {
pins = "gpio99";
function = "gpio";
drive-strength = <8>;
bias-pull-up;
};
touchscreen_pins: ts-pins-gpio-state {
--
2.53.0
^ permalink raw reply related
* [PATCH v6 0/2] Add initial dual front camera and rear flash support for Pixel 3 / 3 XL
From: David Heidelberg via B4 Relay @ 2026-07-20 10:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Konrad Dybcio, Petr Hodina, Richard Acayan, linux-arm-msm,
devicetree, linux-kernel, phone-devel, David Heidelberg
Describe the dual front-facing IMX355 sensors (standard and wide)
and enable the PMI8998 flash LED with hardware-accurate limits.
This brings up the basic camera topology and flash support in DT.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
Changes in v6:
- Remove forgotten bias-pull-down property from cci0_sleep node.
(dtbs_check)
- ..-regulator -> regulator-.. (Konrad)
- Rename camera -pin to -state and remove _pin from the labes. (Konrad,
dtbs_check)
- Link to v5: https://lore.kernel.org/r/20260719-pixel3-camera-v5-0-99593f1bd8ec@ixit.cz
Changes in v5:
- Added function-enumarator to flash LEDs. (Sashiko)
- Dropped l22a regulator needed only for NFOV actuator. (Sashiko)
- Dropped vdda-csi[0-2]-supply, as it was unused. (Sashiko).
- Added previously omited cam_mclk2_sleep sleep state.
- Link to v4: https://lore.kernel.org/r/20260719-pixel3-camera-v4-0-48cab1236852@ixit.cz
Changes in v4:
- Use 24 MHz ext clock for the cameras, as the downstream does, since
the upstream driver can now support it.
- Added additional LED, as the phone contains two separately controlled
white LEDs flash (upper and bottom, in one module).
- Increase flash-max-microamp, as I took wrong "flash" from the
downstream sources and dropped Dmitry R-b.
- Address formatting issues. (Konrad)
- Link to v3: https://lore.kernel.org/r/20260412-pixel3-camera-v3-0-e26b090a6110@ixit.cz
Changes in v3:
- Dropped cam_vio label. (Dmitry)
- Move the MCLK2 pinctrl from cameras to common camss. (Dmitry)
- Link to v2: https://lore.kernel.org/r/20260411-pixel3-camera-v2-0-41b889abb14c@ixit.cz
Changes in v2:
- leds.h include escaped the initial submission. Fixed.
- Link to v1: https://lore.kernel.org/r/20260411-pixel3-camera-v1-0-2757606515b6@ixit.cz
---
David Heidelberg (2):
arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs
arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 198 ++++++++++++++++++++-
1 file changed, 197 insertions(+), 1 deletion(-)
---
base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
change-id: 20260315-pixel3-camera-a9989bf589ee
Best regards,
--
David Heidelberg <david@ixit.cz>
^ permalink raw reply
* [PATCH v6 2/2] arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs
From: David Heidelberg via B4 Relay @ 2026-07-20 10:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Konrad Dybcio, Petr Hodina, Richard Acayan, linux-arm-msm,
devicetree, linux-kernel, phone-devel, David Heidelberg
In-Reply-To: <20260720-pixel3-camera-v6-0-afe419bef476@ixit.cz>
From: David Heidelberg <david@ixit.cz>
Enable the PMI8998 flash LED block and describe two white flash LEDs
used for the rear camera.
Configure the LED in flash mode with hardware limits matching the
original device configuration, including maximum current and timeout.
In contrary to downstream, we can control both LEDs separately.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
index 267dcd6eddaee..c8699f72cfecf 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
@@ -1,16 +1,17 @@
// SPDX-License-Identifier: GPL-2.0-only
/dts-v1/;
#include <dt-bindings/arm/qcom,ids.h>
#include <dt-bindings/dma/qcom-gpi.h>
#include <dt-bindings/input/linux-event-codes.h>
#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include "sdm845.dtsi"
#include "pm8998.dtsi"
#include "pmi8998.dtsi"
/delete-node/ &mpss_region;
@@ -590,16 +591,42 @@ &pm8998_resin {
};
&pmi8998_charger {
monitored-battery = <&battery>;
status = "okay";
};
+&pmi8998_flash {
+ status = "okay";
+
+ /* upper flash module part */
+ led-0 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <1>;
+ led-max-microamp = <500000>;
+ flash-max-microamp = <1500000>;
+ flash-max-timeout-us = <1280000>;
+ function-enumerator = <0>;
+ };
+
+ /* lower flash module part */
+ led-1 {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ led-sources = <2>;
+ led-max-microamp = <500000>;
+ flash-max-microamp = <1500000>;
+ flash-max-timeout-us = <1280000>;
+ function-enumerator = <1>;
+ };
+};
+
&qupv3_id_0 {
status = "okay";
};
&qupv3_id_1 {
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/8] dt-bindings: clock: renesas: Split out RZ/T2H CPG binding
From: Krzysztof Kozlowski @ 2026-07-20 10:53 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Wim Van Sebroeck,
Guenter Roeck, Magnus Damm, linux-renesas-soc, linux-clk,
devicetree, linux-kernel, linux-watchdog, Prabhakar, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <CA+V-a8tfCL58j2TvoO1VhhDAZf=8LB89R4O0SycLghYGf7Rr4w@mail.gmail.com>
On 20/07/2026 12:50, Lad, Prabhakar wrote:
> Hi Krzysztof,
>
> On Mon, Jul 20, 2026 at 6:55 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On Thu, Jul 16, 2026 at 01:34:27PM +0100, Prabhakar wrote:
>>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>>>
>>> Move the RZ/T2H and RZ/N2H clock controller bindings from the generic
>>> renesas,cpg-mssr.yaml schema into a dedicated binding.
>>>
>>> Unlike the traditional Renesas CPG/MSSR block, the RZ/T2H and RZ/N2H
>>> system controller integrates additional functionality beyond clock and
>>> module-stop control, including reset control, clock monitor support,
>>> write-protection registers and other system management features.
>>
>> Nothing of above differences got reflected in the code, so I do not
>> understand this reasoning. Binding is exactly the same as the old one.
>>
> A syscon regmap is implemented [0] as part of the RZ/T2H CPG driver.
> Since the RZ/T2H clock driver uses this syscon wrapper, a function
> pointer is implemented to handle the RZ/T2H-specific configuration.
>
> Also, as the initial implementation used separate device tree nodes,
> Geert suggested splitting this binding schema off into a dedicated
> file [1].
>
I still miss the difference. Can you point me (can be short diff) to
actual difference in this binding?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 0/3] regulator: qcom_smd-regulator: fix PM2250 supply parent mappings
From: Rakesh Kota @ 2026-07-20 10:55 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, devicetree, Kamal Wadhwa,
jishnu.prakash, Rakesh Kota
The rpm_pm2250_regulators table hardcodes supply parent name strings
in the regulator descriptor, causing the Linux regulator framework to
vote on parent supplies from APPS unnecessarily. On RPM-based platforms,
parent-child supply relationships are managed entirely by RPM firmware.
Fix this by setting supply names to NULL in the driver descriptor, and
correct the supply parent mappings in the qrb2210 and Shikra DTS files
to match the actual PM4125 pin connections.
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
Changes in v2:
- Fix the pm4125_s1 regulator min and max voltages.
- Add missing parent supply for pm4125_s1 and pm4125_s2.
- Link to v1: https://patch.msgid.link/20260717-pm2250-fix-supply-parent-v1-0-a6213a42a3b5@oss.qualcomm.com
---
Rakesh Kota (3):
regulator: qcom_smd-regulator: fix PM2250 supply parent mappings
arm64: dts: qcom: qrb2210: fix PM4125 regulator supply parent mappings
arm64: dts: qcom: shikra: add vph_pwr and fix supply parent mappings
arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 13 ++++--
arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 13 ++++--
arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi | 33 ++++++++++++++
drivers/regulator/qcom_smd-regulator.c | 52 +++++++++++-----------
4 files changed, 79 insertions(+), 32 deletions(-)
---
base-commit: 0718283ab28bc3907e10b61a6b4be6fefa1cbb2f
change-id: 20260714-pm2250-fix-supply-parent-b91bed1f65c6
Best regards,
--
Rakesh Kota <rakesh.kota@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v2 1/3] regulator: qcom_smd-regulator: fix PM2250 supply parent mappings
From: Rakesh Kota @ 2026-07-20 10:55 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, devicetree, Kamal Wadhwa,
jishnu.prakash, Rakesh Kota
In-Reply-To: <20260720-pm2250-fix-supply-parent-v2-0-60ca47031b50@oss.qualcomm.com>
The rpm_pm2250_regulators table hardcodes supply parent name strings
in the regulator descriptor, causing the Linux regulator framework to
look up and vote on parent supplies from APPS. This is both unnecessary
and incorrect for RPM-managed regulators.
On RPM-based platforms, the parent-child supply relationships are
managed entirely by the RPM firmware. The RPM ensures that parent
rails are maintained at the correct voltage with appropriate headroom,
based on all active child rail votes across all subsystems. No explicit
parent supply vote from APPS is required.
Furthermore, the supply rail connections to PMIC pins are fixed in
hardware. The previously hardcoded supply name strings were inaccurate
and did not reflect the actual physical pin connections on PM2250-based
platforms. The correct supply relationships are to be described in the
Device Tree, not hardcoded in the driver.
To avoid unnecessary APPS-side parent supply access while still
allowing correct hardware topology to be described in DT, set the
supply name field to NULL in the regulator descriptor.
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
drivers/regulator/qcom_smd-regulator.c | 52 +++++++++++++++++-----------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/regulator/qcom_smd-regulator.c b/drivers/regulator/qcom_smd-regulator.c
index 23ed594b574e..aed01f18af4a 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -800,32 +800,32 @@ static const struct rpm_regulator_data rpm_mp5496_regulators[] = {
};
static const struct rpm_regulator_data rpm_pm2250_regulators[] = {
- { "s1", QCOM_SMD_RPM_SMPA, 1, &pm2250_lvftsmps, "vdd_s1" },
- { "s2", QCOM_SMD_RPM_SMPA, 2, &pm2250_lvftsmps, "vdd_s2" },
- { "s3", QCOM_SMD_RPM_SMPA, 3, &pm2250_lvftsmps, "vdd_s3" },
- { "s4", QCOM_SMD_RPM_SMPA, 4, &pm2250_ftsmps, "vdd_s4" },
- { "l1", QCOM_SMD_RPM_LDOA, 1, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l2", QCOM_SMD_RPM_LDOA, 2, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l3", QCOM_SMD_RPM_LDOA, 3, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l4", QCOM_SMD_RPM_LDOA, 4, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
- { "l5", QCOM_SMD_RPM_LDOA, 5, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l6", QCOM_SMD_RPM_LDOA, 6, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l7", QCOM_SMD_RPM_LDOA, 7, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l8", QCOM_SMD_RPM_LDOA, 8, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l9", QCOM_SMD_RPM_LDOA, 9, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l10", QCOM_SMD_RPM_LDOA, 10, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l11", QCOM_SMD_RPM_LDOA, 11, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l12", QCOM_SMD_RPM_LDOA, 12, &pm660_nldo660, "vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12" },
- { "l13", QCOM_SMD_RPM_LDOA, 13, &pm660_ht_lvpldo, "vdd_l13_l14_l15_l16" },
- { "l14", QCOM_SMD_RPM_LDOA, 14, &pm660_ht_lvpldo, "vdd_l13_l14_l15_l16" },
- { "l15", QCOM_SMD_RPM_LDOA, 15, &pm660_ht_lvpldo, "vdd_l13_l14_l15_l16" },
- { "l16", QCOM_SMD_RPM_LDOA, 16, &pm660_ht_lvpldo, "vdd_l13_l14_l15_l16" },
- { "l17", QCOM_SMD_RPM_LDOA, 17, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
- { "l18", QCOM_SMD_RPM_LDOA, 18, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
- { "l19", QCOM_SMD_RPM_LDOA, 19, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
- { "l20", QCOM_SMD_RPM_LDOA, 20, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
- { "l21", QCOM_SMD_RPM_LDOA, 21, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
- { "l22", QCOM_SMD_RPM_LDOA, 22, &pm660_pldo660, "vdd_l4_l17_l18_l19_l20_l21_l22" },
+ { "s1", QCOM_SMD_RPM_SMPA, 1, &pm2250_lvftsmps, NULL },
+ { "s2", QCOM_SMD_RPM_SMPA, 2, &pm2250_lvftsmps, NULL },
+ { "s3", QCOM_SMD_RPM_SMPA, 3, &pm2250_lvftsmps, NULL },
+ { "s4", QCOM_SMD_RPM_SMPA, 4, &pm2250_ftsmps, NULL },
+ { "l1", QCOM_SMD_RPM_LDOA, 1, &pm660_nldo660, NULL },
+ { "l2", QCOM_SMD_RPM_LDOA, 2, &pm660_nldo660, NULL },
+ { "l3", QCOM_SMD_RPM_LDOA, 3, &pm660_nldo660, NULL },
+ { "l4", QCOM_SMD_RPM_LDOA, 4, &pm660_pldo660, NULL },
+ { "l5", QCOM_SMD_RPM_LDOA, 5, &pm660_nldo660, NULL },
+ { "l6", QCOM_SMD_RPM_LDOA, 6, &pm660_nldo660, NULL },
+ { "l7", QCOM_SMD_RPM_LDOA, 7, &pm660_nldo660, NULL },
+ { "l8", QCOM_SMD_RPM_LDOA, 8, &pm660_nldo660, NULL },
+ { "l9", QCOM_SMD_RPM_LDOA, 9, &pm660_nldo660, NULL },
+ { "l10", QCOM_SMD_RPM_LDOA, 10, &pm660_nldo660, NULL },
+ { "l11", QCOM_SMD_RPM_LDOA, 11, &pm660_nldo660, NULL },
+ { "l12", QCOM_SMD_RPM_LDOA, 12, &pm660_nldo660, NULL },
+ { "l13", QCOM_SMD_RPM_LDOA, 13, &pm660_ht_lvpldo, NULL },
+ { "l14", QCOM_SMD_RPM_LDOA, 14, &pm660_ht_lvpldo, NULL },
+ { "l15", QCOM_SMD_RPM_LDOA, 15, &pm660_ht_lvpldo, NULL },
+ { "l16", QCOM_SMD_RPM_LDOA, 16, &pm660_ht_lvpldo, NULL },
+ { "l17", QCOM_SMD_RPM_LDOA, 17, &pm660_pldo660, NULL },
+ { "l18", QCOM_SMD_RPM_LDOA, 18, &pm660_pldo660, NULL },
+ { "l19", QCOM_SMD_RPM_LDOA, 19, &pm660_pldo660, NULL },
+ { "l20", QCOM_SMD_RPM_LDOA, 20, &pm660_pldo660, NULL },
+ { "l21", QCOM_SMD_RPM_LDOA, 21, &pm660_pldo660, NULL },
+ { "l22", QCOM_SMD_RPM_LDOA, 22, &pm660_pldo660, NULL },
{}
};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: qcom: qrb2210: fix PM4125 regulator supply parent mappings
From: Rakesh Kota @ 2026-07-20 10:55 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, devicetree, Kamal Wadhwa,
jishnu.prakash, Rakesh Kota
In-Reply-To: <20260720-pm2250-fix-supply-parent-v2-0-60ca47031b50@oss.qualcomm.com>
The qrb2210-arduino-imola and qrb2210-rb1 DTS files used coarsely
grouped supply parent names that do not reflect the actual physical
pin connections on the PM4125 PMIC. Since supply rail connections
to PMIC pins are fixed in hardware, these grouped names were
inaccurate descriptions of the hardware topology.
Replace them with the correct per-group supply properties matching
the actual PM4125 pin connections, and align with the companion
driver change that sets supply names to NULL in the qcom_smd-regulator
descriptor so that the correct supply topology is captured in DT.
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts | 13 ++++++++++---
arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 13 ++++++++++---
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
index c472e13fceca..90e6eb284a66 100644
--- a/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
+++ b/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts
@@ -262,9 +262,16 @@ regulators {
compatible = "qcom,rpm-pm2250-regulators";
vdd_s3-supply = <&vph_pwr>;
vdd_s4-supply = <&vph_pwr>;
- vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12-supply = <&pm4125_s3>;
- vdd_l4_l17_l18_l19_l20_l21_l22-supply = <&vph_pwr>;
- vdd_l13_l14_l15_l16-supply = <&pm4125_s4>;
+ vdd_l1-supply = <&pm4125_s3>;
+ vdd_l2_l3-supply = <&pm4125_s3>;
+ vdd_l5_l6_l7_l11_l12-supply = <&pm4125_s3>;
+ vdd_l8_l9-supply = <&pm4125_s3>;
+ vdd_l10-supply = <&pm4125_s3>;
+ vdd_l13_l14-supply = <&pm4125_s4>;
+ vdd_l15_l16-supply = <&pm4125_s4>;
+ vdd_l17_l22-supply = <&vph_pwr>;
+ vdd_l18_l19-supply = <&vph_pwr>;
+ vdd_l4_l20_l21-supply = <&vph_pwr>;
pm4125_s3: s3 {
/* 0.4V-1.6625V -> 1.3V (Power tree requirements) */
diff --git a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
index bf6fb12ad990..3432022274d8 100644
--- a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
+++ b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts
@@ -465,9 +465,16 @@ regulators {
compatible = "qcom,rpm-pm2250-regulators";
vdd_s3-supply = <&vph_pwr>;
vdd_s4-supply = <&vph_pwr>;
- vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12-supply = <&pm4125_s3>;
- vdd_l4_l17_l18_l19_l20_l21_l22-supply = <&vph_pwr>;
- vdd_l13_l14_l15_l16-supply = <&pm4125_s4>;
+ vdd_l1-supply = <&pm4125_s3>;
+ vdd_l2_l3-supply = <&pm4125_s3>;
+ vdd_l5_l6_l7_l11_l12-supply = <&pm4125_s3>;
+ vdd_l8_l9-supply = <&pm4125_s3>;
+ vdd_l10-supply = <&pm4125_s3>;
+ vdd_l13_l14-supply = <&pm4125_s4>;
+ vdd_l15_l16-supply = <&pm4125_s4>;
+ vdd_l17_l22-supply = <&vph_pwr>;
+ vdd_l18_l19-supply = <&vph_pwr>;
+ vdd_l4_l20_l21-supply = <&vph_pwr>;
/*
* S1 - VDD_APC
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/3] arm64: dts: qcom: shikra: add vph_pwr and fix supply parent mappings
From: Rakesh Kota @ 2026-07-20 10:55 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-kernel, devicetree, Kamal Wadhwa,
jishnu.prakash, Rakesh Kota
In-Reply-To: <20260720-pm2250-fix-supply-parent-v2-0-60ca47031b50@oss.qualcomm.com>
Add the vph_pwr fixed regulator representing the PM4125 charger output
supplied by VBAT, and add the correct per-group supply properties
matching the actual PM4125 pin connections on Shikra. Also add the
pm4125_s1 and pm4125_s4 regulator nodes.
Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi | 33 ++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
index dc3861489f64..c7f63ff07283 100644
--- a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
+++ b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
@@ -27,6 +27,16 @@ key-volume-up {
linux,can-disable;
};
};
+
+ /* PM4125 charger out, supplied by VBAT */
+ vph_pwr: regulator-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
};
&pm4125_gpios {
@@ -52,12 +62,35 @@ &pm8005_regulators {
&rpm_requests {
regulators {
compatible = "qcom,rpm-pm2250-regulators";
+ vdd_s1-supply = <&vph_pwr>;
+ vdd_s2-supply = <&vph_pwr>;
+ vdd_s4-supply = <&vph_pwr>;
+ vdd_l1-supply = <&pm4125_s4>;
+ vdd_l2_l3-supply = <&pm4125_s4>;
+ vdd_l5_l6_l7_l11_l12-supply = <&pm4125_s4>;
+ vdd_l8_l9-supply = <&pm4125_s4>;
+ vdd_l10-supply = <&pm4125_s4>;
+ vdd_l13_l14-supply = <&pm4125_s1>;
+ vdd_l15_l16-supply = <&pm4125_s1>;
+ vdd_l17_l22-supply = <&vph_pwr>;
+ vdd_l18_l19-supply = <&vph_pwr>;
+ vdd_l4_l20_l21-supply = <&vph_pwr>;
+
+ pm4125_s1: s1 {
+ regulator-min-microvolt = <2040000>;
+ regulator-max-microvolt = <2040000>;
+ };
pm4125_s2: s2 {
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1200000>;
};
+ pm4125_s4: s4 {
+ regulator-min-microvolt = <640000>;
+ regulator-max-microvolt = <1408000>;
+ };
+
pm4125_l3: l3 {
regulator-min-microvolt = <624000>;
regulator-max-microvolt = <650000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v6 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
From: Konrad Dybcio @ 2026-07-20 11:01 UTC (permalink / raw)
To: david, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Petr Hodina, Richard Acayan, linux-arm-msm, devicetree,
linux-kernel, phone-devel
In-Reply-To: <20260720-pixel3-camera-v6-1-afe419bef476@ixit.cz>
On 7/20/26 12:53 PM, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> The Pixel 3 features two front-facing Sony IMX355 sensors with
> different focal lengths (standard and wide-angle).
[...]
> @@ -127,16 +128,48 @@ vreg_s4a_1p8: regulator-vreg-s4a-1p8 {
> regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <1800000>;
> regulator-always-on;
> regulator-boot-on;
>
> vin-supply = <&vph_pwr>;
> };
>
> + camera_front_avdd: regulator-front-cam-avdd {
This is better, but the regulator nodes still need to be sorted
alphabetically
[...]
> - /* front camera, imx355 @1a */
> + front_cam: camera@10 {
> + compatible = "sony,imx355";
> + reg = <0x10>;
> +
> + clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
> + assigned-clocks = <&clock_camcc CAM_CC_MCLK2_CLK>;
> + assigned-clock-rates = <24000000>;
> +
> + reset-gpios = <&tlmm 21 GPIO_ACTIVE_LOW>;
> +
> + avdd-supply = <&camera_front_avdd>;
> + dvdd-supply = <&vreg_s3a_1p35>;
> + dovdd-supply = <&vreg_lvs1_1p8>;
> +
> + pinctrl-0 = <&cam_front_reset_default>;
> + pinctrl-names = "default";
> +
> + rotation = <270>;
> + orientation = <0>;
https://lore.kernel.org/all/20260628-kbingham-orientation-v3-0-4ed92968aff8@ideasonboard.com/
Please use that for both cameras
Konrad
^ permalink raw reply
* Re: [PATCH v7 06/10] arm64: dts: qcom: shikra: Enable CDSP, LPAICP and MPSS on EVK boards
From: sashiko-bot @ 2026-07-20 11:01 UTC (permalink / raw)
To: Komal Bajaj; +Cc: robh, conor+dt, devicetree, vkoul, Frank.Li, dmaengine
In-Reply-To: <20260720-shikra-dt-m1-v7-6-7dc99100c6dd@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incorrect firmware path specified for the MPSS remote processor in `shikra-iqs-evk.dts`, using the `cqs` directory instead of `iqs`.
--
--- Patch [6]: [PATCH v7 06/10] arm64: dts: qcom: shikra: Enable CDSP, LPAICP and MPSS on EVK boards ---
commit 63fe4aa2fa39f5559ca6adcfb17f05ea60b9924b
Author: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
arm64: dts: qcom: shikra: Enable CDSP, LPAICP and MPSS on EVK boards
This commit enables CDSP, LPAICP, and MPSS for the Qualcomm Shikra CQM,
CQS, and IQS EVK boards by adding the appropriate remoteproc nodes and
firmware paths.
> diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
> index 3003a47bd7594..727809430fd15 100644
> --- a/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
[ ... ]
> @@ -23,6 +23,25 @@ chosen {
> };
> };
>
> +&remoteproc_cdsp {
> + firmware-name = "qcom/shikra/cdsp.mbn";
> +
> + status = "okay";
> +};
> +
> +&remoteproc_lpaicp {
> + firmware-name = "qcom/shikra/lpaicp.mbn",
> + "qcom/shikra/lpaicp_dtb.mbn";
> +
> + status = "okay";
> +};
> +
> +&remoteproc_mpss {
> + firmware-name = "qcom/shikra/cqs/qdsp6sw.mbn";
[Severity: Medium]
Should this firmware path use iqs instead of cqs?
Since this node is in the shikra-iqs-evk.dts file, using the cqs directory
looks like a copy-paste error that might cause the modem remoteproc to fail
to load the correct firmware for the IQS board.
> +
> + status = "okay";
> +};
> +
> &sdhc_1 {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-shikra-dt-m1-v7-0-7dc99100c6dd@oss.qualcomm.com?part=6
^ permalink raw reply
* Re: [PATCH v5 2/2] device property: add test cases for fwnode_for_each_child_node()
From: sashiko-bot @ 2026-07-20 11:02 UTC (permalink / raw)
To: Xu Yang; +Cc: Frank.Li, robh, imx, devicetree, conor+dt
In-Reply-To: <20260720104730.1285552-2-xu.yang_2@oss.nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] The KUnit test fails to use `kunit_add_action()` for global state cleanup, permanently leaking software nodes on test aborts.
Pre-existing issues:
- [High] The newly added tests expose pre-existing infinite loop and double-put bugs in `fwnode_get_next_child_node()` when transitioning between primary OF nodes and secondary SW nodes.
--
--- Patch [2]: [PATCH v5 2/2] device property: add test cases for fwnode_for_each_child_node() ---
commit 6f128f7ffab2a2787ad6820b967d94a17fcbcbc2
Author: Xu Yang <xu.yang_2@nxp.com>
device property: add test cases for fwnode_for_each_child_node()
Add test cases for fwnode_for_each_child_node() API.
> diff --git a/drivers/base/test/property-entry-test.c b/drivers/base/test/property-entry-test.c
> index a8657eb06f94e..a3d1caf28cc7d 100644
> --- a/drivers/base/test/property-entry-test.c
> +++ b/drivers/base/test/property-entry-test.c
[ ... ]
> @@ -489,6 +491,139 @@ static void pe_test_reference(struct kunit *test)
[ ... ]
> + /* 2. Test SW node child iteration */
> +
> + error = software_node_register_node_group(group);
> + KUNIT_ASSERT_EQ(test, error, 0);
> +
> + sw_node = software_node_fwnode(&node);
> +
> + i = 0;
> + num = ARRAY_SIZE(sw_child_array);
> + fwnode_for_each_child_node(sw_node, child) {
> + KUNIT_ASSERT_LT(test, i, num);
[Severity: Medium]
If KUNIT_ASSERT_LT() fails, it will immediately abort the test execution.
Does this bypass the manual software_node_unregister_node_group() call at
the end of the function?
To prevent leaking the software nodes and causing sysfs conflicts on
subsequent test runs, should kunit_add_action() be used to register the
cleanup immediately after registration?
> + KUNIT_EXPECT_STREQ(test, sw_child_array[i++], fwnode_get_name(child));
> + }
> + KUNIT_EXPECT_PTR_EQ(test, child, NULL);
> +
> + /* 3. Test OF (primary) + SW (secondary) node child iteration */
> +
> + of_node->secondary = sw_node;
> + sw_node->secondary = ERR_PTR(-ENODEV);
> +
> + i = 0;
> + num = ARRAY_SIZE(of_sw_child_array);
> + fwnode_for_each_child_node(of_node, child) {
> + KUNIT_ASSERT_LT(test, i, num);
[Severity: High]
This isn't a bug introduced by this patch, but these new tests appear to
expose a pre-existing infinite loop and double-put bug in the core fwnode
iterator.
When fwnode_for_each_child_node() transitions from primary OF children to
secondary SW children, of_fwnode_get_next_child_node() drops the reference
on the last OF child and returns NULL. The core iterator then passes this
same child pointer to the secondary node's iterator:
drivers/base/property.c:fwnode_get_next_child_node() {
...
next = fwnode_call_ptr_op(fwnode, get_next_child_node, child);
if (next)
return next;
return fwnode_call_ptr_op(fwnode->secondary, get_next_child_node, child);
}
Does this cause the secondary iterator (software_node_get_next_child) to
unconditionally drop the reference a second time?
Furthermore, when iterating over the secondary children, the returned SW node
is eventually passed back to the primary iterator. Since to_of_node()
evaluates to NULL for SW nodes, of_get_next_available_child() restarts from
the first OF child:
drivers/of/property.c:of_fwnode_get_next_child_node() {
...
return of_fwnode_handle(of_get_next_available_child(to_of_node(fwnode),
to_of_node(child)));
}
Will this restart cause an infinite loop in the test runner when testing
mixed primary and secondary firmware nodes?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720104730.1285552-1-xu.yang_2@oss.nxp.com?part=2
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: adc: add MAX40080 current-sense amplifier driver
From: Nuno Sá @ 2026-07-20 11:08 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Stefan Popa, linux-iio, Andy Shevchenko, David Lechner, Nuno Sa,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Siratul Islam,
Uwe Kleine-König, Ciprian Hegbeli, devicetree, linux-kernel
In-Reply-To: <20260718004145.079c5262@jic23-huawei>
On Sat, Jul 18, 2026 at 12:41:57AM +0100, Jonathan Cameron wrote:
> On Wed, 15 Jul 2026 16:23:11 +0200
> Nuno Sá <noname.nuno@gmail.com> wrote:
>
> > Hi Stefan,
> >
> > Some comments from me
> >
> > On Wed, Jul 15, 2026 at 09:36:17AM +0300, Stefan Popa wrote:
> > > The MAX40080 is a bidirectional current-sense amplifier with an
> > > integrated 12-bit ADC and an I2C/SMBus interface. It measures the
> > > voltage across an external shunt resistor and the input bus voltage,
> > > storing the results in an internal FIFO.
> > >
> > > No existing IIO driver covers this device or a register-compatible part.
> > > The closest relatives target different silicon with incompatible register
> > > maps and feature sets: max9611 is a unidirectional high-side sensor with a
> > > die-temperature channel and MUX-selected gain and no FIFO/PEC, while
> > > max34408 is an 8-bit multi-channel current monitor. The MAX40080 has a
> > > device-specific register map with bidirectional 13-bit current, a 64-entry
> > > FIFO, PEC, a single-measurement mode triggered by an SMBus Quick Command,
> > > and two selectable input ranges, so it warrants its own driver.
> > >
> > > Add a direct-mode IIO driver exposing the current and voltage channels
> > > with raw and scale attributes, a configurable oversampling (digital
> > > averaging) ratio, and PEC-protected register access. The two selectable
> > > current-sense ranges are exposed through scale/scale_available; the
> > > current scale is derived from the shunt-resistor-micro-ohms device-tree
> > > property.
> > >
> > > Link: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX40080.pdf
> > >
> > > Co-developed-by: Ciprian Hegbeli <ciprian.hegbeli@analog.com>
> > > Signed-off-by: Ciprian Hegbeli <ciprian.hegbeli@analog.com>
> > > Signed-off-by: Stefan Popa <stefan.popa@analog.com>
>
> A couple of follow ups even though v4 is on list.
>
> That should indicate clearly why you should slow down and let people
> get to earlier versions.
>
> Jonathan
>
> > > diff --git a/drivers/iio/adc/max40080.c b/drivers/iio/adc/max40080.c
> > > new file mode 100644
> > > index 0000000000000..a0c1144cfda7c
> > > --- /dev/null
> > > +++ b/drivers/iio/adc/max40080.c
> > > @@ -0,0 +1,630 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * MAX40080 Digital Current-Sense Amplifier driver
> > > + *
> > > + * Copyright 2026 Analog Devices, Inc.
> > > + */
> > > +
> > > +#include <linux/bitfield.h>
> > > +#include <linux/bitops.h>
> > > +#include <linux/cleanup.h>
> > > +#include <linux/i2c.h>
> > > +#include <linux/iopoll.h>
> > > +#include <linux/math64.h>
> > > +#include <linux/module.h>
> >
> > Typically I would say you're missing mod_devicetable.h but now we have:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/include/linux/device-id
> >
> > You might need to base your series on linux-next though.
>
> I merged rc2 into the IIO togreg (and so testing as well) branches to resolve
> merge conflicts with that series. Upshot is just don't bother
> including mod_devicetable.h in any new code. Also don't worry
> about including any of the linux/device-id headers unless you don't
> get them via i2c.h, spi.h etc
>
> >
> > > +#include <linux/mutex.h>
> > > +#include <linux/pm.h>
> > > +#include <linux/property.h>
> > > +#include <linux/time.h>
> > > +static int max40080_read_iv_once(struct max40080_state *st, u32 *iv)
> > > +{
> > > + u8 buf[4];
> > > + int ret;
> > > +
> > > + ret = i2c_smbus_read_i2c_block_data(st->client, MAX40080_REG_IV,
> > > + sizeof(buf), buf);
> >
> > It's not clear to me that i2c will use safe buffer all the time (from a
> > quick look). So I would say to make this DMA safe the usual way we do in
> > IIO.
>
> I2c always bounces unless you use specific dmasafe functions to indicate
> that your particular buffer is DMA safe.
To me it was not clear because of:
https://elixir.bootlin.com/linux/v7.2-rc3/source/drivers/i2c/i2c-core-smbus.c#L604
In the above case it looks like the buffer is just passed to the
controller and it won't fallback for the emaluted case where
i2c_smbus_try_get_dmabuf() seems to be always called.
Having said the above and looking (briefly) at the .smbus_xfer_atomic() users, not
sure it will be such an issue.
- Nuno Sá
>
> >
> > > + if (ret < 0)
> > > + return ret;
> > > + if (ret != sizeof(buf))
> > > + return -EIO;
> > > +
> > > + *iv = get_unaligned_le32(buf);
> > > +
> > > + return 0;
> > > +}
> > > +
^ permalink raw reply
* Re: [PATCH v7 07/10] arm64: dts: qcom: shikra: Enable TSENS and thermal zones
From: sashiko-bot @ 2026-07-20 11:08 UTC (permalink / raw)
To: Komal Bajaj; +Cc: dmaengine, conor+dt, robh, Frank.Li, devicetree, vkoul
In-Reply-To: <20260720-shikra-dt-m1-v7-7-7dc99100c6dd@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] TSENS uplow interrupt must be routed through the MPM for thermal wakeup from sleep.
--
--- Patch [7]: [PATCH v7 07/10] arm64: dts: qcom: shikra: Enable TSENS and thermal zones ---
commit 5c7a177e376df4af941332f06d373b391bca3a3d
Author: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
arm64: dts: qcom: shikra: Enable TSENS and thermal zones
This commit adds the TSENS node and thermal zones for the Shikra SoC.
It configures 14 thermal sensors distributed across the SoC, with hot and
maximum trip points defined at 110°C and 115°C.
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index 12e4281f7b358..3abd0a686d0e2 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
[ ... ]
> @@ -998,6 +999,18 @@ spmi_bus: spmi@1c40000 {
> qcom,ee = <0>;
> };
>
> + tsens0: thermal-sensor@4411000 {
> + compatible = "qcom,shikra-tsens", "qcom,tsens-v2";
> + reg = <0x0 0x04411000 0x0 0x1000>,
> + <0x0 0x04410000 0x0 0x1000>;
> + interrupts = <GIC_SPI 275 IRQ_TYPE_LEVEL_HIGH 0>,
[Severity: Medium]
Will this interrupt mapping prevent thermal wakeups from deep sleep?
The TSENS0 uplow interrupt is mapped directly to the GIC here. However, since
shikra.dtsi configures the MPM to handle this interrupt on pin 2, does this
need to be routed through the MPM instead?
It seems this should be defined using:
interrupts-extended = <&mpm 2 IRQ_TYPE_LEVEL_HIGH>
If mapped directly to the GIC, if the system heats up while suspended, it
will not wake up at the configured thermal trip points to perform thermal
mitigation or a graceful shutdown. It would eventually rely on the abrupt
hardware reset at 120°C.
> + <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH 0>;
> + interrupt-names = "uplow",
> + "critical";
> + #qcom,sensors = <14>;
> + #thermal-sensor-cells = <1>;
> + };
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-shikra-dt-m1-v7-0-7dc99100c6dd@oss.qualcomm.com?part=7
^ permalink raw reply
* [PATCH 0/4] iio: adc: ade9000: add support for ADE9078
From: Antoniu Miclaus @ 2026-07-20 11:07 UTC (permalink / raw)
To: Antoniu Miclaus, Nuno Sá, Michael Hennerich,
Jonathan Cameron, David Lechner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan, Marcelo Schmitt,
Radu Sabau, Jorge Marques, Matti Vaittinen, Jonathan Santos,
Jishnu Prakash, linux-iio, linux, devicetree, linux-kernel,
linux-doc
The ADE9078 is a polyphase energy metering device from the same family as
the ADE9000 and is register compatible with it. The main differences
relevant to the driver are the absence of the on-chip dip/swell detection,
a lower maximum SPI clock (10 MHz), and slightly different full-scale ADC
codes.
This series adds support for the ADE9078 to the existing ade9000 driver.
It first refactors the driver to move the part-specific values (device
name, channel table, and full-scale codes) into a chip_info structure
retrieved via device match data, then adds the new device tree compatible
and the ADE9078 support itself, and finally updates the documentation.
Antoniu Miclaus (4):
iio: adc: ade9000: introduce chip_info structure
dt-bindings: iio: adc: adi,ade9000: add adi,ade9078 compatible
iio: adc: ade9000: add support for ADE9078
docs: iio: ade9000: document ADE9078 support
.../bindings/iio/adc/adi,ade9000.yaml | 30 ++-
Documentation/iio/ade9000.rst | 28 +--
drivers/iio/adc/Kconfig | 14 +-
drivers/iio/adc/ade9000.c | 178 ++++++++++++------
4 files changed, 169 insertions(+), 81 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/4] iio: adc: ade9000: introduce chip_info structure
From: Antoniu Miclaus @ 2026-07-20 11:07 UTC (permalink / raw)
To: Antoniu Miclaus, Nuno Sá, Michael Hennerich,
Jonathan Cameron, David Lechner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan, Marcelo Schmitt,
Radu Sabau, Jorge Marques, Matti Vaittinen, Jonathan Santos,
Jishnu Prakash, linux-iio, linux, devicetree, linux-kernel,
linux-doc
In-Reply-To: <20260720110754.7674-1-antoniu.miclaus@analog.com>
The driver currently hardcodes the device name and the full-scale ADC
codes used to derive the IIO scale attributes. In preparation for
supporting additional parts of the ADE9000 family, move these
part-specific values into a new struct ade9000_chip_info and retrieve it
via spi_get_device_match_data() at probe time.
The channel table and its size are also referenced through the chip_info
so that parts with a different channel layout can be added without
touching the probe path.
No functional change intended for the ADE9000.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
drivers/iio/adc/ade9000.c | 63 +++++++++++++++++++++++++++++----------
1 file changed, 47 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/adc/ade9000.c b/drivers/iio/adc/ade9000.c
index b80cdd8ad982..38a5c7e043b3 100644
--- a/drivers/iio/adc/ade9000.c
+++ b/drivers/iio/adc/ade9000.c
@@ -242,14 +242,6 @@
#define ADE9000_LAST_PAGE_BIT BIT(15)
#define ADE9000_MIDDLE_PAGE_BIT BIT(7)
-/*
- * Full scale Codes referred from Datasheet. Respective digital codes are
- * produced when ADC inputs are at full scale.
- */
-#define ADE9000_RMS_FULL_SCALE_CODES 52866837
-#define ADE9000_WATT_FULL_SCALE_CODES 20694066
-#define ADE9000_PCF_FULL_SCALE_CODES 74770000
-
/* Phase and channel definitions */
#define ADE9000_PHASE_A_NR 0
#define ADE9000_PHASE_B_NR 1
@@ -290,7 +282,29 @@ enum ade9000_wfb_cfg {
#define ADE9000_ADDR_ADJUST(addr, chan) \
(((chan) == 0 ? 0 : (chan) == 1 ? 2 : 4) << 4 | (addr))
+/**
+ * struct ade9000_chip_info - part-specific configuration
+ * @name: IIO device name reported to userspace
+ * @channels: channel specification for this part
+ * @num_channels: number of entries in @channels
+ * @rms_full_scale_codes: digital code produced at full-scale RMS input
+ * @watt_full_scale_codes: digital code produced at full-scale power input
+ * @pcf_full_scale_codes: digital code produced at full-scale xI_PCF/xV_PCF input
+ *
+ * The full-scale codes are taken from the respective datasheets and are used to
+ * derive the IIO scale of the raw measurement channels.
+ */
+struct ade9000_chip_info {
+ const char *name;
+ const struct iio_chan_spec *channels;
+ unsigned int num_channels;
+ unsigned int rms_full_scale_codes;
+ unsigned int watt_full_scale_codes;
+ unsigned int pcf_full_scale_codes;
+};
+
struct ade9000_state {
+ const struct ade9000_chip_info *info;
struct completion reset_completion;
struct mutex lock; /* Protects SPI transactions */
u8 wf_src;
@@ -623,6 +637,19 @@ static const struct iio_chan_spec ade9000_channels[] = {
ADE9000_POWER_FACTOR_CHANNEL(ADE9000_PHASE_C_NR),
};
+/*
+ * Full-scale codes referred from the datasheet. These are the digital codes
+ * produced when the ADC inputs are at full scale.
+ */
+static const struct ade9000_chip_info ade9000_chip_info = {
+ .name = "ade9000",
+ .channels = ade9000_channels,
+ .num_channels = ARRAY_SIZE(ade9000_channels),
+ .rms_full_scale_codes = 52866837,
+ .watt_full_scale_codes = 20694066,
+ .pcf_full_scale_codes = 74770000,
+};
+
static const struct reg_sequence ade9000_initialization_sequence[] = {
{ ADE9000_REG_PGA_GAIN, ADE9000_PGA_GAIN },
{ ADE9000_REG_CONFIG0, ADE9000_CONFIG0 },
@@ -1064,7 +1091,7 @@ static int ade9000_read_raw(struct iio_dev *indio_dev,
case ADE9000_REG_CI_PCF:
case ADE9000_REG_CV_PCF:
*val = 1;
- *val2 = ADE9000_PCF_FULL_SCALE_CODES;
+ *val2 = st->info->pcf_full_scale_codes;
return IIO_VAL_FRACTIONAL;
case ADE9000_REG_AIRMS:
case ADE9000_REG_AVRMS:
@@ -1073,14 +1100,14 @@ static int ade9000_read_raw(struct iio_dev *indio_dev,
case ADE9000_REG_CIRMS:
case ADE9000_REG_CVRMS:
*val = 1;
- *val2 = ADE9000_RMS_FULL_SCALE_CODES;
+ *val2 = st->info->rms_full_scale_codes;
return IIO_VAL_FRACTIONAL;
default:
return -EINVAL;
}
case IIO_POWER:
*val = 1;
- *val2 = ADE9000_WATT_FULL_SCALE_CODES;
+ *val2 = st->info->watt_full_scale_codes;
return IIO_VAL_FRACTIONAL;
default:
break;
@@ -1692,6 +1719,10 @@ static int ade9000_probe(struct spi_device *spi)
st = iio_priv(indio_dev);
+ st->info = spi_get_device_match_data(spi);
+ if (!st->info)
+ return -ENODEV;
+
regmap = devm_regmap_init(dev, NULL, st, &ade9000_regmap_config);
if (IS_ERR(regmap))
return dev_err_probe(dev, PTR_ERR(regmap), "Unable to allocate ADE9000 regmap");
@@ -1726,7 +1757,7 @@ static int ade9000_probe(struct spi_device *spi)
if (ret)
return ret;
- indio_dev->name = "ade9000";
+ indio_dev->name = st->info->name;
indio_dev->info = &ade9000_info;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->setup_ops = &ade9000_buffer_ops;
@@ -1736,8 +1767,8 @@ static int ade9000_probe(struct spi_device *spi)
return dev_err_probe(&spi->dev, ret,
"Failed to get and enable vdd regulator\n");
- indio_dev->channels = ade9000_channels;
- indio_dev->num_channels = ARRAY_SIZE(ade9000_channels);
+ indio_dev->channels = st->info->channels;
+ indio_dev->num_channels = st->info->num_channels;
ret = devm_iio_kfifo_buffer_setup(dev, indio_dev,
&ade9000_buffer_ops);
@@ -1768,13 +1799,13 @@ static int ade9000_probe(struct spi_device *spi)
};
static const struct spi_device_id ade9000_id[] = {
- { .name = "ade9000" },
+ { .name = "ade9000", .driver_data = (kernel_ulong_t)&ade9000_chip_info },
{ }
};
MODULE_DEVICE_TABLE(spi, ade9000_id);
static const struct of_device_id ade9000_of_match[] = {
- { .compatible = "adi,ade9000" },
+ { .compatible = "adi,ade9000", .data = &ade9000_chip_info },
{ }
};
MODULE_DEVICE_TABLE(of, ade9000_of_match);
--
2.43.0
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: iio: adc: adi,ade9000: add adi,ade9078 compatible
From: Antoniu Miclaus @ 2026-07-20 11:07 UTC (permalink / raw)
To: Antoniu Miclaus, Nuno Sá, Michael Hennerich,
Jonathan Cameron, David Lechner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan, Marcelo Schmitt,
Radu Sabau, Jorge Marques, Matti Vaittinen, Jonathan Santos,
Jishnu Prakash, linux-iio, linux, devicetree, linux-kernel,
linux-doc
In-Reply-To: <20260720110754.7674-1-antoniu.miclaus@analog.com>
The ADE9078 is a polyphase energy metering device from the same family as
the ADE9000. It is register-compatible with the ADE9000 but does not
provide the on-chip dip/swell detection and is limited to a 10 MHz SPI
clock.
Add the new compatible along with a conditional constraint lowering the
maximum spi-max-frequency for the ADE9078.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
.../bindings/iio/adc/adi,ade9000.yaml | 30 ++++++++++++++-----
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml
index f22eba0250ee..1e940e8c7297 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ade9000.yaml
@@ -5,21 +5,23 @@
$id: http://devicetree.org/schemas/iio/adc/adi,ade9000.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Analog Devices ADE9000 High Performance, Polyphase Energy Metering
+title: Analog Devices ADE9000/ADE9078 High Performance, Polyphase Energy Metering
maintainers:
- Antoniu Miclaus <antoniu.miclaus@analog.com>
description: |
- The ADE9000 is a highly accurate, fully integrated, multiphase energy and power
- quality monitoring device. Superior analog performance and a digital signal
- processing (DSP) core enable accurate energy monitoring over a wide dynamic
- range. An integrated high end reference ensures low drift over temperature
- with a combined drift of less than ±25 ppm/°C maximum for the entire channel
- including a programmable gain amplifier (PGA) and an analog-to-digital
- converter (ADC).
+ The ADE9000 and ADE9078 are highly accurate, fully integrated, multiphase
+ energy and power quality monitoring devices. Superior analog performance and a
+ digital signal processing (DSP) core enable accurate energy monitoring over a
+ wide dynamic range. An integrated high end reference ensures low drift over
+ temperature with a combined drift of less than ±25 ppm/°C maximum for the
+ entire channel including a programmable gain amplifier (PGA) and an
+ analog-to-digital converter (ADC). The ADE9078 does not provide the on-chip
+ dip/swell detection available on the ADE9000.
https://www.analog.com/media/en/technical-documentation/data-sheets/ADE9000.pdf
+ https://www.analog.com/media/en/technical-documentation/data-sheets/ADE9078.pdf
$ref: /schemas/spi/spi-peripheral-props.yaml#
@@ -27,6 +29,7 @@ properties:
compatible:
enum:
- adi,ade9000
+ - adi,ade9078
reg:
maxItems: 1
@@ -67,6 +70,17 @@ required:
- reg
- vdd-supply
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: adi,ade9078
+ then:
+ properties:
+ spi-max-frequency:
+ maximum: 10000000
+
unevaluatedProperties: false
examples:
--
2.43.0
^ permalink raw reply related
* [PATCH 3/4] iio: adc: ade9000: add support for ADE9078
From: Antoniu Miclaus @ 2026-07-20 11:07 UTC (permalink / raw)
To: Antoniu Miclaus, Nuno Sá, Michael Hennerich,
Jonathan Cameron, David Lechner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan, Marcelo Schmitt,
Radu Sabau, Jorge Marques, Matti Vaittinen, Jonathan Santos,
Jishnu Prakash, linux-iio, linux, devicetree, linux-kernel,
linux-doc
In-Reply-To: <20260720110754.7674-1-antoniu.miclaus@analog.com>
The ADE9078 is a polyphase energy metering device that is register
compatible with the ADE9000. The main differences relevant to the driver
are the absence of the on-chip dip/swell detection and slightly different
full-scale ADC codes.
Add a dedicated channel table that omits the swell/dip voltage events and
a matching chip_info describing the ADE9078 full-scale codes. The RMS
voltage channel macro is split into a shared base and two variants so the
event-less table can reuse the common definition.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
drivers/iio/adc/Kconfig | 14 ++---
drivers/iio/adc/ade9000.c | 121 +++++++++++++++++++++++++-------------
2 files changed, 86 insertions(+), 49 deletions(-)
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index d1b198cb8a80..33f2c281b1aa 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -573,20 +573,20 @@ config AD9467
called ad9467.
config ADE9000
- tristate "Analog Devices ADE9000 Multiphase Energy, and Power Quality Monitoring IC Driver"
+ tristate "Analog Devices ADE9000/ADE9078 Multiphase Energy, and Power Quality Monitoring IC Driver"
depends on SPI
select REGMAP_SPI
select IIO_BUFFER
select IIO_KFIFO_BUF
help
- Say yes here to build support for the Analog Devices ADE9000,
- a highly accurate, multiphase energy and power quality monitoring
- integrated circuit.
+ Say yes here to build support for the Analog Devices ADE9000 and
+ ADE9078, highly accurate, multiphase energy and power quality
+ monitoring integrated circuits.
- The device features high-precision analog-to-digital converters
+ The devices feature high-precision analog-to-digital converters
and digital signal processing to compute RMS values, power factor,
- frequency, and harmonic analysis. It supports SPI communication
- and provides buffered data output through the IIO framework.
+ frequency, and harmonic analysis. They support SPI communication
+ and provide buffered data output through the IIO framework.
To compile this driver as a module, choose M here: the module will
be called ade9000.
diff --git a/drivers/iio/adc/ade9000.c b/drivers/iio/adc/ade9000.c
index 38a5c7e043b3..0de55b7ad1ea 100644
--- a/drivers/iio/adc/ade9000.c
+++ b/drivers/iio/adc/ade9000.c
@@ -502,7 +502,7 @@ static const struct iio_chan_spec_ext_info ade9000_ext_info[] = {
.scan_index = -1 \
}
-#define ADE9000_ALTVOLTAGE_RMS_CHANNEL(num) { \
+#define ADE9000_ALTVOLTAGE_RMS_CHANNEL_BASE(num) \
.type = IIO_ALTVOLTAGE, \
.channel = num, \
.address = ADE9000_ADDR_ADJUST(ADE9000_REG_AVRMS, num), \
@@ -512,9 +512,18 @@ static const struct iio_chan_spec_ext_info ade9000_ext_info[] = {
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
BIT(IIO_CHAN_INFO_SCALE) | \
BIT(IIO_CHAN_INFO_CALIBBIAS), \
+ .scan_index = -1
+
+/* With swell/dip (sag) events - ADE9000 only */
+#define ADE9000_ALTVOLTAGE_RMS_CHANNEL(num) { \
+ ADE9000_ALTVOLTAGE_RMS_CHANNEL_BASE(num), \
.event_spec = ade9000_rms_voltage_events, \
.num_event_specs = ARRAY_SIZE(ade9000_rms_voltage_events), \
- .scan_index = -1 \
+}
+
+/* Without swell/dip events - parts lacking DIP_LVL/SWELL_LVL hardware */
+#define ADE9000_ALTVOLTAGE_RMS_CHANNEL_NO_EVENTS(num) { \
+ ADE9000_ALTVOLTAGE_RMS_CHANNEL_BASE(num), \
}
#define ADE9000_POWER_ACTIVE_CHANNEL(num) { \
@@ -598,48 +607,65 @@ static const struct iio_chan_spec_ext_info ade9000_ext_info[] = {
.scan_index = -1 \
}
-static const struct iio_chan_spec ade9000_channels[] = {
- /* Phase A channels */
- ADE9000_CURRENT_CHANNEL(ADE9000_PHASE_A_NR),
- ADE9000_VOLTAGE_CHANNEL(ADE9000_PHASE_A_NR),
- ADE9000_ALTCURRENT_RMS_CHANNEL(ADE9000_PHASE_A_NR),
- ADE9000_ALTVOLTAGE_RMS_CHANNEL(ADE9000_PHASE_A_NR),
- ADE9000_POWER_ACTIVE_CHANNEL(ADE9000_PHASE_A_NR),
- ADE9000_POWER_REACTIVE_CHANNEL(ADE9000_PHASE_A_NR),
- ADE9000_POWER_APPARENT_CHANNEL(ADE9000_PHASE_A_NR),
- ADE9000_ENERGY_ACTIVE_CHANNEL(ADE9000_PHASE_A_NR, ADE9000_REG_AWATTHR_LO),
- ADE9000_ENERGY_APPARENT_CHANNEL(ADE9000_PHASE_A_NR, ADE9000_REG_AVAHR_LO),
- ADE9000_ENERGY_REACTIVE_CHANNEL(ADE9000_PHASE_A_NR, ADE9000_REG_AFVARHR_LO),
- ADE9000_POWER_FACTOR_CHANNEL(ADE9000_PHASE_A_NR),
- /* Phase B channels */
- ADE9000_CURRENT_CHANNEL(ADE9000_PHASE_B_NR),
- ADE9000_VOLTAGE_CHANNEL(ADE9000_PHASE_B_NR),
- ADE9000_ALTCURRENT_RMS_CHANNEL(ADE9000_PHASE_B_NR),
- ADE9000_ALTVOLTAGE_RMS_CHANNEL(ADE9000_PHASE_B_NR),
- ADE9000_POWER_ACTIVE_CHANNEL(ADE9000_PHASE_B_NR),
- ADE9000_POWER_REACTIVE_CHANNEL(ADE9000_PHASE_B_NR),
- ADE9000_POWER_APPARENT_CHANNEL(ADE9000_PHASE_B_NR),
- ADE9000_ENERGY_ACTIVE_CHANNEL(ADE9000_PHASE_B_NR, ADE9000_REG_BWATTHR_LO),
- ADE9000_ENERGY_APPARENT_CHANNEL(ADE9000_PHASE_B_NR, ADE9000_REG_BVAHR_LO),
- ADE9000_ENERGY_REACTIVE_CHANNEL(ADE9000_PHASE_B_NR, ADE9000_REG_BFVARHR_LO),
- ADE9000_POWER_FACTOR_CHANNEL(ADE9000_PHASE_B_NR),
- /* Phase C channels */
- ADE9000_CURRENT_CHANNEL(ADE9000_PHASE_C_NR),
- ADE9000_VOLTAGE_CHANNEL(ADE9000_PHASE_C_NR),
- ADE9000_ALTCURRENT_RMS_CHANNEL(ADE9000_PHASE_C_NR),
- ADE9000_ALTVOLTAGE_RMS_CHANNEL(ADE9000_PHASE_C_NR),
- ADE9000_POWER_ACTIVE_CHANNEL(ADE9000_PHASE_C_NR),
- ADE9000_POWER_REACTIVE_CHANNEL(ADE9000_PHASE_C_NR),
- ADE9000_POWER_APPARENT_CHANNEL(ADE9000_PHASE_C_NR),
- ADE9000_ENERGY_ACTIVE_CHANNEL(ADE9000_PHASE_C_NR, ADE9000_REG_CWATTHR_LO),
- ADE9000_ENERGY_APPARENT_CHANNEL(ADE9000_PHASE_C_NR, ADE9000_REG_CVAHR_LO),
- ADE9000_ENERGY_REACTIVE_CHANNEL(ADE9000_PHASE_C_NR, ADE9000_REG_CFVARHR_LO),
- ADE9000_POWER_FACTOR_CHANNEL(ADE9000_PHASE_C_NR),
-};
+/*
+ * Declare a full channel array. @altvoltage_rms picks the RMS voltage channel
+ * variant so parts without dip/swell hardware (e.g. ADE9078) omit those events.
+ */
+#define ADE9000_DECLARE_CHANNELS(_name, altvoltage_rms) \
+ static const struct iio_chan_spec _name[] = { \
+ /* Phase A channels */ \
+ ADE9000_CURRENT_CHANNEL(ADE9000_PHASE_A_NR), \
+ ADE9000_VOLTAGE_CHANNEL(ADE9000_PHASE_A_NR), \
+ ADE9000_ALTCURRENT_RMS_CHANNEL(ADE9000_PHASE_A_NR), \
+ altvoltage_rms(ADE9000_PHASE_A_NR), \
+ ADE9000_POWER_ACTIVE_CHANNEL(ADE9000_PHASE_A_NR), \
+ ADE9000_POWER_REACTIVE_CHANNEL(ADE9000_PHASE_A_NR), \
+ ADE9000_POWER_APPARENT_CHANNEL(ADE9000_PHASE_A_NR), \
+ ADE9000_ENERGY_ACTIVE_CHANNEL(ADE9000_PHASE_A_NR, \
+ ADE9000_REG_AWATTHR_LO), \
+ ADE9000_ENERGY_APPARENT_CHANNEL(ADE9000_PHASE_A_NR, \
+ ADE9000_REG_AVAHR_LO), \
+ ADE9000_ENERGY_REACTIVE_CHANNEL(ADE9000_PHASE_A_NR, \
+ ADE9000_REG_AFVARHR_LO), \
+ ADE9000_POWER_FACTOR_CHANNEL(ADE9000_PHASE_A_NR), \
+ /* Phase B channels */ \
+ ADE9000_CURRENT_CHANNEL(ADE9000_PHASE_B_NR), \
+ ADE9000_VOLTAGE_CHANNEL(ADE9000_PHASE_B_NR), \
+ ADE9000_ALTCURRENT_RMS_CHANNEL(ADE9000_PHASE_B_NR), \
+ altvoltage_rms(ADE9000_PHASE_B_NR), \
+ ADE9000_POWER_ACTIVE_CHANNEL(ADE9000_PHASE_B_NR), \
+ ADE9000_POWER_REACTIVE_CHANNEL(ADE9000_PHASE_B_NR), \
+ ADE9000_POWER_APPARENT_CHANNEL(ADE9000_PHASE_B_NR), \
+ ADE9000_ENERGY_ACTIVE_CHANNEL(ADE9000_PHASE_B_NR, \
+ ADE9000_REG_BWATTHR_LO), \
+ ADE9000_ENERGY_APPARENT_CHANNEL(ADE9000_PHASE_B_NR, \
+ ADE9000_REG_BVAHR_LO), \
+ ADE9000_ENERGY_REACTIVE_CHANNEL(ADE9000_PHASE_B_NR, \
+ ADE9000_REG_BFVARHR_LO), \
+ ADE9000_POWER_FACTOR_CHANNEL(ADE9000_PHASE_B_NR), \
+ /* Phase C channels */ \
+ ADE9000_CURRENT_CHANNEL(ADE9000_PHASE_C_NR), \
+ ADE9000_VOLTAGE_CHANNEL(ADE9000_PHASE_C_NR), \
+ ADE9000_ALTCURRENT_RMS_CHANNEL(ADE9000_PHASE_C_NR), \
+ altvoltage_rms(ADE9000_PHASE_C_NR), \
+ ADE9000_POWER_ACTIVE_CHANNEL(ADE9000_PHASE_C_NR), \
+ ADE9000_POWER_REACTIVE_CHANNEL(ADE9000_PHASE_C_NR), \
+ ADE9000_POWER_APPARENT_CHANNEL(ADE9000_PHASE_C_NR), \
+ ADE9000_ENERGY_ACTIVE_CHANNEL(ADE9000_PHASE_C_NR, \
+ ADE9000_REG_CWATTHR_LO), \
+ ADE9000_ENERGY_APPARENT_CHANNEL(ADE9000_PHASE_C_NR, \
+ ADE9000_REG_CVAHR_LO), \
+ ADE9000_ENERGY_REACTIVE_CHANNEL(ADE9000_PHASE_C_NR, \
+ ADE9000_REG_CFVARHR_LO), \
+ ADE9000_POWER_FACTOR_CHANNEL(ADE9000_PHASE_C_NR), \
+ }
+
+ADE9000_DECLARE_CHANNELS(ade9000_channels, ADE9000_ALTVOLTAGE_RMS_CHANNEL);
+ADE9000_DECLARE_CHANNELS(ade9078_channels, ADE9000_ALTVOLTAGE_RMS_CHANNEL_NO_EVENTS);
/*
- * Full-scale codes referred from the datasheet. These are the digital codes
- * produced when the ADC inputs are at full scale.
+ * Full-scale codes referred from the respective datasheets. These are the
+ * digital codes produced when the ADC inputs are at full scale.
*/
static const struct ade9000_chip_info ade9000_chip_info = {
.name = "ade9000",
@@ -650,6 +676,15 @@ static const struct ade9000_chip_info ade9000_chip_info = {
.pcf_full_scale_codes = 74770000,
};
+static const struct ade9000_chip_info ade9078_chip_info = {
+ .name = "ade9078",
+ .channels = ade9078_channels,
+ .num_channels = ARRAY_SIZE(ade9078_channels),
+ .rms_full_scale_codes = 52866837,
+ .watt_full_scale_codes = 20823646,
+ .pcf_full_scale_codes = 74680000,
+};
+
static const struct reg_sequence ade9000_initialization_sequence[] = {
{ ADE9000_REG_PGA_GAIN, ADE9000_PGA_GAIN },
{ ADE9000_REG_CONFIG0, ADE9000_CONFIG0 },
@@ -1800,12 +1835,14 @@ static int ade9000_probe(struct spi_device *spi)
static const struct spi_device_id ade9000_id[] = {
{ .name = "ade9000", .driver_data = (kernel_ulong_t)&ade9000_chip_info },
+ { .name = "ade9078", .driver_data = (kernel_ulong_t)&ade9078_chip_info },
{ }
};
MODULE_DEVICE_TABLE(spi, ade9000_id);
static const struct of_device_id ade9000_of_match[] = {
{ .compatible = "adi,ade9000", .data = &ade9000_chip_info },
+ { .compatible = "adi,ade9078", .data = &ade9078_chip_info },
{ }
};
MODULE_DEVICE_TABLE(of, ade9000_of_match);
--
2.43.0
^ permalink raw reply related
* [PATCH 4/4] docs: iio: ade9000: document ADE9078 support
From: Antoniu Miclaus @ 2026-07-20 11:07 UTC (permalink / raw)
To: Antoniu Miclaus, Nuno Sá, Michael Hennerich,
Jonathan Cameron, David Lechner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Corbet, Shuah Khan, Marcelo Schmitt,
Radu Sabau, Jorge Marques, Matti Vaittinen, Jonathan Santos,
Jishnu Prakash, linux-iio, linux, devicetree, linux-kernel,
linux-doc
In-Reply-To: <20260720110754.7674-1-antoniu.miclaus@analog.com>
Add the ADE9078 to the list of supported devices and note that the
dip/swell voltage events are only available on the ADE9000.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
---
Documentation/iio/ade9000.rst | 28 +++++++++++++++++-----------
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/Documentation/iio/ade9000.rst b/Documentation/iio/ade9000.rst
index c9ff702a4251..72737b5ec59c 100644
--- a/Documentation/iio/ade9000.rst
+++ b/Documentation/iio/ade9000.rst
@@ -1,24 +1,30 @@
.. SPDX-License-Identifier: GPL-2.0
-===============
-ADE9000 driver
-===============
+======================
+ADE9000/ADE9078 driver
+======================
-This driver supports Analog Device's ADE9000 energy measurement IC on SPI bus.
+This driver supports Analog Device's ADE9000 and ADE9078 energy measurement
+ICs on SPI bus.
1. Supported devices
====================
* `ADE9000 <https://www.analog.com/media/en/technical-documentation/data-sheets/ADE9000.pdf>`_
-
-The ADE9000 is a highly accurate, fully integrated, multiphase energy and power
-quality monitoring device. Superior analog performance and a digital signal
-processing (DSP) core enable accurate energy monitoring over a wide dynamic
-range. An integrated high end reference ensures low drift over temperature
-with a combined drift of less than ±25 ppm/°C maximum for the entire channel
-including a programmable gain amplifier (PGA) and an analog-to-digital
+* `ADE9078 <https://www.analog.com/media/en/technical-documentation/data-sheets/ADE9078.pdf>`_
+
+The ADE9000 and ADE9078 are highly accurate, fully integrated, multiphase energy
+and power quality monitoring devices. Superior analog performance and a digital
+signal processing (DSP) core enable accurate energy monitoring over a wide
+dynamic range. An integrated high end reference ensures low drift over
+temperature with a combined drift of less than ±25 ppm/°C maximum for the entire
+channel including a programmable gain amplifier (PGA) and an analog-to-digital
converter (ADC).
+The ADE9078 does not provide the on-chip dip/swell (sag) detection available on
+the ADE9000, so the RMS voltage swell/dip events described below are only
+available on the ADE9000.
+
2. Device attributes
====================
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
From: sashiko-bot @ 2026-07-20 11:11 UTC (permalink / raw)
To: David Heidelberg; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260720-pixel3-camera-v6-1-afe419bef476@ixit.cz>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Assigning the MCLK2 `pinctrl` to the `camss` node breaks the camera sensor probe due to decoupled runtime PM lifecycles.
- [Medium] Incorrect CCI I2C sleep state modification overrides `&cci0_sleep` instead of `&cci1_sleep`.
--
--- Patch [1]: [PATCH v6 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras ---
commit c205a00f81a6553c73e74c2e70cc2c7b6bcef19f
Author: David Heidelberg <david@ixit.cz>
arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
This commit adds device tree nodes for the two front-facing Sony IMX355
sensors on the Pixel 3. The sensors are connected via CSIPHY ports and
controlled over CCI I2C1, sharing MCLK2.
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
> --- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
[ ... ]
> +&camss {
> + vdda-phy-supply = <&vreg_l1a_0p875>;
> + vdda-pll-supply = <&vreg_l26a_1p2>;
> +
> + /*
> + * MCLK2 (GPIO15) is shared between both front camera sensors.
> + * The clock is generated by CAMCC, therefore the pin is
> + * configured here rather than in individual sensor nodes.
> + */
> + pinctrl-0 = <&cam_mclk2_default>;
> + pinctrl-1 = <&cam_mclk2_sleep>;
> + pinctrl-names = "default", "sleep";
[Severity: High]
Does putting the MCLK2 pinctrl states in the camss node break the sensor probe?
Because camss operates with decoupled asynchronous runtime PM, it will likely
be suspended during the imx355 sensor probe. The PM core will put the pin into
the sleep state, which configures bias-pull-down.
When the imx355 driver calls clk_prepare_enable(mclk) during I2C probe to read
its chip ID, the clock controller generates the clock, but the sleep state on
camss will prevent the clock signal from reaching the sensors, causing the
probe to abort.
> +
> + status = "okay";
[ ... ]
> +};
> +
> +&cci0_sleep {
> + /* bus has external pull-up */
> + /delete-property/ bias-pull-down;
> + bias-disable;
> +};
[Severity: Medium]
Since the front cameras are added under the cci_i2c1 bus, should this be
modifying &cci1_sleep instead of &cci0_sleep?
This leaves the cci_i2c1 sleep state with its default bias-pull-down setting,
which will fight the external pull-up and could drain the battery during
sleep. It also incorrectly modifies cci_i2c0 which might affect other devices
on that bus.
> +
> +&cci {
> + status = "okay";
> +};
> @@ -358,7 +443,63 @@ &cci {
> &cci_i2c1 {
> /* actuator @0c */
>
> - /* front camera, imx355 @1a */
> + front_cam: camera@10 {
> + compatible = "sony,imx355";
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-pixel3-camera-v6-0-afe419bef476@ixit.cz?part=1
^ permalink raw reply
* Re: [PATCH v6 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
From: David Heidelberg @ 2026-07-20 11:13 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Petr Hodina, Richard Acayan, linux-arm-msm, devicetree,
linux-kernel, phone-devel
In-Reply-To: <a560a3f6-0bc7-4245-a5c2-b5d0f011e087@oss.qualcomm.com>
[...]
>> + rotation = <270>;
>> + orientation = <0>;
>
> https://lore.kernel.org/all/20260628-kbingham-orientation-v3-0-4ed92968aff8@ideasonboard.com/
>
> Please use that for both cameras
Oh, that's great! Finally instead of comments we have the defines :)
David
>
> Konrad
--
David Heidelberg
^ permalink raw reply
* Re: [PATCH v5 1/2] of: kobj: export of_node_ktype for use by modules
From: Andy Shevchenko @ 2026-07-20 11:13 UTC (permalink / raw)
To: Xu Yang
Cc: gregkh, rafael, dakr, robh, saravanak, bartosz.golaszewski,
driver-core, linux-kernel, devicetree, imx
In-Reply-To: <20260720104730.1285552-1-xu.yang_2@oss.nxp.com>
On Mon, Jul 20, 2026 at 06:47:29PM +0800, Xu Yang wrote:
> of_node_init() is a static inline that references of_node_ktype when
> CONFIG_OF_KOBJ=y. Any module that calls of_node_init() will therefore
> have an unresolved reference to of_node_ktype at load time, because
> the symbol is defined in drivers/of/kobj.c but was never exported.
>
> This causes a modpost build error when CONFIG_OF_KOBJ=y and
> CONFIG_DRIVER_PE_KUNIT_TEST=m:
>
> ERROR: modpost: "of_node_ktype"
> [drivers/base/test/property-entry-test.ko] undefined!
>
> Add EXPORT_SYMBOL_GPL(of_node_ktype) so that GPL-licensed modules
> such as the KUnit property-entry test can call of_node_init() without
> hitting this linker error.
Use special one for KUnits: EXPORT_SYMBOL_IF_KUNIT().
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: clock: renesas: Split out RZ/T2H CPG binding
From: Lad, Prabhakar @ 2026-07-20 11:13 UTC (permalink / raw)
To: Krzysztof Kozlowski, Geert Uytterhoeven
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Wim Van Sebroeck,
Guenter Roeck, Magnus Damm, linux-renesas-soc, linux-clk,
devicetree, linux-kernel, linux-watchdog, Prabhakar, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <2323f9bd-0b1e-41be-8c8d-6906b66b625f@kernel.org>
Hi Krzysztof,
On Mon, Jul 20, 2026 at 11:53 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 20/07/2026 12:50, Lad, Prabhakar wrote:
> > Hi Krzysztof,
> >
> > On Mon, Jul 20, 2026 at 6:55 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >> On Thu, Jul 16, 2026 at 01:34:27PM +0100, Prabhakar wrote:
> >>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >>>
> >>> Move the RZ/T2H and RZ/N2H clock controller bindings from the generic
> >>> renesas,cpg-mssr.yaml schema into a dedicated binding.
> >>>
> >>> Unlike the traditional Renesas CPG/MSSR block, the RZ/T2H and RZ/N2H
> >>> system controller integrates additional functionality beyond clock and
> >>> module-stop control, including reset control, clock monitor support,
> >>> write-protection registers and other system management features.
> >>
> >> Nothing of above differences got reflected in the code, so I do not
> >> understand this reasoning. Binding is exactly the same as the old one.
> >>
> > A syscon regmap is implemented [0] as part of the RZ/T2H CPG driver.
> > Since the RZ/T2H clock driver uses this syscon wrapper, a function
> > pointer is implemented to handle the RZ/T2H-specific configuration.
> >
> > Also, as the initial implementation used separate device tree nodes,
> > Geert suggested splitting this binding schema off into a dedicated
> > file [1].
> >
>
> I still miss the difference. Can you point me (can be short diff) to
> actual difference in this binding?
>
Fair enough! You're right that the schema text itself doesn't differ.
I'll drop this patch in v4 and leave the bindings in
renesas,cpg-mssr.yaml (unless Geert has a different opinion).
Cheers,
Prabhakar
^ permalink raw reply
* Re: [PATCH v7 09/10] arm64: dts: qcom: shikra: Enable WiFi/BT on SoMs
From: sashiko-bot @ 2026-07-20 11:15 UTC (permalink / raw)
To: Komal Bajaj; +Cc: robh, conor+dt, Frank.Li, vkoul, dmaengine, devicetree
In-Reply-To: <20260720-shikra-dt-m1-v7-9-7dc99100c6dd@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Incorrect voltage regulators are assigned to the WCN3988 PMU `vddio-supply` and WiFi `vdd-0.8-cx-mx-supply` rails, leading to severe under- and over-voltage risks.
--
--- Patch [9]: [PATCH v7 09/10] arm64: dts: qcom: shikra: Enable WiFi/BT on SoMs ---
commit 7b0dbc06276bce121a4707dc81431f18358503c8
Author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
arm64: dts: qcom: shikra: Enable WiFi/BT on SoMs
Shikra SoM cards include WCN3988 WiFi/Bluetooth chip, with supplies provided
by on-card PMICs. Enable both interfaces and provide the required supply and
calibration data.
> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
> --- a/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
[ ... ]
> @@ -27,6 +31,42 @@ key-volume-up {
> linux,can-disable;
> };
> };
> +
> + wcn3988-pmu {
> + compatible = "qcom,wcn3988-pmu";
> +
> + pinctrl-0 = <&sw_ctrl_default>;
> + pinctrl-names = "default";
> +
> + swctrl-gpios = <&tlmm 88 GPIO_ACTIVE_HIGH>;
> +
> + vddio-supply = <&pm4125_l7>;
[Severity: Critical]
Does this code assign a 0.664V regulator to a 1.8V supply in wcn3988-pmu?
The WCN3988 PMU's vddio-supply expects 1.8V, but pm4125_l7 is typically 0.664V.
Could this regression cause an undervoltage that prevents digital I/O
communication?
> + vddxo-supply = <&pm4125_l13>;
> + vddrf-supply = <&pm4125_l10>;
[ ... ]
> diff --git a/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi b/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
> --- a/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
[ ... ]
> +&wifi {
> + vdd-0.8-cx-mx-supply = <&pm8150_s4>;
[Severity: Critical]
Does this assignment cause an overvoltage regression in the wifi node?
The vdd-0.8-cx-mx-supply requires ~0.8V, but pm8150_s4 has a 1.08V to 2.04V
range (typically 1.8V), which could lead to hardware damage on the IQS SoM.
> + vdd-1.8-xo-supply = <&vreg_pmu_xo>;
> + vdd-1.3-rfa-supply = <&vreg_pmu_rf>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-shikra-dt-m1-v7-0-7dc99100c6dd@oss.qualcomm.com?part=9
^ permalink raw reply
* Re: [PATCH 3/4] iio: dac: ad5686: extend device support with new parts
From: Rodrigo Alencar @ 2026-07-20 11:16 UTC (permalink / raw)
To: Jonathan Cameron, Rodrigo Alencar via B4 Relay
Cc: Michael Auchter, linux, linux-iio, devicetree, linux-kernel,
Michael Hennerich, David Lechner, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260719224351.1af8aef9@jic23-huawei>
On 19/07/26 22:43, Jonathan Cameron wrote:
> On Sun, 19 Jul 2026 10:51:59 +0100
> Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
>
> > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > Add support for AD5313R, AD5317R, AD5674, AD5679, AD5687, AD5687R, AD5689,
> > AD5689R to the AD5686 SPI driver. Also adding support for AD5316R, AD5675,
> > AD5697R to the AD5696 I2C driver. AD5673R and AD5677R were missing from
> > the of_match table.
>
> Given I'm asking for a v2 anyway, please break out the missing of_match
> table entries as a precursor.
checkpatch complains adding stuff to of_match table without having the entry in
the dt-binding. I suppose the desired order for the changes would be:
clean ups:
- ad5696 dt-binding: adding support for the 'missing' entries.
- ad5696-i2c: add missing of_match entries
- Adjust reformat device list in file-comment headers and Kconfig
extend dev support:
- ad5686 dt-binding changes (new devices)
- ad5696 dt-binding changes (new devices)
- create new chip info's and populated device tables
- Add new devices to Kconfig option description
Does it sound reasonable?
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v3 0/4] phy: qcom: Introduce USB support for Hawi
From: Vinod Koul @ 2026-07-20 11:18 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Ronak Raheja, krzk+dt, conor+dt, robh, neil.armstrong, gregkh,
dmitry.baryshkov, konrad.dybcio, abel.vesa, wesley.cheng,
krzysztof.kozlowski, linux-arm-msm, linux-phy, devicetree,
linux-usb, linux-kernel
In-Reply-To: <chf57j2dkhhjzigpguldadfld5utepa4sxwbo7fjxk5nq37bhp@yci5agzh46ly>
On 13-07-26, 13:12, Manivannan Sadhasivam wrote:
> On Fri, May 08, 2026 at 02:32:30PM -0700, Ronak Raheja wrote:
> > This series adds USB PHY support for the Hawi SoC. It documents the
> > QMP USB3-DP combo PHY and M31 eUSB2 PHY bindings, adds the Hawi
> > compatible to the DWC3 USB binding, and adds the PHY initialization
> > sequences to the qmp-combo driver.
> >
>
> Vinod, does this series look good to you?
It doesnt apply for me, can you folks rebase and resend
--
~Vinod
^ 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