[PATCH v2 0/2] power: sequencing: Add support for Nvidia Tegra modem pwrseq

[PATCH v2 0/2] power: sequencing: Add support for Nvidia Tegra modem pwrseq

[Svyatoslav Ryhel]

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

[PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Svyatoslav Ryhel]

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

[PATCH v2 2/2] power: sequencing: Add support for Nvidia Tegra modem pwrseq

[Svyatoslav Ryhel]

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

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Bartosz Golaszewski]

On Sat, May 23, 2026 at 10:51 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> 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>
> ---

...

> +
> +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
>

I assume there's no such component as the tegra modem *pwrseq*? What
is the relationship between this node and the "infineon,xmm6260"
compatible node?

Bart

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Svyatoslav Ryhel]

вт, 26 трав. 2026 р. о 12:51 Bartosz Golaszewski <brgl@kernel.org> пише:
>
> On Sat, May 23, 2026 at 10:51 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > 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>
> > ---
>
> ...
>
> > +
> > +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
> >
>
> I assume there's no such component as the tegra modem *pwrseq*?

Hardware component, I assume no.

> What is the relationship between this node and the "infineon,xmm6260"
> compatible node?
>

The xmm6260 has a phandle reference to it. Since there is consumer
matching logic in the pwrseq driver I am leaning towards removing this
node entirely. This patches is still in non-final stage and I would
like to hear any opinions on the way to improving it.

> Bart

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Bartosz Golaszewski]

On Tue, 26 May 2026 12:03:59 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
> вт, 26 трав. 2026 р. о 12:51 Bartosz Golaszewski <brgl@kernel.org> пише:
>>
>> On Sat, May 23, 2026 at 10:51 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>> >
>> > 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>
>> > ---
>>
>> ...
>>
>> > +
>> > +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
>> >
>>
>> I assume there's no such component as the tegra modem *pwrseq*?
>
> Hardware component, I assume no.
>
>> What is the relationship between this node and the "infineon,xmm6260"
>> compatible node?
>>
>
> The xmm6260 has a phandle reference to it. Since there is consumer
> matching logic in the pwrseq driver I am leaning towards removing this
> node entirely. This patches is still in non-final stage and I would
> like to hear any opinions on the way to improving it.
>

The node attached to the pwrseq provider device should represent a real
hardware component. Are the enable-gpios and power-supply lines connected
to the modem package? Is there an internal structure to it, like a PMIC to
which these lines connect that controls the actual modem IC?

Bart

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Svyatoslav Ryhel]

вт, 26 трав. 2026 р. о 14:14 Bartosz Golaszewski <brgl@kernel.org> пише:
>
> On Tue, 26 May 2026 12:03:59 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
> > вт, 26 трав. 2026 р. о 12:51 Bartosz Golaszewski <brgl@kernel.org> пише:
> >>
> >> On Sat, May 23, 2026 at 10:51 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >> >
> >> > 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>
> >> > ---
> >>
> >> ...
> >>
> >> > +
> >> > +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
> >> >
> >>
> >> I assume there's no such component as the tegra modem *pwrseq*?
> >
> > Hardware component, I assume no.
> >
> >> What is the relationship between this node and the "infineon,xmm6260"
> >> compatible node?
> >>
> >
> > The xmm6260 has a phandle reference to it. Since there is consumer
> > matching logic in the pwrseq driver I am leaning towards removing this
> > node entirely. This patches is still in non-final stage and I would
> > like to hear any opinions on the way to improving it.
> >
>
> The node attached to the pwrseq provider device should represent a real
> hardware component. Are the enable-gpios and power-supply lines connected
> to the modem package?

Yes, enable-gpio is connected to the modem and signals that USB is set
and ready to work with the modem, while power-supply is an optional
supply connected to the modem's vbus input.

> Is there an internal structure to it, like a PMIC to which these lines connect
> that controls the actual modem IC?

Modem does have internal PMIC to power up all its components, but they
are controlled by the modems internal firmware and are not accessible
via any standard means.

> Bart

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Bartosz Golaszewski]

On Tue, May 26, 2026 at 2:29 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> вт, 26 трав. 2026 р. о 14:14 Bartosz Golaszewski <brgl@kernel.org> пише:
> >
> > On Tue, 26 May 2026 12:03:59 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
> > > вт, 26 трав. 2026 р. о 12:51 Bartosz Golaszewski <brgl@kernel.org> пише:
> > >>
> > >> On Sat, May 23, 2026 at 10:51 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > >> >
> > >> > 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>
> > >> > ---
> > >>
> > >> ...
> > >>
> > >> > +
> > >> > +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
> > >> >
> > >>
> > >> I assume there's no such component as the tegra modem *pwrseq*?
> > >
> > > Hardware component, I assume no.
> > >
> > >> What is the relationship between this node and the "infineon,xmm6260"
> > >> compatible node?
> > >>
> > >
> > > The xmm6260 has a phandle reference to it. Since there is consumer
> > > matching logic in the pwrseq driver I am leaning towards removing this
> > > node entirely. This patches is still in non-final stage and I would
> > > like to hear any opinions on the way to improving it.
> > >
> >
> > The node attached to the pwrseq provider device should represent a real
> > hardware component. Are the enable-gpios and power-supply lines connected
> > to the modem package?
>
> Yes, enable-gpio is connected to the modem and signals that USB is set
> and ready to work with the modem, while power-supply is an optional
> supply connected to the modem's vbus input.
>

The modem is a hard-wired USB device? Do you implement it as a
platform driver or a USB driver?

Is there a connector of any kind that could be used as the HW
component represented by the pwrseq device?

Bart

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Svyatoslav Ryhel]

