* [PATCH v4 1/6] dt-bindings: arm: qcom: Add Samsung Galaxy S4
2026-06-09 8:13 [PATCH v4 0/6] Add Samsung Galaxy S4 support Alexandre MINETTE via B4 Relay
@ 2026-06-09 8:13 ` Alexandre MINETTE via B4 Relay
2026-06-09 8:13 ` [PATCH v4 2/6] pinctrl: qcom: Register functions before enabling pinctrl Alexandre MINETTE via B4 Relay
` (4 subsequent siblings)
5 siblings, 0 replies; 11+ messages in thread
From: Alexandre MINETTE via B4 Relay @ 2026-06-09 8:13 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Guru Das Srinagesh,
Linus Walleij, Rob Clark, Kees Cook, Tony Luck,
Guilherme G. Piccoli
Cc: linux-arm-msm, devicetree, linux-kernel, linux-gpio, phone-devel,
Alexandre MINETTE, Krzysztof Kozlowski
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
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH v4 2/6] pinctrl: qcom: Register functions before enabling pinctrl
2026-06-09 8:13 [PATCH v4 0/6] Add Samsung Galaxy S4 support Alexandre MINETTE via B4 Relay
2026-06-09 8:13 ` [PATCH v4 1/6] dt-bindings: arm: qcom: Add Samsung Galaxy S4 Alexandre MINETTE via B4 Relay
@ 2026-06-09 8:13 ` Alexandre MINETTE via B4 Relay
2026-06-09 10:27 ` sashiko-bot
2026-06-09 8:13 ` [PATCH v4 3/6] ARM: dts: qcom: apq8064: Fix USB controller clocks Alexandre MINETTE via B4 Relay
` (3 subsequent siblings)
5 siblings, 1 reply; 11+ messages in thread
From: Alexandre MINETTE via B4 Relay @ 2026-06-09 8:13 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Guru Das Srinagesh,
Linus Walleij, Rob Clark, Kees Cook, Tony Luck,
Guilherme G. Piccoli
Cc: linux-arm-msm, devicetree, linux-kernel, linux-gpio, phone-devel,
Alexandre MINETTE
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
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH v4 2/6] pinctrl: qcom: Register functions before enabling pinctrl
2026-06-09 8:13 ` [PATCH v4 2/6] pinctrl: qcom: Register functions before enabling pinctrl Alexandre MINETTE via B4 Relay
@ 2026-06-09 10:27 ` sashiko-bot
0 siblings, 0 replies; 11+ messages in thread
From: sashiko-bot @ 2026-06-09 10:27 UTC (permalink / raw)
To: Alexandre MINETTE via B4 Relay; +Cc: conor+dt, devicetree, robh
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Global function pointer `pm_power_off` and `poweroff_pctrl` state are left pointing to freed memory if probe fails.
--
commit 4cee21ced39b9add5c750146fde36a08b79745d3
Author: Alexandre MINETTE <contact@alex-min.fr>
pinctrl: qcom: Register functions before enabling pinctrl
This patch changes the initialization sequence in the Qualcomm pinctrl
driver by registering the pinctrl device with devm_pinctrl_register_and_init,
adding the SoC pin functions, and only then enabling the device to prevent
invalid function map table lookups.
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
> --- 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);
[ ... ]
> + 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");
[Severity: High]
This is a pre-existing issue, but since the failure paths are being
restructured here, what happens to the pm_power_off global pointer if this
registration (or the subsequent pinctrl_enable call) fails?
Earlier in msm_pinctrl_probe(), a call to msm_pinctrl_setup_pm_reset()
assigns the dynamically allocated pctrl to the global poweroff_pctrl pointer
and sets the global pm_power_off to msm_ps_hold_poweroff.
If probe fails here or later:
msm_pinctrl_probe()
msm_pinctrl_setup_pm_reset(pctrl);
...
ret = devm_pinctrl_register_and_init(...)
if (ret)
return dev_err_probe(...);
The pctrl structure is managed by devres and will be freed upon probe
failure, leaving the global poweroff_pctrl pointing to freed memory. If the
system subsequently initiates a shutdown, msm_ps_hold_poweroff() will
dereference the freed memory, leading to a use-after-free.
Would it make sense to update msm_pinctrl_setup_pm_reset() to use
devm_register_sys_off_handler() with SYS_OFF_MODE_POWER_OFF instead of
directly assigning the pm_power_off global pointer?
>
> for (i = 0; i < soc_data->nfunctions; i++) {
> func = &soc_data->functions[i];
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260609-mainline-send-v1-sending-v4-0-83768fbf404d@alex-min.fr?part=2
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v4 3/6] ARM: dts: qcom: apq8064: Fix USB controller clocks
2026-06-09 8:13 [PATCH v4 0/6] Add Samsung Galaxy S4 support Alexandre MINETTE via B4 Relay
2026-06-09 8:13 ` [PATCH v4 1/6] dt-bindings: arm: qcom: Add Samsung Galaxy S4 Alexandre MINETTE via B4 Relay
2026-06-09 8:13 ` [PATCH v4 2/6] pinctrl: qcom: Register functions before enabling pinctrl Alexandre MINETTE via B4 Relay
@ 2026-06-09 8:13 ` Alexandre MINETTE via B4 Relay
2026-06-09 10:39 ` sashiko-bot
2026-06-09 8:13 ` [PATCH v4 4/6] mfd: qcom-pm8xxx: register PM8921 USB ID extcon Alexandre MINETTE via B4 Relay
` (2 subsequent siblings)
5 siblings, 1 reply; 11+ messages in thread
From: Alexandre MINETTE via B4 Relay @ 2026-06-09 8:13 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Guru Das Srinagesh,
Linus Walleij, Rob Clark, Kees Cook, Tony Luck,
Guilherme G. Piccoli
Cc: linux-arm-msm, devicetree, linux-kernel, linux-gpio, phone-devel,
Alexandre MINETTE, Antony Kurniawan Soemardi, Konrad Dybcio,
Dmitry Baryshkov
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
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH v4 3/6] ARM: dts: qcom: apq8064: Fix USB controller clocks
2026-06-09 8:13 ` [PATCH v4 3/6] ARM: dts: qcom: apq8064: Fix USB controller clocks Alexandre MINETTE via B4 Relay
@ 2026-06-09 10:39 ` sashiko-bot
0 siblings, 0 replies; 11+ messages in thread
From: sashiko-bot @ 2026-06-09 10:39 UTC (permalink / raw)
To: Alexandre MINETTE via B4 Relay; +Cc: robh, conor+dt, devicetree
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The essential 60MHz transceiver clock is mapped to the 'fs' clock, which is explicitly disabled by the driver during normal operation, breaking USB functionality.
- [Low] Adding a third clock to the `qcom,ci-hdrc` nodes violates the `maxItems: 2` constraint in the existing binding schema.
--
commit 453c68cf87c5de356d651306bdd24fea9db45f5a
Author: Alexandre MINETTE <contact@alex-min.fr>
ARM: dts: qcom: apq8064: Fix USB controller clocks
This commit updates the clock properties 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 enabled.
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";
[Severity: Low]
Does adding a third clock here violate the binding schema?
Looking at Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml, both the
clocks and clock-names properties are restricted to a maximum of 2 items:
Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml:
clocks:
minItems: 1
maxItems: 2
clock-names:
minItems: 1
maxItems: 2
Will this cause make dtbs_check to fail during validation?
[Severity: High]
Will mapping the transceiver clock to "fs" cause it to be permanently
disabled after probe?
Looking at ci_hdrc_msm_probe() in the MSM ChipIdea driver, the fs clock is
explicitly disabled immediately after the controller reset sequence:
drivers/usb/chipidea/ci_hdrc_msm.c:ci_hdrc_msm_probe() {
...
clk_disable_unprepare(ci->fs_clk);
...
}
Since the 60MHz transceiver clock (USB_HS1_XCVR_CLK) is required for the
PHY and MAC to operate, won't turning it off break USB functionality on
this platform entirely?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260609-mainline-send-v1-sending-v4-0-83768fbf404d@alex-min.fr?part=3
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v4 4/6] mfd: qcom-pm8xxx: register PM8921 USB ID extcon
2026-06-09 8:13 [PATCH v4 0/6] Add Samsung Galaxy S4 support Alexandre MINETTE via B4 Relay
` (2 preceding siblings ...)
2026-06-09 8:13 ` [PATCH v4 3/6] ARM: dts: qcom: apq8064: Fix USB controller clocks Alexandre MINETTE via B4 Relay
@ 2026-06-09 8:13 ` Alexandre MINETTE via B4 Relay
2026-06-09 10:52 ` sashiko-bot
2026-06-09 8:13 ` [PATCH v4 5/6] extcon: qcom-spmi-misc: match PM8xxx USB ID platform device Alexandre MINETTE via B4 Relay
2026-06-09 8:13 ` [PATCH v4 6/6] ARM: dts: qcom: Add Samsung Galaxy S4 Alexandre MINETTE via B4 Relay
5 siblings, 1 reply; 11+ messages in thread
From: Alexandre MINETTE via B4 Relay @ 2026-06-09 8:13 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Guru Das Srinagesh,
Linus Walleij, Rob Clark, Kees Cook, Tony Luck,
Guilherme G. Piccoli
Cc: linux-arm-msm, devicetree, linux-kernel, linux-gpio, phone-devel,
Alexandre MINETTE
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
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH v4 4/6] mfd: qcom-pm8xxx: register PM8921 USB ID extcon
2026-06-09 8:13 ` [PATCH v4 4/6] mfd: qcom-pm8xxx: register PM8921 USB ID extcon Alexandre MINETTE via B4 Relay
@ 2026-06-09 10:52 ` sashiko-bot
0 siblings, 0 replies; 11+ messages in thread
From: sashiko-bot @ 2026-06-09 10:52 UTC (permalink / raw)
To: Alexandre MINETTE via B4 Relay; +Cc: conor+dt, robh, devicetree
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] The dynamically registered child platform device 'usb_extcon' is unregistered twice during driver removal, resulting in a use-after-free and double free.
Pre-existing issues:
- [High] The IRQ domain is freed explicitly while the devm-managed parent IRQ handler is still active, leading to a potential use-after-free if the interrupt fires before devres cleanup finishes.
--
commit c974699adaea81fa53001bda7b03087f8ea67b97
Author: Alexandre MINETTE <contact@alex-min.fr>
Date: Tue Jun 9 08:13:47 2026 +0000
mfd: qcom-pm8xxx: register PM8921 USB ID extcon
This commit registers a child platform device for the USB ID interrupt on
PM8921 to act as an extcon provider. It shares the PMIC's devicetree node
and cleans up the child device upon driver removal or probe failure.
> 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
[ ... ]
> @@ -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);
[Severity: High]
Does this cause a double-free of the usb_extcon platform device?
When of_platform_depopulate() runs, it iterates over all children and invokes
of_platform_device_destroy(). Because usb_extcon is registered with
pdevinfo.of_node_reused = true and shares the parent's of_node (which has the
OF_POPULATED flag set), of_platform_device_destroy() will assume it created
the device and unregister usb_extcon.
Calling pm8xxx_remove_usb_extcon() immediately afterward will call
platform_device_unregister() on the already freed usb_extcon pointer,
resulting in a use-after-free.
> irq_domain_remove(chip->irqdomain);
[Severity: High]
This is a pre-existing issue, but does this explicitly free the IRQ domain
while the parent interrupt handler is still active?
In pm8xxx_probe(), the parent interrupt is requested via devm_request_irq().
This means the devres cleanup mechanism won't free the IRQ until
devres_release_all() runs, which happens after pm8xxx_remove() completes.
If a hardware interrupt triggers during the window between this
irq_domain_remove() call and devres cleanup, will pm8xxx_irq_handler() call
generic_handle_domain_irq() and dereference the freed chip->irqdomain?
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260609-mainline-send-v1-sending-v4-0-83768fbf404d@alex-min.fr?part=4
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v4 5/6] extcon: qcom-spmi-misc: match PM8xxx USB ID platform device
2026-06-09 8:13 [PATCH v4 0/6] Add Samsung Galaxy S4 support Alexandre MINETTE via B4 Relay
` (3 preceding siblings ...)
2026-06-09 8:13 ` [PATCH v4 4/6] mfd: qcom-pm8xxx: register PM8921 USB ID extcon Alexandre MINETTE via B4 Relay
@ 2026-06-09 8:13 ` Alexandre MINETTE via B4 Relay
2026-06-09 11:03 ` sashiko-bot
2026-06-09 8:13 ` [PATCH v4 6/6] ARM: dts: qcom: Add Samsung Galaxy S4 Alexandre MINETTE via B4 Relay
5 siblings, 1 reply; 11+ messages in thread
From: Alexandre MINETTE via B4 Relay @ 2026-06-09 8:13 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Guru Das Srinagesh,
Linus Walleij, Rob Clark, Kees Cook, Tony Luck,
Guilherme G. Piccoli
Cc: linux-arm-msm, devicetree, linux-kernel, linux-gpio, phone-devel,
Alexandre MINETTE
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
^ permalink raw reply related [flat|nested] 11+ messages in thread* Re: [PATCH v4 5/6] extcon: qcom-spmi-misc: match PM8xxx USB ID platform device
2026-06-09 8:13 ` [PATCH v4 5/6] extcon: qcom-spmi-misc: match PM8xxx USB ID platform device Alexandre MINETTE via B4 Relay
@ 2026-06-09 11:03 ` sashiko-bot
0 siblings, 0 replies; 11+ messages in thread
From: sashiko-bot @ 2026-06-09 11:03 UTC (permalink / raw)
To: Alexandre MINETTE via B4 Relay; +Cc: robh, devicetree, conor+dt
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The probe function silently squashes -EPROBE_DEFER and other error codes from platform_get_irq_byname_optional(), permanently breaking device initialization.
--
commit 1e93c1501595aa2edcd9a08fd1d48d4373aaf0ca
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". This commit adds a platform device ID so the
existing extcon driver can bind to this device.
> 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,
[Severity: High]
This is a pre-existing issue, but does qcom_usb_extcon_probe() mishandle
deferred probing?
Looking at qcom_usb_extcon_probe(), if platform_get_irq_byname_optional()
returns -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;
}
...
}
If both IRQs defer, the code falls through and returns -EINVAL instead of
propagating -EPROBE_DEFER, which could permanently prevent the device from
initializing.
Additionally, if one IRQ defers while the other is found, the driver simply
skips requesting it. Could this cause the probe to succeed in a degraded
state without the deferred IRQ?
> + .id_table = qcom_usb_extcon_id,
> .driver = {
> .name = "extcon-pm8941-misc",
> .pm = &qcom_usb_extcon_pm_ops,
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260609-mainline-send-v1-sending-v4-0-83768fbf404d@alex-min.fr?part=5
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v4 6/6] ARM: dts: qcom: Add Samsung Galaxy S4
2026-06-09 8:13 [PATCH v4 0/6] Add Samsung Galaxy S4 support Alexandre MINETTE via B4 Relay
` (4 preceding siblings ...)
2026-06-09 8:13 ` [PATCH v4 5/6] extcon: qcom-spmi-misc: match PM8xxx USB ID platform device Alexandre MINETTE via B4 Relay
@ 2026-06-09 8:13 ` Alexandre MINETTE via B4 Relay
5 siblings, 0 replies; 11+ messages in thread
From: Alexandre MINETTE via B4 Relay @ 2026-06-09 8:13 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Guru Das Srinagesh,
Linus Walleij, Rob Clark, Kees Cook, Tony Luck,
Guilherme G. Piccoli
Cc: linux-arm-msm, devicetree, linux-kernel, linux-gpio, phone-devel,
Alexandre MINETTE
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 | 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
^ permalink raw reply related [flat|nested] 11+ messages in thread