[PATCH v5 0/6] Add Samsung Galaxy S4 support

[PATCH v5 0/6] Add Samsung Galaxy S4 support

[Alexandre MINETTE via B4 Relay]

Add initial mainline support for the Samsung Galaxy S4, codenamed jflte.

This series adds the devicetree binding and board DTS, together with the
small driver and common DTS changes needed to boot the device with working
USB peripheral mode.

Tested on a Samsung Galaxy S4 GT-I9505. This series adds support for
UART, USB peripheral mode with USB networking, the front notification
LED and the physical buttons.

Booting the device also requires an MSM IOMMU master handling fix,
which will be submitted separately.

Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
---
Changes in v5:
- Added Reviewed-by/Acked-by collected on v4
- Link to v4: https://lore.kernel.org/r/20260609-mainline-send-v1-sending-v4-0-83768fbf404d@alex-min.fr

Changes in v4:
- Rework PM8921 USB ID support by registering the extcon device from the
  parent PMIC driver instead of describing a separate DT child node.
- Add GPIO_OPEN_DRAIN flag to i2c-gpio
- Drop the Reviewed-by tag from the Galaxy S4 DTS patch because its USB
  extcon description changed.
- Drop the MSM IOMMU master lookup fix from this series. It needs a
  broader rework and will be sent separately.
- jflte still needs that follow-up MSM IOMMU fix to boot.
- Link to v3: https://lore.kernel.org/r/20260519-mainline-send-v1-sending-v3-0-3dd7aa125353@alex-min.fr

Changes in v3:
- Clarify that the Galaxy S4 compatible is for the Qualcomm
  APQ8064-based variant, and add Krzysztof's Acked-by.
- Clarify the PM8921 USB ID binding, driver and DTS commit messages to
  describe the PMIC interrupt-controller interface and the lack of a
  known register resource for this interrupt-only path.
- Keep the PM8921 USB ID extcon node non-addressable rather than adding a
  speculative reg value.
- Keep the MUIC and LED buses as i2c-gpio. Testing the corresponding
  GSBI controllers on GT-I9505 made USB fail to enumerate with the MUIC
  on GSBI2, and made LED brightness writes time out with the LED on
  GSBI3.
- Reorder APQ8064 USB clock entries to match the related ci-hdrc binding
  update, using iface, core, fs order.
- Sort the jflte DTB Makefile entry after the LG Nexus 4 entry.
- Link to v2: https://lore.kernel.org/r/20260427-mainline-send-v1-sending-v2-0-dcaa9178007b@alex-min.fr

Changes in v2:
- Keep the APQ8064 compatible list in qcom.yaml alphabetically sorted.
- Clarify the Qualcomm pinctrl commit message and include the failing hog
  lookup trace seen on APQ8064.
- Clarify the MSM IOMMU commit message and include the NULL dereference
  trace seen during IOMMU probe on APQ8064.
- Move the PM8921 USB ID extcon node to the end of the PM8921 child nodes.
- Reorder the jflte DTS nodes and pinctrl properties as requested by
  reviewers.
- Add Reviewed-by/Acked-by tags collected on v1.
- Link to v1: https://lore.kernel.org/r/20260421-mainline-send-v1-sending-v1-0-bcb0857724de@alex-min.fr

To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Linus Walleij <linusw@kernel.org>
To: Lee Jones <lee@kernel.org>
To: MyungJoo Ham <myungjoo.ham@samsung.com>
To: Chanwoo Choi <cw00.choi@samsung.com>
To: Kees Cook <kees@kernel.org>
To: Tony Luck <tony.luck@intel.com>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-gpio@vger.kernel.org

---
Alexandre MINETTE (6):
      dt-bindings: arm: qcom: Add Samsung Galaxy S4
      pinctrl: qcom: Register functions before enabling pinctrl
      ARM: dts: qcom: apq8064: Fix USB controller clocks
      mfd: qcom-pm8xxx: register PM8921 USB ID extcon
      extcon: qcom-spmi-misc: match PM8xxx USB ID platform device
      ARM: dts: qcom: Add Samsung Galaxy S4

 Documentation/devicetree/bindings/arm/qcom.yaml    |   1 +
 arch/arm/boot/dts/qcom/Makefile                    |   1 +
 .../boot/dts/qcom/qcom-apq8064-samsung-jflte.dts   | 481 +++++++++++++++++++++
 arch/arm/boot/dts/qcom/qcom-apq8064.dtsi           |  18 +-
 drivers/extcon/extcon-qcom-spmi-misc.c             |   7 +
 drivers/mfd/qcom-pm8xxx.c                          |  78 +++-
 drivers/pinctrl/qcom/pinctrl-msm.c                 |  15 +-
 7 files changed, 588 insertions(+), 13 deletions(-)
---
base-commit: 4bf3800382b91c2898d14452cf4332782b3fe80a
change-id: 20260421-mainline-send-v1-sending-289ec98e6dc1

Best regards,
--  
Alexandre MINETTE <contact@alex-min.fr>

[PATCH v5 1/6] dt-bindings: arm: qcom: Add Samsung Galaxy S4

[Alexandre MINETTE via B4 Relay]

From: Alexandre MINETTE <contact@alex-min.fr>

Add the compatible for the Qualcomm APQ8064-based Samsung Galaxy S4,
codenamed jflte.

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index b4943123d2e4..b7e186ed2efc 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -39,6 +39,7 @@ properties:
           - enum:
               - asus,nexus7-flo
               - lg,nexus4-mako
+              - samsung,jflte
               - sony,xperia-yuga
               - qcom,apq8064-cm-qs600
               - qcom,apq8064-ifc6410

-- 
2.43.0

[PATCH v5 2/6] pinctrl: qcom: Register functions before enabling pinctrl

[Alexandre MINETTE via B4 Relay]

From: Alexandre MINETTE <contact@alex-min.fr>

pinctrl consumers can request states while the pinctrl core enables the
controller. On Qualcomm pinctrl drivers this can happen before the SoC
function list has been registered, which leaves the function table
incomplete during state lookup.

On APQ8064 this can fail while claiming pinctrl hogs:

   apq8064-pinctrl 800000.pinctrl: invalid function ps_hold in map table
   apq8064-pinctrl 800000.pinctrl: error claiming hogs: -22
   apq8064-pinctrl 800000.pinctrl: could not claim hogs: -22

Register Qualcomm pinctrl with devm_pinctrl_register_and_init(), add the
SoC pin functions, and only then enable the pinctrl device.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
---
 drivers/pinctrl/qcom/pinctrl-msm.c | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