вт, 26 трав. 2026 р. о 15:35 Bartosz Golaszewski <brgl@kernel.org> пише:
>
> On Tue, May 26, 2026 at 2:29 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > вт, 26 трав. 2026 р. о 14:14 Bartosz Golaszewski <brgl@kernel.org> пише:
> > >
> > > On Tue, 26 May 2026 12:03:59 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
> > > > вт, 26 трав. 2026 р. о 12:51 Bartosz Golaszewski <brgl@kernel.org> пише:
> > > >>
> > > >> On Sat, May 23, 2026 at 10:51 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > > >> >
> > > >> > 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>
> > > >> > ---
> > > >>
> > > >> ...
> > > >>
> > > >> > +
> > > >> > +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
> > > >> >
> > > >>
> > > >> I assume there's no such component as the tegra modem *pwrseq*?
> > > >
> > > > Hardware component, I assume no.
> > > >
> > > >> What is the relationship between this node and the "infineon,xmm6260"
> > > >> compatible node?
> > > >>
> > > >
> > > > The xmm6260 has a phandle reference to it. Since there is consumer
> > > > matching logic in the pwrseq driver I am leaning towards removing this
> > > > node entirely. This patches is still in non-final stage and I would
> > > > like to hear any opinions on the way to improving it.
> > > >
> > >
> > > The node attached to the pwrseq provider device should represent a real
> > > hardware component. Are the enable-gpios and power-supply lines connected
> > > to the modem package?
> >
> > Yes, enable-gpio is connected to the modem and signals that USB is set
> > and ready to work with the modem, while power-supply is an optional
> > supply connected to the modem's vbus input.
> >
>
> The modem is a hard-wired USB device? Do you implement it as a
> platform driver or a USB driver?
>

It is not a traditional USB device. XMM6260 is an embedded modem used
in the Tegra phones, it is linked with the AP using USB line in HSIC
mode. The driver is implemented as a platform device since it does not
interacts with the exposed USB device directly, it just ensures that
USB device is properly configured and is ready for IPC.

> Is there a connector of any kind that could be used as the HW
> component represented by the pwrseq device?

I assume control over USB line is the HW base, but as I have said, I
can integrate binding in the modem node itself, and pwrseq can get all
it needs from the match. Pwrseq framework states "This framework is
designed to abstract complex power-up sequences that are shared
between multiple logical devices in the Linux kernel." it does not say
that it must represent some specific hardware.

Using pwrseq allows modem driver to be SoC independent since USB line
handling is moved into SoC specific power sequence, and this modem is
used in Exynos and OMAP too with similar setup but they all have
different USB controllers. Maybe you can point me where SoC specific
USB controller handling can be implemented?

>
> Bart

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Bartosz Golaszewski]

On Tue, May 26, 2026 at 2:55 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> > > >
> > > > The node attached to the pwrseq provider device should represent a real
> > > > hardware component. Are the enable-gpios and power-supply lines connected
> > > > to the modem package?
> > >
> > > Yes, enable-gpio is connected to the modem and signals that USB is set
> > > and ready to work with the modem, while power-supply is an optional
> > > supply connected to the modem's vbus input.
> > >
> >
> > The modem is a hard-wired USB device? Do you implement it as a
> > platform driver or a USB driver?
> >
>
> It is not a traditional USB device. XMM6260 is an embedded modem used
> in the Tegra phones, it is linked with the AP using USB line in HSIC
> mode. The driver is implemented as a platform device since it does not
> interacts with the exposed USB device directly, it just ensures that
> USB device is properly configured and is ready for IPC.
>
> > Is there a connector of any kind that could be used as the HW
> > component represented by the pwrseq device?
>
> I assume control over USB line is the HW base, but as I have said, I
> can integrate binding in the modem node itself, and pwrseq can get all
> it needs from the match. Pwrseq framework states "This framework is
> designed to abstract complex power-up sequences that are shared
> between multiple logical devices in the Linux kernel." it does not say
> that it must represent some specific hardware.
>

No, not at all. We just can't make up any imaginary, logical "pwrseq"
devices and describe them in DT bindings.

> Using pwrseq allows modem driver to be SoC independent since USB line
> handling is moved into SoC specific power sequence, and this modem is
> used in Exynos and OMAP too with similar setup but they all have
> different USB controllers. Maybe you can point me where SoC specific
> USB controller handling can be implemented?
>

I'm not sure I'm following. Can you rephrase or point me where OMAP
and Samsung implement it?

Bart

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Svyatoslav Ryhel]

вт, 26 трав. 2026 р. о 16:14 Bartosz Golaszewski <brgl@kernel.org> пише:
>
> On Tue, May 26, 2026 at 2:55 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > > > >
> > > > > The node attached to the pwrseq provider device should represent a real
> > > > > hardware component. Are the enable-gpios and power-supply lines connected
> > > > > to the modem package?
> > > >
> > > > Yes, enable-gpio is connected to the modem and signals that USB is set
> > > > and ready to work with the modem, while power-supply is an optional
> > > > supply connected to the modem's vbus input.
> > > >
> > >
> > > The modem is a hard-wired USB device? Do you implement it as a
> > > platform driver or a USB driver?
> > >
> >
> > It is not a traditional USB device. XMM6260 is an embedded modem used
> > in the Tegra phones, it is linked with the AP using USB line in HSIC
> > mode. The driver is implemented as a platform device since it does not
> > interacts with the exposed USB device directly, it just ensures that
> > USB device is properly configured and is ready for IPC.
> >
> > > Is there a connector of any kind that could be used as the HW
> > > component represented by the pwrseq device?
> >
> > I assume control over USB line is the HW base, but as I have said, I
> > can integrate binding in the modem node itself, and pwrseq can get all
> > it needs from the match. Pwrseq framework states "This framework is
> > designed to abstract complex power-up sequences that are shared
> > between multiple logical devices in the Linux kernel." it does not say
> > that it must represent some specific hardware.
> >
>
> No, not at all. We just can't make up any imaginary, logical "pwrseq"
> devices and describe them in DT bindings.
>

Ye, ye, sure, pwrseq framework is quite flexible and I am not stating
this bindings is mandatory.

> > Using pwrseq allows modem driver to be SoC independent since USB line
> > handling is moved into SoC specific power sequence, and this modem is
> > used in Exynos and OMAP too with similar setup but they all have
> > different USB controllers. Maybe you can point me where SoC specific
> > USB controller handling can be implemented?
> >
>
> I'm not sure I'm following. Can you rephrase or point me where OMAP
> and Samsung implement it?
>

They did not.

The XMM6260 modem is used not only in the Tegra phones but in the OMAP
and Exynos based too. Replicant tried to implement support locally
with midas devices and they had some progress. From what I have seen
generic implementation I am proposing will work with any of those 3
SoCs maybe with some slight tweaks, only part that is totally
different and SoC specific is how USB controller used by the modem is
handled (well and IPC but that is out of scope of this patchset
anyway).

