* Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq
From: sashiko-bot @ 2026-05-23 9:00 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260523085102.51000-2-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Modeling a software power sequence as a virtual standalone device tree node, bypassing physical bus topology.
--
commit 5baacde1b782878f582e887bcf988caf135487f5
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq
This commit documents the Tegra modem power sequence configuration. It provides
a node to manage interaction between the application processor and the modem,
including control over the USB lines.
> diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra-modem-pwrseq.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra-modem-pwrseq.yaml
> new file mode 100644
> index 0000000000000..3770fd6dc2cf9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra-modem-pwrseq.yaml
[ ... ]
> +properties:
> + compatible:
> + const: nvidia,tegra-modem-pwrseq
> +
> + enable-gpios:
> + description: GPIO connected to the modem EINT1 pin
> + maxItems: 1
> +
> + nvidia,usb-bus:
> + description:
> + Contains phandle pointing to the Host's USB controller
> + $ref: /schemas/types.yaml#/definitions/phandle
[Severity: High]
Does this binding model a software power sequence rather than the physical
hardware layout?
The device tree typically describes physical topology. Under standard bus
architecture, would a USB-connected modem be modeled as a child node under
the corresponding USB controller or hub port, including its required
power-supplies and enable-gpios as properties of that physical child node?
By introducing a standalone virtual node that points backwards to the USB
controller via the nvidia,usb-bus phandle, does this bypass the driver core's
standard bus hierarchy and device link management?
Without a structural dependency established through device links, if the USB
controller driver is unbound, could the power sequencer retain a dangling
pointer to the USB bus device and trigger a use-after-free during the next
enable or disable sequence?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523085102.51000-1-clamor95@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v4 3/3] gpio: zynq: Add eio gpio support
From: Linus Walleij @ 2026-05-23 8:59 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-kernel, git, shubhrajyoti.datta, Srinivas Neeli,
Michal Simek, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260512060917.2096456-4-shubhrajyoti.datta@amd.com>
On Tue, May 12, 2026 at 8:09 AM Shubhrajyoti Datta
<shubhrajyoti.datta@amd.com> wrote:
> Add support for the EIO GPIO controller found on
> xa2ve3288 silicon.
>
> The EIO GPIO block provides access to multiplexed I/O pins exposed
> through the EIO interface. Only bank 0 and bank 1 are connected to
> external MIO pins, with 26 GPIOs per bank (52 GPIOs total). This
> change extends the Zynq GPIO driver to support the EIO GPIO
> variant.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/3] pinctrl: qcom: spmi-gpio: Add pm8010 GPIO support
From: Linus Walleij @ 2026-05-23 8:57 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Subbaraman Narayanamurthy,
linux-gpio, devicetree, linux-kernel, David Collins, kamal.wadhwa,
kernel
In-Reply-To: <20260507-pm8010_gpio-v1-0-3bce9da8d2ba@oss.qualcomm.com>
On Fri, May 8, 2026 at 7:34 AM Fenglin Wu <fenglin.wu@oss.qualcomm.com> wrote:
> Add compatible string for pm8010 GPIO in the binding and driver. Also
> add GPIO device nodes in the existing pm8010*.dtsi files.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Patches 1 & 2 applied to the pinctrl tree!
Take patch 3 through the SoC qcom tree (Bjorn) please.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V9 3/3] arm64: dts: qcom: glymur-crd: add Audio sound card node
From: Sibi Sankar @ 2026-05-23 8:55 UTC (permalink / raw)
To: robh, srini, krzk+dt, conor+dt, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, prasad.kumpatla,
Mohammad Rafi Shaik, Konrad Dybcio
In-Reply-To: <20260523085511.2532669-1-sibi.sankar@oss.qualcomm.com>
From: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Add the sound card of Glymur-crd board with the routing for speakers.
Add device nodes for the sound support with WSA884x smart speakers
and playback via speakers and recording via DMIC microphones.
Co-developed-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Co-developed-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 110 +++++++++++++++++++++++
1 file changed, 110 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
index e784b538f42e..6c272fb6081a 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
@@ -68,6 +68,54 @@ switch-lid {
};
};
+ sound {
+ compatible = "qcom,glymur-sndcard";
+ model = "GLYMUR-CRD";
+ audio-routing = "WooferLeft IN", "WSA WSA_SPK1 OUT",
+ "TweeterLeft IN", "WSA WSA_SPK2 OUT",
+ "WooferRight IN", "WSA2 WSA_SPK1 OUT",
+ "TweeterRight IN", "WSA2 WSA_SPK2 OUT",
+ "VA DMIC0", "vdd-micb",
+ "VA DMIC1", "vdd-micb",
+ "VA DMIC2", "vdd-micb",
+ "VA DMIC3", "vdd-micb";
+
+ wsa-dai-link {
+ link-name = "WSA Playback";
+
+ cpu {
+ sound-dai = <&q6apmbedai WSA_CODEC_DMA_RX_0>;
+ };
+
+ codec {
+ sound-dai = <&left_woofer>, <&left_tweeter>,
+ <&swr0 0>, <&lpass_wsamacro 0>,
+ <&right_woofer>, <&right_tweeter>,
+ <&swr3 0>, <&lpass_wsa2macro 0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
+ va-dai-link {
+ link-name = "VA Capture";
+
+ cpu {
+ sound-dai = <&q6apmbedai VA_CODEC_DMA_TX_0>;
+ };
+
+ codec {
+ sound-dai = <&lpass_vamacro 0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+ };
+
vreg_nvme: regulator-nvme {
compatible = "regulator-fixed";
@@ -444,6 +492,12 @@ vreg_l4h_e0_1p2: ldo4 {
};
};
+&lpass_vamacro {
+ pinctrl-0 = <&dmic01_default>, <&dmic23_default>;
+ pinctrl-names = "default";
+ qcom,dmic-sample-rate = <4800000>;
+};
+
&pcie3b {
vddpe-3v3-supply = <&vreg_nvmesec>;
@@ -571,6 +625,62 @@ &pon_resin {
status = "okay";
};
+&swr0 {
+ status = "okay";
+
+ /* WSA8845, Left Woofer */
+ left_woofer: speaker@0,0 {
+ compatible = "sdw20217020400";
+ reg = <0 0>;
+ reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "WooferLeft";
+ vdd-1p8-supply = <&vreg_l15b_e0_1p8>;
+ vdd-io-supply = <&vreg_l18b_e0_1p2>;
+ qcom,port-mapping = <1 2 3 7 12 14>;
+ };
+
+ /* WSA8845, Left Tweeter */
+ left_tweeter: speaker@0,1 {
+ compatible = "sdw20217020400";
+ reg = <0 1>;
+ reset-gpios = <&lpass_tlmm 12 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "TweeterLeft";
+ vdd-1p8-supply = <&vreg_l15b_e0_1p8>;
+ vdd-io-supply = <&vreg_l18b_e0_1p2>;
+ qcom,port-mapping = <4 5 6 7 13 15>;
+ };
+};
+
+&swr3 {
+ status = "okay";
+
+ /* WSA8845, Right Woofer */
+ right_woofer: speaker@0,0 {
+ compatible = "sdw20217020400";
+ reg = <0 0>;
+ reset-gpios = <&lpass_tlmm 13 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "WooferRight";
+ vdd-1p8-supply = <&vreg_l15b_e0_1p8>;
+ vdd-io-supply = <&vreg_l18b_e0_1p2>;
+ qcom,port-mapping = <1 2 3 7 12 14>;
+ };
+
+ /* WSA8845, Right Tweeter */
+ right_tweeter: speaker@0,1 {
+ compatible = "sdw20217020400";
+ reg = <0 1>;
+ reset-gpios = <&lpass_tlmm 13 GPIO_ACTIVE_LOW>;
+ #sound-dai-cells = <0>;
+ sound-name-prefix = "TweeterRight";
+ vdd-1p8-supply = <&vreg_l15b_e0_1p8>;
+ vdd-io-supply = <&vreg_l18b_e0_1p2>;
+ qcom,port-mapping = <4 5 6 7 13 15>;
+ };
+};
+
&remoteproc_adsp {
firmware-name = "qcom/glymur/adsp.mbn",
"qcom/glymur/adsp_dtb.mbn";
--
2.34.1
^ permalink raw reply related
* [PATCH V9 2/3] arm64: dts: glymur: Add LPASS macro codecs and pinctrl
From: Sibi Sankar @ 2026-05-23 8:55 UTC (permalink / raw)
To: robh, srini, krzk+dt, conor+dt, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, prasad.kumpatla,
Mohammad Rafi Shaik, Konrad Dybcio
In-Reply-To: <20260523085511.2532669-1-sibi.sankar@oss.qualcomm.com>
From: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Add LPASS macro codecs and LPASS TLMM pin controller on Qualcomm glymur
for proper sound support.
Also add GPR (Generic Pack router) node along with APM (Audio Process
Manager) and PRM (Proxy resource Manager) audio services.
Co-developed-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 263 +++++++++++++++++++++++++++
1 file changed, 263 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 72c7dc6e4f09..787d7d498bfe 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -20,7 +20,9 @@
#include <dt-bindings/power/qcom,rpmhpd.h>
#include <dt-bindings/power/qcom-rpmpd.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include <dt-bindings/soc/qcom,gpr.h>
#include <dt-bindings/soc/qcom,rpmh-rsc.h>
+#include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
#include <dt-bindings/spmi/spmi.h>
#include "glymur-ipcc.h"
@@ -3891,9 +3893,138 @@ compute-cb@8 {
dma-coherent;
};
};
+
+ gpr {
+ compatible = "qcom,gpr";
+ qcom,glink-channels = "adsp_apps";
+ qcom,domain = <GPR_DOMAIN_ID_ADSP>;
+ qcom,intents = <512 20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ q6apm: service@1 {
+ compatible = "qcom,q6apm";
+ reg = <GPR_APM_MODULE_IID>;
+ #sound-dai-cells = <0>;
+ qcom,protection-domain = "avs/audio",
+ "msm/adsp/audio_pd";
+
+ q6apmbedai: bedais {
+ compatible = "qcom,q6apm-lpass-dais";
+ #sound-dai-cells = <1>;
+ };
+
+ q6apmdai: dais {
+ compatible = "qcom,q6apm-dais";
+ iommus = <&apps_smmu 0x1001 0x80>,
+ <&apps_smmu 0x1061 0x20>;
+ };
+ };
+
+ q6prm: service@2 {
+ compatible = "qcom,q6prm";
+ reg = <GPR_PRM_MODULE_IID>;
+ qcom,protection-domain = "avs/audio",
+ "msm/adsp/audio_pd";
+
+ q6prmcc: clock-controller {
+ compatible = "qcom,q6prm-lpass-clocks";
+ #clock-cells = <2>;
+ };
+ };
+ };
};
};
+ swr0: soundwire@6c80000 {
+ compatible = "qcom,soundwire-v3.1.0";
+ reg = <0x0 0x06c80000 0x0 0x10000>;
+ interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&lpass_wsamacro>;
+ clock-names = "iface";
+ label = "WSA";
+
+ pinctrl-0 = <&wsa_swr_active>;
+ pinctrl-names = "default";
+
+ qcom,ports-block-pack-mode = /bits/ 8 <0x00 0x01 0x01 0x00 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00 0x01 0x01>;
+ qcom,ports-word-length = /bits/ 8 <0xff 0xff 0xff 0xff 0xff 0xff 0x08 0xff 0xff 0xff 0xff 0xff 0xff 0x18 0x18 0xff 0xff>;
+ qcom,ports-offset1 = /bits/ 8 <0x01 0x03 0x05 0x02 0x04 0x15 0x00 0xff 0xff 0xff 0xff 0x06 0x0d 0x0 0x19 0x06 0x06>;
+ qcom,ports-offset2 = /bits/ 8 <0xff 0x07 0x1f 0xff 0x07 0x1f 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-sinterval = /bits/ 16 <0x07 0x1f 0x3f 0x07 0x1f 0x3f 0xc8 0xff 0xff 0xff 0xff 0x0f 0x0f 0x31f 0x31f 0x0f 0x0f >;
+ qcom,ports-hstart = /bits/ 8 <0xff 0xff 0xff 0xff 0xff 0xff 0x08 0xff 0xff 0xff 0xff 0xff 0xff 0xf 0xf 0xff 0xff>;
+ qcom,ports-hstop = /bits/ 8 <0xff 0xff 0xff 0xff 0xff 0xff 0x08 0xff 0xff 0xff 0xff 0xff 0xff 0x0f 0x0f 0xff 0xff>;
+ qcom,ports-lane-control = /bits/ 8 <0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ status = "disabled";
+ };
+
+ lpass_wsamacro: codec@6c90000 {
+ compatible = "qcom,glymur-lpass-wsa-macro", "qcom,sm8550-lpass-wsa-macro";
+ reg = <0x0 0x06c90000 0x0 0x1000>;
+ clocks = <&q6prmcc LPASS_CLK_ID_WSA_CORE_TX_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&lpass_vamacro>;
+ clock-names = "mclk",
+ "macro",
+ "dcodec",
+ "fsgen";
+
+ #clock-cells = <0>;
+ clock-output-names = "mclk";
+ #sound-dai-cells = <1>;
+ sound-name-prefix = "WSA";
+ };
+
+ swr3: soundwire@6ca0000 {
+ compatible = "qcom,soundwire-v3.1.0";
+ reg = <0x0 0x06ca0000 0x0 0x10000>;
+ interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&lpass_wsa2macro>;
+ clock-names = "iface";
+ label = "WSA2";
+
+ pinctrl-0 = <&wsa2_swr_active>;
+ pinctrl-names = "default";
+
+ qcom,ports-block-pack-mode = /bits/ 8 <0x00 0x01 0x01 0x00 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00 0x01 0x01>;
+ qcom,ports-word-length = /bits/ 8 <0xff 0xff 0xff 0xff 0xff 0xff 0x08 0xff 0xff 0xff 0xff 0xff 0xff 0x18 0x18 0xff 0xff>;
+ qcom,ports-offset1 = /bits/ 8 <0x01 0x03 0x05 0x02 0x04 0x15 0x00 0xff 0xff 0xff 0xff 0x06 0x0d 0x0 0x19 0x06 0x06>;
+ qcom,ports-offset2 = /bits/ 8 <0xff 0x07 0x1f 0xff 0x07 0x1f 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-sinterval = /bits/ 16 <0x07 0x1f 0x3f 0x07 0x1f 0x3f 0xc8 0xff 0xff 0xff 0xff 0x0f 0x0f 0x31f 0x31f 0x0f 0x0f >;
+ qcom,ports-hstart = /bits/ 8 <0xff 0xff 0xff 0xff 0xff 0xff 0x08 0xff 0xff 0xff 0xff 0xff 0xff 0xf 0xf 0xff 0xff>;
+ qcom,ports-hstop = /bits/ 8 <0xff 0xff 0xff 0xff 0xff 0xff 0x08 0xff 0xff 0xff 0xff 0xff 0xff 0x0f 0x0f 0xff 0xff>;
+ qcom,ports-lane-control = /bits/ 8 <0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
+ qcom,ports-block-group-count = /bits/ 8 <0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff>;
+
+ #address-cells = <2>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ status = "disabled";
+ };
+
+ lpass_wsa2macro: codec@6cb0000 {
+ compatible = "qcom,glymur-lpass-wsa-macro", "qcom,sm8550-lpass-wsa-macro";
+ reg = <0x0 0x06cb0000 0x0 0x1000>;
+ clocks = <&q6prmcc LPASS_CLK_ID_WSA2_CORE_TX_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&lpass_vamacro>;
+ clock-names = "mclk",
+ "macro",
+ "dcodec",
+ "fsgen";
+
+ #clock-cells = <0>;
+ clock-output-names = "wsa2-mclk";
+ #sound-dai-cells = <1>;
+ sound-name-prefix = "WSA2";
+ };
+
lpass_lpiaon_noc: interconnect@7400000 {
compatible = "qcom,glymur-lpass-lpiaon-noc";
reg = <0x0 0x07400000 0x0 0x19080>;
@@ -3908,6 +4039,138 @@ lpass_lpicx_noc: interconnect@7420000 {
#interconnect-cells = <2>;
};
+ lpass_vamacro: codec@7660000 {
+ compatible = "qcom,glymur-lpass-va-macro", "qcom,sm8550-lpass-va-macro";
+ reg = <0x0 0x07660000 0x0 0x2000>;
+ clocks = <&q6prmcc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "mclk",
+ "macro",
+ "dcodec";
+
+ #clock-cells = <0>;
+ clock-output-names = "fsgen";
+ #sound-dai-cells = <1>;
+ };
+
+ lpass_tlmm: pinctrl@7760000 {
+ compatible = "qcom,glymur-lpass-lpi-pinctrl", "qcom,sm8650-lpass-lpi-pinctrl";
+ reg = <0x0 0x07760000 0x0 0x20000>;
+
+ clocks = <&q6prmcc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>,
+ <&q6prmcc LPASS_HW_DCODEC_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>;
+ clock-names = "core", "audio";
+
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpass_tlmm 0 0 23>;
+
+ tx_swr_active: tx-swr-active-state {
+ clk-pins {
+ pins = "gpio0";
+ function = "swr_tx_clk";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ bias-disable;
+ };
+
+ data-pins {
+ pins = "gpio1", "gpio2";
+ function = "swr_tx_data";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ bias-bus-hold;
+ };
+ };
+
+ rx_swr_active: rx-swr-active-state {
+ clk-pins {
+ pins = "gpio3";
+ function = "swr_rx_clk";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ bias-disable;
+ };
+
+ data-pins {
+ pins = "gpio4", "gpio5";
+ function = "swr_rx_data";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ bias-bus-hold;
+ };
+ };
+
+ dmic01_default: dmic01-default-state {
+ clk-pins {
+ pins = "gpio6";
+ function = "dmic1_clk";
+ drive-strength = <8>;
+ output-high;
+ };
+
+ data-pins {
+ pins = "gpio7";
+ function = "dmic1_data";
+ drive-strength = <8>;
+ input-enable;
+ };
+ };
+
+ dmic23_default: dmic23-default-state {
+ clk-pins {
+ pins = "gpio8";
+ function = "dmic2_clk";
+ drive-strength = <8>;
+ output-high;
+ };
+
+ data-pins {
+ pins = "gpio9";
+ function = "dmic2_data";
+ drive-strength = <8>;
+ input-enable;
+ };
+ };
+
+ wsa_swr_active: wsa-swr-active-state {
+ clk-pins {
+ pins = "gpio10";
+ function = "wsa_swr_clk";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ bias-disable;
+ };
+
+ data-pins {
+ pins = "gpio11";
+ function = "wsa_swr_data";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ bias-bus-hold;
+ };
+ };
+
+ wsa2_swr_active: wsa2-swr-active-state {
+ clk-pins {
+ pins = "gpio15";
+ function = "wsa2_swr_clk";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ bias-disable;
+ };
+
+ data-pins {
+ pins = "gpio16";
+ function = "wsa2_swr_data";
+ drive-strength = <2>;
+ slew-rate = <1>;
+ bias-bus-hold;
+ };
+ };
+ };
+
lpass_ag_noc: interconnect@7e40000 {
compatible = "qcom,glymur-lpass-ag-noc";
reg = <0x0 0x07e40000 0x0 0xe080>;
--
2.34.1
^ permalink raw reply related
* [PATCH V9 1/3] dt-bindings: soundwire: qcom: Increase max data ports to 17
From: Sibi Sankar @ 2026-05-23 8:55 UTC (permalink / raw)
To: robh, srini, krzk+dt, conor+dt, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, prasad.kumpatla
In-Reply-To: <20260523085511.2532669-1-sibi.sankar@oss.qualcomm.com>
Bump the maxItems from 16 to 17 for all qcom,ports-* properties to
accommodate SoundWire controllers v3.1.0 with 17 data ports.
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
---
.../bindings/soundwire/qcom,soundwire.yaml | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
index 9447a2f371b5..8e6973fa229c 100644
--- a/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
+++ b/Documentation/devicetree/bindings/soundwire/qcom,soundwire.yaml
@@ -90,7 +90,7 @@ properties:
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 16
+ maxItems: 17
qcom,ports-sinterval-low:
$ref: /schemas/types.yaml#/definitions/uint8-array
@@ -101,7 +101,7 @@ properties:
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 16
+ maxItems: 17
qcom,ports-sinterval:
$ref: /schemas/types.yaml#/definitions/uint16-array
@@ -112,7 +112,7 @@ properties:
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 16
+ maxItems: 17
qcom,ports-offset1:
$ref: /schemas/types.yaml#/definitions/uint8-array
@@ -123,7 +123,7 @@ properties:
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 16
+ maxItems: 17
qcom,ports-offset2:
$ref: /schemas/types.yaml#/definitions/uint8-array
@@ -134,7 +134,7 @@ properties:
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 16
+ maxItems: 17
qcom,ports-lane-control:
$ref: /schemas/types.yaml#/definitions/uint8-array
@@ -145,7 +145,7 @@ properties:
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 16
+ maxItems: 17
qcom,ports-block-pack-mode:
$ref: /schemas/types.yaml#/definitions/uint8-array
@@ -158,7 +158,7 @@ properties:
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 16
+ maxItems: 17
items:
oneOf:
- minimum: 0
@@ -175,7 +175,7 @@ properties:
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 16
+ maxItems: 17
items:
oneOf:
- minimum: 0
@@ -192,7 +192,7 @@ properties:
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 16
+ maxItems: 17
items:
oneOf:
- minimum: 0
@@ -208,7 +208,7 @@ properties:
or applicable for the respective data port.
More info in MIPI Alliance SoundWire 1.0 Specifications.
minItems: 3
- maxItems: 16
+ maxItems: 17
items:
oneOf:
- minimum: 0
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 0/2] pinctrl: qcom: Add support for Qualcomm Shikra SoC
From: Linus Walleij @ 2026-05-23 8:55 UTC (permalink / raw)
To: Komal Bajaj
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, linux-arm-msm, linux-gpio, devicetree,
linux-kernel, netdev, Krzysztof Kozlowski
In-Reply-To: <20260512-shikra-pinctrl-v4-0-b93c3a2e4c08@oss.qualcomm.com>
On Tue, May 12, 2026 at 3:25 PM Komal Bajaj
<komal.bajaj@oss.qualcomm.com> wrote:
> Add the pinctrl driver, document the bindings and enable the
> driver in defconfig as default.
>
> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
Patches applied!
I had to fuzz around a bit because 2/2 didn't apply cleanly
so check the result.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V9 0/3] Enable ADSP and CDSP for Glymur SoC
From: Sibi Sankar @ 2026-05-23 8:55 UTC (permalink / raw)
To: robh, srini, krzk+dt, conor+dt, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, prasad.kumpatla
Qualcomm Glymur SoC variants predominantly boot Linux at EL2. This means
that the firmware streams of the remote processors are managed in kernel
and not in Gunyah hypervisor. Given that the Peripheral Image Loader for
Qualcomm SoCs now support running Linux Host at EL2 [1], this series
documents and enables ADSP and CDSP on Qualcomm Glymur SoCs with its
fastrpc nodes. A few variants of the SoC are expected to run Linux at EL1
hence the iommus properties are left optional.
[1] - https://lore.kernel.org/all/20260105-kvmrprocv10-v10-0-022e96815380@oss.qualcomm.com/
Changes in v9:
- Include a binding patch to accommodate the data port increase to 17. [Sashiko-review-bot]
- Fix all double spaces in data list present in qcom,port-* properties.
- Fix routing of WooferRight In to WSA2 WSA_SPK1 OUT. [Sashiko-review-bot]
- Fix all incorrect lowercase speaker/dmic names. [Sashiko-review-bot]
- Link to v8: https://lore.kernel.org/lkml/20260520141828.2724689-1-sibi.sankar@oss.qualcomm.com/
Changes in v8:
- Drop bindings and remoteproc nodes since they've already been picked up by Greg/Bjorn.
- Fix SID duplication between gpr and fastrpc nodes. [Sibi]
- Fix Incomplete DCO. [Krzysztof]
- Match model name to the one already used in Audioreach topology. [Krzysztof]
- Link to v7: https://lore.kernel.org/lkml/20260331032121.1279203-1-sibi.sankar@oss.qualcomm.com/
Changes in v7:
- Rebased on the latest Linux-next
- Split patch series so that Greg can pick this one up so that
the dt changes can be picked up by Bjorn.
- Link to v6: https://lore.kernel.org/lkml/20260325035338.1393287-1-sibi.sankar@oss.qualcomm.com/
Changes in v6:
- Pick the audio series up. [Srini]
- Pickup Rbs from the list.
- Rebase on top of the lastest linux-next.
- Fix up address size and other misc fixes. [Konrad]
- Fix the ordering the various audio nodes. [Sibi]
- Link to v5: https://lore.kernel.org/lkml/20260313120814.1312410-1-sibi.sankar@oss.qualcomm.com/
- Link to v0 audio series: https://lore.kernel.org/lkml/20260311124230.2241781-1-srinivas.kandagatla@oss.qualcomm.com/
Changes in v5:
- Fix commit messages (patch 1/2) to accurately describe compatibility [Krzysztof]
- Link to v4: https://lore.kernel.org/lkml/20260310033617.3108675-1-sibi.sankar@oss.qualcomm.com/
Changes in v4:
- Fix SID used in ADSP/CDSP for correctness [Konrad]
- Link to v3: https://lore.kernel.org/lkml/20260129001358.770053-1-sibi.sankar@oss.qualcomm.com/
Changes in v3:
- A few variants of the SoC are expected to run Linux at EL1 hence the
iommus properties are left optional.
- Add fastrpc bindings and nodes.
- Link to v2: https://lore.kernel.org/all/20251029-knp-remoteproc-v2-0-6c81993b52ea@oss.qualcomm.com/
Changes in v2:
- Combined into Kaanapali series since they are fully compatible.
- Link to v1: https://lore.kernel.org/all/20250924183726.509202-1-sibi.sankar@oss.qualcomm.com/
Sibi Sankar (1):
dt-bindings: soundwire: qcom: Increase max data ports to 17
Srinivas Kandagatla (2):
arm64: dts: glymur: Add LPASS macro codecs and pinctrl
arm64: dts: qcom: glymur-crd: add Audio sound card node
.../bindings/soundwire/qcom,soundwire.yaml | 20 +-
arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 110 ++++++++
arch/arm64/boot/dts/qcom/glymur.dtsi | 263 ++++++++++++++++++
3 files changed, 383 insertions(+), 10 deletions(-)
base-commit: 550604d6c9b9efc8d068aff94dc301694a7afdee
--
2.34.1
^ permalink raw reply
* [PATCH v2 2/2] power: sequencing: Add support for Nvidia Tegra modem pwrseq
From: Svyatoslav Ryhel @ 2026-05-23 8:51 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Bartosz Golaszewski, Svyatoslav Ryhel
Cc: devicetree, linux-tegra, linux-kernel, linux-pm
In-Reply-To: <20260523085102.51000-1-clamor95@gmail.com>
Nvidia Tegra modem power sequence is a set of configurations used in Tegra
SoCs to provide proper interaction between the application processor and
the modem, as well as control over one of the SoC's USB lines for the
modem.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/power/sequencing/Kconfig | 12 +
drivers/power/sequencing/Makefile | 1 +
drivers/power/sequencing/pwrseq-tegra-modem.c | 209 ++++++++++++++++++
3 files changed, 222 insertions(+)
create mode 100644 drivers/power/sequencing/pwrseq-tegra-modem.c
diff --git a/drivers/power/sequencing/Kconfig b/drivers/power/sequencing/Kconfig
index 1c5f5820f5b7..e04a6bacb476 100644
--- a/drivers/power/sequencing/Kconfig
+++ b/drivers/power/sequencing/Kconfig
@@ -46,4 +46,16 @@ config POWER_SEQUENCING_PCIE_M2
connectors. This driver handles the power sequencing for the M.2
connectors exposing multiple interfaces like PCIe, SATA, UART, etc...
+config POWER_SEQUENCING_TEGRA_MODEM
+ tristate "NVIDIA Tegra modem power sequencing driver"
+ depends on ARCH_TEGRA && USB_NET_XMM6260 && USB_SUPPORT
+ help
+ Enable this to support power sequence for XMM6260 modem found in
+ various Tegra devices with cellular capabilities, like
+ LG Optimus 4X P880, LG Optimus Vu P895, Google Nexus 7 (2012) 3G
+ and ASUS Transformer Pad 3G TF300TG.
+
+ To compile this driver as a module, choose M here: the module will
+ be called pwrseq-tegra-modem.
+
endif
diff --git a/drivers/power/sequencing/Makefile b/drivers/power/sequencing/Makefile
index 0911d4618298..c36be7edb8ca 100644
--- a/drivers/power/sequencing/Makefile
+++ b/drivers/power/sequencing/Makefile
@@ -6,3 +6,4 @@ pwrseq-core-y := core.o
obj-$(CONFIG_POWER_SEQUENCING_QCOM_WCN) += pwrseq-qcom-wcn.o
obj-$(CONFIG_POWER_SEQUENCING_TH1520_GPU) += pwrseq-thead-gpu.o
obj-$(CONFIG_POWER_SEQUENCING_PCIE_M2) += pwrseq-pcie-m2.o
+obj-$(CONFIG_POWER_SEQUENCING_TEGRA_MODEM) += pwrseq-tegra-modem.o
diff --git a/drivers/power/sequencing/pwrseq-tegra-modem.c b/drivers/power/sequencing/pwrseq-tegra-modem.c
new file mode 100644
index 000000000000..61df645e642d
--- /dev/null
+++ b/drivers/power/sequencing/pwrseq-tegra-modem.c
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/gpio/consumer.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/pwrseq/provider.h>
+#include <linux/regulator/consumer.h>
+#include <linux/usb.h>
+#include <linux/usb/chipidea.h>
+#include <linux/usb/tegra_usb_phy.h>
+
+struct pwrseq_tegra_modem_ctx {
+ struct device *dev;
+ struct pwrseq_device *pwrseq;
+
+ struct gpio_desc *enable_gpio;
+ struct regulator *power_supply;
+
+ struct platform_device *usb_dev;
+ struct tegra_usb *usb;
+};
+
+static int pwrseq_tegra_modem_power_enable(struct pwrseq_device *pwrseq)
+{
+ struct pwrseq_tegra_modem_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+ return regulator_enable(ctx->power_supply);
+}
+
+static int pwrseq_tegra_modem_power_disable(struct pwrseq_device *pwrseq)
+{
+ struct pwrseq_tegra_modem_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+
+ return regulator_disable(ctx->power_supply);
+}
+
+static const struct pwrseq_unit_data pwrseq_tegra_modem_power_unit_data = {
+ .name = "power-enable",
+ .enable = pwrseq_tegra_modem_power_enable,
+ .disable = pwrseq_tegra_modem_power_disable,
+};
+
+static const struct pwrseq_unit_data *pwrseq_tegra_modem_unit_deps[] = {
+ &pwrseq_tegra_modem_power_unit_data,
+ NULL,
+};
+
+static int pwrseq_tegra_modem_enable(struct pwrseq_device *pwrseq)
+{
+ struct pwrseq_tegra_modem_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+ struct tegra_usb *usb = ctx->usb;
+ int ret;
+
+ /*
+ * USB controller registers shouldn't be touched before PHY is
+ * initialized, otherwise CPU will hang because clocks are gated.
+ * PHY driver controls gating of internal USB clocks on Tegra.
+ */
+ ret = usb_phy_init(usb->phy);
+ if (ret) {
+ dev_err(ctx->dev, "failed to init USB PHY\n");
+ return ret;
+ }
+
+ usb->dev = ci_hdrc_add_device(&ctx->usb_dev->dev,
+ ctx->usb_dev->resource,
+ ctx->usb_dev->num_resources,
+ &usb->data);
+ if (IS_ERR(usb->dev)) {
+ usb_phy_shutdown(usb->phy);
+ dev_err(ctx->dev, "failed to register USB controller\n");
+ return PTR_ERR(usb->dev);
+ }
+
+ gpiod_set_value_cansleep(ctx->enable_gpio, 1);
+
+ return 0;
+}
+
+static int pwrseq_tegra_modem_disable(struct pwrseq_device *pwrseq)
+{
+ struct pwrseq_tegra_modem_ctx *ctx = pwrseq_device_get_drvdata(pwrseq);
+ struct tegra_usb *usb = ctx->usb;
+
+ gpiod_set_value_cansleep(ctx->enable_gpio, 0);
+ ci_hdrc_remove_device(usb->dev);
+ usb_phy_shutdown(usb->phy);
+
+ /* For USB to settle after turning off */
+ msleep(500);
+
+ return 0;
+}
+
+static const struct pwrseq_unit_data pwrseq_tegra_modem_unit = {
+ .name = "modem-power-sequence",
+ .deps = pwrseq_tegra_modem_unit_deps,
+ .enable = pwrseq_tegra_modem_enable,
+ .disable = pwrseq_tegra_modem_disable,
+};
+
+static const struct pwrseq_target_data pwrseq_tegra_modem_target = {
+ .name = "modem-power",
+ .unit = &pwrseq_tegra_modem_unit,
+};
+
+static const struct pwrseq_target_data *pwrseq_tegra_modem_targets[] = {
+ &pwrseq_tegra_modem_target,
+ NULL
+};
+
+static int pwrseq_tegra_modem_match(struct pwrseq_device *pwrseq,
+ struct device *dev)
+{
+ /* We only match the specific modem compatible for now */
+ if (!of_device_is_compatible(dev->of_node, "infineon,xmm6260"))
+ return PWRSEQ_NO_MATCH;
+
+ return PWRSEQ_MATCH_OK;
+}
+
+static void pwrseq_tegra_modem_put_device(void *dev)
+{
+ put_device(dev);
+}
+
+static int pwrseq_tegra_modem_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *usb_node;
+ struct pwrseq_tegra_modem_ctx *ctx;
+ struct pwrseq_config config = { };
+ int ret;
+
+ ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ ctx->dev = dev;
+
+ ctx->enable_gpio = devm_gpiod_get_optional(dev, "enable",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(ctx->enable_gpio))
+ return dev_err_probe(dev, PTR_ERR(ctx->enable_gpio),
+ "failed to get enable GPIO\n");
+
+ ctx->power_supply = devm_regulator_get(dev, "power");
+ if (IS_ERR(ctx->power_supply))
+ return dev_err_probe(dev, PTR_ERR(ctx->power_supply),
+ "failed to get power supply\n");
+
+ usb_node = of_parse_phandle(dev->of_node, "nvidia,usb-bus", 0);
+ if (!usb_node)
+ return dev_err_probe(dev, -ENODEV,
+ "failed to parse modem USB bus\n");
+
+ ctx->usb_dev = of_find_device_by_node(usb_node);
+ of_node_put(usb_node);
+ if (!ctx->usb_dev)
+ return -EPROBE_DEFER;
+
+ ret = devm_add_action_or_reset(dev, pwrseq_tegra_modem_put_device,
+ &ctx->usb_dev->dev);
+ if (ret)
+ return ret;
+
+ ctx->usb = platform_get_drvdata(ctx->usb_dev);
+ if (!ctx->usb)
+ return -EPROBE_DEFER;
+
+ config.parent = dev;
+ config.owner = THIS_MODULE;
+ config.drvdata = ctx;
+ config.match = pwrseq_tegra_modem_match;
+ config.targets = pwrseq_tegra_modem_targets;
+
+ ctx->pwrseq = devm_pwrseq_device_register(dev, &config);
+ if (IS_ERR(ctx->pwrseq))
+ return dev_err_probe(dev, PTR_ERR(ctx->pwrseq),
+ "failed to register the power sequencer\n");
+
+ return 0;
+}
+
+static const struct of_device_id pwrseq_tegra_modem_of_match[] = {
+ { .compatible = "nvidia,tegra-modem-pwrseq" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, pwrseq_tegra_modem_of_match);
+
+static struct platform_driver pwrseq_tegra_modem_driver = {
+ .driver = {
+ .name = "pwrseq-tegra-modem",
+ .of_match_table = pwrseq_tegra_modem_of_match,
+ },
+ .probe = pwrseq_tegra_modem_probe,
+};
+module_platform_driver(pwrseq_tegra_modem_driver);
+
+MODULE_AUTHOR("Svyatolsav Ryhel <clamor95@gmail.com>");
+MODULE_DESCRIPTION("Tegra modem power sequencer driver");
+MODULE_LICENSE("GPL");
--
2.51.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq
From: Svyatoslav Ryhel @ 2026-05-23 8:51 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Bartosz Golaszewski, Svyatoslav Ryhel
Cc: devicetree, linux-tegra, linux-kernel, linux-pm
In-Reply-To: <20260523085102.51000-1-clamor95@gmail.com>
Document the Tegra modem pwseq used by various devices based on the Nvidia
Tegra SoC, describing its usage. The power sequence provides interaction
between the modem and SoC-specific interface configurations.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../soc/tegra/nvidia,tegra-modem-pwrseq.yaml | 49 +++++++++++++++++++
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/tegra/nvidia,tegra-modem-pwrseq.yaml
diff --git a/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra-modem-pwrseq.yaml b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra-modem-pwrseq.yaml
new file mode 100644
index 000000000000..3770fd6dc2cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/tegra/nvidia,tegra-modem-pwrseq.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/tegra/nvidia,tegra-modem-pwrseq.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nvidia Tegra modem power sequence
+
+description:
+ A configuration sequence used in Tegra SoCs to provide proper interaction
+ between the application processor and the modem, as well as control over
+ one of the SoC's USB lines for the modem.
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra-modem-pwrseq
+
+ enable-gpios:
+ description: GPIO connected to the modem EINT1 pin
+ maxItems: 1
+
+ nvidia,usb-bus:
+ description:
+ Contains phandle pointing to the Host's USB controller
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ power-supply: true
+
+required:
+ - compatible
+ - nvidia,usb-bus
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ pwrseq-modem {
+ compatible = "nvidia,tegra-modem-pwrseq";
+
+ enable-gpios = <&gpio 165 GPIO_ACTIVE_HIGH>;
+ power-supply = <&vdd_3v3_vbat>;
+
+ nvidia,usb-bus = <&usb2>;
+ };
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/2] power: sequencing: Add support for Nvidia Tegra modem pwrseq
From: Svyatoslav Ryhel @ 2026-05-23 8:51 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Bartosz Golaszewski, Svyatoslav Ryhel
Cc: devicetree, linux-tegra, linux-kernel, linux-pm
Patchset implements support for the Tegra-specific modem powerseqence,
which handles the registration and unregistration of the USB controller.
This patchset is a part of larger series aiming to bring XMM6260 modem
support for Tegra devices:
https://lore.kernel.org/lkml/20260511135703.62470-1-clamor95@gmail.com/
---
Changes in v2:
- previous phy driver reshaped into pwrseq driver
---
Svyatoslav Ryhel (2):
dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq
power: sequencing: Add support for Nvidia Tegra modem pwrseq
.../soc/tegra/nvidia,tegra-modem-pwrseq.yaml | 49 ++++
drivers/power/sequencing/Kconfig | 12 +
drivers/power/sequencing/Makefile | 1 +
drivers/power/sequencing/pwrseq-tegra-modem.c | 209 ++++++++++++++++++
4 files changed, 271 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/tegra/nvidia,tegra-modem-pwrseq.yaml
create mode 100644 drivers/power/sequencing/pwrseq-tegra-modem.c
--
2.51.0
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: usb: chipidea,usb2-tegra: Document nvidia,external-control property
From: sashiko-bot @ 2026-05-23 8:47 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260523083013.46372-3-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Adding `nvidia,external-control` to prevent the host from accessing the controller is an architectural anti-pattern that duplicates the purpose of the standard `status` property and misattributes resource ownership.
--
commit ba773e6bd558f2861c226bd39627e8f4363d1a0d
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: usb: chipidea,usb2-tegra: Document nvidia,external-control property
This commit documents the nvidia,external-control property for USB controllers.
It indicates that the controller is configured externally, typically for a
modem requiring precise control over the USB bus in HSIC mode.
> diff --git a/Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml b/Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml
> index 78046f8a63ad5..d99a18900b5a8 100644
> --- a/Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml
> +++ b/Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml
[ ... ]
> @@ -40,6 +40,13 @@ properties:
> type: boolean
> deprecated: true
>
> + nvidia,external-control:
> + description:
> + Indicates that the controller is configured externally and that the host
> + should not attempt to access it. This is usually used by a modem that
> + requires precise bus configuration.
> + type: boolean
> +
[Severity: Medium]
Does this new property duplicate the purpose of the standard status property
and misattribute resource ownership?
Device tree is intended to describe hardware, not software workarounds. If
the hardware block is exclusively controlled by an external entity like a
modem and should not be accessed by the host OS, standard semantics generally
dictate using status = "disabled" or status = "reserved".
If the modem relies on the host to provide shared resources like clocks or
resets to bring the bus up before enumeration, could those resources be
modeled via a power-sequencer or assigned directly to the modem hardware
node?
Modeling the resources this way might avoid using the USB controller node as a
silent resource enabler, which would help keep the hardware description
decoupled from software policy.
> required:
> - compatible
> - reg
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523083013.46372-1-clamor95@gmail.com?part=2
^ permalink raw reply
* [PATCH v2 2/2] net: usb: Add Infineon XMM6260 Baseband modem support
From: Svyatoslav Ryhel @ 2026-05-23 8:44 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Svyatoslav Ryhel
Cc: netdev, devicetree, linux-kernel, linux-usb
In-Reply-To: <20260523084408.50346-1-clamor95@gmail.com>
The Infineon/Intel XMM6260 is a 3G-focused, slim modem platform designed
for smartphones, data cards, and Machine-to-Machine (M2M) applications.
The modem is usually connected via the application processor's USB line
in HSIC mode; however, to work properly, the modem must control this line
Dmesg with modem appearing on LG Optimus Vu (P895):
[ 9.427014] ci_hdrc ci_hdrc.1: EHCI Host Controller
[ 9.431488] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 1
[ 9.457197] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
[ 9.460370] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.16
[ 9.468470] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 9.475597] usb usb1: Product: EHCI Host Controller
[ 9.480508] usb usb1: Manufacturer: Linux 6.16.0+ ehci_hcd
[ 9.485913] usb usb1: SerialNumber: ci_hdrc.1
[ 9.490862] hub 1-0:1.0: USB hub found
[ 9.494005] hub 1-0:1.0: 1 port detected
[ 9.657191] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[ 9.844726] usb 1-1: New USB device found, idVendor=1519, idProduct=0020, bcdDevice=12.74
[ 9.850530] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9.857594] usb 1-1: Product: HSIC Device
[ 9.861606] usb 1-1: Manufacturer: Comneon
[ 9.865627] usb 1-1: SerialNumber: 0123456789
[ 9.908739] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/net/usb/Kconfig | 15 ++
drivers/net/usb/Makefile | 1 +
drivers/net/usb/baseband-xmm6260.c | 378 +++++++++++++++++++++++++++++
3 files changed, 394 insertions(+)
create mode 100644 drivers/net/usb/baseband-xmm6260.c
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index 52a5c0922c79..d54d8db752df 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -642,4 +642,19 @@ config USB_RTL8153_ECM
CONFIG_USB_RTL8152 is not set, or the RTL8153 device is not
supported by r8152 driver.
+config USB_NET_XMM6260
+ tristate "Infineon XMM626X Baseband HSPA/HSUPA modem"
+ depends on USB_CHIPIDEA && (RFKILL || RFKILL=n)
+ help
+ Select this if you want to use an Infineon XMM626X modem, found in
+ devices such as the LG Optimus 4X P880, LG Optimus Vu P895, Samsung
+ Galaxy S II (GT-I9100), and Galaxy Nexus (GT-I9250). This driver
+ handles the modem configuration and provides a stable way to expose
+ the modem's USB interface. To establish a connection, you will first
+ need a userspace program to send the correct commands to the modem
+ through its CDC ACM port, as well as a DHCP client.
+
+ To compile this driver as a module, choose M here: the module will
+ be called baseband-xmm6260.
+
endif # USB_NET_DRIVERS
diff --git a/drivers/net/usb/Makefile b/drivers/net/usb/Makefile
index 4964f7b326fb..ffa532c7d7d6 100644
--- a/drivers/net/usb/Makefile
+++ b/drivers/net/usb/Makefile
@@ -42,3 +42,4 @@ obj-$(CONFIG_USB_NET_CDC_MBIM) += cdc_mbim.o
obj-$(CONFIG_USB_NET_CH9200) += ch9200.o
obj-$(CONFIG_USB_NET_AQC111) += aqc111.o
obj-$(CONFIG_USB_RTL8153_ECM) += r8153_ecm.o
+obj-$(CONFIG_USB_NET_XMM6260) += baseband-xmm6260.o
diff --git a/drivers/net/usb/baseband-xmm6260.c b/drivers/net/usb/baseband-xmm6260.c
new file mode 100644
index 000000000000..557ec79f5e2a
--- /dev/null
+++ b/drivers/net/usb/baseband-xmm6260.c
@@ -0,0 +1,378 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2011 NVIDIA Corporation
+ * Copyright (C) 2023 Svyatoslav Ryhel <clamor95@gmail.com>
+ */
+
+#include <linux/array_size.h>
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/gpio/consumer.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/notifier.h>
+#include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/pwrseq/consumer.h>
+#include <linux/regulator/consumer.h>
+#include <linux/rfkill.h>
+#include <linux/usb.h>
+
+#define BASEBAND_XMM_INIT_DELAY 5000
+
+#define BASEBAND_PRODUCT_ID_XMM6260 0x0020
+#define BASEBAND_VENDOR_ID_COMNEON 0x1519
+
+/*
+ * Starting from ver 1145 modem starts in the IPC_AP_WAKE_IRQ_READY state.
+ * AP wake interrupt keeps low util CP starts to initiate its HSIC hw. AP wake
+ * interrupt goes up during CP HSIC init (BASEBAND_XMM_IPC_AP_WAKE_INIT1 state)
+ * at this point Host USB bus must be configured in order for modem to set
+ * properly. Then interrupt goes down when CP HSIC is ready
+ * (BASEBAND_XMM_IPC_AP_WAKE_INIT2 state) and at this point XMM6260 USB device
+ * should appear and be accessible for further work. In case it does not, the
+ * cycle must repeat.
+ */
+
+/* bits [0:2] */
+enum baseband_xmm_ipc_ap_wake_state {
+ BASEBAND_XMM_IPC_AP_WAKE_IRQ_READY,
+ BASEBAND_XMM_IPC_AP_WAKE_INIT1,
+ BASEBAND_XMM_IPC_AP_WAKE_INIT2,
+ BASEBAND_XMM_IPC_AP_WAKE_L,
+ BASEBAND_XMM_IPC_AP_WAKE_H,
+ BASEBAND_XMM_IPC_AP_WAKE_UNINIT,
+ BASEBAND_XMM_IPC_AP_WAKE_MASK = 7,
+};
+
+#define BASEBAND_XMM_IPC_AP_WAKE_MAX 3
+
+#define BASEBAND_XMM_STATE_POWERED 3 /* Tracks regulator state */
+#define BASEBAND_XMM_STATE_PROTECTED 4 /* Prevents rfkill from access */
+#define BASEBAND_XMM_STATE_PRESENT 5 /* Tracks USB device presence */
+#define BASEBAND_XMM_STATE_POWEROFF 6 /* Prevents poweroff recursive call */
+#define BASEBAND_XMM_STATE_MAX 8
+
+struct baseband_xmm_data {
+ struct device *dev;
+ struct rfkill *rfkill_dev;
+ struct pwrseq_desc *pwrseq;
+
+ DECLARE_BITMAP(state, BASEBAND_XMM_STATE_MAX);
+ int irq;
+
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *enable_gpio;
+
+ struct gpio_desc *ipc_cp_gpio;
+ struct gpio_desc *ipc_ap_gpio;
+
+ struct regulator *vbat_supply;
+
+ struct delayed_work modem_work;
+ struct notifier_block nb;
+};
+
+static int get_ipc_ap_wake(struct baseband_xmm_data *priv)
+{
+ int i, ret = 0;
+
+ for (i = 0; i < BASEBAND_XMM_IPC_AP_WAKE_MAX; i++)
+ ret |= (test_bit(i, priv->state) << i);
+
+ return ret;
+}
+
+static void set_ipc_ap_wake(struct baseband_xmm_data *priv,
+ enum baseband_xmm_ipc_ap_wake_state state)
+{
+ for (int i = 0; i < BASEBAND_XMM_IPC_AP_WAKE_MAX; i++)
+ if (state & BIT(i))
+ set_bit(i, priv->state);
+ else
+ clear_bit(i, priv->state);
+}
+
+static void baseband_xmm_reset(struct baseband_xmm_data *priv)
+{
+ int ret;
+
+ set_bit(BASEBAND_XMM_STATE_PROTECTED, priv->state);
+
+ if (!test_bit(BASEBAND_XMM_STATE_POWERED, priv->state)) {
+ ret = regulator_enable(priv->vbat_supply);
+ if (ret)
+ dev_err(priv->dev,
+ "failed to enable vbat power supply\n");
+
+ set_bit(BASEBAND_XMM_STATE_POWERED, priv->state);
+ }
+
+ gpiod_set_value_cansleep(priv->enable_gpio, 0);
+ msleep(50);
+
+ gpiod_set_value_cansleep(priv->reset_gpio, 1);
+ msleep(200);
+ gpiod_set_value_cansleep(priv->reset_gpio, 0);
+
+ msleep(50);
+
+ /* falling edge trigger to CP */
+ gpiod_set_value_cansleep(priv->enable_gpio, 1);
+ usleep_range(50, 100);
+ gpiod_set_value_cansleep(priv->enable_gpio, 0);
+ msleep(20);
+}
+
+static void baseband_xmm_poweroff(struct baseband_xmm_data *priv)
+{
+ /*
+ * The test_bit check prevents poweroff from being recursively
+ * called during USB device deregistration. USB device
+ * deregistration can be triggered by the driver by calling this
+ * function or by some external event. The first case will cause
+ * a recursive call by the notifier if not handled, while the
+ * second case requires this call to handle the USB controller
+ * properly.
+ */
+ if (test_bit(BASEBAND_XMM_STATE_POWEROFF, priv->state))
+ return;
+
+ set_bit(BASEBAND_XMM_STATE_PROTECTED, priv->state);
+ set_bit(BASEBAND_XMM_STATE_POWEROFF, priv->state);
+
+ pwrseq_power_off(priv->pwrseq);
+ gpiod_set_value_cansleep(priv->reset_gpio, 1);
+
+ if (test_bit(BASEBAND_XMM_STATE_POWERED, priv->state)) {
+ regulator_disable(priv->vbat_supply);
+ clear_bit(BASEBAND_XMM_STATE_POWERED, priv->state);
+ }
+ set_ipc_ap_wake(priv, BASEBAND_XMM_IPC_AP_WAKE_IRQ_READY);
+
+ clear_bit(BASEBAND_XMM_STATE_PROTECTED, priv->state);
+ clear_bit(BASEBAND_XMM_STATE_PRESENT, priv->state);
+ clear_bit(BASEBAND_XMM_STATE_POWEROFF, priv->state);
+}
+
+static int baseband_xmm_usb_notifier_call(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct baseband_xmm_data *priv =
+ container_of(nb, struct baseband_xmm_data, nb);
+ struct usb_device *udev;
+ u16 product, vendor;
+
+ if (action == USB_BUS_ADD || action == USB_BUS_REMOVE)
+ return NOTIFY_OK;
+
+ udev = data;
+ product = le16_to_cpu(udev->descriptor.idProduct);
+ vendor = le16_to_cpu(udev->descriptor.idVendor);
+
+ switch (action) {
+ case USB_DEVICE_ADD:
+ /* Infineon XMM6260 ID 1519:0020 */
+ if (vendor == BASEBAND_VENDOR_ID_COMNEON &&
+ product == BASEBAND_PRODUCT_ID_XMM6260) {
+ cancel_delayed_work_sync(&priv->modem_work);
+ clear_bit(BASEBAND_XMM_STATE_PROTECTED, priv->state);
+ set_bit(BASEBAND_XMM_STATE_PRESENT, priv->state);
+ }
+ break;
+
+ case USB_DEVICE_REMOVE:
+ /* Infineon XMM6260 ID 1519:0020 */
+ if (vendor == BASEBAND_VENDOR_ID_COMNEON &&
+ product == BASEBAND_PRODUCT_ID_XMM6260)
+ baseband_xmm_poweroff(priv);
+ break;
+
+ default:
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static int baseband_xmm_set_block(void *data, bool blocked)
+{
+ struct baseband_xmm_data *priv = data;
+
+ if (test_bit(BASEBAND_XMM_STATE_PROTECTED, priv->state))
+ return -EBUSY;
+
+ if (blocked && test_bit(BASEBAND_XMM_STATE_PRESENT, priv->state))
+ baseband_xmm_poweroff(priv);
+ else if (!blocked && !test_bit(BASEBAND_XMM_STATE_PRESENT, priv->state))
+ baseband_xmm_reset(priv);
+
+ return 0;
+}
+
+static const struct rfkill_ops baseband_xmm_rfkill_ops = {
+ .set_block = baseband_xmm_set_block,
+};
+
+static void baseband_xmm_work(struct work_struct *work)
+{
+ struct baseband_xmm_data *priv =
+ container_of(work, struct baseband_xmm_data, modem_work.work);
+
+ baseband_xmm_poweroff(priv);
+};
+
+static irqreturn_t baseband_hostwake_interrupt(int irq, void *dev_id)
+{
+ struct baseband_xmm_data *priv = dev_id;
+ int state = gpiod_get_value(priv->ipc_ap_gpio);
+
+ switch (get_ipc_ap_wake(priv)) {
+ case BASEBAND_XMM_IPC_AP_WAKE_IRQ_READY:
+ if (!state) {
+ set_ipc_ap_wake(priv, BASEBAND_XMM_IPC_AP_WAKE_INIT1);
+ pwrseq_power_on(priv->pwrseq);
+ }
+ break;
+
+ case BASEBAND_XMM_IPC_AP_WAKE_INIT1:
+ if (state) {
+ set_ipc_ap_wake(priv, BASEBAND_XMM_IPC_AP_WAKE_INIT2);
+ schedule_delayed_work(&priv->modem_work,
+ msecs_to_jiffies(BASEBAND_XMM_INIT_DELAY));
+ }
+ break;
+
+ default:
+ break;
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int baseband_xmm_probe(struct platform_device *pdev)
+{
+ struct baseband_xmm_data *priv;
+ struct device *dev = &pdev->dev;
+ unsigned long irqflags;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->dev = dev;
+ platform_set_drvdata(pdev, priv);
+
+ priv->vbat_supply = devm_regulator_get(dev, "vbat");
+ if (IS_ERR(priv->vbat_supply))
+ return dev_err_probe(dev, PTR_ERR(priv->vbat_supply),
+ "failed to get vbat regulator\n");
+
+ /* Own modem gpios */
+ priv->reset_gpio = devm_gpiod_get_optional(dev, "reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(priv->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(priv->reset_gpio),
+ "failed to get reset GPIO\n");
+
+ priv->enable_gpio = devm_gpiod_get_optional(dev, "enable",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(priv->enable_gpio))
+ return dev_err_probe(dev, PTR_ERR(priv->enable_gpio),
+ "failed to get enable GPIO\n");
+
+ /* CP - AP connections */
+ priv->ipc_cp_gpio = devm_gpiod_get_optional(dev, "cp-wake",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(priv->ipc_cp_gpio))
+ return dev_err_probe(dev, PTR_ERR(priv->ipc_cp_gpio),
+ "failed to get CP wake GPIO\n");
+
+ priv->ipc_ap_gpio = devm_gpiod_get_optional(dev, "ap-wake", GPIOD_IN);
+ if (IS_ERR(priv->ipc_ap_gpio))
+ return dev_err_probe(dev, PTR_ERR(priv->ipc_ap_gpio),
+ "failed to get AP wake GPIO\n");
+
+ /* Modem power sequence */
+ priv->pwrseq = devm_pwrseq_get(dev, "modem-power");
+ if (IS_ERR(priv->pwrseq))
+ return dev_err_probe(dev, PTR_ERR(priv->pwrseq),
+ "failed to get modem pwrseq");
+
+ bitmap_zero(priv->state, BASEBAND_XMM_STATE_MAX);
+ INIT_DELAYED_WORK(&priv->modem_work, baseband_xmm_work);
+
+ priv->irq = platform_get_irq(pdev, 0);
+ if (priv->irq < 0)
+ return dev_err_probe(dev, priv->irq, "failed to get IRQ\n");
+
+ /*
+ * Systems using device tree should set up interrupt via DT,
+ * the rest will use the default edge both interrupt.
+ */
+ irqflags = dev->of_node ? 0 : IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING;
+
+ ret = devm_request_threaded_irq(dev, priv->irq, NULL,
+ &baseband_hostwake_interrupt,
+ IRQF_ONESHOT | irqflags,
+ "modem-hostwake", priv);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "failed to register IRQ %d\n", priv->irq);
+
+ priv->rfkill_dev = rfkill_alloc("xmm-modem", dev, RFKILL_TYPE_WWAN,
+ &baseband_xmm_rfkill_ops, priv);
+ if (!priv->rfkill_dev)
+ return -ENOMEM;
+
+ ret = rfkill_register(priv->rfkill_dev);
+ if (ret) {
+ rfkill_destroy(priv->rfkill_dev);
+ return dev_err_probe(dev, ret,
+ "failed to register WWAN rfkill\n");
+ }
+
+ priv->nb.notifier_call = baseband_xmm_usb_notifier_call;
+ usb_register_notify(&priv->nb);
+
+ return 0;
+}
+
+static void baseband_xmm_remove(struct platform_device *pdev)
+{
+ struct baseband_xmm_data *priv = platform_get_drvdata(pdev);
+
+ rfkill_unregister(priv->rfkill_dev);
+ rfkill_destroy(priv->rfkill_dev);
+
+ disable_irq(priv->irq);
+ cancel_delayed_work_sync(&priv->modem_work);
+
+ usb_unregister_notify(&priv->nb);
+ baseband_xmm_poweroff(priv);
+}
+
+static const struct of_device_id baseband_xmm_match[] = {
+ { .compatible = "infineon,xmm6260" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, baseband_xmm_match);
+
+static struct platform_driver baseband_xmm_driver = {
+ .driver = {
+ .name = "baseband-xmm6260",
+ .of_match_table = baseband_xmm_match,
+ },
+ .probe = baseband_xmm_probe,
+ .remove = baseband_xmm_remove,
+};
+module_platform_driver(baseband_xmm_driver);
+
+MODULE_AUTHOR("Svyatolsav Ryhel <clamor95@gmail.com>");
+MODULE_DESCRIPTION("Baseband Infineon XMM6260 driver");
+MODULE_LICENSE("GPL");
--
2.51.0
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: net: Document Infineon/Intel XMM6260 modem
From: Svyatoslav Ryhel @ 2026-05-23 8:44 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Svyatoslav Ryhel
Cc: netdev, devicetree, linux-kernel, linux-usb
In-Reply-To: <20260523084408.50346-1-clamor95@gmail.com>
Describe the Infineon/Intel XMM6260, a 3G-focused, slim modem platform
designed for smartphones, data cards, and Machine-to-Machine (M2M)
applications.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../bindings/net/infineon,xmm6260.yaml | 74 +++++++++++++++++++
1 file changed, 74 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/infineon,xmm6260.yaml
diff --git a/Documentation/devicetree/bindings/net/infineon,xmm6260.yaml b/Documentation/devicetree/bindings/net/infineon,xmm6260.yaml
new file mode 100644
index 000000000000..ffff58e479ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/infineon,xmm6260.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/infineon,xmm6260.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon/Intel XMM6260 embedded USB modem
+
+description:
+ The Infineon/Intel XMM6260 is a 3G-focused, slim modem platform designed
+ for smartphones, data cards, and Machine-to-Machine (M2M) applications.
+ The modem is usually connected via the application processor's USB line
+ in HSIC mode; however, to work properly, the modem must control this line.
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+properties:
+ compatible:
+ const: infineon,xmm6260
+
+ interrupts:
+ maxItems: 1
+
+ enable-gpios:
+ description: GPIO connected to the ON1 pin
+ maxItems: 1
+
+ reset-gpios:
+ description: GPIO connected to the RESET_PWRDWN_N pin
+ maxItems: 1
+
+ ap-wake-gpios:
+ description: GPIO connected to the EINT3 pin
+ maxItems: 1
+
+ cp-wake-gpios:
+ description: GPIO connected to the EINT2 pin
+ maxItems: 1
+
+ vbat-supply:
+ description: Supply connected to the VBAT lines.
+
+ infineon,modem-pwrseq:
+ description:
+ Contains phandle pointing to the modem's power sequence.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+required:
+ - compatible
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ modem {
+ compatible = "infineon,xmm6260";
+
+ interrupt-parent = <&gpio>;
+ interrupts = <168 IRQ_TYPE_EDGE_BOTH>;
+
+ enable-gpios = <&gpio 112 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio 169 GPIO_ACTIVE_LOW>;
+
+ cp-wake-gpios = <&gpio 151 GPIO_ACTIVE_HIGH>;
+ ap-wake-gpios = <&gpio 168 GPIO_ACTIVE_HIGH>;
+
+ infineon,modem-pwrseq = <&xmm6260_modem_pwrseq>;
+ vbat-supply = <&vdd_3v3_vbat>;
+ };
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/2] Add support for Infineon/Intel XMM6260 modem
From: Svyatoslav Ryhel @ 2026-05-23 8:44 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Svyatoslav Ryhel
Cc: netdev, devicetree, linux-kernel, linux-usb
The Infineon/Intel XMM6260 is a 3G-focused, slim modem platform designed
for smartphones, data cards, and Machine-to-Machine (M2M) applications.
The modem is typically connected via the application processor's USB line
in HSIC mode. To function correctly, the modem must control this line, as
it requires precise timing to initiate or de-initialize the USB connection.
This control is necessary to successfully enumerate the next stage of the
USB device loader (moving from firmware loading to the actual device
interface for example).
Patchset adds support for the generic portion of the Infineon XMM6260
baseband modem, which was used in many Tegra-, OMAP-, and Exynos-based
devices circa 2012. This driver provides generic power sequences,
manages initial communication with the application processor, handles the
SoC-specific modem powersequence, and verifies that the modem USB device
appears correctly.
While current support is relatively basic, this configuration already
allows the modem device to appear in the dmesg of my device
(LG Optimus Vu (P895)):
[ 9.427014] ci_hdrc ci_hdrc.1: EHCI Host Controller
[ 9.431488] ci_hdrc ci_hdrc.1: new USB bus registered, assigned bus number 1
[ 9.457197] ci_hdrc ci_hdrc.1: USB 2.0 started, EHCI 1.00
[ 9.460370] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.16
[ 9.468470] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 9.475597] usb usb1: Product: EHCI Host Controller
[ 9.480508] usb usb1: Manufacturer: Linux 6.16.0+ ehci_hcd
[ 9.485913] usb usb1: SerialNumber: ci_hdrc.1
[ 9.490862] hub 1-0:1.0: USB hub found
[ 9.494005] hub 1-0:1.0: 1 port detected
[ 9.657191] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[ 9.844726] usb 1-1: New USB device found, idVendor=1519, idProduct=0020, bcdDevice=12.74
[ 9.850530] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9.857594] usb 1-1: Product: HSIC Device
[ 9.861606] usb 1-1: Manufacturer: Comneon
[ 9.865627] usb 1-1: SerialNumber: 0123456789
[ 9.908739] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
This patchset is a part of larger series aiming to bring XMM6260 modem
support for Tegra devices:
https://lore.kernel.org/lkml/20260511135703.62470-1-clamor95@gmail.com/
---
Changes in v2:
- changed phy to pwrseq in schema
- adjusted Kconfig dependencies
- implemented bitmap for modem state tracking
- switched from phy to power sequencing
- in notifier added chech to filter only USB events
- in notifier added USB_DEVICE_REMOVE
- added tracking for regulator, rfkill access, usb device
presence and poweroff calls using bitops
- moved pseq on call from work to irq handler
- improved rfkill registration logic
---
Svyatoslav Ryhel (2):
dt-bindings: net: Document Infineon/Intel XMM6260 modem
net: usb: Add Infineon XMM6260 Baseband modem support
.../bindings/net/infineon,xmm6260.yaml | 74 ++++
drivers/net/usb/Kconfig | 15 +
drivers/net/usb/Makefile | 1 +
drivers/net/usb/baseband-xmm6260.c | 378 ++++++++++++++++++
4 files changed, 468 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/infineon,xmm6260.yaml
create mode 100644 drivers/net/usb/baseband-xmm6260.c
--
2.51.0
^ permalink raw reply
* [PATCH v2 4/4] usb: chipidea: tegra: Expose tegra_usb structure
From: Svyatoslav Ryhel @ 2026-05-23 8:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Peter Chen,
Svyatoslav Ryhel, Xu Yang, Peng Fan
Cc: linux-usb, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260523083013.46372-1-clamor95@gmail.com>
The tegra_usb structure is platform data of USB controller and is required
for proper controller malipulation if its init/deinit is externally
controlled.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/usb/chipidea/ci_hdrc_tegra.c | 13 +------------
include/linux/usb/tegra_usb_phy.h | 15 +++++++++++++++
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c b/drivers/usb/chipidea/ci_hdrc_tegra.c
index a19cb3b33bf3..109c4afdee4a 100644
--- a/drivers/usb/chipidea/ci_hdrc_tegra.c
+++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
@@ -16,6 +16,7 @@
#include <linux/usb/hcd.h>
#include <linux/usb/of.h>
#include <linux/usb/phy.h>
+#include <linux/usb/tegra_usb_phy.h>
#include <soc/tegra/common.h>
@@ -23,18 +24,6 @@
#include "ci.h"
-struct tegra_usb {
- struct ci_hdrc_platform_data data;
- struct platform_device *dev;
-
- const struct tegra_usb_soc_info *soc;
- struct usb_phy *phy;
- struct clk *clk;
-
- bool needs_double_reset;
- bool externally_controlled;
-};
-
struct tegra_usb_soc_info {
unsigned long flags;
unsigned int txfifothresh;
diff --git a/include/linux/usb/tegra_usb_phy.h b/include/linux/usb/tegra_usb_phy.h
index 6343f88df5de..ba74b7ebfba0 100644
--- a/include/linux/usb/tegra_usb_phy.h
+++ b/include/linux/usb/tegra_usb_phy.h
@@ -9,6 +9,7 @@
#include <linux/clk.h>
#include <linux/regmap.h>
#include <linux/reset.h>
+#include <linux/usb/chipidea.h>
#include <linux/usb/otg.h>
struct gpio_desc;
@@ -62,6 +63,20 @@ enum tegra_usb_phy_port_speed {
TEGRA_USB_PHY_PORT_SPEED_HIGH,
};
+struct tegra_usb_soc_info;
+
+struct tegra_usb {
+ struct ci_hdrc_platform_data data;
+ struct platform_device *dev;
+
+ const struct tegra_usb_soc_info *soc;
+ struct usb_phy *phy;
+ struct clk *clk;
+
+ bool needs_double_reset;
+ bool externally_controlled;
+};
+
struct tegra_xtal_freq;
struct tegra_usb_phy {
--
2.51.0
^ permalink raw reply related
* [PATCH v2 3/4] usb: chipidea: tegra: Avoid controller/PHY init if bus is externally controlled
From: Svyatoslav Ryhel @ 2026-05-23 8:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Peter Chen,
Svyatoslav Ryhel, Xu Yang, Peng Fan
Cc: linux-usb, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260523083013.46372-1-clamor95@gmail.com>
If the USB controller and PHY are externally controlled, then the
registration of the controller and the PHY initialization should be
skipped, since these configurations must be done by the device that
controls the bus to work correctly.
Since USB PHY in Tegra controls clock gates required by the controller
itself, Chipidea core PHY management is not suitable for Tegra.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/usb/chipidea/ci_hdrc_tegra.c | 32 ++++++++++++++++++----------
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c b/drivers/usb/chipidea/ci_hdrc_tegra.c
index 372788f0f970..a19cb3b33bf3 100644
--- a/drivers/usb/chipidea/ci_hdrc_tegra.c
+++ b/drivers/usb/chipidea/ci_hdrc_tegra.c
@@ -32,6 +32,7 @@ struct tegra_usb {
struct clk *clk;
bool needs_double_reset;
+ bool externally_controlled;
};
struct tegra_usb_soc_info {
@@ -312,6 +313,9 @@ static int tegra_usb_probe(struct platform_device *pdev)
if (device_property_present(&pdev->dev, "nvidia,needs-double-reset"))
usb->needs_double_reset = true;
+ if (device_property_present(&pdev->dev, "nvidia,external-control"))
+ usb->externally_controlled = true;
+
err = tegra_usb_reset_controller(&pdev->dev);
if (err) {
dev_err_probe(&pdev->dev, err, "failed to reset controller");
@@ -323,9 +327,11 @@ static int tegra_usb_probe(struct platform_device *pdev)
* initialized, otherwise CPU will hang because clocks are gated.
* PHY driver controls gating of internal USB clocks on Tegra.
*/
- err = usb_phy_init(usb->phy);
- if (err)
- goto fail_power_off;
+ if (!usb->externally_controlled) {
+ err = usb_phy_init(usb->phy);
+ if (err)
+ goto fail_power_off;
+ }
/* setup and register ChipIdea HDRC device */
usb->soc = soc;
@@ -342,12 +348,14 @@ static int tegra_usb_probe(struct platform_device *pdev)
if (of_usb_get_phy_mode(pdev->dev.of_node) == USBPHY_INTERFACE_MODE_ULPI)
usb->data.flags &= ~CI_HDRC_SUPPORTS_RUNTIME_PM;
- usb->dev = ci_hdrc_add_device(&pdev->dev, pdev->resource,
- pdev->num_resources, &usb->data);
- if (IS_ERR(usb->dev)) {
- err = dev_err_probe(&pdev->dev, PTR_ERR(usb->dev),
- "failed to add HDRC device");
- goto phy_shutdown;
+ if (!usb->externally_controlled) {
+ usb->dev = ci_hdrc_add_device(&pdev->dev, pdev->resource,
+ pdev->num_resources, &usb->data);
+ if (IS_ERR(usb->dev)) {
+ err = dev_err_probe(&pdev->dev, PTR_ERR(usb->dev),
+ "failed to add HDRC device");
+ goto phy_shutdown;
+ }
}
return 0;
@@ -365,8 +373,10 @@ static void tegra_usb_remove(struct platform_device *pdev)
{
struct tegra_usb *usb = platform_get_drvdata(pdev);
- ci_hdrc_remove_device(usb->dev);
- usb_phy_shutdown(usb->phy);
+ if (!usb->externally_controlled) {
+ ci_hdrc_remove_device(usb->dev);
+ usb_phy_shutdown(usb->phy);
+ }
pm_runtime_put_sync_suspend(&pdev->dev);
pm_runtime_force_suspend(&pdev->dev);
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: usb: chipidea,usb2-tegra: Document nvidia,external-control property
From: Svyatoslav Ryhel @ 2026-05-23 8:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Peter Chen,
Svyatoslav Ryhel, Xu Yang, Peng Fan
Cc: linux-usb, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260523083013.46372-1-clamor95@gmail.com>
Document the nvidia,external-control property required, for example, for
USB lines in HSIC mode connected to a modem, where the modem requires
precise control over the USB bus to properly enumerate all its stages and
intermediate devices.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../devicetree/bindings/usb/chipidea,usb2-tegra.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml b/Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml
index 78046f8a63ad..d99a18900b5a 100644
--- a/Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml
+++ b/Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml
@@ -40,6 +40,13 @@ properties:
type: boolean
deprecated: true
+ nvidia,external-control:
+ description:
+ Indicates that the controller is configured externally and that the host
+ should not attempt to access it. This is usually used by a modem that
+ requires precise bus configuration.
+ type: boolean
+
required:
- compatible
- reg
--
2.51.0
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: usb: Move Tegra-specific Chipidea USB properties into a dedicated schema
From: Svyatoslav Ryhel @ 2026-05-23 8:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Peter Chen,
Svyatoslav Ryhel, Xu Yang, Peng Fan
Cc: linux-usb, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260523083013.46372-1-clamor95@gmail.com>
Move all Tegra-specific Chipidea devices and their properties into a
dedicated schema file, by analogy with i.MX.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../bindings/usb/chipidea,usb2-tegra.yaml | 88 +++++++++++++++++++
.../devicetree/bindings/usb/ci-hdrc-usb2.yaml | 22 -----
2 files changed, 88 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml
diff --git a/Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml b/Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml
new file mode 100644
index 000000000000..78046f8a63ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/chipidea,usb2-tegra.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Tegra USB2 ChipIdea USB controller
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - nvidia,tegra20-ehci
+ - nvidia,tegra20-udc
+ - nvidia,tegra30-ehci
+ - nvidia,tegra30-udc
+ - nvidia,tegra114-udc
+ - nvidia,tegra124-udc
+ - items:
+ - enum:
+ - nvidia,tegra114-ehci
+ - nvidia,tegra124-ehci
+ - nvidia,tegra210-ehci
+ - const: nvidia,tegra30-ehci
+
+ operating-points-v2:
+ description: A phandle to the OPP table containing the performance states.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ nvidia,phy:
+ description: phandle of usb phy that connects to the port. Use "phys" instead.
+ $ref: /schemas/types.yaml#/definitions/phandle
+ deprecated: true
+
+ nvidia,needs-double-reset:
+ description: Indicates double reset or not.
+ type: boolean
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - resets
+
+allOf:
+ - $ref: chipidea,usb2-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/tegra30-car.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ usb@7d000000 {
+ compatible = "nvidia,tegra30-udc";
+ reg = <0x7d000000 0x4000>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ phy_type = "utmi";
+ clocks = <&tegra_car TEGRA30_CLK_USBD>;
+ resets = <&tegra_car 22>;
+ reset-names = "usb";
+ phys = <&phy1>;
+ power-domains = <&pd_core>;
+ operating-points-v2 = <&usbd_dvfs_opp_table>;
+
+ dr_mode = "otg";
+
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+
+ usb-role-switch;
+ extcon = <&charger>, <&extcon>; /* vbus, id */
+ vbus-supply = <&usb_otg_vbus>;
+
+ port {
+ usb_in: endpoint {
+ remote-endpoint = <&connector_out>;
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
index 691d6cf02c27..5abca0572714 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
@@ -17,20 +17,8 @@ properties:
- chipidea,usb2
- lsi,zevio-usb
- nuvoton,npcm750-udc
- - nvidia,tegra20-ehci
- - nvidia,tegra20-udc
- - nvidia,tegra30-ehci
- - nvidia,tegra30-udc
- - nvidia,tegra114-udc
- - nvidia,tegra124-udc
- nxp,s32g2-usb
- qcom,ci-hdrc
- - items:
- - enum:
- - nvidia,tegra114-ehci
- - nvidia,tegra124-ehci
- - nvidia,tegra210-ehci
- - const: nvidia,tegra30-ehci
- items:
- const: xlnx,zynq-usb-2.20a
- const: chipidea,usb2
@@ -65,16 +53,6 @@ properties:
- description: register offset
- description: phy index
- nvidia,phy:
- description: phandle of usb phy that connects to the port. Use "phys" instead.
- $ref: /schemas/types.yaml#/definitions/phandle
- deprecated: true
-
- nvidia,needs-double-reset:
- description: Indicates double reset or not.
- type: boolean
- deprecated: true
-
ulpi:
type: object
additionalProperties: false
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/4] usb: chipidea: tegra: Add external control option
From: Svyatoslav Ryhel @ 2026-05-23 8:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thierry Reding, Jonathan Hunter, Peter Chen,
Svyatoslav Ryhel, Xu Yang, Peng Fan
Cc: linux-usb, devicetree, linux-tegra, linux-kernel
Patchset adjusts the Tegra-specific portion of the Chipidea USB controller
to allow for the disabling of automatic PHY and USB controller
registration. This is achieved by adding the nvidia,external-control
property/flag. It does not affect any existing configurations, but it
allows the USB line to be registered or deregistered by an external
device — in this case, the modem.
Since Tegra USB PHY holds clock gating for controller PHY cannot be
handled by code Chipidea mechanism.
This patchset is a part of larger series aiming to bring XMM6260 modem
support for Tegra devices:
https://lore.kernel.org/lkml/20260511135703.62470-1-clamor95@gmail.com/
---
Changes in v2:
- separated Tegra USB into its own schema
- tegra_usb structure moved into tegra_usb_phy.h
---
Svyatoslav Ryhel (4):
dt-bindings: usb: Move Tegra-specific Chipidea USB properties into a
dedicated schema
dt-bindings: usb: chipidea,usb2-tegra: Document
nvidia,external-control property
usb: chipidea: tegra: Avoid controller/PHY init if bus is externally
controlled
usb: chipidea: tegra: Expose tegra_usb structure
.../bindings/usb/chipidea,usb2-tegra.yaml | 95 +++++++++++++++++++
.../devicetree/bindings/usb/ci-hdrc-usb2.yaml | 22 -----
drivers/usb/chipidea/ci_hdrc_tegra.c | 43 ++++-----
include/linux/usb/tegra_usb_phy.h | 15 +++
4 files changed, 131 insertions(+), 44 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/chipidea,usb2-tegra.yaml
--
2.51.0
^ permalink raw reply
* Re: [PATCH net-next v8 10/10] net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration
From: Lorenzo Bianconi @ 2026-05-23 8:23 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: sashiko-reviews, robh, devicetree, conor+dt, netdev
In-Reply-To: <20260522165820.04839729@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]
On May 22, Jakub Kicinski wrote:
> On Fri, 22 May 2026 21:25:37 +0200 Lorenzo Bianconi wrote:
> > - What happens when device tree does not provide MAC addresses for two or
> > more same-side GDM interfaces?
> > - This is the same comment reported in [0].
> > Since the hw exposes just a single register (REG_FE_LAN_MAC_H or
> > REG_FE_WAN_MAC_H) for the LAN/WAN mac address MSBs, we need to
> > require all the interfaces configured as LAN or WAN to share the
> > mac address MSBs and the user needs to select the new mac address
> > observing this limitation.
> > Please note this limitation is only valid if multiple net_devices
> > are configured as LAN (or WAN). Since in the current codebase we
> > do not support multiple interfaces configured as LAN or WAN, we are
> > not introducing any regression.
> > I do not think selecting a "base" for the mac address is helpful
> > if the user does not provide the mac address via the DTS or NVME
> > (as suggested by sashiko) since it will not help us if the mac
> > addresses configured via DTS are "wrong" (if they do not respect
> > the limitation described above). What do you think?
>
> If the MACs are not provided something is obviously wrong with the
> device. We should try to provide enough functionality for the user
> to be able to troubleshoot. For an AP perhaps that means SSH / remote
> logs? So switching/routing doesn't have to work, I'd think.
>
> Will the user be able to log in when REG_FE_LAN_MAC_H does not match
> the MAC of a port?
REG_FE_LAN_MAC_H and REG_FE_WAN_MAC_H regs are used by the FE module to
hw accelerate forwarded traffic and does not prevent the user to log into
the device even if they are set to a different values with respect to the
configured mac addresses (just hw acceleration will not work properly).
To prove it, I set to 0 REG_FE_WAN_MAC_H, REG_FE_WAN_MAC_LMIN and
REG_FE_WAN_MAC_LMAX and I still able to ping the device via the WAN
interface.
I guess the easiest solution is to neglect errors from airoha_set_macaddr()
in airoha_dev_init() (as it is in the current codebase) in order to allow
the device to probe successfully and provide a warning message to the user
regarding the mac address misconfiguration. What do you think?
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] riscv: dts: spacemit: k1: Add Banana Pi BPI-CM6 IO board
From: Michael Opdenacker @ 2026-05-23 7:35 UTC (permalink / raw)
To: Junhui Liu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Yixun Lan, Vivian Wang, Paolo Abeni, Guodong Xu, Yangyu Chen
Cc: michael.opdenacker, devicetree, linux-riscv, spacemit,
linux-kernel
In-Reply-To: <20260522-bpi-cm6-v1-3-707ef1917a30@pigmoral.tech>
Hi Junhui
Thanks a lot for these patches!
Yours are much more exhaustive than the ones I was cooking.
On 5/22/26 12:01 PM, Junhui Liu wrote:
> The Banana Pi BPI-CM6 IO board combines the BPI-CM6 compute module with
> an IO carrier board. The core module integrates the SpacemiT K1 SoC,
> PMIC, DDR, eMMC, the eth0 PHY, and wireless connectivity. The companion
> IO carrier board extends it by providing the eth1 PHY and exposing
> standard interfaces, including dual Gigabit Ethernet, MicroSD, two USB-A
> ports, a USB Type-C port, two PCIe M.2 slots, and a serial console.
>
> The board also has two I2C EEPROMs. One is on the core module, which
> stores factory manufacturing data and is marked read-only. The other is
> on the carrier board, which is shipped unprogrammed and left writable
> for evaluation purposes.
>
> Add initial support for UART console, eMMC, SD card, I2C, EEPROMs,
> PCIe, USB, and dual Ethernet interfaces.
>
> Link: https://docs.banana-pi.org/en/BPI-CM6/BananaPi_BPI-CM6
> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> ---
> arch/riscv/boot/dts/spacemit/Makefile | 1 +
> .../riscv/boot/dts/spacemit/k1-bananapi-cm6-io.dts | 215 +++++++++++++++++++
> arch/riscv/boot/dts/spacemit/k1-bananapi-cm6.dtsi | 227 +++++++++++++++++++++
> 3 files changed, 443 insertions(+)
Reviewed-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
Tested-by: Michael Opdenacker <michael.opdenacker@rootcommit.com>
For booting on MMC, I also had to add Iker Pedrosa's patches in Ulf
Hanson's mmc/next branch
(https://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git/log/?h=next)
Thanks again!
Cheers
Michael.
--
Root Commit
Embedded Linux Training and Consulting
https://rootcommit.com
^ permalink raw reply
* Re: [PATCH] clk: canaan: k230: Fix sparse warnings reported by LKP
From: Xukai Wang @ 2026-05-23 7:00 UTC (permalink / raw)
To: Conor Dooley
Cc: Conor Dooley, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Paul Walmsley, Palmer Dabbelt,
Albert Ou, linux-clk, devicetree, linux-kernel, linux-riscv,
Samuel Holland, Troy Mitchell, Krzysztof Kozlowski
In-Reply-To: <20260522-removed-lyricism-7c879febc3b3@spud>
On 2026/5/23 04:39, Conor Dooley wrote:
> On Fri, May 22, 2026 at 08:59:12PM +0800, Xukai Wang wrote:
>> Fix all sparse warnings detected during LKP randconfig testing:
>> - Replace plain integer 0 with NULL.
>> - Add static modifier to k230_plls and k230_pll_divs.
>>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes: https://lore.kernel.org/oe-kbuild-all/202605220724.j4ZeM3KI-lkp@intel.com/
>> Signed-off-by: Xukai Wang <kingxukai@zohomail.com>
> Forgot to reply earlier, but I went and squashed this in.
Thanks Conor!
--
Best regards,
Xukai Wang
^ permalink raw reply
* Re: [PATCH v8 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: sashiko-bot @ 2026-05-23 3:35 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: linux-phy, robh, vkoul, neil.armstrong, olteanv, conor+dt,
devicetree
In-Reply-To: <20260523-x1e-csi2-phy-v8-2-a85668459521@linaro.org>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] Integer underflow in PHY settle count calculation.
- [High] Missing bounds checking for device tree lane arrays leads to out-of-bounds IO memory writes.
- [High] Unconditional dereference of csi2phy->pd_list can cause a kernel panic if power domains are missing.
- [Medium] Probe ignores -ENODEV from OPP table initialization, but power_on unconditionally fails without it.
- [Medium] qcom_csi2_phy_xlate lacks args_count validation before reading args array.
--
commit 66168a7f8131d0b43bbb6d3d1472182c1beff538
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
This commit adds a new MIPI CSI2 driver for DPHY mode, importing CAMSS CSI
PHY init sequences for initial support. The driver handles data/clock lane
configuration and replaces the useless interrupt handler with regulator and
clock bulk APIs.
> diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
> new file mode 100644
> index 0000000000000..86ec405820e62
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
[ ... ]
> +static u8 phy_qcom_mipi_csi2_settle_cnt_calc(s64 link_freq, u32 timer_clk_rate)
> +{
> + u32 t_hs_prepare_max_ps;
> + u32 timer_period_ps;
> + u32 t_hs_settle_ps;
> + u8 settle_cnt;
> + u32 ui_ps;
> +
> + if (link_freq <= 0)
> + return 0;
> +
> + ui_ps = div_u64(PSEC_PER_SEC, link_freq);
> + ui_ps /= 2;
> + t_hs_prepare_max_ps = 85000 + 6 * ui_ps;
> + t_hs_settle_ps = t_hs_prepare_max_ps;
> +
> + timer_period_ps = div_u64(PSEC_PER_SEC, timer_clk_rate);
> + settle_cnt = t_hs_settle_ps / timer_period_ps - 6;
[Severity: High]
Can this underflow if the ratio is less than 6?
For example, with a CSI-2 link frequency of 200 MHz, the ratio could evaluate
to 5. Subtracting 6 would result in an unsigned integer underflow, yielding 255
for the u8 variable. This could cause an inflated settle count to be written
to the PHY registers. Does this calculation need to clamp the result to 0 or
ensure the ratio is greater than or equal to 6?
> +
> + return settle_cnt;
> +}
[ ... ]
> +static int phy_qcom_mipi_csi2_lanes_enable(struct mipi_csi2phy_device *csi2phy,
> + struct mipi_csi2phy_stream_cfg *cfg)
> +{
[ ... ]
> + /* Lane configuration for polarity @ CSIPHY-base + CTRL9 */
> + for (i = 0; i < cfg->num_data_lanes; i++) {
> + if (lane_cfg->data[i].pol) {
> + u8 pos = lane_cfg->data[i].pos;
> +
> + writel(BIT(2), csi2phy->base + CSIPHY_2PH_LN_CSI_2PHASE_CTRL9n(pos));
[Severity: High]
Does this code perform bounds checking on the device tree lane arrays?
Since the data-lanes and clock-lanes properties from the device tree are
stored in pos without validation, a large pos value could trigger
out-of-bounds IO memory writes via the CSIPHY_2PH_LN_CSI_2PHASE_CTRL9n(pos)
offset and BIT(pos) bitwise shift.
> + }
> + }
> +
> + if (lane_cfg->clk.pol)
> + writel(BIT(2), csi2phy->base + CSIPHY_2PH_LN_CSI_2PHASE_CTRL9n(lane_cfg->clk.pos));
[ ... ]
> diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
> new file mode 100644
> index 0000000000000..dfeff863a406f
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
[ ... ]
> +static int
> +phy_qcom_mipi_csi2_set_clock_rates(struct mipi_csi2phy_device *csi2phy,
> + s64 link_freq)
> +{
> + struct device *dev = csi2phy->dev;
> + unsigned long opp_rate = link_freq / 4;
> + struct dev_pm_opp *opp;
> + long timer_rate;
> + int i, ret;
> +
> + opp = dev_pm_opp_find_freq_ceil(dev, &opp_rate);
> + if (IS_ERR(opp)) {
[Severity: Medium]
Will this fail unconditionally if the OPP table is missing?
In phy_qcom_mipi_csi2_probe(), the -ENODEV error from
devm_pm_opp_of_add_table() is explicitly ignored, allowing the probe to
succeed even if the device tree lacks an OPP table.
However, dev_pm_opp_find_freq_ceil() is called here unconditionally,
which would return an error and cause the power_on routine to fail. Should
we enforce the OPP table presence during probe or handle its absence
gracefully here?
> + dev_err(csi2phy->dev, "Couldn't find ceiling for %lld Hz\n",
> + link_freq);
> + return PTR_ERR(opp);
> + }
> +
> + for (i = 0; i < csi2phy->pd_list->num_pds; i++) {
[Severity: High]
Can this dereference a NULL pointer if power domains are missing?
If the device tree lacks the power-domains property,
devm_pm_domain_attach_list() returns 0 and leaves csi2phy->pd_list as NULL.
Iterating with csi2phy->pd_list->num_pds without a NULL check would cause
a kernel panic.
> + unsigned int perf = dev_pm_opp_get_required_pstate(opp, i);
[ ... ]
> +static struct phy *qcom_csi2_phy_xlate(struct device *dev,
> + const struct of_phandle_args *args)
> +{
> + struct mipi_csi2phy_device *csi2phy = dev_get_drvdata(dev);
> +
> + if (args->args[0] != PHY_TYPE_DPHY) {
[Severity: Medium]
Should this check args->args_count before accessing the args array?
If a malformed device tree specifies #phy-cells = <0>, args_count will be 0,
and reading args->args[0] will access uninitialized memory.
> + dev_err(csi2phy->dev, "mode %d -EOPNOTSUPP\n", args->args[0]);
> + return ERR_PTR(-EOPNOTSUPP);
> + }
> +
> + csi2phy->phy_mode = args->args[0];
> +
> + return csi2phy->phy;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260523-x1e-csi2-phy-v8-0-a85668459521@linaro.org?part=2
^ permalink raw reply
* Re: (subset) [PATCH v2 0/4] add ufs support for Exynosautov920 SoC
From: Martin K. Petersen @ 2026-05-23 3:14 UTC (permalink / raw)
To: avri.altman, bvanassche, robh, krzk+dt, Alim Akhtar
Cc: Martin K . Petersen, sowon.na, peter.griffin, linux-scsi,
devicetree, linux-samsung-soc, linux-kernel
In-Reply-To: <20260417121452.827054-1-alim.akhtar@samsung.com>
On Fri, 17 Apr 2026 17:44:48 +0530, Alim Akhtar wrote:
> This series adds ufs driver support for ExynosAutov920,
> ExynosAutov920 has the UFSHCI 3.1 compliant UFS controller.
>
> ExynosAutov920 has a different mask of UFS sharability from ExynosAutov9,
> so this series provide flexible parameter for the mask.
>
> With this series applied, UFS is functional and basic I/O operations are
> known to be working.
>
> [...]
Applied to 7.2/scsi-queue, thanks!
[2/4] dt-bindings: ufs: exynos: add ExynosAutov920 compatible string
https://git.kernel.org/mkp/scsi/c/45c9dee6d653
[3/4] scsi: ufs: exynos: add support for ExynosAutov920 SoC
https://git.kernel.org/mkp/scsi/c/50349bd5d0ab
--
Martin K. Petersen
^ 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