index 45b3a2763eb8..a2a1e0835735 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -1593,11 +1593,11 @@ int msm_pinctrl_probe(struct platform_device *pdev,
 	pctrl->desc.pins = pctrl->soc->pins;
 	pctrl->desc.npins = pctrl->soc->npins;
 
-	pctrl->pctrl = devm_pinctrl_register(&pdev->dev, &pctrl->desc, pctrl);
-	if (IS_ERR(pctrl->pctrl)) {
-		dev_err(&pdev->dev, "Couldn't register pinctrl driver\n");
-		return PTR_ERR(pctrl->pctrl);
-	}
+	ret = devm_pinctrl_register_and_init(&pdev->dev, &pctrl->desc,
+					     pctrl, &pctrl->pctrl);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret,
+				     "Couldn't register pinctrl driver\n");
 
 	for (i = 0; i < soc_data->nfunctions; i++) {
 		func = &soc_data->functions[i];
@@ -1607,6 +1607,11 @@ int msm_pinctrl_probe(struct platform_device *pdev,
 			return ret;
 	}
 
+	ret = pinctrl_enable(pctrl->pctrl);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret,
+				     "Couldn't enable pinctrl driver\n");
+
 	ret = msm_gpio_init(pctrl);
 	if (ret)
 		return ret;

-- 
2.43.0

[PATCH v5 3/6] ARM: dts: qcom: apq8064: Fix USB controller clocks

[Alexandre MINETTE via B4 Relay]

From: Alexandre MINETTE <contact@alex-min.fr>

The APQ8064 HS USB controller nodes describe the transceiver clock as
"core", but the ChipIdea MSM glue expects "core" to be the controller
fabric clock and "fs" to be the transceiver clock.

This mismatch can leave the fabric clock disabled while the controller is
accessed. Some boards may tolerate that if the clock is already enabled
elsewhere, but it is not a correct description of the hardware.

Describe the RPM Daytona fabric clock as "core", the AHB clock as
"iface", and the transceiver clock as "fs" for all APQ8064 HS USB
controllers. Without this, USB does not probe reliably on Samsung Galaxy
S4 because the fabric clock remains disabled.

Link: https://lore.kernel.org/all/20260516-qcom-ci-hdrc-clock-fix-v2-1-aaec8d33d0aa@smankusors.com/
Suggested-by: Antony Kurniawan Soemardi <linux@smankusors.com>
Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
 arch/arm/boot/dts/qcom/qcom-apq8064.dtsi | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