Obviously, non of the 3 vendors have submitted any mainline patches,
everything is in the downstream forks. I have investigated a bit how
this modem works on my Tegra phone and re-implemented it to work with
mainline kernel (I don't have Exynos and OMAP devices to play with). I
have come up with generic platform driver which handles modem
configuration and a SoC specific part which performs USB controller
bind/probe when modem is ready to handle the USB. ATM this SoC
specific part is available and tested only for Tegra devices.

> Bart

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Bartosz Golaszewski]

On Tue, 26 May 2026 15:41:58 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
> вт, 26 трав. 2026 р. о 16:14 Bartosz Golaszewski <brgl@kernel.org> пише:
>>
>> On Tue, May 26, 2026 at 2:55 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>> >
>> > > > >
>> > > > > The node attached to the pwrseq provider device should represent a real
>> > > > > hardware component. Are the enable-gpios and power-supply lines connected
>> > > > > to the modem package?
>> > > >
>> > > > Yes, enable-gpio is connected to the modem and signals that USB is set
>> > > > and ready to work with the modem, while power-supply is an optional
>> > > > supply connected to the modem's vbus input.
>> > > >
>> > >
>> > > The modem is a hard-wired USB device? Do you implement it as a
>> > > platform driver or a USB driver?
>> > >
>> >
>> > It is not a traditional USB device. XMM6260 is an embedded modem used
>> > in the Tegra phones, it is linked with the AP using USB line in HSIC
>> > mode. The driver is implemented as a platform device since it does not
>> > interacts with the exposed USB device directly, it just ensures that
>> > USB device is properly configured and is ready for IPC.
>> >
>> > > Is there a connector of any kind that could be used as the HW
>> > > component represented by the pwrseq device?
>> >
>> > I assume control over USB line is the HW base, but as I have said, I
>> > can integrate binding in the modem node itself, and pwrseq can get all
>> > it needs from the match. Pwrseq framework states "This framework is
>> > designed to abstract complex power-up sequences that are shared
>> > between multiple logical devices in the Linux kernel." it does not say
>> > that it must represent some specific hardware.
>> >
>>
>> No, not at all. We just can't make up any imaginary, logical "pwrseq"
>> devices and describe them in DT bindings.
>>
>
> Ye, ye, sure, pwrseq framework is quite flexible and I am not stating
> this bindings is mandatory.
>
>> > Using pwrseq allows modem driver to be SoC independent since USB line
>> > handling is moved into SoC specific power sequence, and this modem is
>> > used in Exynos and OMAP too with similar setup but they all have
>> > different USB controllers. Maybe you can point me where SoC specific
>> > USB controller handling can be implemented?
>> >
>>
>> I'm not sure I'm following. Can you rephrase or point me where OMAP
>> and Samsung implement it?
>>
>
> They did not.
>
> The XMM6260 modem is used not only in the Tegra phones but in the OMAP
> and Exynos based too. Replicant tried to implement support locally
> with midas devices and they had some progress. From what I have seen
> generic implementation I am proposing will work with any of those 3
> SoCs maybe with some slight tweaks, only part that is totally
> different and SoC specific is how USB controller used by the modem is
> handled (well and IPC but that is out of scope of this patchset
> anyway).
>
> Obviously, non of the 3 vendors have submitted any mainline patches,
> everything is in the downstream forks. I have investigated a bit how
> this modem works on my Tegra phone and re-implemented it to work with
> mainline kernel (I don't have Exynos and OMAP devices to play with). I
> have come up with generic platform driver which handles modem
> configuration and a SoC specific part which performs USB controller
> bind/probe when modem is ready to handle the USB. ATM this SoC
> specific part is available and tested only for Tegra devices.
>

Are you familiar with the PCI pwrctrl code that lives under
drivers/pci/pwrctrl/? It seems to be solving a somewhat similar issue for
PCI devices that are hardwired and powered externally. Maybe you could use
some of that code for your USB use-case?

Bartosz

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Krzysztof Kozlowski]

On 23/05/2026 10:51, Svyatoslav Ryhel wrote:
> 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

There is no such thing as pwrseq. I pointed you to existing code showing
how to do it - PCI or USB. Fake devices won't be accepted.

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Krzysztof Kozlowski]

On 27/05/2026 09:55, Bartosz Golaszewski wrote:
> On Tue, 26 May 2026 15:41:58 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
>> вт, 26 трав. 2026 р. о 16:14 Bartosz Golaszewski <brgl@kernel.org> пише:
>>>
>>> On Tue, May 26, 2026 at 2:55 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>>>>
>>>>>>>
>>>>>>> The node attached to the pwrseq provider device should represent a real
>>>>>>> hardware component. Are the enable-gpios and power-supply lines connected
>>>>>>> to the modem package?
>>>>>>
>>>>>> Yes, enable-gpio is connected to the modem and signals that USB is set
>>>>>> and ready to work with the modem, while power-supply is an optional
>>>>>> supply connected to the modem's vbus input.
>>>>>>
>>>>>
>>>>> The modem is a hard-wired USB device? Do you implement it as a
>>>>> platform driver or a USB driver?
>>>>>
>>>>
>>>> It is not a traditional USB device. XMM6260 is an embedded modem used
>>>> in the Tegra phones, it is linked with the AP using USB line in HSIC
>>>> mode. The driver is implemented as a platform device since it does not
>>>> interacts with the exposed USB device directly, it just ensures that
>>>> USB device is properly configured and is ready for IPC.
>>>>
>>>>> Is there a connector of any kind that could be used as the HW
>>>>> component represented by the pwrseq device?
>>>>
>>>> I assume control over USB line is the HW base, but as I have said, I
>>>> can integrate binding in the modem node itself, and pwrseq can get all
>>>> it needs from the match. Pwrseq framework states "This framework is
>>>> designed to abstract complex power-up sequences that are shared
>>>> between multiple logical devices in the Linux kernel." it does not say
>>>> that it must represent some specific hardware.
>>>>
>>>
>>> No, not at all. We just can't make up any imaginary, logical "pwrseq"
>>> devices and describe them in DT bindings.
>>>
>>
>> Ye, ye, sure, pwrseq framework is quite flexible and I am not stating
>> this bindings is mandatory.
>>
>>>> Using pwrseq allows modem driver to be SoC independent since USB line
>>>> handling is moved into SoC specific power sequence, and this modem is
>>>> used in Exynos and OMAP too with similar setup but they all have
>>>> different USB controllers. Maybe you can point me where SoC specific
>>>> USB controller handling can be implemented?
>>>>
>>>
>>> I'm not sure I'm following. Can you atrephrase or point me where OMAP
>>> and Samsung implement it?
>>>
>>
>> They did not.
>>
>> The XMM6260 modem is used not only in the Tegra phones but in the OMAP
>> and Exynos based too. Replicant tried to implement support locally
>> with midas devices and they had some progress. From what I have seen
>> generic implementation I am proposing will work with any of those 3
>> SoCs maybe with some slight tweaks, only part that is totally
>> different and SoC specific is how USB controller used by the modem is
>> handled (well and IPC but that is out of scope of this patchset
>> anyway).
>>
>> Obviously, non of the 3 vendors have submitted any mainline patches,
>> everything is in the downstream forks. I have investigated a bit how
>> this modem works on my Tegra phone and re-implemented it to work with
>> mainline kernel (I don't have Exynos and OMAP devices to play with). I
>> have come up with generic platform driver which handles modem
>> configuration and a SoC specific part which performs USB controller
>> bind/probe when modem is ready to handle the USB. ATM this SoC
>> specific part is available and tested only for Tegra devices.
>>
> 
> Are you familiar with the PCI pwrctrl code that lives under
> drivers/pci/pwrctrl/? It seems to be solving a somewhat similar issue for
> PCI devices that are hardwired and powered externally. Maybe you could use
> some of that code for your USB use-case?


I pointed to PCI already:
https://lore.kernel.org/lkml/20260518-mustard-rabbit-of-ecstasy-eed3b6@quoll/

And emphasized to describe hardware, not drivers. This binding AGAIN
describes drivers, so we did not move forward at all.


Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Svyatoslav Ryhel]

