[PATCH v3 0/8] Add Samsung Galaxy S4 support

[PATCH v3 0/8] 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. With this series the device boots
and supports UART, USB peripheral mode with USB networking, the front
notification LED and the physical buttons.

Signed-off-by: Alexandre MINETTE <contact@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

---
Alexandre MINETTE (8):
      dt-bindings: arm: qcom: Add Samsung Galaxy S4
      dt-bindings: extcon: qcom,pm8941-misc: Add PM8921 compatible
      pinctrl: qcom: Register functions before enabling pinctrl
      iommu/msm: Look up masters per IOMMU instance
      extcon: qcom-spmi-misc: Add PM8921 compatible
      ARM: dts: qcom: apq8064: Fix USB controller clocks
      ARM: dts: qcom: pm8921: Add USB ID extcon
      ARM: dts: qcom: Add Samsung Galaxy S4

 Documentation/devicetree/bindings/arm/qcom.yaml    |   1 +
 .../bindings/extcon/qcom,pm8941-misc.yaml          |  17 +-
 arch/arm/boot/dts/qcom/Makefile                    |   1 +
 arch/arm/boot/dts/qcom/pm8921.dtsi                 |   7 +
 .../boot/dts/qcom/qcom-apq8064-samsung-jflte.dts   | 485 +++++++++++++++++++++
 arch/arm/boot/dts/qcom/qcom-apq8064.dtsi           |  18 +-
 drivers/extcon/extcon-qcom-spmi-misc.c             |   1 +
 drivers/iommu/msm_iommu.c                          |  28 +-
 drivers/pinctrl/qcom/pinctrl-msm.c                 |  15 +-
 9 files changed, 546 insertions(+), 27 deletions(-)
---
base-commit: 4bf3800382b91c2898d14452cf4332782b3fe80a
change-id: 20260421-mainline-send-v1-sending-289ec98e6dc1

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

[PATCH v3 1/8] 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 v3 2/8] dt-bindings: extcon: qcom,pm8941-misc: Add PM8921 compatible

[Alexandre MINETTE via B4 Relay]

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

PM8921/PM8821 provide USB ID detection through the PMIC USB block. The
USB_ID_IN interrupt is exposed by the PM8921 interrupt controller and is
used by APQ8064 platforms for OTG role detection.

The device is modeled as a child of the SSBI-connected PM8921 PMIC.
Unlike PM8941, the downstream PM8xxx misc device is not instantiated with
a register resource for this path, and the mainline extcon driver only
needs the named USB ID interrupt. Allow qcom,pm8921-misc without requiring
reg.

Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
---
 .../devicetree/bindings/extcon/qcom,pm8941-misc.yaml    | 17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
index 6b80518cbf62..4e3d0aadb83c 100644
--- a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
+++ b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
@@ -4,7 +4,7 @@
 $id: http://devicetree.org/schemas/extcon/qcom,pm8941-misc.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: Qualcomm Technologies, Inc. PM8941 USB ID Extcon device
+title: Qualcomm Technologies, Inc. PMIC USB ID Extcon device
 
 maintainers:
   - Guru Das Srinagesh <quic_gurus@quicinc.com>
@@ -15,8 +15,9 @@ description: |
 
 properties:
   compatible:
-    items:
-      - const: qcom,pm8941-misc
+    enum:
+      - qcom,pm8921-misc
+      - qcom,pm8941-misc
 
   reg:
     maxItems: 1
@@ -37,10 +38,18 @@ properties:
           - const: usb_vbus
 required:
   - compatible
-  - reg
   - interrupts
   - interrupt-names
 
+allOf:
+  - if:
+      properties:
+        compatible:
+          const: qcom,pm8941-misc
+    then:
+      required:
+        - reg
+
 additionalProperties: false
 
 examples:

-- 
2.43.0

Re: [PATCH v3 2/8] dt-bindings: extcon: qcom,pm8941-misc: Add PM8921 compatible

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The parent PMIC schema (`qcom-pm8xxx.yaml`) is not updated to allow the new `qcom,pm8921-misc` child node, causing validation errors for any DT using it.
- [High] The `if` condition uses `const: qcom,pm8941-misc` instead of `contains: const: qcom,pm8941-misc` for the `compatible` property, inadvertently making `reg` optional for `qcom,pm8941-misc` devices.
- [Medium] The schema allows `qcom,pm8921-misc` devices to have a `reg` property, even though the hardware variant does not use a register resource.
--

