* Re: [PATCH 04/12] clk: qcom: gcc-mdm9607: Fix BIMC PLL definition
From: Konrad Dybcio @ 2026-06-16 10:52 UTC (permalink / raw)
To: Stephan Gerhold, Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Georgi Djakov,
Shawn Guo, Bryan O'Donoghue, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <aimlsgJssczxBGhQ@linaro.org>
On 6/10/26 7:58 PM, Stephan Gerhold wrote:
> On Wed, Jun 10, 2026 at 10:43:12PM +0530, Taniya Das wrote:
>> On 6/9/2026 7:44 PM, Stephan Gerhold wrote:
>>> The gcc-mdm9607 driver was originally based on gcc-msm8916, but a closer
>>> match nowadays is gcc-msm8909. Looking at the differences between
>>> gcc-mdm9607 and gcc-msm8909, there is quite some confusion around the
>>> definitions for the BIMC PLL.
>>>
>>> It turns out the BIMC PLL on MDM9607 is actually an Alpha PLL just like on
>>> MSM8909. We can vote for it using BIT(2), which explains why BIT(3) was
>>> used for GPLL2.
>>
>> BIMC PLL is never controlled from High Level OS (APSS). These are
>> controlled by other subsystems and voting should be via the ICC for BW
>> requirements.
>>
>
> The driver doesn't really control the BIMC PLL here, the PLL is defined
> with fixed/shared/read-only ops so it mostly just exists to model the
> clock tree properly and have the clock rate readable for the PLL itself
> and any downstream consumers.
>
> There are multiple drivers that do it like this (e.g. gcc-msm8916,
> gcc-msm8939), is there a reason why we should drop this?
My fear is that the kernel may have stale data at any point.. perhaps
unless we set CLK_GET_RATE_NOCACHE?
Konrad
^ permalink raw reply
* [PATCH] arm64: dts: imx93-kontron: Fix memory node
From: Frieder Schrempf @ 2026-06-16 10:43 UTC (permalink / raw)
To: Conor Dooley, devicetree, Frank Li, Frieder Schrempf, imx,
Krzysztof Kozlowski, linux-arm-kernel, linux-kernel, Rob Herring,
Sascha Hauer, Shawn Guo
Cc: Fabio Estevam, Pengutronix Kernel Team
From: Frieder Schrempf <frieder.schrempf@kontron.de>
The start address of the DRAM area is 0x80000000. The minimal
size of the DDR on the SoM is 1 GiB. Fix this.
Fixes: 2b52fd6035b7 ("arm64: dts: Add support for Kontron i.MX93 OSM-S SoM and BL carrier board")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
arch/arm64/boot/dts/freescale/imx93-kontron-osm-s.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx93-kontron-osm-s.dtsi b/arch/arm64/boot/dts/freescale/imx93-kontron-osm-s.dtsi
index c79b1df339db..f881912cde46 100644
--- a/arch/arm64/boot/dts/freescale/imx93-kontron-osm-s.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93-kontron-osm-s.dtsi
@@ -15,9 +15,9 @@ aliases {
rtc1 = &bbnsm_rtc;
};
- memory@40000000 {
+ memory@80000000 {
device_type = "memory";
- reg = <0x0 0x40000000 0 0x80000000>;
+ reg = <0x0 0x80000000 0 0x40000000>;
};
chosen {
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3 11/12] iio: dac: ad5686: read_raw/write_raw: use guard(mutex)()
From: Rodrigo Alencar @ 2026-06-16 10:50 UTC (permalink / raw)
To: Andy Shevchenko, rodrigo.alencar
Cc: Michael Auchter, linux, linux-iio, devicetree, linux-kernel,
linux-hardening, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Kees Cook, Gustavo A. R. Silva,
Maxwell Doose, Joshua Crofts
In-Reply-To: <ajEo5pOp3ElX4cP7@ashevche-desk.local>
On 16/06/26 13:43, Andy Shevchenko wrote:
> On Tue, Jun 16, 2026 at 09:21:17AM +0100, Rodrigo Alencar via B4 Relay wrote:
>
> > Use guarded mutex lock to facilitate code review when adding new
> > attributes. This will allow for early returns, avoiding error-prone
> > locking and unlocking in error paths. This also adds missing include
> > linux/cleanup.h. Gain-control support will allow the scale attribute
> > to be configurable.
>
> What about interrupt handler? You just added yet another mutex lock/unlock
> there. Perhaps this patch should be done before the previous one?
Can't add the guard(mutex)() in the trigger handler because of the goto.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* [PATCH V1] arm64: dts: imx8mq-evk: add uart3 and bluetooth node
From: Sherry Sun (OSS) @ 2026-06-16 10:52 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam
Cc: imx, devicetree, linux-arm-kernel, linux-kernel, sherry.sun
From: Sherry Sun <sherry.sun@nxp.com>
Add uart3 and bluetooth node.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 22 ++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index e7d87ea81b69..b9b03416aa39 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -498,6 +498,19 @@ &uart1 {
status = "okay";
};
+&uart3 { /* BT */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ assigned-clocks = <&clk IMX8MQ_CLK_UART3>;
+ assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
&usb3_phy1 {
status = "okay";
};
@@ -657,6 +670,15 @@ MX8MQ_IOMUXC_UART1_TXD_UART1_DCE_TX 0x49
>;
};
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX8MQ_IOMUXC_UART3_TXD_UART3_DCE_TX 0x49
+ MX8MQ_IOMUXC_UART3_RXD_UART3_DCE_RX 0x49
+ MX8MQ_IOMUXC_ECSPI1_MISO_UART3_DCE_CTS_B 0x49
+ MX8MQ_IOMUXC_ECSPI1_SS0_UART3_DCE_RTS_B 0x49
+ >;
+ };
+
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
MX8MQ_IOMUXC_SD1_CLK_USDHC1_CLK 0x83
base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v3 12/12] iio: dac: ad5686: add gain control support
From: Andy Shevchenko @ 2026-06-16 10:47 UTC (permalink / raw)
To: rodrigo.alencar
Cc: Michael Auchter, linux, linux-iio, devicetree, linux-kernel,
linux-hardening, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20260616-ad5686-new-features-v3-12-f829fb7e9262@analog.com>
On Tue, Jun 16, 2026 at 09:21:18AM +0100, Rodrigo Alencar via B4 Relay wrote:
> Most of the supported devices rely on a GAIN pin to control a 2x
> multiplier applied to the output voltage. Other devices, e.g. the
> single-channel ones, provides a gain control through a bit field in
> the control register. Some designs might have the GAIN pin hardwired
> to VDD/VLOGIC or GND, which would have no "gain-gpios" device property,
> being able to set "adi,range-double" if it is hardwired to VDD. The
> vref_mv field is moved down in the struct ad5686_state, so that the
> overall size increase is reduced.
...
> +static void ad5686_init_scale_avail(struct ad5686_state *st)
> +{
> + int realbits = st->chip_info->channels[0].scan_type.realbits;
> + s64 tmp = 2ULL * st->vref_mv * NANO >> realbits;
As Nuno noticed in other patch review, this can probably use mul_u64_u32_shr().
> + st->scale_avail[2] = div_s64_rem(tmp, NANO, &st->scale_avail[3]);
> + st->scale_avail[0] = div_s64_rem(tmp >> 1, NANO, &st->scale_avail[1]);
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 10/10] arm64: dts: renesas: r9a08g046l48-smarc: Add USB2.0 support
From: Biju @ 2026-06-16 10:44 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Biju Das, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Biju Das
In-Reply-To: <20260616104459.410743-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Enable USB2.0 on the RZ/G3L SMARC board (r9a08g046l48-smarc).
Port 0 (ehci0, ohci0, usb2_phy0) is configured as OTG with
usb0_pins pinmux (USB20_OVRCUR, USB20_VBUSEN) and usb0_vbus_otg
as the VBUS supply. Port 1 (ehci1, ohci1, usb2_phy1) is configured
as host-only with usb1_pins pinmux (USB21_OVRCUR, USB21_VBUSEN),
usb1_vbus_otg as the VBUS supply, and renesas,no-otg-pins set to
indicate no OTG pin routing. The phyrst USB PHY reset controller is
also enabled.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v1->v2:
* Updated commit description.
---
.../boot/dts/renesas/r9a08g046l48-smarc.dts | 49 +++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts b/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
index 96cc7ee46a6a..b189ae8e808d 100644
--- a/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
+++ b/arch/arm64/boot/dts/renesas/r9a08g046l48-smarc.dts
@@ -87,6 +87,16 @@ vqmmc_sd1_pvdd: regulator-vqmmc-sd1-pvdd {
#endif
};
+&ehci0 {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&ehci1 {
+ dr_mode = "host";
+ status = "okay";
+};
+
&i2c2 {
pinctrl-0 = <&i2c2_pins>;
pinctrl-names = "default";
@@ -138,6 +148,20 @@ &keys {
#endif
};
+&ohci0 {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&ohci1 {
+ dr_mode = "host";
+ status = "okay";
+};
+
+&phyrst {
+ status = "okay";
+};
+
&pinctrl {
audio_clk_pins: audio-clock {
pinmux = <RZG3L_PORT_PINMUX(H, 4, 6)>, /* AUDIO_CLK_B */
@@ -259,6 +283,16 @@ ssi0_pins: ssi0 {
<RZG3L_PORT_PINMUX(H, 2, 9)>, /* SSIF0_RCK */
<RZG3L_PORT_PINMUX(H, 3, 9)>; /* SSIF0_TXD */
};
+
+ usb0_pins: usb0 {
+ pinmux = <RZG3L_PORT_PINMUX(3, 0, 12)>, /* USB20_OVRCUR */
+ <RZG3L_PORT_PINMUX(3, 1, 12)>; /* USB20_VBUSEN */
+ };
+
+ usb1_pins: usb1 {
+ pinmux = <RZG3L_PORT_PINMUX(3, 4, 12)>, /* USB21_OVRCUR */
+ <RZG3L_PORT_PINMUX(3, 5, 12)>; /* USB21_VBUSEN */
+ };
};
#if SW_SER0_PMOD
@@ -330,3 +364,18 @@ &ssi0 {
status = "okay";
};
#endif
+
+&usb2_phy0 {
+ pinctrl-0 = <&usb0_pins>;
+ pinctrl-names = "default";
+ vbus-supply = <&usb0_vbus_otg>;
+ status = "okay";
+};
+
+&usb2_phy1 {
+ pinctrl-0 = <&usb1_pins>;
+ pinctrl-names = "default";
+ vbus-supply = <&usb1_vbus_otg>;
+ renesas,no-otg-pins;
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 09/10] arm64: dts: renesas: r9a08g046: Add USB2.0 device nodes
From: Biju @ 2026-06-16 10:44 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Biju Das, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Biju Das
In-Reply-To: <20260616104459.410743-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Add USB2.0 device nodes to the RZ/G3L (r9a08g046) SoC DTSI, covering
the USB PHY controller, OHCI/EHCI host controllers, and USB2 PHYs for
both ports.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v1->v2:
* Updated commit description.
* Added regulators group node and its children.
---
arch/arm64/boot/dts/renesas/r9a08g046.dtsi | 105 +++++++++++++++++++++
1 file changed, 105 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a08g046.dtsi b/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
index 85e409ac8d5c..926a81cec37e 100644
--- a/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a08g046.dtsi
@@ -1198,6 +1198,111 @@ queue3 {
};
};
+ phyrst: usbphy-ctrl@11e00000 {
+ compatible = "renesas,r9a08g046-usbphy-ctrl";
+ reg = <0 0x11e00000 0 0x10000>;
+ clocks = <&cpg CPG_MOD R9A08G046_USB_PCLK>;
+ resets = <&cpg R9A08G046_USB_PRESETN>;
+ power-domains = <&cpg>;
+ #reset-cells = <1>;
+ renesas,sysc-pwrrdy = <&sysc 0xd70 0x1>;
+ status = "disabled";
+
+ regulators {
+ usb0_vbus_otg: vbus0 {
+ regulator-name = "usb0_vbus";
+ };
+
+ usb1_vbus_otg: vbus1 {
+ regulator-name = "usb1_vbus";
+ };
+ };
+ };
+
+ ohci0: usb@11e10000 {
+ compatible = "generic-ohci";
+ reg = <0 0x11e10000 0 0x100>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A08G046_USB_PCLK>,
+ <&cpg CPG_MOD R9A08G046_USB_U2H0_HCLK>;
+ resets = <&phyrst 0>,
+ <&cpg R9A08G046_USB_U2H0_HRESETN>;
+ phys = <&usb2_phy0 1>;
+ phy-names = "usb";
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
+ ohci1: usb@11e90000 {
+ compatible = "generic-ohci";
+ reg = <0 0x11e90000 0 0x100>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A08G046_USB_PCLK>,
+ <&cpg CPG_MOD R9A08G046_USB_U2H1_HCLK>;
+ resets = <&phyrst 1>,
+ <&cpg R9A08G046_USB_U2H1_HRESETN>;
+ phys = <&usb2_phy1 1>;
+ phy-names = "usb";
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
+ ehci0: usb@11e10100 {
+ compatible = "generic-ehci";
+ reg = <0 0x11e10100 0 0x100>;
+ interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A08G046_USB_PCLK>,
+ <&cpg CPG_MOD R9A08G046_USB_U2H0_HCLK>;
+ resets = <&phyrst 0>,
+ <&cpg R9A08G046_USB_U2H0_HRESETN>;
+ phys = <&usb2_phy0 2>;
+ phy-names = "usb";
+ companion = <&ohci0>;
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
+ ehci1: usb@11e90100 {
+ compatible = "generic-ehci";
+ reg = <0 0x11e90100 0 0x100>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A08G046_USB_PCLK>,
+ <&cpg CPG_MOD R9A08G046_USB_U2H1_HCLK>;
+ resets = <&phyrst 1>,
+ <&cpg R9A08G046_USB_U2H1_HRESETN>;
+ phys = <&usb2_phy1 2>;
+ phy-names = "usb";
+ companion = <&ohci1>;
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
+ usb2_phy0: usb-phy@11e10200 {
+ compatible = "renesas,usb2-phy-r9a08g046";
+ reg = <0 0x11e10200 0 0x700>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A08G046_USB_PCLK>,
+ <&cpg CPG_MOD R9A08G046_USB_U2H0_HCLK>;
+ resets = <&phyrst 0>,
+ <&cpg R9A08G046_USB_U2H0_HRESETN>;
+ #phy-cells = <1>;
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
+ usb2_phy1: usb-phy@11e90200 {
+ compatible = "renesas,usb2-phy-r9a08g046";
+ reg = <0 0x11e90200 0 0x700>;
+ interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD R9A08G046_USB_PCLK>,
+ <&cpg CPG_MOD R9A08G046_USB_U2H1_HCLK>;
+ resets = <&phyrst 1>,
+ <&cpg R9A08G046_USB_U2H1_HRESETN>;
+ #phy-cells = <1>;
+ power-domains = <&cpg>;
+ status = "disabled";
+ };
+
pcie: pcie@11e40000 {
reg = <0 0x11e40000 0 0x10000>;
ranges = <0x02000000 0 0x30000000 0 0x30000000 0 0x08000000>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 02/10] dt-bindings: phy: renesas,usb2-phy: Document RZ/G3L PHY bindings
From: Biju @ 2026-06-16 10:44 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, Neil Armstrong, Yoshihiro Shimoda, linux-phy,
devicetree, linux-kernel, linux-renesas-soc,
Prabhakar Mahadev Lad, Biju Das, Krzysztof Kozlowski
In-Reply-To: <20260616104459.410743-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Add device tree binding support for the RZ/G3L (r9a08g046) USB2 PHY.
The RZ/G3L USB PHY is almost identical to the RZ/G3S USB PHY, the
difference being 2 OTG blocks on RZ/G3L compared to 1 on RZ/G3S.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v1->v2:
* Collected tag.
---
Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
index 9740e5b335f9..d6b9d08ceec6 100644
--- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml
@@ -16,6 +16,7 @@ properties:
- enum:
- renesas,usb2-phy-r8a77470 # RZ/G1C
- renesas,usb2-phy-r9a08g045 # RZ/G3S
+ - renesas,usb2-phy-r9a08g046 # RZ/G3L
- renesas,usb2-phy-r9a09g057 # RZ/V2H(P)
- items:
@@ -132,6 +133,7 @@ allOf:
enum:
- renesas,usb2-phy-r9a09g057
- renesas,usb2-phy-r9a08g045
+ - renesas,usb2-phy-r9a08g046
- renesas,rzg2l-usb2-phy
then:
properties:
--
2.43.0
^ permalink raw reply related
* [PATCH v2 01/10] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3L support
From: Biju @ 2026-06-16 10:44 UTC (permalink / raw)
To: Philipp Zabel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, devicetree, linux-kernel, linux-renesas-soc,
Prabhakar Mahadev Lad, Biju Das
In-Reply-To: <20260616104459.410743-1-biju.das.jz@bp.renesas.com>
From: Biju Das <biju.das.jz@bp.renesas.com>
Document Renesas RZ/G3L (r9a08g046) USB PHY controller bindings.
The RZ/G3L USB PHY block is similar to RZ/G3S but differs in that each
port has its own OTG controller, whereas RZ/G3S only has one on port 1.
To reflect this, RZ/G3L uses a regulators sub-node with per-port vbus0
and vbus1 entries instead of the single regulator-vbus property used
by other compatible SoCs.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
v1->v2:
* Updated commit description.
* Added enum instead of const in the compatible section.
* Dropped regulator1-vbus and added a regulators group node.
* Updated schema check.
---
.../reset/renesas,rzg2l-usbphy-ctrl.yaml | 49 +++++++++++++++++--
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
index c83469a1b379..12da48d069e5 100644
--- a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
+++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml
@@ -16,13 +16,17 @@ description:
properties:
compatible:
oneOf:
+ - items:
+ - enum:
+ - renesas,r9a08g045-usbphy-ctrl # RZ/G3S
+ - renesas,r9a08g046-usbphy-ctrl # RZ/G3L
+
- items:
- enum:
- renesas,r9a07g043-usbphy-ctrl # RZ/G2UL and RZ/Five
- renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC}
- renesas,r9a07g054-usbphy-ctrl # RZ/V2L
- const: renesas,rzg2l-usbphy-ctrl
- - const: renesas,r9a08g045-usbphy-ctrl # RZ/G3S
reg:
maxItems: 1
@@ -50,6 +54,28 @@ properties:
$ref: /schemas/regulator/regulator.yaml#
unevaluatedProperties: false
+ regulators:
+ type: object
+ description:
+ list of vbus regulators provided by this controller.
+
+ properties:
+ vbus0:
+ type: object
+ description: Port 1 USB VBUS regulator
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ vbus1:
+ type: object
+ description: Port 2 USB VBUS regulator
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+
+ required:
+ - vbus0
+ - vbus1
+
renesas,sysc-pwrrdy:
description:
The system controller PWRRDY indicates to the USB PHY if the power supply
@@ -71,14 +97,15 @@ required:
- resets
- power-domains
- '#reset-cells'
- - regulator-vbus
allOf:
- if:
properties:
compatible:
contains:
- const: renesas,r9a08g045-usbphy-ctrl
+ enum:
+ - renesas,r9a08g045-usbphy-ctrl
+ - renesas,r9a08g046-usbphy-ctrl
then:
required:
- renesas,sysc-pwrrdy
@@ -86,6 +113,22 @@ allOf:
properties:
renesas,sysc-pwrrdy: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a08g046-usbphy-ctrl
+ then:
+ properties:
+ regulator-vbus: false
+ required:
+ - regulators
+ else:
+ properties:
+ regulators: false
+ required:
+ - regulator-vbus
+
additionalProperties: false
examples:
--
2.43.0
^ permalink raw reply related
* [PATCH v2 00/10] Add RZ/G3L USB2.0 host support
From: Biju @ 2026-06-16 10:44 UTC (permalink / raw)
To: Philipp Zabel, Vinod Koul, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Liam Girdwood, Mark Brown, Magnus Damm
Cc: Biju Das, Neil Armstrong, Yoshihiro Shimoda, linux-phy,
devicetree, linux-kernel, linux-clk, linux-renesas-soc,
Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
Add device tree binding support for the RZ/G3L (r9a08g046) USB PHY
controller. The RZ/G3L USB PHY block is similar to RZ/G3S, but each port
has an OTG controller, unlike RZ/G3S, which has an OTG controller only on
port 1.
v1->v2:
* Dropped patch#6(Introduce helper for regulator registration)
* Passing pointer to an array of regulators to make it scalable.
* Dropped regulator1-vbus and added a regulators group node.
* Updated commit description for patch#1,#4,#6,#7,#8,#9 and #10.
* Added enum instead of const in the compatible section.
* Updated schema check.
* Collected tag for PHY binding patch.
in the regulator driver.
* Added regulators group node and its children in SoC dtsi.
Biju Das (10):
dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3L support
dt-bindings: phy: renesas,usb2-phy: Document RZ/G3L PHY bindings
clk: renesas: r9a08g046: Add USB2.0 clock and reset entries
reset: rzg2l-usbphy-ctrl: Introduce info struct for match data
reset: rzg2l-usbphy-ctrl: Add RZ/G3L support
regulator: renesas-usb-vbus-regulator: Add RZ/G3L VBUS regulator
support
phy: renesas: phy-rcar-gen3-usb2: Add RZ/G3L support
phy: renesas: phy-rcar-gen3-usb2: Fix devm action registration for
disabled VBUS regulator
arm64: dts: renesas: r9a08g046: Add USB2.0 device nodes
arm64: dts: renesas: r9a08g046l48-smarc: Add USB2.0 support
.../bindings/phy/renesas,usb2-phy.yaml | 2 +
.../reset/renesas,rzg2l-usbphy-ctrl.yaml | 49 +++++++-
arch/arm64/boot/dts/renesas/r9a08g046.dtsi | 105 ++++++++++++++++++
.../boot/dts/renesas/r9a08g046l48-smarc.dts | 49 ++++++++
drivers/clk/renesas/r9a08g046-cpg.c | 15 +++
drivers/phy/renesas/phy-rcar-gen3-usb2.c | 20 ++--
.../regulator/renesas-usb-vbus-regulator.c | 53 +++++++++
drivers/reset/reset-rzg2l-usbphy-ctrl.c | 44 +++++---
8 files changed, 312 insertions(+), 25 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v3 11/12] iio: dac: ad5686: read_raw/write_raw: use guard(mutex)()
From: Andy Shevchenko @ 2026-06-16 10:43 UTC (permalink / raw)
To: rodrigo.alencar
Cc: Michael Auchter, linux, linux-iio, devicetree, linux-kernel,
linux-hardening, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Kees Cook, Gustavo A. R. Silva,
Maxwell Doose, Joshua Crofts
In-Reply-To: <20260616-ad5686-new-features-v3-11-f829fb7e9262@analog.com>
On Tue, Jun 16, 2026 at 09:21:17AM +0100, Rodrigo Alencar via B4 Relay wrote:
> Use guarded mutex lock to facilitate code review when adding new
> attributes. This will allow for early returns, avoiding error-prone
> locking and unlocking in error paths. This also adds missing include
> linux/cleanup.h. Gain-control support will allow the scale attribute
> to be configurable.
What about interrupt handler? You just added yet another mutex lock/unlock
there. Perhaps this patch should be done before the previous one?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 10/12] iio: dac: ad5686: add triggered buffer support
From: Andy Shevchenko @ 2026-06-16 10:42 UTC (permalink / raw)
To: rodrigo.alencar
Cc: Michael Auchter, linux, linux-iio, devicetree, linux-kernel,
linux-hardening, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20260616-ad5686-new-features-v3-10-f829fb7e9262@analog.com>
On Tue, Jun 16, 2026 at 09:21:16AM +0100, Rodrigo Alencar via B4 Relay wrote:
> Implement trigger handler by leveraging the LDAC gpio to update all DAC
> channels at once when it is available. Also, the multiple channel writes
> can be flushed at once with the sync() operation.
...
> +static irqreturn_t ad5686_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio_dev = pf->indio_dev;
> + struct iio_buffer *buffer = indio_dev->buffer;
> + struct ad5686_state *st = iio_priv(indio_dev);
> + u16 val[AD5686_MAX_CHANNELS] = { };
> + unsigned int scan_count;
> + int ret, ch, i = 0;
Decouple assignment and definition. Also do 'i' and 'ch' need to be signed?
> + bool async_update;
> + u8 cmd;
> +
> + ret = iio_pop_from_buffer(buffer, val);
> + if (ret)
> + goto out_notify_done;
> +
> + mutex_lock(&st->lock);
> +
> + scan_count = bitmap_weight(indio_dev->active_scan_mask,
> + iio_get_masklength(indio_dev));
> + async_update = st->ldac_gpio && scan_count > 1;
> + if (async_update) {
> + /* use LDAC to update all channels simultaneously */
> + cmd = AD5686_CMD_WRITE_INPUT_N;
> + gpiod_set_value_cansleep(st->ldac_gpio, 0);
> + } else {
> + cmd = AD5686_CMD_WRITE_INPUT_N_UPDATE_N;
> + }
> +
> + iio_for_each_active_channel(indio_dev, ch) {
> + ret = st->ops->write(st, cmd, indio_dev->channels[ch].address, val[i++]);
> + if (ret)
> + break;
> + }
> +
> + /*
> + * If sync() is available, it is called here regardless of write
> + * failure to allow bus implementation to reset. In that case, partial
> + * writes are unlikely as the write operations would just queue up
> + * the transfers.
> + */
> + if (st->ops->sync)
> + ret = st->ops->sync(st); /* flush all pending transfers */
'ret' is set but not used. Always compile your code with `make W=1` and both
GCC and clang.
> + if (async_update)
> + gpiod_set_value_cansleep(st->ldac_gpio, 1);
> +
> + mutex_unlock(&st->lock);
> +out_notify_done:
> + iio_trigger_notify_done(indio_dev->trig);
> +
> + return IRQ_HANDLED;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v9 1/2] dt-bindings: ufs: Document static TX Equalization settings properties
From: Peter Wang (王信友) @ 2026-06-16 10:36 UTC (permalink / raw)
To: beanhuo@micron.com, mani@kernel.org, can.guo@oss.qualcomm.com,
bvanassche@acm.org, krzk@kernel.org, martin.petersen@oracle.com
Cc: avri.altman@wdc.com, zhml@posteo.com, linux-scsi@vger.kernel.org,
robh@kernel.org, linux-kernel@vger.kernel.org, krzk+dt@kernel.org,
alim.akhtar@samsung.com, quic_rdwivedi@quicinc.com,
conor+dt@kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20260615132834.2985346-2-can.guo@oss.qualcomm.com>
On Mon, 2026-06-15 at 06:28 -0700, Can Guo wrote:
> UFS v5.0/UFSHCI v5.0 adds HS-G6 support (46.6 Gbps/lane) via UniPro
> v3.0 and M-PHY v6.0. These specs define TX Equalization for all
> High-Speed Gears (not only HS-G6) to compensate channel loss and
> improve signal integrity at high speed.
>
> For HS-G6, M-PHY uses PAM4 1b1b line coding. Pre-Coding may also be
> required depending on channel characteristics.
>
> Document vendor-neutral properties in ufs-common.yaml:
> - txeq-preshoot-g[1-6]
> - txeq-deemphasis-g[1-6]
> - tx-precode-enable-g6
>
> Values are per-lane Host/Device tuples (2 values for x1, 4 values for
> x2). PreShoot/DeEmphasis range from 0..7, and Precode is 0/1.
>
> These are board-specific signal-integrity tuning values. They depend
> on
> channel SI/PHY characterization and validation (host PHY, device PHY,
> package, and board routing), and are determined by HW/PHY designers.
>
> Although UFSHCI v5.0 supports TX Equalization Training via UniPro
> v3.0,
> which allows host software to determine optimal TX Equalization at
> runtime, static board-specific TX Equalization settings in the Device
> Tree are still necessary because:
> - TX Equalization Training is not supported for HS-G3 and below
> - TX Equalization Training is disabled on some platforms
>
> Signed-off-by: Can Guo <can.guo@oss.qualcomm.com>
> ---
Reviewed-by: Peter Wang <peter.wang@mediatek.com>
^ permalink raw reply
* Re: [PATCH v3 09/12] iio: dac: ad5686: implement new sync() op for the spi bus
From: Andy Shevchenko @ 2026-06-16 10:35 UTC (permalink / raw)
To: rodrigo.alencar
Cc: Michael Auchter, linux, linux-iio, devicetree, linux-kernel,
linux-hardening, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20260616-ad5686-new-features-v3-9-f829fb7e9262@analog.com>
On Tue, Jun 16, 2026 at 09:21:15AM +0100, Rodrigo Alencar via B4 Relay wrote:
> Use of local SPI bus data to manage a collection of SPI transfers and
> flush them to the SPI platform driver with the sync() operation. This
> allows for faster handling of multiple channel DAC writes, avoiding kernel
> overhead per spi_sync() call, which will be helpful when enabling
> triggered buffer support.
...
> static int ad5686_spi_probe(struct spi_device *spi)
> {
> - return ad5686_probe(&spi->dev, spi_get_device_match_data(spi),
> - spi->modalias, &ad5686_spi_ops);
> + const struct ad5686_chip_info *info = spi_get_device_match_data(spi);
Sashiko might still complain on driver_override case, which means we need to
add a NULL check (or is NULL fine?).
> + struct ad5686_spi_data *bus_data;
> + struct device *dev = &spi->dev;
> + unsigned int capacity;
> +
> + /* read operation requires at least 2 transfers */
> + capacity = max(info->num_channels, 2);
> + bus_data = devm_kzalloc(dev, struct_size(bus_data, xfers, capacity),
> + GFP_KERNEL);
> + if (!bus_data)
> + return -ENOMEM;
> +
> + bus_data->capacity = capacity;
> +
> + return ad5686_probe(dev, info, spi->modalias, &ad5686_spi_ops, bus_data);
> }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 07/12] iio: dac: ad5686: add ldac gpio
From: Andy Shevchenko @ 2026-06-16 10:32 UTC (permalink / raw)
To: rodrigo.alencar
Cc: Michael Auchter, linux, linux-iio, devicetree, linux-kernel,
linux-hardening, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20260616-ad5686-new-features-v3-7-f829fb7e9262@analog.com>
On Tue, Jun 16, 2026 at 09:21:13AM +0100, Rodrigo Alencar via B4 Relay wrote:
> If wired LDAC, should be held low when unused (pin is active-low), which
> allows for synchronous DAC updates. This will be used to update all the
> channels at the same time when adding buffer support.
...
> +struct gpio_desc;
+ blank line to decouple generic declarations from local ones?
> struct ad5686_state;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 2/3] counter: add GPIO-based quadrature encoder driver
From: William Breathitt Gray @ 2026-06-16 10:30 UTC (permalink / raw)
To: Wadim Mueller
Cc: William Breathitt Gray, Krzysztof Kozlowski, Rob Herring,
Conor Dooley, linux-iio, devicetree, linux-kernel
In-Reply-To: <2u2lqetlfph2leoggp6d7sxqv4toxpnsts2f2zgq3pwt7ae4ol@ploty2jwm3t3>
On Sun, May 24, 2026 at 09:35:45PM +0200, Wadim Mueller wrote:
> On 2026-05-21 09:26, William Breathitt Gray wrote:
> > From: Wadim Mueller <wafgo01@gmail.com>
> >
> > On Wed, May 20, 2026 at 01:45:20PM +0900, William Breathitt Gray wrote:
> > > On Fri, May 15, 2026 at 05:36:15PM +0200, Wadim Mueller wrote:
> > > > +static int gpio_qenc_a_delta(struct gpio_qenc_priv *priv, int a, int b,
> > > > + int prev_a, int prev_b)
> > > > +{
> > > > + int state = CREATE_QE_STATE(prev_a, prev_b, a, b);
> > > > +
> > > > + switch (priv->function) {
> > > > + case COUNTER_FUNCTION_QUADRATURE_X4:
> > > > + return gpio_qenc_quad_x4_table[state];
> > > > +
> > > > + case COUNTER_FUNCTION_QUADRATURE_X2_A:
> > > > + /* Both edges of A; sign comes from current A vs B. */
> > > > + return (a == b) ? -1 : 1;
> > > > +
> > > > + case COUNTER_FUNCTION_QUADRATURE_X1_A:
> > > > + /* Rising edge of A only. */
> > > > + if (!prev_a && a)
> > > > + return b ? -1 : 1;
> > > > + return 0;
> > >
> > > Quadrature X1 count modes trigger on the falling edge when the direction
> > > is backward. This isn't simply a requirement by definition, but
> > > necessary for the proper interpretation of the quadrature encoding.
> > >
> > > Let's evaluate an incremental encoder used in a positioning application
> > > as typical use case.[^1] These are commonly implemented using a rotating
> > > shaft with a quadrature-offset pattern; aligned sensors detect the
> > > physical A/B pattern as the shaft rotates.[^2] As the shaft rotates a
> > > quadrature encoding emerges whose A-B phase difference allows us to
> > > determine direction: forward when rising edge of signal A leads B, and
> > > backward when it trails.[^3]
> > >
> > > Now consider what happens to the signals when the rotation changes
> > > direction: there is a phase change between Signals A and B.[^4] The A/B
> > > pattern on the shaft is physically present so it has not changed; rather
> > > the pattern is now fed backwards to the sensors due to the direction
> > > reversal. The key point is the physical boundaries of the pattern are
> > > located in the same shaft positions they have always been, yet the
> > > signal edges representing those boundaries have flipped as a result of
> > > the direction change: positions marked by rising edges now appear as
> > > falling edges.
> > >
> > > In Quadrature X4 and X2, the pattern reversal doesn't affect positioning
> > > because we count on both edges, so swapping rising and falling edges
> > > nets the same position count. Quadrature X1 presents a problem because
> > > we count on a single edge type, so a phase-difference in the encoding
> > > results in a physical shift in real-life position. The way to account
> > > for that phase shift is to swap counting to the other edge type when the
> > > direction changes. That's how dedicated quadrature encoder devices solve
> > > this problem.
> > >
> > > I'm not sure of the best way to solve the Quadrature X1 problem in this
> > > driver. Right now we fire off interrupts on both edges, so perhaps
> > > there's a way for us to determine whether we're firing on a rising edge
> > > or falling edge and evaluate accordingly. Does the GPIO subsystem
> > > provide an indication for which edge triggered the interrupt? Or would
> > > it make sense to provide two interrupt service routines (one on rising
> > > edge and one on falling edge) and handle it that way?
> >
> > The simplest method might be to evaluate the current GPIO level to
> > determine the edge polarity. Because we trigger on both edges, we can
> > assume a high level means a low-high transition (rising edge) and a low
> > level means a high-low transition (falling edge).
> >
> > Using that assumption, we can implement the Quadrature X1 case by
> > checking the current state and direction, and adjusting the counting
> > accordingly when applicable: count up if rising edge and forward
> > direction, and count down if falling edge and backward direction.
> >
>
> Implemented in following v5 as suggested in both signal-A and signal-B ISRs.
Hello Wadim,
I apologize again for the delays in my responses. I'm currently
reviewing your v5 submission, but I do have a question below.
> One
> caveat I called out in the source: in pure X1 mode the driver never
> sees both edges of both signals, so direction is whatever the last
> X4/X2 sample produced (or whatever userspace set via sysfs). In
> practice X1 fits applications that already know the direction or
> that have just calibrated in X4.
Wouldn't the driver see both edges of both signals in X1 mode? The
ISR callbacks (gpio_counter_a_isr and gpio_counter_b_isr) execute on
both edges of their respective Signals (A and B). The driver can use
GPIO_COUNTER_GET_DIRECTION() to get the current quadrature direction and
update priv->direction accordingly during each ISR.
In that way, any quadrature mode selected will always be capable of
knowing its current direction regardless of whether it's X4, X2, or X1.
William Breathitt Gray
^ permalink raw reply
* Re: [PATCH v4 11/12] hwmon: spd5118: Add I3C support
From: sashiko-bot @ 2026-06-16 10:30 UTC (permalink / raw)
To: Akhil R; +Cc: robh, devicetree, conor+dt, linux-hwmon, linux-i3c, Frank.Li
In-Reply-To: <20260616095429.3947205-12-akhilrajeev@nvidia.com>
> Add a regmap config and a probe function to support I3C-based
> communication with SPD5118 devices.
>
> On an I3C bus, SPD5118 devices are enumerated via SETAASA and always
> require an ACPI or device tree entry. Device matching is hence through
> the OF match tables only and does not need an I3C class match table. The
> device identity is verified in the type registers before proceeding to
> the common probe function.
>
> Acked-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616095429.3947205-1-akhilrajeev@nvidia.com?part=11
^ permalink raw reply
* Re: [PATCH v3 06/12] iio: dac: ad5686: consume optional reset signal
From: Andy Shevchenko @ 2026-06-16 10:30 UTC (permalink / raw)
To: rodrigo.alencar
Cc: Michael Auchter, linux, linux-iio, devicetree, linux-kernel,
linux-hardening, Michael Hennerich, Jonathan Cameron,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20260616-ad5686-new-features-v3-6-f829fb7e9262@analog.com>
On Tue, Jun 16, 2026 at 09:21:12AM +0100, Rodrigo Alencar via B4 Relay wrote:
> Add RESET pin GPIO support through an optional reset control, which is
> local to the probe function. A reset pulse is manually generated after
> the device is powered up.
...
> + fsleep(1); /* reset pulse: comfortably bigger than the spec */
What spec? Same comment basically, extend with the reference to the datasheet.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 05/12] iio: dac: ad5686: add support for missing power supplies
From: Andy Shevchenko @ 2026-06-16 10:29 UTC (permalink / raw)
To: Joshua Crofts
Cc: Rodrigo Alencar via B4 Relay, rodrigo.alencar, Michael Auchter,
linux, linux-iio, devicetree, linux-kernel, linux-hardening,
Michael Hennerich, Jonathan Cameron, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20260616113322.00005273@gmail.com>
On Tue, Jun 16, 2026 at 11:33:22AM +0200, Joshua Crofts wrote:
> On Tue, 16 Jun 2026 09:21:11 +0100
> Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
...
> > st->use_internal_vref = ret == -ENODEV;
> > st->vref_mv = st->use_internal_vref ? st->chip_info->int_vref_mv : ret / 1000;
> I'd use a macro from <linux/units.h> instead of just doing / 1000.
In this case we use (MICRO / MILLI) as we don't have (yet?) the
MILLIVOLTS_PER_VOLT and so on. Feeling like you want to add those?
...
> > + fsleep(5); /* power-up time */
>
> I'd recommend using a macro to define the sleep time, removing
> the need for a comment.
OTOH macro might hide the actual value. The comment is fine, but I would extend
it with a reference to a data sheet page, table, section, et cetera.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2 3/3] irqchip/qcom-pdc: Add puwra compatible for PDC secondary mode
From: Maulik Shah @ 2026-06-16 10:27 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
Maulik Shah
In-Reply-To: <20260616-purwa-pdc-v2-0-8dda7ef25ce5@oss.qualcomm.com>
X1P42100 (Purwa) and X1E80100 (Hamoa) shares the same PDC and windows
firmware sets the PDC to secondary mode for X1P42100 too. Add support
to reset the PDC to pass through mode using qcom_scm_io_writel() similar
to X1E80100.
Make sure x1e_quirk to workaround a hardware bug is set only for X1E80100
as X1P42100 have this fixed in sillicon.
Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
---
drivers/irqchip/qcom-pdc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/irqchip/qcom-pdc.c b/drivers/irqchip/qcom-pdc.c
index c6f2935ff788..0f638556d4d0 100644
--- a/drivers/irqchip/qcom-pdc.c
+++ b/drivers/irqchip/qcom-pdc.c
@@ -704,7 +704,10 @@ static int qcom_pdc_probe(struct platform_device *pdev, struct device_node *pare
}
pdc->x1e_quirk = true;
+ }
+ if (of_device_is_compatible(node, "qcom,x1e80100-pdc") ||
+ of_device_is_compatible(node, "qcom,x1p42100-pdc")) {
if (!qcom_scm_is_available())
return -EPROBE_DEFER;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: qcom: purwa: Drop the Hamoa workaround for PDC
From: Maulik Shah @ 2026-06-16 10:27 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
Maulik Shah
In-Reply-To: <20260616-purwa-pdc-v2-0-8dda7ef25ce5@oss.qualcomm.com>
X1P42100 (Purwa) shares the X1E80100 (Hamoa) PDC device, but the hardware
register bug addressed in commit e9a48ea4d90b ("irqchip/qcom-pdc:
Workaround hardware register bug on X1E80100") is already fixed in
X1P42100 silicon.
X1E80100 compatible forces the software workaround. Use the X1P42100
specific compatible string for the PDC node to remove the workaround.
Fixes: f08edb529916 ("arm64: dts: qcom: Add X1P42100 SoC and CRD")
Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/purwa.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/purwa.dtsi b/arch/arm64/boot/dts/qcom/purwa.dtsi
index 9ab4f26b35f2..0db8c561e7ba 100644
--- a/arch/arm64/boot/dts/qcom/purwa.dtsi
+++ b/arch/arm64/boot/dts/qcom/purwa.dtsi
@@ -166,6 +166,11 @@ &pcie6a_phy {
compatible = "qcom,x1p42100-qmp-gen4x4-pcie-phy";
};
+/* X1P42100 PDC is same as X1E80100, but without hardware register bug */
+&pdc {
+ compatible = "qcom,x1p42100-pdc", "qcom,pdc";
+};
+
&qfprom {
gpu_speed_bin: gpu-speed-bin@119 {
reg = <0x119 0x2>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: interrupt-controller: qcom,pdc: Document Purwa PDC
From: Maulik Shah @ 2026-06-16 10:27 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
Maulik Shah
In-Reply-To: <20260616-purwa-pdc-v2-0-8dda7ef25ce5@oss.qualcomm.com>
X1P42100 (Purwa) shares the X1E80100 (Hamoa) PDC device, but the hardware
register bug addressed in commit e9a48ea4d90b ("irqchip/qcom-pdc:
Workaround hardware register bug on X1E80100") is already fixed in
X1P42100 silicon.
X1E80100 compatible forces the software workaround. Add PDC compatible
for purwa as "qcom,x1p42100-pdc" to remove the workaround from Purwa.
Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
---
Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml
index 07a46c5457a4..420421863328 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml
@@ -57,6 +57,7 @@ properties:
- qcom,sm8650-pdc
- qcom,sm8750-pdc
- qcom,x1e80100-pdc
+ - qcom,x1p42100-pdc
- const: qcom,pdc
reg:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 4/4] arm64: dts: qcom: Add PMIH0108 haptics device node
From: Konrad Dybcio @ 2026-06-16 10:27 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260616-qcom-spmi-haptics-v1-4-d24e422de6b4@oss.qualcomm.com>
On 6/16/26 12:08 PM, Fenglin Wu wrote:
> Add haptics device node in the PMIH0108 PMIC base dtsi files, and enable
> it on several boards according to the LRA (Linear Resonant Actuator)
> component mounted on each of them.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 7 +++++++
> arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 7 +++++++
> arch/arm64/boot/dts/qcom/pmih0108-kaanapali.dtsi | 9 +++++++++
> arch/arm64/boot/dts/qcom/pmih0108.dtsi | 9 +++++++++
> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 7 +++++++
> arch/arm64/boot/dts/qcom/sm8750-qrd.dts | 7 +++++++
One commit per board, please
> 6 files changed, 46 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
> index 07247dc98b70..7e3f59fc008e 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
> +++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
> @@ -952,6 +952,13 @@ wifi@0 {
> };
> };
>
> +&pmih0108_e1_haptics {
> + status = "okay";
'status' should go last
> +
> + qcom,lra-period-us = <6667>;
> + qcom,vmax-mv = <3600>;
Do these properties depend on the physical characteristics on what's
connected to the other end of the haptics driver?
Konrad
^ permalink raw reply
* [PATCH v2 0/3] purwa: Drop the Hamoa PDC workaround from purwa
From: Maulik Shah @ 2026-06-16 10:27 UTC (permalink / raw)
To: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-kernel, devicetree, Konrad Dybcio,
Maulik Shah
Purwa shares the Hamoa PDC compatible. Hamoa had the software workaround
added due to hardware register bug mentioned in commit [1] which used
Hamoa/X1E80100 compatible to apply the workaround.
As the hardware bug mentioned in [1] is fixed on purwa silicon add purwa
compatible to avoid applying workaround meant for hamoa.
[1] https://lore.kernel.org/all/20250218-x1e80100-pdc-hw-wa-v2-1-29be4c98e355@linaro.org/
---
Changes in v2:
- Remove Fixes tag from bindings
- Rename $subject to use hamoa and purwa name
- Add comment above compatible in devicetree
- Rebase and mark dependency
- Add new change to invoke SMC call for purwa PDC mode setting
- Link to v1: https://lore.kernel.org/r/20251231-purwa_pdc-v1-0-2b4979dd88ad@oss.qualcomm.com
---
To: Thomas Gleixner <tglx@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
---
Maulik Shah (3):
dt-bindings: interrupt-controller: qcom,pdc: Document Purwa PDC
arm64: dts: qcom: purwa: Drop the Hamoa workaround for PDC
irqchip/qcom-pdc: Add puwra compatible for PDC secondary mode
Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.yaml | 1 +
arch/arm64/boot/dts/qcom/purwa.dtsi | 5 +++++
drivers/irqchip/qcom-pdc.c | 3 +++
3 files changed, 9 insertions(+)
---
base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac
change-id: 20260616-purwa-pdc-198063b482b9
prerequisite-message-id: <20260616-hamoa_pdc_v3-v3-0-4d8e1504ea75@oss.qualcomm.com>
prerequisite-patch-id: 060eef1520c1c4dd8dac1be913d3a3807e2e4297
prerequisite-patch-id: 8f3baf0a17cf193edc0a3dd072a1e148970d1818
prerequisite-patch-id: 00e0419592d6b43eb8d17bbe2ef24ccf708f15c3
prerequisite-patch-id: e6711f15783ab50499e556618767b3450e2f1367
prerequisite-patch-id: 531aa20d79ee018e28c86567c11ea88f665cb2e5
prerequisite-patch-id: 085301f3a331a482e3f16cdd4b588139cf1f2ae5
prerequisite-patch-id: aa6592f80552d5be8f73cf2068d31f1bc214c923
prerequisite-patch-id: 501c83baa6ed0870e2f535e09b64d7510e261def
Best regards,
--
Maulik Shah <maulik.shah@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 3/4] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: Konrad Dybcio @ 2026-06-16 10:25 UTC (permalink / raw)
To: Fenglin Wu, linux-arm-msm, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Stephen Boyd,
Bjorn Andersson, Konrad Dybcio
Cc: David Collins, Subbaraman Narayanamurthy, Kamal Wadhwa, kernel,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260616-qcom-spmi-haptics-v1-3-d24e422de6b4@oss.qualcomm.com>
On 6/16/26 12:08 PM, Fenglin Wu wrote:
> Add an initial driver for the Qualcomm PMIH010x PMIC haptics module,
> named as HAP530_HV. This module supports several play modes, including
> DIRECT_PLAY, FIFO, PAT_MEM, and SWR, each with distinct data sourcing
> and hardware data handling logic. Currently, the driver provides support
> for two play modes using the input force-feedback framework: FF_CONSTANT
> effect for DIRECT_PLAY mode and FF_PERIODIC effect with FF_CUSTOM
> waveform for FIFO mode.
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
[...]
> +static int cfg_write(struct qcom_haptics *h, u32 off, u32 val)
static inline
although I have mixed feelings about having so many accessors
[...]
> +static int haptics_write_fifo_chunk(struct qcom_haptics *h,
> + const s8 *data, u32 len)
> +{
> + u32 i, bulk_len = ALIGN_DOWN(len, 4);
Please avoid mixing multiple declarations and assignments
> + int ret;
> +
> + for (i = 0; i < bulk_len; i += 4) {
You can do 'int i' in loops nowadays
> + ret = ptn_bulk_write(h, HAP_PTN_FIFO_DIN_0_REG, &data[i], 4);
> + if (ret)
> + return ret;
> + }
> +
> + for (; i < len; i++) {
> + ret = ptn_write(h, HAP_PTN_FIFO_DIN_1B_REG, (u8)data[i]);
> + if (ret)
> + return ret;
> + }
So if i'm reading this right, the first loop will always write
4*(len//4) bytes and the second one will be entered at most once,
to write len rem 4 bytes.. should this be an if instead?
> +
> + return 0;
> +}
> +
> +/*
> + * Configure the hardware FIFO memory boundary.
> + * FIFO occupies addresses [0, fifo_len).
> + */
> +static int haptics_configure_fifo_mmap(struct qcom_haptics *h)
> +{
> + u32 fifo_len, fifo_units;
> +
> + /* Config all memory space for FIFO usage for now */
What's the not-"for now" endgame for this?
> + fifo_len = HAP530_MEM_TOTAL_BYTES;
> + fifo_len = ALIGN_DOWN(fifo_len, 64);
> + fifo_units = fifo_len / 64;
> + h->fifo_len = fifo_len;
> +
> + return ptn_write(h, HAP_PTN_MMAP_FIFO_REG,
> + MMAP_FIFO_EXIST_BIT |
> + FIELD_PREP(MMAP_FIFO_LEN_MASK, fifo_units - 1));
> +}
> +
> +static u32 haptics_gain_scaled_vmax(struct qcom_haptics *h, u32 vmax_mv)
> +{
> + u32 v = (u32)((u64)vmax_mv * h->gain / 0xFFFF);
mult_frac()
> +
> + return max_t(u32, v, VMAX_STEP_MV);
> +}
> +
> +static void haptics_fifo_irq_enable(struct qcom_haptics *h, bool enable)
> +{
> + if (h->irq_enabled == enable)
> + return;
> +
> + if (enable)
> + enable_irq(h->fifo_empty_irq);
> + else
> + disable_irq_nosync(h->fifo_empty_irq);
This is called in the .remove() path, I think you may need the
sync variant as the underlying device may be destroyed before the
ISR completes if there's a late interrupt
[...]
> +static int haptics_playback(struct input_dev *dev, int effect_id, int val)
> +{
> + struct qcom_haptics *h = input_get_drvdata(dev);
> +
> + h->cur_effect_id = effect_id;
> + h->play_request = (val > 0);
> + schedule_work(&h->play_work);
> + return 0;
nit: \n before return is 'nice'
[...]
> + ret = device_property_read_u32_array(&pdev->dev, "reg", regs,
> + ARRAY_SIZE(regs));
Here you use device_property_
> + if (ret)
> + return dev_err_probe(&pdev->dev, ret,
> + "failed to read 'reg' property\n");
> +
> + h->cfg_base = regs[0];
> + h->ptn_base = regs[1];
> +
> + ret = of_property_read_u32(h->dev->of_node, "qcom,lra-period-us",
> + &h->t_lra_us);
And here you use of_property_ (please use device_)
[...]
> + input->name = "qcom-spmi-haptics";
Odd whitespace
Konrad
^ 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