ср, 27 трав. 2026 р. о 11:26 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On 27/05/2026 09:55, Bartosz Golaszewski wrote:
> > On Tue, 26 May 2026 15:41:58 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
> >> вт, 26 трав. 2026 р. о 16:14 Bartosz Golaszewski <brgl@kernel.org> пише:
> >>>
> >>> On Tue, May 26, 2026 at 2:55 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >>>>
> >>>>>>>
> >>>>>>> The node attached to the pwrseq provider device should represent a real
> >>>>>>> hardware component. Are the enable-gpios and power-supply lines connected
> >>>>>>> to the modem package?
> >>>>>>
> >>>>>> Yes, enable-gpio is connected to the modem and signals that USB is set
> >>>>>> and ready to work with the modem, while power-supply is an optional
> >>>>>> supply connected to the modem's vbus input.
> >>>>>>
> >>>>>
> >>>>> The modem is a hard-wired USB device? Do you implement it as a
> >>>>> platform driver or a USB driver?
> >>>>>
> >>>>
> >>>> It is not a traditional USB device. XMM6260 is an embedded modem used
> >>>> in the Tegra phones, it is linked with the AP using USB line in HSIC
> >>>> mode. The driver is implemented as a platform device since it does not
> >>>> interacts with the exposed USB device directly, it just ensures that
> >>>> USB device is properly configured and is ready for IPC.
> >>>>
> >>>>> Is there a connector of any kind that could be used as the HW
> >>>>> component represented by the pwrseq device?
> >>>>
> >>>> I assume control over USB line is the HW base, but as I have said, I
> >>>> can integrate binding in the modem node itself, and pwrseq can get all
> >>>> it needs from the match. Pwrseq framework states "This framework is
> >>>> designed to abstract complex power-up sequences that are shared
> >>>> between multiple logical devices in the Linux kernel." it does not say
> >>>> that it must represent some specific hardware.
> >>>>
> >>>
> >>> No, not at all. We just can't make up any imaginary, logical "pwrseq"
> >>> devices and describe them in DT bindings.
> >>>
> >>
> >> Ye, ye, sure, pwrseq framework is quite flexible and I am not stating
> >> this bindings is mandatory.
> >>
> >>>> Using pwrseq allows modem driver to be SoC independent since USB line
> >>>> handling is moved into SoC specific power sequence, and this modem is
> >>>> used in Exynos and OMAP too with similar setup but they all have
> >>>> different USB controllers. Maybe you can point me where SoC specific
> >>>> USB controller handling can be implemented?
> >>>>
> >>>
> >>> I'm not sure I'm following. Can you atrephrase or point me where OMAP
> >>> and Samsung implement it?
> >>>
> >>
> >> They did not.
> >>
> >> The XMM6260 modem is used not only in the Tegra phones but in the OMAP
> >> and Exynos based too. Replicant tried to implement support locally
> >> with midas devices and they had some progress. From what I have seen
> >> generic implementation I am proposing will work with any of those 3
> >> SoCs maybe with some slight tweaks, only part that is totally
> >> different and SoC specific is how USB controller used by the modem is
> >> handled (well and IPC but that is out of scope of this patchset
> >> anyway).
> >>
> >> Obviously, non of the 3 vendors have submitted any mainline patches,
> >> everything is in the downstream forks. I have investigated a bit how
> >> this modem works on my Tegra phone and re-implemented it to work with
> >> mainline kernel (I don't have Exynos and OMAP devices to play with). I
> >> have come up with generic platform driver which handles modem
> >> configuration and a SoC specific part which performs USB controller
> >> bind/probe when modem is ready to handle the USB. ATM this SoC
> >> specific part is available and tested only for Tegra devices.
> >>
> >
> > Are you familiar with the PCI pwrctrl code that lives under
> > drivers/pci/pwrctrl/? It seems to be solving a somewhat similar issue for
> > PCI devices that are hardwired and powered externally. Maybe you could use
> > some of that code for your USB use-case?
>
>
> I pointed to PCI already:
> https://lore.kernel.org/lkml/20260518-mustard-rabbit-of-ecstasy-eed3b6@quoll/
>
> And emphasized to describe hardware, not drivers. This binding AGAIN
> describes drivers, so we did not move forward at all.
>
>
> Best regards,
> Krzysztof

Krzysztof, why are you so mean? Yes, I misunderstood you and sent this
schema. However, I am not stating or arguing that it must be applied
or whatever. I am just looking for a proper solution to issue I am
currently facing.

Anyway. That does not matter, what matters is how to organize
everything I have regarding this modem into a logic set. This is why I
am looking for maintainer suggestions.

How I see it ATM:
- I will remove this schema entirely and add usb-gpio (trigger for
modem that USB is ready), vbus supply (yes, modem has this line too
you can check in the P895 schematic) and infineon,usb-bus which
represents HSIC connection to the modem to the modem schema itself.
Obviously, I will add detailed descriptions of each component.
- I will resent patch 2 of this pwrseq with the modem patchset to have
a bigger picture. Pwrseq will obtain needed data from the modem node
itself (Bartosz Golaszewski are you fine with this?)
- I will try to get control over Tegra USB controller in the pwrseq
without need in externally-controlled flag I have proposed for
chipidea driver. I hope my idea will work.

Will this be acceptable for both of you?

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Bartosz Golaszewski]