commit 8b3e7ba33de64864005f6ce3e91467d662e5662d
Author: Alexandre MINETTE <contact@alex-min.fr>

dt-bindings: extcon: qcom,pm8941-misc: Add PM8921 compatible

This commit adds the qcom,pm8921-misc compatible string to the PMIC USB
ID Extcon binding. It makes the reg property optional since the downstream
PM8xxx misc device does not use a register resource.

>     The device is modeled as a child of the SSBI-connected PM8921 PMIC.
>     Unlike PM8941, the downstream PM8xxx misc device is not instantiated with
>     a register resource for this path, and the mainline extcon driver only
>     needs the named USB ID interrupt. Allow qcom,pm8921-misc without requiring
>     reg.

The parent schema (qcom-pm8xxx.yaml) enforces additionalProperties: false
and strictly defines permitted children via patternProperties.

Without an update to the parent schema, will device trees including the
qcom,pm8921-misc node fail dt_binding_check?

> diff --git a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
> index 6b80518cbf629..4e3d0aadb83cc 100644
> --- a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
> +++ b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.yaml
[ ... ]
> @@ -37,10 +38,18 @@ properties:
>            - const: usb_vbus
>  required:
>    - compatible
> -  - reg
>    - interrupts
>    - interrupt-names
>  
> +allOf:
> +  - if:
> +      properties:
> +        compatible:
> +          const: qcom,pm8941-misc

Devicetree schemas evaluate the compatible property as an array of strings.
Because comparing an array to a scalar string always evaluates to false,
this condition will never match, and the reg property will silently stop
being enforced for qcom,pm8941-misc devices.

Should this condition use "contains: const: qcom,pm8941-misc" instead?

> +    then:
> +      required:
> +        - reg

Even though reg is no longer globally required, the global properties block
still defines it. This means the schema will silently accept a bogus reg
property for qcom,pm8921-misc without an explicit disallowance.

Since the PM8921 variant is not instantiated with a register resource,
should this block include an "else" clause specifying "reg: false"?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-mainline-send-v1-sending-v3-0-3dd7aa125353@alex-min.fr?part=2

[PATCH v3 3/8] 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.

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

Re: [PATCH v3 3/8] pinctrl: qcom: Register functions before enabling pinctrl

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Use-After-Free in system power-off path if probe fails
--

commit 7e913e496347a43b567ce3ce3e00954f1fc74caf
Author: Alexandre MINETTE <contact@alex-min.fr>

pinctrl: qcom: Register functions before enabling pinctrl

This commit changes the Qualcomm pinctrl initialization sequence to register
functions before enabling the controller. It replaces devm_pinctrl_register()
with devm_pinctrl_register_and_init() and an explicit pinctrl_enable() call.

> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 45b3a2763eb85..a2a1e0835735d 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
[ ... ]
> @@ -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");

This isn't a regression strictly introduced by this patch, but it adds a
new failure path that could trigger an existing issue.

Earlier in msm_pinctrl_probe(), msm_pinctrl_setup_pm_reset() is called,
which assigns the devm-allocated pctrl to the global poweroff_pctrl pointer
and sets the global pm_power_off callback.

If pinctrl_enable() fails, the probe function aborts and the devm framework
will automatically free the pctrl memory. However, there is no corresponding
teardown to clear the global pm_power_off callback or poweroff_pctrl pointer.

If the system is later powered off, could the kernel invoke the callback and
dereference the freed poweroff_pctrl pointer?

> +
>  	ret = msm_gpio_init(pctrl);
>  	if (ret)
>  		return ret;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-mainline-send-v1-sending-v3-0-3dd7aa125353@alex-min.fr?part=3

Re: [PATCH v3 3/8] pinctrl: qcom: Register functions before enabling pinctrl

[Linus Walleij]

Hi Alexandre,

thanks for your patch!

On Tue, May 19, 2026 at 9:16 AM Alexandre MINETTE via B4 Relay
<devnull+contact.alex-min.fr@kernel.org> wrote:

> 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.
>
> Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>

I think I've seen this one before, if Björn or someone else from Qualcomm
can review this and test on some other hardware it would be great.

But if there is no reaction I might just merge it so something happens.

Yours,
Linus Walleij