index 09062b2ad8ba..d64a162abdad 100644
--- a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
@@ -813,8 +813,10 @@ usb1: usb@12500000 {
 			reg = <0x12500000 0x200>,
 			      <0x12500200 0x200>;
 			interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&gcc USB_HS1_XCVR_CLK>, <&gcc USB_HS1_H_CLK>;
-			clock-names = "core", "iface";
+			clocks = <&gcc USB_HS1_H_CLK>,
+				 <&rpmcc RPM_DAYTONA_FABRIC_CLK>,
+				 <&gcc USB_HS1_XCVR_CLK>;
+			clock-names = "iface", "core", "fs";
 			assigned-clocks = <&gcc USB_HS1_XCVR_CLK>;
 			assigned-clock-rates = <60000000>;
 			resets = <&gcc USB_HS1_RESET>;
@@ -844,8 +846,10 @@ usb3: usb@12520000 {
 			reg = <0x12520000 0x200>,
 			      <0x12520200 0x200>;
 			interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&gcc USB_HS3_XCVR_CLK>, <&gcc USB_HS3_H_CLK>;
-			clock-names = "core", "iface";
+			clocks = <&gcc USB_HS3_H_CLK>,
+				 <&rpmcc RPM_DAYTONA_FABRIC_CLK>,
+				 <&gcc USB_HS3_XCVR_CLK>;
+			clock-names = "iface", "core", "fs";
 			assigned-clocks = <&gcc USB_HS3_XCVR_CLK>;
 			assigned-clock-rates = <60000000>;
 			resets = <&gcc USB_HS3_RESET>;
@@ -875,8 +879,10 @@ usb4: usb@12530000 {
 			reg = <0x12530000 0x200>,
 			      <0x12530200 0x200>;
 			interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&gcc USB_HS4_XCVR_CLK>, <&gcc USB_HS4_H_CLK>;
-			clock-names = "core", "iface";
+			clocks = <&gcc USB_HS4_H_CLK>,
+				 <&rpmcc RPM_DAYTONA_FABRIC_CLK>,
+				 <&gcc USB_HS4_XCVR_CLK>;
+			clock-names = "iface", "core", "fs";
 			assigned-clocks = <&gcc USB_HS4_XCVR_CLK>;
 			assigned-clock-rates = <60000000>;
 			resets = <&gcc USB_HS4_RESET>;

-- 
2.43.0

[PATCH v5 4/6] mfd: qcom-pm8xxx: register PM8921 USB ID extcon

[Alexandre MINETTE via B4 Relay]

From: Alexandre MINETTE <contact@alex-min.fr>

PM8921 reports the USB ID pin through interrupt 49 of its interrupt
controller. Unlike PM8941, this path has no separate addressable misc
block to represent as a devicetree child node.

Register a child platform device for the existing Qualcomm USB extcon
driver after creating the PMIC IRQ domain. Pass the USB ID interrupt as
a named resource and reuse the PM8921 firmware node, allowing consumers
to reference the PMIC node directly as their extcon provider.

Unregister the child device and dispose of the IRQ mapping when the
PMIC is removed or probing fails.

Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
---
 drivers/mfd/qcom-pm8xxx.c | 78 +++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 76 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
index 0cf374c015ce..884fc99a1488 100644
--- a/drivers/mfd/qcom-pm8xxx.c
+++ b/drivers/mfd/qcom-pm8xxx.c
@@ -7,6 +7,7 @@
 
 #include <linux/kernel.h>
 #include <linux/interrupt.h>
+#include <linux/ioport.h>
 #include <linux/irqchip/chained_irq.h>
 #include <linux/irq.h>
 #include <linux/irqdomain.h>
@@ -64,12 +65,15 @@
 
 struct pm_irq_data {
 	int num_irqs;
+	int usb_id_irq;
 	struct irq_chip *irq_chip;
 	irq_handler_t irq_handler;
 };
 
 struct pm_irq_chip {
 	struct regmap		*regmap;
+	struct platform_device	*usb_extcon;
+	unsigned int		usb_id_irq;
 	spinlock_t		pm_irq_lock;
 	struct irq_domain	*irqdomain;
 	unsigned int		num_blocks;
@@ -492,6 +496,13 @@ static const struct pm_irq_data pm8xxx_data = {
 	.irq_handler = pm8xxx_irq_handler,
 };
 
+static const struct pm_irq_data pm8921_data = {
+	.num_irqs = PM8XXX_NR_IRQS,
+	.usb_id_irq = 49,
+	.irq_chip = &pm8xxx_irq_chip,
+	.irq_handler = pm8xxx_irq_handler,
+};
+
 static const struct pm_irq_data pm8821_data = {
 	.num_irqs = PM8821_NR_IRQS,
 	.irq_chip = &pm8821_irq_chip,
@@ -501,11 +512,60 @@ static const struct pm_irq_data pm8821_data = {
 static const struct of_device_id pm8xxx_id_table[] = {
 	{ .compatible = "qcom,pm8058", .data = &pm8xxx_data},
 	{ .compatible = "qcom,pm8821", .data = &pm8821_data},
-	{ .compatible = "qcom,pm8921", .data = &pm8xxx_data},
+	{ .compatible = "qcom,pm8921", .data = &pm8921_data},
 	{ }
 };
 MODULE_DEVICE_TABLE(of, pm8xxx_id_table);
 
+static int pm8xxx_add_usb_extcon(struct platform_device *pdev,
+				 struct pm_irq_chip *chip,
+				 unsigned int hwirq)
+{
+	struct irq_fwspec fwspec = {
+		.fwnode = dev_fwnode(&pdev->dev),
+		.param_count = 2,
+		.param = { hwirq, IRQ_TYPE_EDGE_BOTH },
+	};
+	struct platform_device_info pdevinfo = {
+		.parent = &pdev->dev,
+		.fwnode = dev_fwnode(&pdev->dev),
+		.of_node_reused = true,
+		.name = "qcom-pm8xxx-usb-id",
+		.id = PLATFORM_DEVID_NONE,
+	};
+	struct resource resource;
+
+	chip->usb_id_irq = irq_create_fwspec_mapping(&fwspec);
+	if (!chip->usb_id_irq)
+		return -ENXIO;
+
+	resource = DEFINE_RES_IRQ_NAMED(chip->usb_id_irq, "usb_id");
+	pdevinfo.res = &resource;
+	pdevinfo.num_res = 1;
+
+	chip->usb_extcon = platform_device_register_full(&pdevinfo);
+	if (IS_ERR(chip->usb_extcon)) {
+		int ret = PTR_ERR(chip->usb_extcon);
+
+		chip->usb_extcon = NULL;
+		irq_dispose_mapping(chip->usb_id_irq);
+		chip->usb_id_irq = 0;
+
+		return ret;
+	}
+
+	return 0;
+}
+
+static void pm8xxx_remove_usb_extcon(struct pm_irq_chip *chip)
+{
+	if (chip->usb_extcon)
+		platform_device_unregister(chip->usb_extcon);
+
+	if (chip->usb_id_irq)
+		irq_dispose_mapping(chip->usb_id_irq);
+}
+
 static int pm8xxx_probe(struct platform_device *pdev)
 {
 	const struct pm_irq_data *data;
@@ -570,9 +630,22 @@ static int pm8xxx_probe(struct platform_device *pdev)
 
 	irq_set_irq_wake(irq, 1);
 
+	if (data->usb_id_irq) {
+		rc = pm8xxx_add_usb_extcon(pdev, chip, data->usb_id_irq);
+		if (rc)
+			goto err_domain;
+	}
+
 	rc = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
 	if (rc)
-		irq_domain_remove(chip->irqdomain);
+		goto err_extcon;
+
+	return 0;
+
+err_extcon:
+	pm8xxx_remove_usb_extcon(chip);
+err_domain:
+	irq_domain_remove(chip->irqdomain);
 
 	return rc;
 }
@@ -582,6 +655,7 @@ static void pm8xxx_remove(struct platform_device *pdev)
 	struct pm_irq_chip *chip = platform_get_drvdata(pdev);
 
 	of_platform_depopulate(&pdev->dev);
+	pm8xxx_remove_usb_extcon(chip);
 	irq_domain_remove(chip->irqdomain);
 }
 

-- 
2.43.0

[PATCH v5 5/6] extcon: qcom-spmi-misc: match PM8xxx USB ID platform device

[Alexandre MINETTE via B4 Relay]

From: Alexandre MINETTE <contact@alex-min.fr>

The PM8xxx MFD registers the PM8921 USB ID detector as a platform device
named "qcom-pm8xxx-usb-id". Its reused firmware node remains compatible
with "qcom,pm8921", so it does not match the extcon driver's OF table.

Add a platform device ID so the existing extcon driver binds to this
device and consumes its named USB ID interrupt.

Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
---
 drivers/extcon/extcon-qcom-spmi-misc.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/extcon/extcon-qcom-spmi-misc.c b/drivers/extcon/extcon-qcom-spmi-misc.c
index afaba5685c3d..e16c109b553e 100644
--- a/drivers/extcon/extcon-qcom-spmi-misc.c
+++ b/drivers/extcon/extcon-qcom-spmi-misc.c
@@ -204,8 +204,15 @@ static const struct of_device_id qcom_usb_extcon_dt_match[] = {
 };
 MODULE_DEVICE_TABLE(of, qcom_usb_extcon_dt_match);
 
+static const struct platform_device_id qcom_usb_extcon_id[] = {
+	{ "qcom-pm8xxx-usb-id" },
+	{ }
+};
+MODULE_DEVICE_TABLE(platform, qcom_usb_extcon_id);
+
 static struct platform_driver qcom_usb_extcon_driver = {
 	.probe		= qcom_usb_extcon_probe,
+	.id_table	= qcom_usb_extcon_id,
 	.driver		= {
 		.name	= "extcon-pm8941-misc",
 		.pm	= &qcom_usb_extcon_pm_ops,

-- 
2.43.0

[PATCH v5 6/6] ARM: dts: qcom: Add Samsung Galaxy S4

[Alexandre MINETTE via B4 Relay]

From: Alexandre MINETTE <contact@alex-min.fr>

Add a device tree for the Samsung Galaxy S4, codenamed jflte.

This has been tested on a Samsung Galaxy S4 GT-I9505. The initial support
covers UART, USB peripheral mode with USB networking, the front LED and
the physical buttons.

Acked-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
---
 arch/arm/boot/dts/qcom/Makefile                    |   1 +
 .../boot/dts/qcom/qcom-apq8064-samsung-jflte.dts   | 481 +++++++++++++++++++++
 2 files changed, 482 insertions(+)

diff --git a/arch/arm/boot/dts/qcom/Makefile b/arch/arm/boot/dts/qcom/Makefile
index 32a44b02d2fa..6f89ba426f98 100644
--- a/arch/arm/boot/dts/qcom/Makefile
+++ b/arch/arm/boot/dts/qcom/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
 	qcom-apq8064-sony-xperia-lagan-yuga.dtb \
 	qcom-apq8064-asus-nexus7-flo.dtb \
 	qcom-apq8064-lg-nexus4-mako.dtb \
+	qcom-apq8064-samsung-jflte.dtb \
 	qcom-apq8074-dragonboard.dtb \
 	qcom-ipq4018-ap120c-ac.dtb \
 	qcom-ipq4018-ap120c-ac-bit.dtb \
diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-samsung-jflte.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-samsung-jflte.dts
new file mode 100644
index 000000000000..75ae19af96e5
--- /dev/null
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-samsung-jflte.dts
@@ -0,0 +1,481 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/mfd/qcom-rpm.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+
+#include "qcom-apq8064-v2.0.dtsi"
+#include "pm8821.dtsi"
+#include "pm8921.dtsi"
+
+/ {
+	model = "Samsung Galaxy S4 (jflte)";
+	compatible = "samsung,jflte", "qcom,apq8064";
+	chassis-type = "handset";
+
+	aliases {
+		serial0 = &gsbi7_serial;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		ramoops@88d00000 {
+			compatible = "ramoops";
+			reg = <0x88d00000 0x100000>;
+			record-size = <0x20000>;
+			console-size = <0x20000>;
+			ftrace-size = <0x20000>;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		pinctrl-0 = <&gpio_keys_default>;
+		pinctrl-names = "default";
+
+		key-home {
+			label = "Home";
+			gpios = <&pm8921_gpio 30 GPIO_ACTIVE_LOW>;
+			debounce-interval = <5>;
+			linux,code = <KEY_HOME>;
+			wakeup-source;
+		};
+
+		key-volume-up {
+			label = "Volume Up";
+			gpios = <&pm8921_gpio 35 GPIO_ACTIVE_LOW>;
+			debounce-interval = <5>;
+			linux,code = <KEY_VOLUMEUP>;
+			wakeup-source;
+		};
+
+		key-volume-down {
+			label = "Volume Down";
+			gpios = <&pm8921_gpio 37 GPIO_ACTIVE_LOW>;
+			debounce-interval = <5>;
+			linux,code = <KEY_VOLUMEDOWN>;
+			wakeup-source;
+		};
+	};
+
+	i2c-led {
+		compatible = "i2c-gpio";
+		sda-gpios = <&tlmm_pinmux 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+		scl-gpios = <&tlmm_pinmux 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+		i2c-gpio,delay-us = <2>;
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		led-controller@30 {
+			compatible = "panasonic,an30259a";
+			reg = <0x30>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			led@1 {
+				reg = <1>;
+				function = LED_FUNCTION_STATUS;
+				color = <LED_COLOR_ID_RED>;
+			};
+
+			led@2 {
+				reg = <2>;
+				function = LED_FUNCTION_STATUS;
+				color = <LED_COLOR_ID_GREEN>;
+			};
+
+			led@3 {
+				reg = <3>;
+				function = LED_FUNCTION_STATUS;
+				color = <LED_COLOR_ID_BLUE>;
+			};
+		};
+	};
+
+	i2c-muic {
+		compatible = "i2c-gpio";
+		sda-gpios = <&tlmm_pinmux 22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+		scl-gpios = <&tlmm_pinmux 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+		i2c-gpio,delay-us = <2>;
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		max77693: pmic@66 {
+			compatible = "maxim,max77693";
+			reg = <0x66>;
+			interrupt-parent = <&tlmm_pinmux>;
+			interrupts = <55 IRQ_TYPE_EDGE_FALLING>;
+			pinctrl-0 = <&muic_int_default_state>;
+			pinctrl-names = "default";
+
+			muic: muic {
+				compatible = "maxim,max77693-muic";
+				safeout1-supply = <&esafeout1_reg>;
+				safeout2-supply = <&esafeout2_reg>;
+			};
+
+			regulators {
+				esafeout1_reg: ESAFEOUT1 {
+					regulator-name = "ESAFEOUT1";
+				};
+
+				esafeout2_reg: ESAFEOUT2 {
+					regulator-name = "ESAFEOUT2";
+				};
+			};
+		};
+	};
+};
+
+&gsbi7 {
+	qcom,mode = <GSBI_PROT_I2C_UART>;
+
+	status = "okay";
+};
+
+&gsbi7_serial {
+	pinctrl-0 = <&gsbi7_uart_pin_a>;
+	pinctrl-names = "default";
+
+	status = "okay";
+};
+
+&pm8821 {
+	interrupts-extended = <&tlmm_pinmux 76 IRQ_TYPE_LEVEL_LOW>;
+};
+
+&pm8921 {
+	interrupts-extended = <&tlmm_pinmux 74 IRQ_TYPE_LEVEL_LOW>;
+};
+
+&riva {
+	pinctrl-0 = <&riva_wlan_pin_a>, <&riva_bt_pin_a>, <&riva_fm_pin_a>;
+	pinctrl-names = "default";
+
+	vddcx-supply = <&pm8921_s3>;
+	vddmx-supply = <&pm8921_l24>;
+	vddpx-supply = <&pm8921_s4>;
+
+	status = "okay";
+
+	iris {
+		vddxo-supply = <&pm8921_l4>;
+		vddrfa-supply = <&pm8921_s2>;
+		vddpa-supply = <&pm8921_l10>;
+		vdddig-supply = <&pm8921_lvs2>;
+	};
+};
+
+&rpm {
+	regulators {
+		compatible = "qcom,rpm-pm8921-regulators";
+
+		vdd_l1_l2_l12_l18-supply = <&pm8921_s4>;
+		vdd_l24-supply = <&pm8921_s1>;
+		vdd_l25-supply = <&pm8921_s1>;
+		vdd_l26-supply = <&pm8921_s7>;
+		vdd_l27-supply = <&pm8921_s7>;
+		vdd_l28-supply = <&pm8921_s7>;
+		vin_lvs1_3_6-supply = <&pm8921_s4>;
+		vin_lvs2-supply = <&pm8921_s1>;
+		vin_lvs4_5_7-supply = <&pm8921_s4>;
+
+		pm8921_l1: l1 {
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1100000>;
+			regulator-always-on;
+			bias-pull-down;
+		};
+
+		/* mipi_dsi.1-dsi1_pll_vdda */
+		pm8921_l2: l2 {
+			regulator-min-microvolt = <1200000>;
+			regulator-max-microvolt = <1200000>;
+			bias-pull-down;
+		};
+
+		/* msm_otg-HSUSB_3p3 */
+		pm8921_l3: l3 {
+			regulator-min-microvolt = <3075000>;
+			regulator-max-microvolt = <3500000>;
+			bias-pull-down;
+		};
+
+		/* msm_otg-HSUSB_1p8 */
+		pm8921_l4: l4 {
+			regulator-always-on;
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+		};
+
+		/* msm_sdcc.1-sdc_vdd */
+		pm8921_l5: l5 {
+			regulator-min-microvolt = <2950000>;
+			regulator-max-microvolt = <2950000>;
+			bias-pull-down;
+		};
+
+		/* earjack_debug */
+		pm8921_l6: l6 {
+			regulator-min-microvolt = <3000000>;
+			regulator-max-microvolt = <3000000>;
+			bias-pull-down;
+		};
+
+		/* mipi_dsi.1-dsi_vci */
+		pm8921_l8: l8 {
+			regulator-min-microvolt = <2800000>;
+			regulator-max-microvolt = <3000000>;
+			bias-pull-down;
+		};
+
+		/* wcnss_wlan.0-iris_vddpa */
+		pm8921_l10: l10 {
+			regulator-min-microvolt = <2900000>;
+			regulator-max-microvolt = <2900000>;
+			bias-pull-down;
+		};
+
+		/* mipi_dsi.1-dsi1_avdd */
+		pm8921_l11: l11 {
+			regulator-min-microvolt = <2850000>;
+			regulator-max-microvolt = <2850000>;
+			bias-pull-down;
+		};
+
+		/* touch_vdd */
+		pm8921_l15: l15 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <2950000>;
+			bias-pull-down;
+		};
+
+		/* slimport_dvdd */
+		pm8921_l18: l18 {
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1100000>;
+			bias-pull-down;
+		};
+
+		/* touch_io */
+		pm8921_l22: l22 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			bias-pull-down;
+		};
+
+		/*
+		 * mipi_dsi.1-dsi_vddio
+		 * pil_qdsp6v4.1-pll_vdd
+		 * pil_qdsp6v4.2-pll_vdd
+		 * msm_ehci_host.0-HSUSB_1p8
+		 * msm_ehci_host.1-HSUSB_1p8
+		 */
+		pm8921_l23: l23 {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			bias-pull-down;
+		};
+
+		/*
+		 * tabla2x-slim-CDC_VDDA_A_1P2V
+		 * tabla2x-slim-VDDD_CDC_D
+		 */
+		pm8921_l24: l24 {
+			regulator-min-microvolt = <750000>;
+			regulator-max-microvolt = <1150000>;
+			bias-pull-down;
+		};
+
+		pm8921_l25: l25 {
+			regulator-min-microvolt = <1250000>;
+			regulator-max-microvolt = <1250000>;
+			regulator-always-on;
+			bias-pull-down;
+		};
+
+		pm8921_l26: l26 {
+			regulator-min-microvolt = <375000>;
+			regulator-max-microvolt = <1050000>;
+			regulator-always-on;
+			bias-pull-down;
+		};
+
+		pm8921_l27: l27 {
+			regulator-min-microvolt = <1100000>;
+			regulator-max-microvolt = <1100000>;
+		};
+
+		pm8921_l28: l28 {
+			regulator-min-microvolt = <1050000>;
+			regulator-max-microvolt = <1050000>;
+			bias-pull-down;
+		};
+
+		/* wcnss_wlan.0-iris_vddio */
+		pm8921_lvs1: lvs1 {
+			bias-pull-down;
+		};
+
+		/* wcnss_wlan.0-iris_vdddig */
+		pm8921_lvs2: lvs2 {
+			bias-pull-down;
+		};
+
+		pm8921_lvs3: lvs3 {
+			bias-pull-down;
+		};
+
+		pm8921_lvs4: lvs4 {
+			bias-pull-down;
+		};
+
+		pm8921_lvs5: lvs5 {
+			bias-pull-down;
+		};
+
+		/* mipi_dsi.1-dsi_iovcc */
+		pm8921_lvs6: lvs6 {
+			bias-pull-down;
+		};
+
+		/*
+		 * pil_riva-pll_vdd
+		 * lvds.0-lvds_vdda
+		 * mipi_dsi.1-dsi1_vddio
+		 * hdmi_msm.0-hdmi_vdda
+		 */
+		pm8921_lvs7: lvs7 {
+			bias-pull-down;
+		};
+
+		pm8921_ncp: ncp {
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			qcom,switch-mode-frequency = <1600000>;
+		};
+
+		/* Buck SMPS */
+		pm8921_s1: s1 {
+			regulator-always-on;
+			regulator-min-microvolt = <1225000>;
+			regulator-max-microvolt = <1225000>;
+			qcom,switch-mode-frequency = <3200000>;
+			bias-pull-down;
+		};
+
+		pm8921_s2: s2 {
+			regulator-min-microvolt = <1300000>;
+			regulator-max-microvolt = <1300000>;
+			qcom,switch-mode-frequency = <1600000>;
+			bias-pull-down;
+		};
+
+		/* msm otg HSUSB_VDDCX */
+		pm8921_s3: s3 {
+			regulator-min-microvolt = <500000>;
+			regulator-max-microvolt = <1150000>;
+			qcom,switch-mode-frequency = <4800000>;
+			bias-pull-down;
+		};
+
+		/*
+		 * msm_sdcc.1-sdc-vdd_io
+		 * tabla2x-slim-CDC_VDDA_RX
+		 * tabla2x-slim-CDC_VDDA_TX
+		 * tabla2x-slim-CDC_VDD_CP
+		 * tabla2x-slim-VDDIO_CDC
+		 */
+		pm8921_s4: s4 {
+			regulator-always-on;
+			regulator-min-microvolt = <1800000>;
+			regulator-max-microvolt = <1800000>;
+			qcom,switch-mode-frequency = <1600000>;
+			bias-pull-down;
+			qcom,force-mode = <QCOM_RPM_FORCE_MODE_AUTO>;
+		};
+
+		/*
+		 * supply vdd_l26, vdd_l27, vdd_l28
+		 */
+		pm8921_s7: s7 {
+			regulator-min-microvolt = <1300000>;
+			regulator-max-microvolt = <1300000>;
+			qcom,switch-mode-frequency = <3200000>;
+		};
+
+		pm8921_s8: s8 {
+			regulator-min-microvolt = <2200000>;
+			regulator-max-microvolt = <2200000>;
+			qcom,switch-mode-frequency = <1600000>;
+		};
+	};
+};
+
+/* eMMC */
+&sdcc1 {
+	vmmc-supply = <&pm8921_l5>;
+	vqmmc-supply = <&pm8921_s4>;
+
+	status = "okay";
+};
+
+&pm8921_gpio {
+	gpio_keys_default: gpio-keys-default-state {
+		pins = "gpio30", "gpio35", "gpio37";
+		function = PMIC_GPIO_FUNC_NORMAL;
+		input-enable;
+		bias-pull-up;
+		power-source = <PM8921_GPIO_S4>;
+	};
+};
+
+&tlmm_pinmux {
+	gsbi7_uart_pin_a: gsbi7-uart-pin-active-state {
+		rx-pins {
+			pins = "gpio83";
+			function = "gsbi7";
+			drive-strength = <2>;
+			bias-pull-up;
+		};
+
+		tx-pins {
+			pins = "gpio82";
+			function = "gsbi7";
+			drive-strength = <4>;
+			bias-disable;
+		};
+	};
+
+	muic_int_default_state: muic-int-default-state {
+		pins = "gpio55";
+		function = "gpio";
+		drive-strength = <2>;
+		input-enable;
+		bias-disable;
+	};
+};
+
+&usb_hs1_phy {
+	v3p3-supply = <&pm8921_l3>;
+	v1p8-supply = <&pm8921_l4>;
+	extcon = <&muic>;
+};
+
+&usb1 {
+	dr_mode = "otg";
+	extcon = <&muic>, <&pm8921>;
+
+	status = "okay";
+};

-- 
2.43.0

Re: [PATCH v5 3/6] ARM: dts: qcom: apq8064: Fix USB controller clocks

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Mapping the transceiver clock to 'fs' causes it to be unconditionally disabled after probe, starving the USB controller.
- [Medium] The patch violates the generic ChipIdea USB2 device tree binding by defining three clocks for the 'qcom,ci-hdrc' compatible.
--

--- Patch [3]: [PATCH v5 3/6] ARM: dts: qcom: apq8064: Fix USB controller clocks ---
commit 3215e94f01093ac3a7be7c7e9537c0ae784e33fa
Author: Alexandre MINETTE <contact@alex-min.fr>
ARM: dts: qcom: apq8064: Fix USB controller clocks

This patch modifies the clock assignments for the APQ8064 HS USB controllers.
It maps the RPM Daytona fabric clock to "core", the AHB clock to "iface", and
the transceiver clock to "fs" to ensure the fabric clock is properly enabled
during controller access.

Link: https://lore.kernel.org/all/20260516-qcom-ci-hdrc-clock-fix-v2-1-aaec8d33d0aa@smankusors.com/

> diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
> --- a/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom/qcom-apq8064.dtsi
> @@ -813,8 +813,10 @@ usb1: usb@12500000 {
>  			reg = <0x12500000 0x200>,
>  			      <0x12500200 0x200>;
>  			interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
> -			clocks = <&gcc USB_HS1_XCVR_CLK>, <&gcc USB_HS1_H_CLK>;
> -			clock-names = "core", "iface";
> +			clocks = <&gcc USB_HS1_H_CLK>,
> +				 <&rpmcc RPM_DAYTONA_FABRIC_CLK>,
> +				 <&gcc USB_HS1_XCVR_CLK>;
> +			clock-names = "iface", "core", "fs";

[Severity: Medium]
Does this change violate the generic ChipIdea USB2 device tree binding?

Looking at the schema in Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml,
it restricts the qcom,ci-hdrc compatible to a maximum of 2 clocks:

Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml:
  clocks:
    minItems: 1
    maxItems: 2

Adding a third clock ("fs") without first updating the binding schema might
cause an ABI validation failure during dtbs_check.

[Severity: High]
Will mapping the transceiver clock to "fs" cause it to be disabled during
probe, starving the USB controller?

In drivers/usb/chipidea/ci_hdrc_msm.c:ci_hdrc_msm_probe(), the driver appears
to treat the "fs" clock as a temporary reset clock, turning it off immediately
after the reset sequence:

drivers/usb/chipidea/ci_hdrc_msm.c:ci_hdrc_msm_probe() {
    ...
    reset_control_deassert(reset);

    clk_disable_unprepare(ci->fs_clk);

    ret = clk_prepare_enable(ci->core_clk);
    ...
}

Since there appear to be no PM runtime callbacks to re-enable it, mapping the
USB_HS1_XCVR_CLK transceiver clock to "fs" seems to mean the 60MHz ULPI clock
will remain disabled unconditionally after probe.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-mainline-send-v1-sending-v5-0-149dd4372ac8@alex-min.fr?part=3

Re: [PATCH v5 6/6] ARM: dts: qcom: Add Samsung Galaxy S4

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `muic` node contains invalid properties `safeout1-supply` and `safeout2-supply` which violate the device tree schema.
--

--- Patch [6]: [PATCH v5 6/6] ARM: dts: qcom: Add Samsung Galaxy S4 ---
commit 71d3822fee0022c24c538ba38400b342e55f2d78
Author: Alexandre MINETTE <contact@alex-min.fr>

ARM: dts: qcom: Add Samsung Galaxy S4

This commit adds initial device tree support for the Samsung Galaxy S4 (jflte).
It covers UART, USB peripheral mode, networking, front LED, and physical buttons.

> diff --git a/arch/arm/boot/dts/qcom/qcom-apq8064-samsung-jflte.dts b/arch/arm/boot/dts/qcom/qcom-apq8064-samsung-jflte.dts
> new file mode 100644
> index 0000000000000..75ae19af96e54
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom/qcom-apq8064-samsung-jflte.dts

[ ... ]

> @@ -115,14 +115,14 @@
> +			interrupts = <55 IRQ_TYPE_EDGE_FALLING>;
> +			pinctrl-0 = <&muic_int_default_state>;
> +			pinctrl-names = "default";
> +
> +			muic: muic {
> +				compatible = "maxim,max77693-muic";
> +				safeout1-supply = <&esafeout1_reg>;
> +				safeout2-supply = <&esafeout2_reg>;

[Severity: Low]
Are safeout1-supply and safeout2-supply supported by the maxim,max77693-muic
device tree binding?

The schema validation fails here because the binding does not define these
properties. This causes a validation failure during make dtbs_check.

> +			};
> +
> +			regulators {
> +				esafeout1_reg: ESAFEOUT1 {

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-mainline-send-v1-sending-v5-0-149dd4372ac8@alex-min.fr?part=6

Re: [PATCH v5 4/6] mfd: qcom-pm8xxx: register PM8921 USB ID extcon

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [High] The newly registered platform device 'qcom-pm8xxx-usb-id' violates MFD naming guidelines and will never bind to the intended extcon driver.
- [High] The `usb_extcon` child platform device is unregistered twice, leading to a use-after-free, and inadvertently leaks the parent PMIC device.

Pre-existing issues:
- [High] The IRQ domain is explicitly destroyed before the devres-managed physical parent interrupt is freed, leading to a Use-After-Free.
- [High] Missing `irq_domain_remove()` on the `devm_request_irq()` error path causes the IRQ domain to leak and hold a dangling `host_data` pointer.
--

--- Patch [4]: [PATCH v5 4/6] mfd: qcom-pm8xxx: register PM8921 USB ID extcon ---
commit 61c97946b38af2a5d88c53960d6a580a045442ed
Author: Alexandre MINETTE <contact@alex-min.fr>
Subject: mfd: qcom-pm8xxx: register PM8921 USB ID extcon

This commit registers a child platform device for the USB extcon driver on
PM8921 after setting up the PMIC IRQ domain. It passes the USB ID interrupt
as a named resource and reuses the PMIC firmware node.

> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> index 0cf374c015ce7..884fc99a1488f 100644
> --- a/drivers/mfd/qcom-pm8xxx.c
> +++ b/drivers/mfd/qcom-pm8xxx.c
[ ... ]
> @@ -501,11 +512,60 @@ static const struct of_device_id pm8xxx_id_table[] = {
>  	{ .compatible = "qcom,pm8821", .data = &pm8821_data},
> -	{ .compatible = "qcom,pm8921", .data = &pm8xxx_data},
> +	{ .compatible = "qcom,pm8921", .data = &pm8921_data},
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, pm8xxx_id_table);
>  
> +static int pm8xxx_add_usb_extcon(struct platform_device *pdev,
> +				 struct pm_irq_chip *chip,
> +				 unsigned int hwirq)
> +{
[ ... ]
> +	struct platform_device_info pdevinfo = {
> +		.parent = &pdev->dev,
> +		.fwnode = dev_fwnode(&pdev->dev),
> +		.of_node_reused = true,

[Severity: High]
Can setting of_node_reused to true lead to a double-free during removal?

When usb_extcon is created with of_node_reused set to true, it shares the
parent PMIC's of_node. The parent's of_node has the OF_POPULATED flag set
by of_platform_populate().

Later, when pm8xxx_remove() calls of_platform_depopulate(), it iterates over
the PMIC's children. Because usb_extcon shares the parent's of_node,
of_platform_device_destroy() will unregister usb_extcon and incorrectly
clear the OF_POPULATED flag from the parent's of_node.

This prevents the bus core from properly depopulating the PMIC later, causing
the parent PMIC device to leak.

Furthermore, after of_platform_depopulate() returns, pm8xxx_remove()
explicitly calls pm8xxx_remove_usb_extcon(), which invokes
platform_device_unregister() a second time on the already-freed usb_extcon
pointer.

Does this sequence result in a use-after-free crash?

> +		.name = "qcom-pm8xxx-usb-id",

[Severity: High]
Will this platform device bind to the target extcon driver?

The target driver for PMIC USB extcon is extcon-qcom-spmi-misc.c, which
matches against the driver name extcon-pm8941-misc or the OF compatible
qcom,pm8941-misc.

Because the device inherits the parent PMIC's qcom,pm8921 compatible and
uses the qcom-pm8xxx-usb-id device name, the driver core will not bind the
extcon driver to this new platform device.

Does this also violate the MFD subsystem naming guidelines which advise
against including the driver's own filename or the string mfd in names?

> +		.id = PLATFORM_DEVID_NONE,
> +	};
[ ... ]
> @@ -570,9 +630,22 @@ static int pm8xxx_probe(struct platform_device *pdev)
[ ... ]
>  	chip->irqdomain = irq_domain_create_linear(dev_fwnode(&pdev->dev), data->num_irqs,
>  						   &pm8xxx_irq_domain_ops, chip);
>  	if (!chip->irqdomain)
>  		return -ENODEV;
>  
>  	rc = devm_request_irq(&pdev->dev, irq, data->irq_handler, 0, dev_name(&pdev->dev), chip);
>  	if (rc)
>  		return rc;

[Severity: High]
This is a pre-existing issue, but does this error path leak the newly
created IRQ domain?

In pm8xxx_probe(), irq_domain_create_linear() dynamically allocates an IRQ
domain, registers it in the global domain list, and sets domain->host_data
to the devres-managed chip structure.

If devm_request_irq() fails, the function returns directly without calling
irq_domain_remove().

The IRQ domain remains permanently leaked in the global list, while devres
automatically frees the chip structure.

If another device requests an IRQ mapping on this fwnode, will the system
use the orphaned domain, dereference the freed chip pointer via host_data,
and trigger a use-after-free?

>  
>  	irq_set_irq_wake(irq, 1);
>  
> +	if (data->usb_id_irq) {
> +		rc = pm8xxx_add_usb_extcon(pdev, chip, data->usb_id_irq);
> +		if (rc)
> +			goto err_domain;
> +	}
> +
>  	rc = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
>  	if (rc)
> -		irq_domain_remove(chip->irqdomain);
> +		goto err_extcon;
> +
> +	return 0;
> +
> +err_extcon:
> +	pm8xxx_remove_usb_extcon(chip);
> +err_domain:
> +	irq_domain_remove(chip->irqdomain);

[Severity: High]
This is a pre-existing issue, but is it safe to explicitly destroy the IRQ
domain before the physical parent interrupt is freed?

The physical parent interrupt is managed by devm_request_irq(), meaning it
is only disabled and freed later during the devres cleanup phase, after the
probe function has already returned.

If the physical interrupt fires in the window between this
irq_domain_remove() call and the devres cleanup, pm8xxx_irq_handler() will
execute and attempt to call generic_handle_domain_irq() on the freed domain
pointer.

Could this trigger a use-after-free crash?

>  
>  	return rc;
>  }
> @@ -582,6 +655,7 @@ static void pm8xxx_remove(struct platform_device *pdev)
>  	struct pm_irq_chip *chip = platform_get_drvdata(pdev);
>  
>  	of_platform_depopulate(&pdev->dev);
> +	pm8xxx_remove_usb_extcon(chip);
>  	irq_domain_remove(chip->irqdomain);

[Severity: High]
This is a pre-existing issue, but does destroying the IRQ domain here
create a similar use-after-free risk during device removal?

Just like in the probe error path, the physical parent interrupt is managed
by devm_request_irq() and remains active while irq_domain_remove() is
called.

If the interrupt fires before devres cleans up the IRQ, could it result in a
use-after-free when handling the interrupt?

>  }
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-mainline-send-v1-sending-v5-0-149dd4372ac8@alex-min.fr?part=4

Re: [PATCH v5 5/6] extcon: qcom-spmi-misc: match PM8xxx USB ID platform device

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Unbalanced IRQ wake state and lost error codes in suspend/resume due to overwritten return value.
- [High] Failure to read ID IRQ line state aborts VBUS detection entirely.
--

--- Patch [5]: [PATCH v5 5/6] extcon: qcom-spmi-misc: match PM8xxx USB ID platform device ---
commit b4c56e1cb1867cf0c94f9ba05c18446ffacc8bd5
Author: Alexandre MINETTE <contact@alex-min.fr>

extcon: qcom-spmi-misc: match PM8xxx USB ID platform device

The PM8xxx MFD registers the PM8921 USB ID detector as a platform device
named "qcom-pm8xxx-usb-id". Its reused firmware node remains compatible
with "qcom,pm8921", so it does not match the extcon driver's OF table.

Add a platform device ID so the existing extcon driver binds to this
device and consumes its named USB ID interrupt.

> diff --git a/drivers/extcon/extcon-qcom-spmi-misc.c b/drivers/extcon/extcon-qcom-spmi-misc.c
> index afaba5685c3dc..e16c109b553e2 100644
> --- a/drivers/extcon/extcon-qcom-spmi-misc.c
> +++ b/drivers/extcon/extcon-qcom-spmi-misc.c
> @@ -204,8 +204,15 @@ static const struct of_device_id qcom_usb_extcon_dt_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, qcom_usb_extcon_dt_match);
>  
> +static const struct platform_device_id qcom_usb_extcon_id[] = {
> +	{ "qcom-pm8xxx-usb-id" },
> +	{ }
> +};
> +MODULE_DEVICE_TABLE(platform, qcom_usb_extcon_id);
> +
>  static struct platform_driver qcom_usb_extcon_driver = {
>  	.probe		= qcom_usb_extcon_probe,
> +	.id_table	= qcom_usb_extcon_id,
>  	.driver		= {
>  		.name	= "extcon-pm8941-misc",
>  		.pm	= &qcom_usb_extcon_pm_ops,

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in the 
suspend/resume path that might cause unbalanced IRQ wake disables or leaked 
wake_depth refcounts:

drivers/extcon/extcon-qcom-spmi-misc.c:qcom_usb_extcon_suspend() {
    ...
	if (device_may_wakeup(dev)) {
		if (info->id_irq > 0)
			ret = enable_irq_wake(info->id_irq);
		if (info->vbus_irq > 0)
			ret = enable_irq_wake(info->vbus_irq);
	}

	return ret;
}

If enable_irq_wake(info->id_irq) fails, the error code is stored in ret.
However, if enable_irq_wake(info->vbus_irq) succeeds, it returns 0 and
overwrites the previous error code in ret.

If this happens, the system will suspend and eventually call
qcom_usb_extcon_resume(). In the resume path, disable_irq_wake(info->id_irq)
will be called on an IRQ that was never successfully enabled for wake, which
triggers a kernel WARN for an unbalanced IRQ wake disable. 

Conversely, if id_irq succeeds but vbus_irq fails, ret returns an error to
the PM core. The suspend is aborted, meaning qcom_usb_extcon_resume() is
skipped for this device. This prevents disable_irq_wake(info->id_irq) from
being called, permanently leaking the IRQ's wake_depth refcount.

Should the return codes for these two wake IRQs be handled independently?


[Severity: High]
This isn't a bug introduced by this patch, but I also noticed a potential
logic issue in how cable detection is handled:

drivers/extcon/extcon-qcom-spmi-misc.c:qcom_usb_extcon_detect_cable() {
    ...
	if (info->id_irq > 0) {
		/* check ID and update cable state */
		ret = irq_get_irqchip_state(info->id_irq,
				IRQCHIP_STATE_LINE_LEVEL, &state);
		if (ret)
			return;
    ...
}

If reading the ID IRQ line state fails (for instance, due to an SPMI bus
transaction error), the function returns immediately. 

Since the VBUS state detection happens after this in the same function,
returning early completely aborts the independent VBUS detection logic. This
means USB insertions and removals could be completely missed by the extcon
driver just because of a read failure on the ID pin line.

Would it be better to let the VBUS detection proceed even if the ID line
state read fails?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260804-mainline-send-v1-sending-v5-0-149dd4372ac8@alex-min.fr?part=5

Re: [PATCH v5 3/6] ARM: dts: qcom: apq8064: Fix USB controller clocks

[Antony Kurniawan Soemardi]

On 8/4/2026 1:34 PM, Alexandre MINETTE via B4 Relay wrote:
> From: Alexandre MINETTE <contact@alex-min.fr>
> 
> The APQ8064 HS USB controller nodes describe the transceiver clock as
> "core", but the ChipIdea MSM glue expects "core" to be the controller
> fabric clock and "fs" to be the transceiver clock.
> 
> This mismatch can leave the fabric clock disabled while the controller is
> accessed. Some boards may tolerate that if the clock is already enabled
> elsewhere, but it is not a correct description of the hardware.
> 
> Describe the RPM Daytona fabric clock as "core", the AHB clock as
> "iface", and the transceiver clock as "fs" for all APQ8064 HS USB
> controllers. Without this, USB does not probe reliably on Samsung Galaxy
> S4 because the fabric clock remains disabled.

oh sorry, I forgot to mention that, depending on the feedback on
msm8960's patch [1], we might end up swapping the Daytona fabric and
HS1_H clocks. So, Daytona fabric would be the "iface" and HS1_H would be
the "core".

[1] 
https://lore.kernel.org/all/1416ada5-ccdf-400e-b2b8-d2c5c7e335dc@oss.qualcomm.com/

-- 
Thanks,
Antony K. S.