On Wed, 27 May 2026 11:06:11 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
> ср, 27 трав. 2026 р. о 11:26 Krzysztof Kozlowski <krzk@kernel.org> пише:
>>
>> On 27/05/2026 09:55, Bartosz Golaszewski wrote:
>> > On Tue, 26 May 2026 15:41:58 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
>> >> вт, 26 трав. 2026 р. о 16:14 Bartosz Golaszewski <brgl@kernel.org> пише:
>> >>>
>> >>> On Tue, May 26, 2026 at 2:55 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>> >>>>
>> >>>>>>>
>> >>>>>>> The node attached to the pwrseq provider device should represent a real
>> >>>>>>> hardware component. Are the enable-gpios and power-supply lines connected
>> >>>>>>> to the modem package?
>> >>>>>>
>> >>>>>> Yes, enable-gpio is connected to the modem and signals that USB is set
>> >>>>>> and ready to work with the modem, while power-supply is an optional
>> >>>>>> supply connected to the modem's vbus input.
>> >>>>>>
>> >>>>>
>> >>>>> The modem is a hard-wired USB device? Do you implement it as a
>> >>>>> platform driver or a USB driver?
>> >>>>>
>> >>>>
>> >>>> It is not a traditional USB device. XMM6260 is an embedded modem used
>> >>>> in the Tegra phones, it is linked with the AP using USB line in HSIC
>> >>>> mode. The driver is implemented as a platform device since it does not
>> >>>> interacts with the exposed USB device directly, it just ensures that
>> >>>> USB device is properly configured and is ready for IPC.
>> >>>>
>> >>>>> Is there a connector of any kind that could be used as the HW
>> >>>>> component represented by the pwrseq device?
>> >>>>
>> >>>> I assume control over USB line is the HW base, but as I have said, I
>> >>>> can integrate binding in the modem node itself, and pwrseq can get all
>> >>>> it needs from the match. Pwrseq framework states "This framework is
>> >>>> designed to abstract complex power-up sequences that are shared
>> >>>> between multiple logical devices in the Linux kernel." it does not say
>> >>>> that it must represent some specific hardware.
>> >>>>
>> >>>
>> >>> No, not at all. We just can't make up any imaginary, logical "pwrseq"
>> >>> devices and describe them in DT bindings.
>> >>>
>> >>
>> >> Ye, ye, sure, pwrseq framework is quite flexible and I am not stating
>> >> this bindings is mandatory.
>> >>
>> >>>> Using pwrseq allows modem driver to be SoC independent since USB line
>> >>>> handling is moved into SoC specific power sequence, and this modem is
>> >>>> used in Exynos and OMAP too with similar setup but they all have
>> >>>> different USB controllers. Maybe you can point me where SoC specific
>> >>>> USB controller handling can be implemented?
>> >>>>
>> >>>
>> >>> I'm not sure I'm following. Can you atrephrase or point me where OMAP
>> >>> and Samsung implement it?
>> >>>
>> >>
>> >> They did not.
>> >>
>> >> The XMM6260 modem is used not only in the Tegra phones but in the OMAP
>> >> and Exynos based too. Replicant tried to implement support locally
>> >> with midas devices and they had some progress. From what I have seen
>> >> generic implementation I am proposing will work with any of those 3
>> >> SoCs maybe with some slight tweaks, only part that is totally
>> >> different and SoC specific is how USB controller used by the modem is
>> >> handled (well and IPC but that is out of scope of this patchset
>> >> anyway).
>> >>
>> >> Obviously, non of the 3 vendors have submitted any mainline patches,
>> >> everything is in the downstream forks. I have investigated a bit how
>> >> this modem works on my Tegra phone and re-implemented it to work with
>> >> mainline kernel (I don't have Exynos and OMAP devices to play with). I
>> >> have come up with generic platform driver which handles modem
>> >> configuration and a SoC specific part which performs USB controller
>> >> bind/probe when modem is ready to handle the USB. ATM this SoC
>> >> specific part is available and tested only for Tegra devices.
>> >>
>> >
>> > Are you familiar with the PCI pwrctrl code that lives under
>> > drivers/pci/pwrctrl/? It seems to be solving a somewhat similar issue for
>> > PCI devices that are hardwired and powered externally. Maybe you could use
>> > some of that code for your USB use-case?
>>
>>
>> I pointed to PCI already:
>> https://lore.kernel.org/lkml/20260518-mustard-rabbit-of-ecstasy-eed3b6@quoll/
>>
>> And emphasized to describe hardware, not drivers. This binding AGAIN
>> describes drivers, so we did not move forward at all.
>>
>>
>> Best regards,
>> Krzysztof
>
> Krzysztof, why are you so mean? Yes, I misunderstood you and sent this
> schema. However, I am not stating or arguing that it must be applied
> or whatever. I am just looking for a proper solution to issue I am
> currently facing.
>

Krzysztof reviews hundreds of patches so his fuse is quite short, don't take
it personally, he's a nice guy in real life. :)

> Anyway. That does not matter, what matters is how to organize
> everything I have regarding this modem into a logic set. This is why I
> am looking for maintainer suggestions.
>
> How I see it ATM:
> - I will remove this schema entirely and add usb-gpio (trigger for
> modem that USB is ready), vbus supply (yes, modem has this line too
> you can check in the P895 schematic) and infineon,usb-bus which
> represents HSIC connection to the modem to the modem schema itself.
> Obviously, I will add detailed descriptions of each component.
> - I will resent patch 2 of this pwrseq with the modem patchset to have
> a bigger picture. Pwrseq will obtain needed data from the modem node
> itself (Bartosz Golaszewski are you fine with this?)

As in: the modem driver will be the pwrseq provider? Sure, sounds good.

> - I will try to get control over Tegra USB controller in the pwrseq
> without need in externally-controlled flag I have proposed for
> chipidea driver. I hope my idea will work.
>
> Will this be acceptable for both of you?
>

Bart

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Krzysztof Kozlowski]