Re: [PATCH v3 3/8] pinctrl: qcom: Register functions before enabling pinctrl

[MINETTE Alexandre]

Thanks a lot Linus!

This patch is required for my Samsung Galaxy S4 GT-I9505 to boot but I also
have confirmation from another contributor that the same pinctrl patch
helped boot the ASUS Nexus 7 (2013), codenamed flo, which is also based
on APQ8064.

-- 
  MINETTE Alexandre
  contact@alex-min.fr

Mar 19 mai 2026, à 10:31, Linus Walleij a écrit :
> Hi Alexandre,
>
> thanks for your patch!
>
> On Tue, May 19, 2026 at 9:16 AM Alexandre MINETTE via B4 Relay
> <devnull+contact.alex-min.fr@kernel.org> wrote:
>
>> 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.
>>
>> Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
>
> I think I've seen this one before, if Björn or someone else from Qualcomm
> can review this and test on some other hardware it would be great.
>
> But if there is no reaction I might just merge it so something happens.
>
> Yours,
> Linus Walleij

Re: [PATCH v3 3/8] pinctrl: qcom: Register functions before enabling pinctrl

[David Heidelberg]

On 19/05/2026 10:48, MINETTE Alexandre wrote:
> Thanks a lot Linus!
> 
> This patch is required for my Samsung Galaxy S4 GT-I9505 to boot but I also
> have confirmation from another contributor that the same pinctrl patch
> helped boot the ASUS Nexus 7 (2013), codenamed flo, which is also based
> on APQ8064.
> 

Hello Alex,

if what you wrote about asus-flo/deb is true, then this patch should have 
`Fixes: ` tag, as I remember it was booting with few limited patches ~5 years 
back then (only one serious was hack for proper clock bringup).

David

-- 
David Heidelberg

[PATCH v3 4/8] iommu/msm: Look up masters per IOMMU instance

[Alexandre MINETTE via B4 Relay]

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

MSM IOMMU stores context descriptors on each IOMMU instance. Looking up
the descriptor through dev_iommu_priv_get() is not sufficient because a
device can reference multiple IOMMU provider nodes.

Look up the master from the target IOMMU ctx_list instead, and use the
same helper when probing and attaching devices. This avoids
dereferencing a NULL master when an IOMMU already has context entries
for another device, and keeps separate context descriptors for separate
IOMMU instances.

On APQ8064 this crashes during IOMMU probe while qcom_iommu_of_xlate()
adds stream IDs for a device referencing multiple IOMMU provider nodes.
The failure comes from insert_iommu_master() dereferencing a NULL master
after dev_iommu_priv_get() returns no context descriptor for the current
IOMMU instance:

  Unable to handle kernel NULL pointer dereference at virtual address 00000088
  PC is at qcom_iommu_of_xlate+0x84/0x174
  Call trace:
   qcom_iommu_of_xlate from of_iommu_configure+0x140/0x234
   of_iommu_configure from of_dma_configure_id+0xec/0x3b0
   of_dma_configure_id from platform_dma_configure+0xb0/0xcc
   platform_dma_configure from __iommu_probe_device+0x270/0x450
   __iommu_probe_device from probe_iommu_group+0x24/0x48
   probe_iommu_group from bus_for_each_dev+0x7c/0xcc
   bus_for_each_dev from iommu_device_register+0xcc/0x220
   iommu_device_register from msm_iommu_probe+0x47c/0x578

This is required to boot APQ8064 boards using multiple IOMMU contexts.

Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
---
 drivers/iommu/msm_iommu.c | 28 ++++++++++++++++------------
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index 0ad5ff431d5b..9c03878d0d2c 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -357,17 +357,25 @@ static int msm_iommu_domain_config(struct msm_priv *priv)
 	return 0;
 }
 