On 27/05/2026 11:06, Svyatoslav Ryhel wrote:
> ср, 27 трав. 2026 р. о 11:26 Krzysztof Kozlowski <krzk@kernel.org> пише:
>>
>> On 27/05/2026 09:55, Bartosz Golaszewski wrote:
>>> On Tue, 26 May 2026 15:41:58 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
>>>> вт, 26 трав. 2026 р. о 16:14 Bartosz Golaszewski <brgl@kernel.org> пише:
>>>>>
>>>>> On Tue, May 26, 2026 at 2:55 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>>>>>>
>>>>>>>>>
>>>>>>>>> The node attached to the pwrseq provider device should represent a real
>>>>>>>>> hardware component. Are the enable-gpios and power-supply lines connected
>>>>>>>>> to the modem package?
>>>>>>>>
>>>>>>>> Yes, enable-gpio is connected to the modem and signals that USB is set
>>>>>>>> and ready to work with the modem, while power-supply is an optional
>>>>>>>> supply connected to the modem's vbus input.
>>>>>>>>
>>>>>>>
>>>>>>> The modem is a hard-wired USB device? Do you implement it as a
>>>>>>> platform driver or a USB driver?
>>>>>>>
>>>>>>
>>>>>> It is not a traditional USB device. XMM6260 is an embedded modem used
>>>>>> in the Tegra phones, it is linked with the AP using USB line in HSIC
>>>>>> mode. The driver is implemented as a platform device since it does not
>>>>>> interacts with the exposed USB device directly, it just ensures that
>>>>>> USB device is properly configured and is ready for IPC.
>>>>>>
>>>>>>> Is there a connector of any kind that could be used as the HW
>>>>>>> component represented by the pwrseq device?
>>>>>>
>>>>>> I assume control over USB line is the HW base, but as I have said, I
>>>>>> can integrate binding in the modem node itself, and pwrseq can get all
>>>>>> it needs from the match. Pwrseq framework states "This framework is
>>>>>> designed to abstract complex power-up sequences that are shared
>>>>>> between multiple logical devices in the Linux kernel." it does not say
>>>>>> that it must represent some specific hardware.
>>>>>>
>>>>>
>>>>> No, not at all. We just can't make up any imaginary, logical "pwrseq"
>>>>> devices and describe them in DT bindings.
>>>>>
>>>>
>>>> Ye, ye, sure, pwrseq framework is quite flexible and I am not stating
>>>> this bindings is mandatory.
>>>>
>>>>>> Using pwrseq allows modem driver to be SoC independent since USB line
>>>>>> handling is moved into SoC specific power sequence, and this modem is
>>>>>> used in Exynos and OMAP too with similar setup but they all have
>>>>>> different USB controllers. Maybe you can point me where SoC specific
>>>>>> USB controller handling can be implemented?
>>>>>>
>>>>>
>>>>> I'm not sure I'm following. Can you atrephrase or point me where OMAP
>>>>> and Samsung implement it?
>>>>>
>>>>
>>>> They did not.
>>>>
>>>> The XMM6260 modem is used not only in the Tegra phones but in the OMAP
>>>> and Exynos based too. Replicant tried to implement support locally
>>>> with midas devices and they had some progress. From what I have seen
>>>> generic implementation I am proposing will work with any of those 3
>>>> SoCs maybe with some slight tweaks, only part that is totally
>>>> different and SoC specific is how USB controller used by the modem is
>>>> handled (well and IPC but that is out of scope of this patchset
>>>> anyway).
>>>>
>>>> Obviously, non of the 3 vendors have submitted any mainline patches,
>>>> everything is in the downstream forks. I have investigated a bit how
>>>> this modem works on my Tegra phone and re-implemented it to work with
>>>> mainline kernel (I don't have Exynos and OMAP devices to play with). I
>>>> have come up with generic platform driver which handles modem
>>>> configuration and a SoC specific part which performs USB controller
>>>> bind/probe when modem is ready to handle the USB. ATM this SoC
>>>> specific part is available and tested only for Tegra devices.
>>>>
>>>
>>> Are you familiar with the PCI pwrctrl code that lives under
>>> drivers/pci/pwrctrl/? It seems to be solving a somewhat similar issue for
>>> PCI devices that are hardwired and powered externally. Maybe you could use
>>> some of that code for your USB use-case?
>>
>>
>> I pointed to PCI already:
>> https://lore.kernel.org/lkml/20260518-mustard-rabbit-of-ecstasy-eed3b6@quoll/
>>
>> And emphasized to describe hardware, not drivers. This binding AGAIN
>> describes drivers, so we did not move forward at all.
>>
>>
>> Best regards,
>> Krzysztof
> 
> Krzysztof, why are you so mean? Yes, I misunderstood you and sent this

Just to recap:

https://lore.kernel.org/all/CAPVz0n09ZP1i2tasdTvnt8RvjhALvUYjv9u_EGRtnXPOYQtuqQ@mail.gmail.com/

And enormous discussion wasting our time here:
https://lore.kernel.org/all/CAPVz0n0u7uhL8_FQFiuB7DrnL++ecbaEKEoV7N2PgTVRBVECkw@mail.gmail.com/
because you were pushing your solution. I run out of spare time to
handle endless discussions with you because you reject standard comments
and expect long discussions with multiple justifications for standard
(and documented in writing bindings) DT rules.

So here I told you to do like USB and PCI. This patchset is nothing like
them.

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Svyatoslav Ryhel]