+static struct msm_iommu_ctx_dev *find_iommu_master(struct msm_iommu_dev *iommu,
+						   struct device *dev)
+{
+	struct msm_iommu_ctx_dev *master;
+
+	list_for_each_entry(master, &iommu->ctx_list, list)
+		if (master->of_node == dev->of_node)
+			return master;
+
+	return NULL;
+}
+
 /* Must be called under msm_iommu_lock */
 static struct msm_iommu_dev *find_iommu_for_dev(struct device *dev)
 {
 	struct msm_iommu_dev *iommu, *ret = NULL;
-	struct msm_iommu_ctx_dev *master;
 
 	list_for_each_entry(iommu, &qcom_iommu_devices, dev_node) {
-		master = list_first_entry(&iommu->ctx_list,
-					  struct msm_iommu_ctx_dev,
-					  list);
-		if (master->of_node == dev->of_node) {
+		if (find_iommu_master(iommu, dev)) {
 			ret = iommu;
 			break;
 		}
@@ -405,10 +413,7 @@ static int msm_iommu_attach_dev(struct iommu_domain *domain, struct device *dev,
 
 	spin_lock_irqsave(&msm_iommu_lock, flags);
 	list_for_each_entry(iommu, &qcom_iommu_devices, dev_node) {
-		master = list_first_entry(&iommu->ctx_list,
-					  struct msm_iommu_ctx_dev,
-					  list);
-		if (master->of_node == dev->of_node) {
+		if (find_iommu_master(iommu, dev)) {
 			ret = __enable_clocks(iommu);
 			if (ret)
 				goto fail;
@@ -601,10 +606,10 @@ static int insert_iommu_master(struct device *dev,
 				struct msm_iommu_dev **iommu,
 				const struct of_phandle_args *spec)
 {
-	struct msm_iommu_ctx_dev *master = dev_iommu_priv_get(dev);
+	struct msm_iommu_ctx_dev *master = find_iommu_master(*iommu, dev);
 	int sid;
 
-	if (list_empty(&(*iommu)->ctx_list)) {
+	if (!master) {
 		master = kzalloc_obj(*master, GFP_ATOMIC);
 		if (!master) {
 			dev_err(dev, "Failed to allocate iommu_master\n");
@@ -612,7 +617,6 @@ static int insert_iommu_master(struct device *dev,
 		}
 		master->of_node = dev->of_node;
 		list_add(&master->list, &(*iommu)->ctx_list);
-		dev_iommu_priv_set(dev, master);
 	}
 
 	for (sid = 0; sid < master->num_mids; sid++)

-- 
2.43.0

Re: [PATCH v3 4/8] iommu/msm: Look up masters per IOMMU instance

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [Critical] msm_iommu_attach_dev and detach unconditionally loop over all shared masters, breaking IOMMU isolation, causing attach failures, and corrupting domain lists.
- [High] msm_iommu_iova_to_phys() performs address translation using the wrong hardware context bank for shared IOMMUs.
- [High] Error path in msm_iommu_attach_dev leaks IOMMU clocks.
- [High] Buffer overflow in insert_iommu_master when writing stream IDs to master->mids array.
- [High] msm_iommu_probe modifies a global list without acquiring the required lock, causing race conditions.
--

commit a857d6e3a3b0380237f9c6c7b9ba76932246dfa4
Author: Alexandre MINETTE <contact@alex-min.fr>

iommu/msm: Look up masters per IOMMU instance

This commit updates the MSM IOMMU driver to look up context descriptors on
each IOMMU instance instead of using a global device provider. It introduces
a helper to search the target IOMMU context list when probing and attaching
devices. This aims to prevent null pointer dereferences when a device
references multiple IOMMU provider nodes.

> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index 0ad5ff431d5b6..9c03878d0d2cb 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -357,17 +357,25 @@ static int msm_iommu_domain_config(struct msm_priv *priv)
>  	return 0;
>  }
>  
> +static struct msm_iommu_ctx_dev *find_iommu_master(struct msm_iommu_dev *iommu,
> +						   struct device *dev)
> +{
> +	struct msm_iommu_ctx_dev *master;
> +
> +	list_for_each_entry(master, &iommu->ctx_list, list)
> +		if (master->of_node == dev->of_node)
> +			return master;
> +
> +	return NULL;
> +}

Since this patch allows multiple masters to be added to an IOMMU's ctx_list,
are there other functions that still assume the list only contains a single
element?

For example, doesn't msm_iommu_iova_to_phys() hardcode
list_first_entry(&iommu->ctx_list, ...) to select the master and query its
specific hardware context bank?

If translation is requested for any device other than the first one attached
to the IOMMU, could the driver read the hardware registers for the wrong
context bank, returning incorrect physical addresses?

>  /* Must be called under msm_iommu_lock */
>  static struct msm_iommu_dev *find_iommu_for_dev(struct device *dev)
>  {
>  	struct msm_iommu_dev *iommu, *ret = NULL;
> -	struct msm_iommu_ctx_dev *master;
>  
>  	list_for_each_entry(iommu, &qcom_iommu_devices, dev_node) {

This problem wasn't introduced by this patch, but msm_iommu_probe() adds the
newly allocated device to the global qcom_iommu_devices list without holding
the msm_iommu_lock spinlock:

msm_iommu_probe() {
    ...
    list_add(&iommu->dev_node, &qcom_iommu_devices);
    ...
}

Since other functions (like find_iommu_for_dev) concurrently access this
list under the lock, could this unprotected list mutation lead to list
corruption or a crash in asynchronous probing scenarios?

> -		master = list_first_entry(&iommu->ctx_list,
> -					  struct msm_iommu_ctx_dev,
> -					  list);
> -		if (master->of_node == dev->of_node) {
> +		if (find_iommu_master(iommu, dev)) {
>  			ret = iommu;
>  			break;
>  		}

[ ... ]

> @@ -405,10 +413,7 @@ static int msm_iommu_attach_dev(struct iommu_domain *domain, struct device *dev,
>  
>  	spin_lock_irqsave(&msm_iommu_lock, flags);
>  	list_for_each_entry(iommu, &qcom_iommu_devices, dev_node) {
> -		master = list_first_entry(&iommu->ctx_list,
> -					  struct msm_iommu_ctx_dev,
> -					  list);
> -		if (master->of_node == dev->of_node) {
> +		if (find_iommu_master(iommu, dev)) {
>  			ret = __enable_clocks(iommu);
>  			if (ret)
>  				goto fail;

With this change, multiple masters can be present in the ctx_list, but
msm_iommu_attach_dev() and msm_iommu_identity_attach() still unconditionally
iterate over the entire ctx_list instead of filtering for the target master:

msm_iommu_attach_dev() {
    ...
    if (find_iommu_master(iommu, dev)) {
        ...
        list_for_each_entry(master, &iommu->ctx_list, list) {
            ...

When the first device attaches, does this incorrectly provision hardware
contexts for all shared devices using its own domain, breaking IOMMU
isolation?

Also, because msm_iommu_alloc_ctx() can return 0, the safety check
if (master->num) evaluates to false for context bank 0. When a subsequent
device attaches, the loop re-allocates contexts and executes
list_add(&iommu->dom_node, &priv->list_attached) a second time. Could this
result in corruption of the doubly-linked domain list, leading to an
infinite loop and hang?

If a non-zero context bank was allocated, subsequent attaches hit
if (master->num) and unconditionally fail with -EEXIST. Would this prevent
shared IOMMUs from functioning?

Furthermore, does detaching one device via msm_iommu_identity_attach()
unintentionally tear down active DMA mappings for all other shared devices?

If the loop encounters a master with a non-zero context bank
(if (master->num)), it sets ret = -EEXIST and goes to the fail label:

msm_iommu_attach_dev() {
    ...
    if (master->num) {
        dev_err(dev, "domain already attached");
        ret = -EEXIST;
        goto fail;
    }

Since the fail label unlocks the spinlock and returns without calling
__disable_clocks(iommu), and shared IOMMUs will hit this reliably, does
this cause a permanent clock resource leak during probe/attach?

[ ... ]

> @@ -601,10 +606,10 @@ static int insert_iommu_master(struct device *dev,
>  				struct msm_iommu_dev **iommu,
>  				const struct of_phandle_args *spec)
>  {
> -	struct msm_iommu_ctx_dev *master = dev_iommu_priv_get(dev);
> +	struct msm_iommu_ctx_dev *master = find_iommu_master(*iommu, dev);
>  	int sid;
>  
> -	if (list_empty(&(*iommu)->ctx_list)) {
> +	if (!master) {
>  		master = kzalloc_obj(*master, GFP_ATOMIC);
>  		if (!master) {
>  			dev_err(dev, "Failed to allocate iommu_master\n");
> @@ -612,7 +617,6 @@ static int insert_iommu_master(struct device *dev,
>  		}
>  		master->of_node = dev->of_node;
>  		list_add(&master->list, &(*iommu)->ctx_list);
> -		dev_iommu_priv_set(dev, master);
>  	}
>  
>  	for (sid = 0; sid < master->num_mids; sid++)

This wasn't introduced by this patch, but does this function lack bounds
checking when appending stream IDs to the master->mids array?

If a maliciously crafted or malformed Device Tree provides more than
MAX_NUM_MIDS (32) stream IDs for a single device, could this result in an
out-of-bounds write, corrupting adjacent heap memory?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-mainline-send-v1-sending-v3-0-3dd7aa125353@alex-min.fr?part=4

[PATCH v3 5/8] extcon: qcom-spmi-misc: Add PM8921 compatible

[Alexandre MINETTE via B4 Relay]

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

PM8921 exposes the USB ID signal through the PMIC interrupt controller as
USB_ID_IN. The qcom-spmi-misc extcon driver already supports
interrupt-only USB ID detection, so add the PM8921 compatible.

This lets APQ8064 boards describe the PM8921 USB ID interrupt as an
extcon provider for USB role detection.

Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
 drivers/extcon/extcon-qcom-spmi-misc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/extcon/extcon-qcom-spmi-misc.c b/drivers/extcon/extcon-qcom-spmi-misc.c
index afaba5685c3d..6811d3383254 100644
--- a/drivers/extcon/extcon-qcom-spmi-misc.c
+++ b/drivers/extcon/extcon-qcom-spmi-misc.c
@@ -199,6 +199,7 @@ static SIMPLE_DEV_PM_OPS(qcom_usb_extcon_pm_ops,
 			 qcom_usb_extcon_suspend, qcom_usb_extcon_resume);
 
 static const struct of_device_id qcom_usb_extcon_dt_match[] = {
+	{ .compatible = "qcom,pm8921-misc", },
 	{ .compatible = "qcom,pm8941-misc", },
 	{ }
 };

-- 
2.43.0

Re: [PATCH v3 5/8] extcon: qcom-spmi-misc: Add PM8921 compatible

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The driver incorrectly handles negative error codes from platform_get_irq_byname_optional(), breaking -EPROBE_DEFER for the IRQs.
- [High] An early return during ID IRQ state reading causes VBUS state changes to be permanently lost.
--

commit 6e0b86ed0580b2ce5f0ed399603c0e9bc321f55d
Author: Alexandre MINETTE <contact@alex-min.fr>

extcon: qcom-spmi-misc: Add PM8921 compatible

This commit adds the PM8921 compatible to the qcom-spmi-misc extcon driver.
It allows APQ8064 boards to describe the PM8921 USB ID interrupt as an
extcon provider for USB role detection.

> diff --git a/drivers/extcon/extcon-qcom-spmi-misc.c b/drivers/extcon/extcon-qcom-spmi-misc.c
> index afaba5685c3dc..6811d3383254f 100644
> --- a/drivers/extcon/extcon-qcom-spmi-misc.c
> +++ b/drivers/extcon/extcon-qcom-spmi-misc.c
> @@ -199,6 +199,7 @@ static SIMPLE_DEV_PM_OPS(qcom_usb_extcon_pm_ops,
>  			 qcom_usb_extcon_suspend, qcom_usb_extcon_resume);
>  
>  static const struct of_device_id qcom_usb_extcon_dt_match[] = {
> +	{ .compatible = "qcom,pm8921-misc", },

While this isn't a bug introduced by this patch, there are some pre-existing
issues in the driver that might affect platforms using this compatible.

Does the driver correctly handle -EPROBE_DEFER for the IRQs?

drivers/extcon/extcon-qcom-spmi-misc.c:qcom_usb_extcon_probe() {
    ...
	info->id_irq = platform_get_irq_byname_optional(pdev, "usb_id");
	if (info->id_irq > 0) {
    ...
	info->vbus_irq = platform_get_irq_byname_optional(pdev, "usb_vbus");
	if (info->vbus_irq > 0) {
    ...
	if (info->id_irq < 0 && info->vbus_irq < 0) {
		dev_err(dev, "ID and VBUS IRQ not found\n");
		return -EINVAL;
	}
    ...
}

When platform_get_irq_byname_optional() returns -EPROBE_DEFER, the checks
if (info->id_irq > 0) and if (info->vbus_irq > 0) fail, bypassing the IRQ
requests.

If both IRQs return -EPROBE_DEFER, or if one is missing and the other defers,
if (info->id_irq < 0 && info->vbus_irq < 0) evaluates to true. The driver
logs an error and returns -EINVAL. This converts a deferred probe into a
permanent failure, preventing the driver from ever successfully probing.

If one IRQ is successfully found (> 0) and the other returns -EPROBE_DEFER,
the probe succeeds and returns 0. The deferred IRQ is silently dropped and
the driver loads with permanently broken hardware capability.


Can an early return during ID IRQ state reading cause VBUS state changes to be
permanently lost?

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 (info->vbus_irq > 0) {
    ...
}

In the qcom_usb_extcon_detect_cable() workqueue handler, the driver checks
both ID and VBUS states sequentially.

It first reads the ID IRQ line level via irq_get_irqchip_state(). If this
call fails, the handler executes if (ret) return; and exits immediately.

This completely skips the subsequent block that checks info->vbus_irq.

If the handler was scheduled to process a VBUS interrupt, and the ID IRQ read
fails, the VBUS state change will be dropped entirely. Since edge-triggered
interrupts are used, the extcon state will remain permanently out of sync
until the next physical cable plug/unplug event.

>  	{ .compatible = "qcom,pm8941-misc", },
>  	{ }
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-mainline-send-v1-sending-v3-0-3dd7aa125353@alex-min.fr?part=5

[PATCH v3 6/8] 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

Re: [PATCH v3 6/8] 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] Moving the transceiver clock (`USB_HSx_XCVR_CLK`) to the "fs" clock causes it to be permanently disabled during normal operation, breaking USB functionality.
- [Medium] Adding a third clock to the `qcom,ci-hdrc` nodes violates the `maxItems: 2` constraint in the `ci-hdrc-usb2.yaml` device tree binding schema.
--

commit 5a018643b67a319b143bcd44640fccd2fe85acc0
Author: Alexandre MINETTE <contact@alex-min.fr>

ARM: dts: qcom: apq8064: Fix USB controller clocks

This commit reorganizes the clock descriptions 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.

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
> index 09062b2ad8ba5..d64a162abdad4 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";

Does adding a third clock here violate the maxItems: 2 constraint in the
ci-hdrc-usb2.yaml device tree binding schema?

The qcom,ci-hdrc compatible string is validated by this schema. Expanding
the device tree node to include three clocks without updating the
corresponding YAML schema will cause the device tree to fail schema
validation.

Will mapping the transceiver clock to the fs clock cause it to be permanently
disabled during normal operation?

In drivers/usb/chipidea/ci_hdrc_msm.c, the fs clock is used exclusively for
a hardware reset sequence during probe. The driver calls
clk_prepare_enable(ci->fs_clk), toggles the reset controller, and immediately
calls clk_disable_unprepare(ci->fs_clk). It is never re-enabled.

Previously, the transceiver clock was mapped to core, which the driver keeps
continuously enabled during normal operation. Since the qcom,usb-hs-phy
driver does not independently request or enable the transceiver clock, this
change appears to guarantee the transceiver will be clock-gated while the USB
controller is actually running.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-mainline-send-v1-sending-v3-0-3dd7aa125353@alex-min.fr?part=6

[PATCH v3 7/8] ARM: dts: qcom: pm8921: Add USB ID extcon

[Alexandre MINETTE via B4 Relay]

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

PM8921 exposes the USB ID signal through the PMIC interrupt controller as
USB_ID_IN. Add an extcon child for this interrupt so USB controllers can
consume it for role detection.

Unlike PM8941, the PM8921 USB ID interrupt path has no known register
resource. The downstream PM8xxx misc device is also instantiated without
one, and the mainline extcon driver only consumes the named USB ID
interrupt. Keep the node non-addressable and describe only the interrupt.

Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
---
 arch/arm/boot/dts/qcom/pm8921.dtsi | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/qcom/pm8921.dtsi b/arch/arm/boot/dts/qcom/pm8921.dtsi
index 535cb6a2543f..30366536f580 100644
--- a/arch/arm/boot/dts/qcom/pm8921.dtsi
+++ b/arch/arm/boot/dts/qcom/pm8921.dtsi
@@ -121,6 +121,13 @@ ref_muxoff: adc-channel@f {
 				reg = <0x00 0x0f>;
 			};
 		};
+
+		usb_id: usb-detect {
+			compatible = "qcom,pm8921-misc";
+			interrupt-names = "usb_id";
+			interrupts-extended = <&pm8921 49 IRQ_TYPE_EDGE_BOTH>;
+			status = "disabled";
+		};
 	};
 };
 

-- 
2.43.0

Re: [PATCH v3 7/8] ARM: dts: qcom: pm8921: Add USB ID extcon

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Adding the `usb-detect` child node without updating the parent PMIC MFD schema will cause a `dtbs_check` validation error.
--

commit 1720dad1a12f125ee675cf2a28ab06f2b81a9589
Author: Alexandre MINETTE <contact@alex-min.fr>

ARM: dts: qcom: pm8921: Add USB ID extcon

This commit adds a non-addressable extcon child node to the PM8921 PMIC to
expose the USB ID signal for role detection.

> diff --git a/arch/arm/boot/dts/qcom/pm8921.dtsi b/arch/arm/boot/dts/qcom/pm8921.dtsi
> index 535cb6a2543f6..30366536f5803 100644
> --- a/arch/arm/boot/dts/qcom/pm8921.dtsi
> +++ b/arch/arm/boot/dts/qcom/pm8921.dtsi

[ ... ]

> @@ -121,6 +121,13 @@ ref_muxoff: adc-channel@f {
>  				reg = <0x00 0x0f>;
>  			};
>  		};
> +
> +		usb_id: usb-detect {
> +			compatible = "qcom,pm8921-misc";

Will this cause a dtbs_check validation error?

The parent PMIC device tree binding in
Documentation/devicetree/bindings/mfd/qcom-pm8xxx.yaml specifies
additionalProperties: false and explicitly enumerates all permitted child
nodes.

It does not appear to define or allow a usb-detect node or the
qcom,pm8921-misc compatible string.

> +			interrupt-names = "usb_id";
> +			interrupts-extended = <&pm8921 49 IRQ_TYPE_EDGE_BOTH>;
> +			status = "disabled";
> +		};
>  	};
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-mainline-send-v1-sending-v3-0-3dd7aa125353@alex-min.fr?part=7

[PATCH v3 8/8] 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.

Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
---
 arch/arm/boot/dts/qcom/Makefile                    |   1 +
 .../boot/dts/qcom/qcom-apq8064-samsung-jflte.dts   | 485 +++++++++++++++++++++
 2 files changed, 486 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..2f10466077c7
--- /dev/null
+++ b/arch/arm/boot/dts/qcom/qcom-apq8064-samsung-jflte.dts
@@ -0,0 +1,485 @@
+// 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>;
+		scl-gpios = <&tlmm_pinmux 23 GPIO_ACTIVE_HIGH>;
+		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>;
+};
+
+&usb_id {
+	status = "okay";
+};
+
+&usb1 {
+	dr_mode = "otg";
+	extcon = <&muic>, <&usb_id>;
+
+	status = "okay";
+};

-- 
2.43.0

Re: [PATCH v3 8/8] 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 'sda-gpios' and 'scl-gpios' properties in the 'i2c-muic' node omit the 'GPIO_OPEN_DRAIN' flag.
--

commit 2dc0aa912f65c9935abe21e36b8281387360daac
Author: Alexandre MINETTE <contact@alex-min.fr>

ARM: dts: qcom: Add Samsung Galaxy S4

This commit adds a device tree for the Samsung Galaxy S4 (jflte) based on the
Qualcomm APQ8064 platform. It includes initial support for UART, USB peripheral
mode, LEDs, 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..2f10466077c7a
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom/qcom-apq8064-samsung-jflte.dts

[ ... ]

> +	i2c-muic {
> +		compatible = "i2c-gpio";
> +		sda-gpios = <&tlmm_pinmux 22 GPIO_ACTIVE_HIGH>;
> +		scl-gpios = <&tlmm_pinmux 23 GPIO_ACTIVE_HIGH>;

Does this configuration omit the GPIO_OPEN_DRAIN flag?

The i2c-gpio driver requests the pins with GPIOD_OUT_HIGH_OPEN_DRAIN.
When the GPIO_OPEN_DRAIN flag is omitted in the device tree, the GPIO
subsystem enforces the open-drain semantics to prevent hardware issues
but emits a boot warning about the missing flag.

Could the GPIO_OPEN_DRAIN flag be added here to satisfy the i2c-gpio
bindings and silence the warning, similar to how the i2c-led node is
configured?

> +		i2c-gpio,delay-us = <2>;
> +
> +		#address-cells = <1>;
> +		#size-cells = <0>;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260519-mainline-send-v1-sending-v3-0-3dd7aa125353@alex-min.fr?part=8