ср, 27 трав. 2026 р. о 12:15 Bartosz Golaszewski <brgl@kernel.org> пише:
>
> On Wed, 27 May 2026 11:06:11 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
> > ср, 27 трав. 2026 р. о 11:26 Krzysztof Kozlowski <krzk@kernel.org> пише:
> >>
> >> On 27/05/2026 09:55, Bartosz Golaszewski wrote:
> >> > On Tue, 26 May 2026 15:41:58 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
> >> >> вт, 26 трав. 2026 р. о 16:14 Bartosz Golaszewski <brgl@kernel.org> пише:
> >> >>>
> >> >>> On Tue, May 26, 2026 at 2:55 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >> >>>>
> >> >>>>>>>
> >> >>>>>>> The node attached to the pwrseq provider device should represent a real
> >> >>>>>>> hardware component. Are the enable-gpios and power-supply lines connected
> >> >>>>>>> to the modem package?
> >> >>>>>>
> >> >>>>>> Yes, enable-gpio is connected to the modem and signals that USB is set
> >> >>>>>> and ready to work with the modem, while power-supply is an optional
> >> >>>>>> supply connected to the modem's vbus input.
> >> >>>>>>
> >> >>>>>
> >> >>>>> The modem is a hard-wired USB device? Do you implement it as a
> >> >>>>> platform driver or a USB driver?
> >> >>>>>
> >> >>>>
> >> >>>> It is not a traditional USB device. XMM6260 is an embedded modem used
> >> >>>> in the Tegra phones, it is linked with the AP using USB line in HSIC
> >> >>>> mode. The driver is implemented as a platform device since it does not
> >> >>>> interacts with the exposed USB device directly, it just ensures that
> >> >>>> USB device is properly configured and is ready for IPC.
> >> >>>>
> >> >>>>> Is there a connector of any kind that could be used as the HW
> >> >>>>> component represented by the pwrseq device?
> >> >>>>
> >> >>>> I assume control over USB line is the HW base, but as I have said, I
> >> >>>> can integrate binding in the modem node itself, and pwrseq can get all
> >> >>>> it needs from the match. Pwrseq framework states "This framework is
> >> >>>> designed to abstract complex power-up sequences that are shared
> >> >>>> between multiple logical devices in the Linux kernel." it does not say
> >> >>>> that it must represent some specific hardware.
> >> >>>>
> >> >>>
> >> >>> No, not at all. We just can't make up any imaginary, logical "pwrseq"
> >> >>> devices and describe them in DT bindings.
> >> >>>
> >> >>
> >> >> Ye, ye, sure, pwrseq framework is quite flexible and I am not stating
> >> >> this bindings is mandatory.
> >> >>
> >> >>>> Using pwrseq allows modem driver to be SoC independent since USB line
> >> >>>> handling is moved into SoC specific power sequence, and this modem is
> >> >>>> used in Exynos and OMAP too with similar setup but they all have
> >> >>>> different USB controllers. Maybe you can point me where SoC specific
> >> >>>> USB controller handling can be implemented?
> >> >>>>
> >> >>>
> >> >>> I'm not sure I'm following. Can you atrephrase or point me where OMAP
> >> >>> and Samsung implement it?
> >> >>>
> >> >>
> >> >> They did not.
> >> >>
> >> >> The XMM6260 modem is used not only in the Tegra phones but in the OMAP
> >> >> and Exynos based too. Replicant tried to implement support locally
> >> >> with midas devices and they had some progress. From what I have seen
> >> >> generic implementation I am proposing will work with any of those 3
> >> >> SoCs maybe with some slight tweaks, only part that is totally
> >> >> different and SoC specific is how USB controller used by the modem is
> >> >> handled (well and IPC but that is out of scope of this patchset
> >> >> anyway).
> >> >>
> >> >> Obviously, non of the 3 vendors have submitted any mainline patches,
> >> >> everything is in the downstream forks. I have investigated a bit how
> >> >> this modem works on my Tegra phone and re-implemented it to work with
> >> >> mainline kernel (I don't have Exynos and OMAP devices to play with). I
> >> >> have come up with generic platform driver which handles modem
> >> >> configuration and a SoC specific part which performs USB controller
> >> >> bind/probe when modem is ready to handle the USB. ATM this SoC
> >> >> specific part is available and tested only for Tegra devices.
> >> >>
> >> >
> >> > Are you familiar with the PCI pwrctrl code that lives under
> >> > drivers/pci/pwrctrl/? It seems to be solving a somewhat similar issue for
> >> > PCI devices that are hardwired and powered externally. Maybe you could use
> >> > some of that code for your USB use-case?
> >>
> >>
> >> I pointed to PCI already:
> >> https://lore.kernel.org/lkml/20260518-mustard-rabbit-of-ecstasy-eed3b6@quoll/
> >>
> >> And emphasized to describe hardware, not drivers. This binding AGAIN
> >> describes drivers, so we did not move forward at all.
> >>
> >>
> >> Best regards,
> >> Krzysztof
> >
> > Krzysztof, why are you so mean? Yes, I misunderstood you and sent this
> > schema. However, I am not stating or arguing that it must be applied
> > or whatever. I am just looking for a proper solution to issue I am
> > currently facing.
> >
>
> Krzysztof reviews hundreds of patches so his fuse is quite short, don't take
> it personally, he's a nice guy in real life. :)
>
> > Anyway. That does not matter, what matters is how to organize
> > everything I have regarding this modem into a logic set. This is why I
> > am looking for maintainer suggestions.
> >
> > How I see it ATM:
> > - I will remove this schema entirely and add usb-gpio (trigger for
> > modem that USB is ready), vbus supply (yes, modem has this line too
> > you can check in the P895 schematic) and infineon,usb-bus which
> > represents HSIC connection to the modem to the modem schema itself.
> > Obviously, I will add detailed descriptions of each component.
> > - I will resent patch 2 of this pwrseq with the modem patchset to have
> > a bigger picture. Pwrseq will obtain needed data from the modem node
> > itself (Bartosz Golaszewski are you fine with this?)
>
> As in: the modem driver will be the pwrseq provider? Sure, sounds good.
>

No, consumer. Modem calls SoC specific pwrseq.

> > - I will try to get control over Tegra USB controller in the pwrseq
> > without need in externally-controlled flag I have proposed for
> > chipidea driver. I hope my idea will work.
> >
> > Will this be acceptable for both of you?
> >
>
> Bart

Re: [PATCH v2 1/2] dt-bindings: soc: tegra: Document Nvidia Tegra modem pwrseq

[Svyatoslav Ryhel]

ср, 27 трав. 2026 р. о 12:20 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On 27/05/2026 11:06, Svyatoslav Ryhel wrote:
> > ср, 27 трав. 2026 р. о 11:26 Krzysztof Kozlowski <krzk@kernel.org> пише:
> >>
> >> On 27/05/2026 09:55, Bartosz Golaszewski wrote:
> >>> On Tue, 26 May 2026 15:41:58 +0200, Svyatoslav Ryhel <clamor95@gmail.com> said:
> >>>> вт, 26 трав. 2026 р. о 16:14 Bartosz Golaszewski <brgl@kernel.org> пише:
> >>>>>
> >>>>> On Tue, May 26, 2026 at 2:55 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >>>>>>
> >>>>>>>>>
> >>>>>>>>> The node attached to the pwrseq provider device should represent a real
> >>>>>>>>> hardware component. Are the enable-gpios and power-supply lines connected
> >>>>>>>>> to the modem package?
> >>>>>>>>
> >>>>>>>> Yes, enable-gpio is connected to the modem and signals that USB is set
> >>>>>>>> and ready to work with the modem, while power-supply is an optional
> >>>>>>>> supply connected to the modem's vbus input.
> >>>>>>>>
> >>>>>>>
> >>>>>>> The modem is a hard-wired USB device? Do you implement it as a
> >>>>>>> platform driver or a USB driver?
> >>>>>>>
> >>>>>>
> >>>>>> It is not a traditional USB device. XMM6260 is an embedded modem used
> >>>>>> in the Tegra phones, it is linked with the AP using USB line in HSIC
> >>>>>> mode. The driver is implemented as a platform device since it does not
> >>>>>> interacts with the exposed USB device directly, it just ensures that
> >>>>>> USB device is properly configured and is ready for IPC.
> >>>>>>
> >>>>>>> Is there a connector of any kind that could be used as the HW
> >>>>>>> component represented by the pwrseq device?
> >>>>>>
> >>>>>> I assume control over USB line is the HW base, but as I have said, I
> >>>>>> can integrate binding in the modem node itself, and pwrseq can get all
> >>>>>> it needs from the match. Pwrseq framework states "This framework is
> >>>>>> designed to abstract complex power-up sequences that are shared
> >>>>>> between multiple logical devices in the Linux kernel." it does not say
> >>>>>> that it must represent some specific hardware.
> >>>>>>
> >>>>>
> >>>>> No, not at all. We just can't make up any imaginary, logical "pwrseq"
> >>>>> devices and describe them in DT bindings.
> >>>>>
> >>>>
> >>>> Ye, ye, sure, pwrseq framework is quite flexible and I am not stating
> >>>> this bindings is mandatory.
> >>>>
> >>>>>> Using pwrseq allows modem driver to be SoC independent since USB line
> >>>>>> handling is moved into SoC specific power sequence, and this modem is
> >>>>>> used in Exynos and OMAP too with similar setup but they all have
> >>>>>> different USB controllers. Maybe you can point me where SoC specific
> >>>>>> USB controller handling can be implemented?
> >>>>>>
> >>>>>
> >>>>> I'm not sure I'm following. Can you atrephrase or point me where OMAP
> >>>>> and Samsung implement it?
> >>>>>
> >>>>
> >>>> They did not.
> >>>>
> >>>> The XMM6260 modem is used not only in the Tegra phones but in the OMAP
> >>>> and Exynos based too. Replicant tried to implement support locally
> >>>> with midas devices and they had some progress. From what I have seen
> >>>> generic implementation I am proposing will work with any of those 3
> >>>> SoCs maybe with some slight tweaks, only part that is totally
> >>>> different and SoC specific is how USB controller used by the modem is
> >>>> handled (well and IPC but that is out of scope of this patchset
> >>>> anyway).
> >>>>
> >>>> Obviously, non of the 3 vendors have submitted any mainline patches,
> >>>> everything is in the downstream forks. I have investigated a bit how
> >>>> this modem works on my Tegra phone and re-implemented it to work with
> >>>> mainline kernel (I don't have Exynos and OMAP devices to play with). I
> >>>> have come up with generic platform driver which handles modem
> >>>> configuration and a SoC specific part which performs USB controller
> >>>> bind/probe when modem is ready to handle the USB. ATM this SoC
> >>>> specific part is available and tested only for Tegra devices.
> >>>>
> >>>
> >>> Are you familiar with the PCI pwrctrl code that lives under
> >>> drivers/pci/pwrctrl/? It seems to be solving a somewhat similar issue for
> >>> PCI devices that are hardwired and powered externally. Maybe you could use
> >>> some of that code for your USB use-case?
> >>
> >>
> >> I pointed to PCI already:
> >> https://lore.kernel.org/lkml/20260518-mustard-rabbit-of-ecstasy-eed3b6@quoll/
> >>
> >> And emphasized to describe hardware, not drivers. This binding AGAIN
> >> describes drivers, so we did not move forward at all.
> >>
> >>
> >> Best regards,
> >> Krzysztof
> >
> > Krzysztof, why are you so mean? Yes, I misunderstood you and sent this
>
> Just to recap:
>
> https://lore.kernel.org/all/CAPVz0n09ZP1i2tasdTvnt8RvjhALvUYjv9u_EGRtnXPOYQtuqQ@mail.gmail.com/
>
> And enormous discussion wasting our time here:
> https://lore.kernel.org/all/CAPVz0n0u7uhL8_FQFiuB7DrnL++ecbaEKEoV7N2PgTVRBVECkw@mail.gmail.com/
> because you were pushing your solution. I run out of spare time to
> handle endless discussions with you because you reject standard comments
> and expect long discussions with multiple justifications for standard
> (and documented in writing bindings) DT rules.
>
> So here I told you to do like USB and PCI. This patchset is nothing like
> them.
>

You are creating an entire database of discussions we had. I am flattered.

> Best regards,
> Krzysztof

Re: [PATCH v2 0/2] power: sequencing: Add support for Nvidia Tegra modem pwrseq

[Svyatoslav Ryhel]

сб, 23 трав. 2026 р. о 11:51 Svyatoslav Ryhel <clamor95@gmail.com> пише:
>
> 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
>

Hello there! There will be no v3. Sorry for disturbing LKML with 15
year old obsolete tech. My mistake.