USB: dwc3: qcom: fix wakeup after probe deferral
Subsystems (5)
cover USB: dwc3: qcom: fix wakeup after probe deferral
When testing a recent series that addresses resource leaks on probe deferral [1] I realised that probe deferral can break wakeup from suspend due to how the wakeup interrupts are currently requested.
I'll send a separate series for the Qualcomm devicetrees that used incorrect trigger types for the wakeup interrupts. Included here is just a patch fixing the binding example which hopefully will make it less likely that more of these gets introduced. Fortunately, there should be no dependency between this series and the devicetree one.
Note also that I decided to include a related trivial cleanup patch.
Johan
[1] https://lore.kernel.org/lkml/[email protected]/
Johan Hovold (3):
dt-bindings: usb: qcom,dwc3: fix example wakeup interrupt types
USB: dwc3: qcom: fix wakeup after probe deferral
USB: dwc3: qcom: simplify wakeup interrupt setup
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 4 ++-- drivers/usb/dwc3/dwc3-qcom.c | 12 ++++-------- 2 files changed, 6 insertions(+), 10 deletions(-)
Signature · 1 line
2.41.0
PATCH 1/3 dt-bindings: usb: qcom,dwc3: fix example wakeup interrupt types
The DP/DM wakeup interrupts are edge triggered and which edge to trigger on depends on use-case and whether a Low speed or Full/High speed device is connected.
--- Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +2 -2
@@ -521,8 +521,8 @@ examples: interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 486 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 488 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 489 IRQ_TYPE_LEVEL_HIGH>; + <GIC_SPI 488 IRQ_TYPE_EDGE_BOTH>, + <GIC_SPI 489 IRQ_TYPE_EDGE_BOTH>; interrupt-names = "hs_phy_irq", "ss_phy_irq", "dm_hs_phy_irq", "dp_hs_phy_irq";
Signature · 1 line
2.41.0
Re: [PATCH 1/3] dt-bindings: usb: qcom,dwc3: fix example wakeup interrupt types
Quoted 7 lines · Johan Hovold
The DP/DM wakeup interrupts are edge triggered and which edge to trigger on depends on use-case and whether a Low speed or Full/High speed device is connected.
Fixes 3828026c9ec8 ("dt-bindings: usb: qcom,dwc3: Convert USB DWC3 bindings")Signed-off-by Johan Hovold <[email protected]>---
Best regards,
Krzysztof
PATCH 2/3 USB: dwc3: qcom: fix wakeup after probe deferral
In reply to Johan HovoldThe Qualcomm glue driver is overriding the interrupt trigger types defined by firmware when requesting the wakeup interrupts during probe.
This can lead to a failure to map the DP/DM wakeup interrupts after a probe deferral as the firmware defined trigger types do not match the type used for the initial mapping:
irq: type mismatch, failed to map hwirq-14 for interrupt-controller@b220000!
irq: type mismatch, failed to map hwirq-15 for interrupt-controller@b220000!
Fix this by not overriding the firmware provided trigger types when requesting the wakeup interrupts.
--- drivers/usb/dwc3/dwc3-qcom.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/usb/dwc3/dwc3-qcom.c +4 -4
@@ -549,7 +549,7 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_TRIGGER_HIGH |IRQF_ONESHOT , +IRQF_ONESHOT ,"qcom_dwc3 HS" , qcom);if (ret) {dev_err (qcom->dev,"hs_phy_irq failed: %d\n" , ret);
@@ -564,7 +564,7 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_TRIGGER_HIGH |IRQF_ONESHOT , +IRQF_ONESHOT ,"qcom_dwc3 DP_HS" , qcom);if (ret) {dev_err (qcom->dev,"dp_hs_phy_irq failed: %d\n" , ret);
@@ -579,7 +579,7 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_TRIGGER_HIGH |IRQF_ONESHOT , +IRQF_ONESHOT ,"qcom_dwc3 DM_HS" , qcom);if (ret) {dev_err (qcom->dev,"dm_hs_phy_irq failed: %d\n" , ret);
@@ -594,7 +594,7 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_TRIGGER_HIGH |IRQF_ONESHOT , +IRQF_ONESHOT ,"qcom_dwc3 SS" , qcom);if (ret) {dev_err (qcom->dev,"ss_phy_irq failed: %d\n" , ret);
Signature · 1 line
2.41.0
Quoted 7 lines · Johan Hovold
The Qualcomm glue driver is overriding the interrupt trigger types defined by firmware when requesting the wakeup interrupts during probe.
This can lead to a failure to map the DP/DM wakeup interrupts after a probe deferral as the firmware defined trigger types do not match the type used for the initial mapping:
Quoted 5 lines
irq: type mismatch, failed to map hwirq-14 for interrupt-controller@b220000!
irq: type mismatch, failed to map hwirq-15 for interrupt-controller@b220000!Fix this by not overriding the firmware provided trigger types when requesting the wakeup interrupts.
This series looks good to me and makes sense except for one point that I'm struggling to understand. What exactly is the relationship with this failure and probe deferral?
Thanks,
Andrew
Quoted 52 lines
Fixes a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")Cc [email protected] # 4.18Signed-off-by Johan Hovold <[email protected]>--- drivers/usb/dwc3/dwc3-qcom.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/usb/dwc3/dwc3-qcom.c +4
-4@@ -549,7 +549,7 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_TRIGGER_HIGH |IRQF_ONESHOT , +IRQF_ONESHOT ,"qcom_dwc3 HS" , qcom);if (ret) {dev_err (qcom->dev,"hs_phy_irq failed: %d\n" , ret);@@ -564,7 +564,7 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_TRIGGER_HIGH |IRQF_ONESHOT , +IRQF_ONESHOT ,"qcom_dwc3 DP_HS" , qcom);if (ret) {dev_err (qcom->dev,"dp_hs_phy_irq failed: %d\n" , ret);@@ -579,7 +579,7 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_TRIGGER_HIGH |IRQF_ONESHOT , +IRQF_ONESHOT ,"qcom_dwc3 DM_HS" , qcom);if (ret) {dev_err (qcom->dev,"dm_hs_phy_irq failed: %d\n" , ret);@@ -594,7 +594,7 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_TRIGGER_HIGH |IRQF_ONESHOT , +IRQF_ONESHOT ,"qcom_dwc3 SS" , qcom);if (ret) {dev_err (qcom->dev,"ss_phy_irq failed: %d\n" , ret);Signature · 1 line
2.41.0
Quoted 11 lines · Andrew Halaney
Quoted 10 lines · Johan Hovold
The Qualcomm glue driver is overriding the interrupt trigger types defined by firmware when requesting the wakeup interrupts during probe.
This can lead to a failure to map the DP/DM wakeup interrupts after a probe deferral as the firmware defined trigger types do not match the type used for the initial mapping:
irq: type mismatch, failed to map hwirq-14 for interrupt-controller@b220000!
irq: type mismatch, failed to map hwirq-15 for interrupt-controller@b220000!
Quoted 6 lines
Quoted 2 lines
Fix this by not overriding the firmware provided trigger types when requesting the wakeup interrupts.
This series looks good to me and makes sense except for one point that I'm struggling to understand. What exactly is the relationship with this failure and probe deferral?
Eric Chanudet pointed out to me (thanks!) offlist that if you:
1. Probe
2. Grab the IRQ
3. Request it (and muck with the trigger from the firmware default)
4. Defer out
5. Reprobe
6. Grab the IRQ again
You get that error, which I played with some this afternoon... and can confirm.
It really seems like maybe we should consider reworking messing with the trigger type at all (which is done later for runtime/system suspend) in a follow-up series?
As far as I can tell if you were to remove the driver and reprobe after a suspend you'd hit similar. I've been sitting here scratching my head a bit trying to reason out why keeping it as IRQ_TYPE_EDGE_BOTH isn't acceptable in dwc3_qcom_enable_interrupts()... Correct me if you think that playing with the trigger there is really ok, but it seems like you run the same risks if you do that and then modprobe -r dwc3-qcom.
I get that dwc3_qcom_enable_interrupts() limits the scope of what wakes us up to what we expect given the current device (or lack thereof), but it doesn't seem like you're really meant to play with the IRQ triggers, or at least the warning you shared makes me think it is not a great idea if you plan to probe the device ever again in the future.
I'll post the current comment in dwc3_qcom_enable_interrupts() to explain the "limits the scope of what wakes us up" a bit more clearly:
/*
* Configure DP/DM line interrupts based on the USB2 device attached to
* the root hub port. When HS/FS device is connected, configure the DP line
* as falling edge to detect both disconnect and remote wakeup scenarios. When
* LS device is connected, configure DM line as falling edge to detect both
* disconnect and remote wakeup. When no device is connected, configure both
* DP and DM lines as rising edge to detect HS/HS/LS device connect scenario. */
Quoted 56 lines
Thanks,
AndrewQuoted 52 lines
Fixes a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver")Cc [email protected] # 4.18Signed-off-by Johan Hovold <[email protected]>--- drivers/usb/dwc3/dwc3-qcom.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/usb/dwc3/dwc3-qcom.c +4
-4@@ -549,7 +549,7 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_TRIGGER_HIGH |IRQF_ONESHOT , +IRQF_ONESHOT ,"qcom_dwc3 HS" , qcom);if (ret) {dev_err (qcom->dev,"hs_phy_irq failed: %d\n" , ret);@@ -564,7 +564,7 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_TRIGGER_HIGH |IRQF_ONESHOT , +IRQF_ONESHOT ,"qcom_dwc3 DP_HS" , qcom);if (ret) {dev_err (qcom->dev,"dp_hs_phy_irq failed: %d\n" , ret);@@ -579,7 +579,7 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_TRIGGER_HIGH |IRQF_ONESHOT , +IRQF_ONESHOT ,"qcom_dwc3 DM_HS" , qcom);if (ret) {dev_err (qcom->dev,"dm_hs_phy_irq failed: %d\n" , ret);@@ -594,7 +594,7 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev)irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_TRIGGER_HIGH |IRQF_ONESHOT , +IRQF_ONESHOT ,"qcom_dwc3 SS" , qcom);if (ret) {dev_err (qcom->dev,"ss_phy_irq failed: %d\n" , ret);Signature · 1 line
2.41.0
Quoted 31 lines · Andrew Halaney
Quoted 11 lines · Andrew Halaney
Quoted 10 lines · Johan Hovold
The Qualcomm glue driver is overriding the interrupt trigger types defined by firmware when requesting the wakeup interrupts during probe.
This can lead to a failure to map the DP/DM wakeup interrupts after a probe deferral as the firmware defined trigger types do not match the type used for the initial mapping:
irq: type mismatch, failed to map hwirq-14 for interrupt-controller@b220000!
irq: type mismatch, failed to map hwirq-15 for interrupt-controller@b220000!Quoted 6 lines
Quoted 2 lines
Fix this by not overriding the firmware provided trigger types when requesting the wakeup interrupts.
This series looks good to me and makes sense except for one point that I'm struggling to understand. What exactly is the relationship with this failure and probe deferral?
Eric Chanudet pointed out to me (thanks!) offlist that if you:
1. Probe
2. Grab the IRQ
3. Request it (and muck with the trigger from the firmware default)
4. Defer out
5. Reprobe
6. Grab the IRQ againYou get that error, which I played with some this afternoon... and can confirm.
Quoted 6 lines
It really seems like maybe we should consider reworking messing with the trigger type at all (which is done later for runtime/system suspend) in a follow-up series?
As far as I can tell if you were to remove the driver and reprobe after a suspend you'd hit similar.
Correct, but people don't go around unloading modules (unlike probe deferral which anyone can hit). It's a development (debugging) feature so there being some corner cases are not that big of a deal.
Quoted 5 lines
I've been sitting here scratching my head a
bit trying to reason out why keeping it asIRQ_TYPE_EDGE_BOTHisn't acceptable indwc3_qcom_enable_interrupts()... Correct me if you think that playing with the trigger there is really ok, but it seems like you run the same risks if you do that and then modprobe -r dwc3-qcom.
Changing the trigger type during runtime depending on use-case should be fine. It just doesn't play well with the kernel's interrupt mapping code, which assumes that if an interrupt already has a mapping then it is a shared interrupt.
I considered addressing that in the core code, but yeah, I don't want too much time since the remaining issue only affects module unload and there are other ways to avoid that issue too.
Quoted 9 lines
I get that
dwc3_qcom_enable_interrupts()limits the scope of what wakes us up to what we expect given the current device (or lack thereof), but it doesn't seem like you're really meant to play with the IRQ triggers, or at least the warning you shared makes me think it is not a great idea if you plan to probe the device ever again in the future.I'll post the current comment in
dwc3_qcom_enable_interrupts()to explain the "limits the scope of what wakes us up" a bit more clearly:
Quoted 8 lines
/*
* Configure DP/DM line interrupts based on the USB2 device attached to
* the root hub port. When HS/FS device is connected, configure the DP line
* as falling edge to detect both disconnect and remote wakeup scenarios. When
* LS device is connected, configure DM line as falling edge to detect both
* disconnect and remote wakeup. When no device is connected, configure both
* DP and DM lines as rising edge to detect HS/HS/LS device connect scenario. */
Yes, that is how it is currently implemented and I intend to change that shortly. I just wanted to get the fixes out first.
Specifically, I consider the current implementation to be broken in that it generates wakeup events on disconnect which is generally not want you want. Consider closing the lid of your laptop and disconnecting a USB mouse before putting it in your backpack. Now it's no longer suspended as you would expect it to be.
With the devictrees soon fixed, we could also do away with changing the trigger type, but since this is how it was implemented initially we now need to consider backward compatibility with the broken DTs. We've dealt with that before, but yeah, getting things right from the start would have been so much better.
Johan
Quoted 28 lines
Quoted 10 lines
I get that
dwc3_qcom_enable_interrupts()limits the scope of what wakes us up to what we expect given the current device (or lack thereof), but it doesn't seem like you're really meant to play with the IRQ triggers, or at least the warning you shared makes me think it is not a great idea if you plan to probe the device ever again in the future.I'll post the current comment in
dwc3_qcom_enable_interrupts()to explain the "limits the scope of what wakes us up" a bit more clearly:Quoted 8 lines
/*
* Configure DP/DM line interrupts based on the USB2 device attached to
* the root hub port. When HS/FS device is connected, configure the DP line
* as falling edge to detect both disconnect and remote wakeup scenarios. When
* LS device is connected, configure DM line as falling edge to detect both
* disconnect and remote wakeup. When no device is connected, configure both
* DP and DM lines as rising edge to detect HS/HS/LS device connect scenario. */Yes, that is how it is currently implemented and I intend to change that shortly. I just wanted to get the fixes out first.
Specifically, I consider the current implementation to be broken in that it generates wakeup events on disconnect which is generally not want you want. Consider closing the lid of your laptop and disconnecting a USB mouse before putting it in your backpack. Now it's no longer suspended as you would expect it to be.
Quoted 6 lines
With the devictrees soon fixed, we could also do away with changing the trigger type, but since this is how it was implemented initially we now need to consider backward compatibility with the broken DTs. We've dealt with that before, but yeah, getting things right from the start would have been so much better.
Hi Johan,
Just one query. Even if it wakes up after closing the lid and removing
the mouse, wouldn't pm suspend be triggered again later by the system once it sees that usb is also good to be suspended again ? I presume a laptop form factor would be having this facility of re-trigerring suspend. Let me know if this is not the case.
Also, the warning you are mentioning in [1] comes because this is a laptop form factor and we have some firmware running (I don't know much about ACPI and stuff) ?
[1]: https://lore.kernel.org/all/[email protected]/
Regards,
Krishna,
Quoted 11 lines · Krishna Kurapati PSSNV
Quoted 5 lines
Specifically, I consider the current implementation to be broken in that it generates wakeup events on disconnect which is generally not want you want. Consider closing the lid of your laptop and disconnecting a USB mouse before putting it in your backpack. Now it's no longer suspended as you would expect it to be.
Just one query. Even if it wakes up after closing the lid and removing
the mouse, wouldn't pm suspend be triggered again later by the system once it sees that usb is also good to be suspended again ? I presume a laptop form factor would be having this facility of re-trigerring suspend. Let me know if this is not the case.
No, we generally don't use opportunistic suspend (e.g. unlike android) so the laptop will not suspend again.
So this is an actual bug affecting, for example, the Lenovo ThinkPad X13s.
Quoted 3 lines
Also, the warning you are mentioning in [1] comes because this is a laptop form factor and we have some firmware running (I don't know much about ACPI and stuff) ?
No, the "firmware" in this case is just the devicetree which has the DP/DM interrupts defined as edge-triggered while the driver requests them as level triggered.
(It would look similar with ACPI firmware which also has these declared as edge triggered.)
Johan
Quoted 6 lines
Quoted 5 lines
Just one query. Even if it wakes up after closing the lid and removing
the mouse, wouldn't pm suspend be triggered again later by the system once it sees that usb is also good to be suspended again ? I presume a laptop form factor would be having this facility of re-trigerring suspend. Let me know if this is not the case.
Quoted 6 lines
No, we generally don't use opportunistic suspend (e.g. unlike android) so the laptop will not suspend again.
So this is an actual bug affecting, for example, the Lenovo ThinkPad X13s.
Thanks for the clarification. I was thinking in android perspective only. But if we don't wake up the system upon disconnect, wouldn't the controller still be under the assumption that device is connected when it is actually not and only realise this when we resume later ?
Quoted 11 lines
Quoted 3 lines
Also, the warning you are mentioning in [1] comes because this is a laptop form factor and we have some firmware running (I don't know much about ACPI and stuff) ?
No, the "firmware" in this case is just the devicetree which has the DP/DM interrupts defined as edge-triggered while the driver requests them as level triggered.
(It would look similar with ACPI firmware which also has these declared as edge triggered.)
Got it. Thanks for the clarification.
Regards,
Krishna,
Quoted 9 lines · Krishna Kurapati PSSNV
Quoted 9 lines
Quoted 5 lines
Just one query. Even if it wakes up after closing the lid and removing
the mouse, wouldn't pm suspend be triggered again later by the system once it sees that usb is also good to be suspended again ? I presume a laptop form factor would be having this facility of re-trigerring suspend. Let me know if this is not the case.No, we generally don't use opportunistic suspend (e.g. unlike android) so the laptop will not suspend again.
Quoted 7 lines
Quoted 2 lines
So this is an actual bug affecting, for example, the Lenovo ThinkPad X13s.
Thanks for the clarification. I was thinking in android perspective only. But if we don't wake up the system upon disconnect, wouldn't the controller still be under the assumption that device is connected when it is actually not and only realise this when we resume later ?
Correct.
Johan
PATCH 3/3 USB: dwc3: qcom: simplify wakeup interrupt setup
In reply to Johan HovoldUse the IRQF_NO_AUTOEN irq flag when requesting the wakeup interrupts instead of setting it separately.
No functional change intended.
--- drivers/usb/dwc3/dwc3-qcom.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)
drivers/usb/dwc3/dwc3-qcom.c +4 -8
@@ -546,10 +546,9 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev) pdata ? pdata->hs_phy_irq_index : -1);if (irq >0 ) {/* Keep wakeup interrupts disabled until suspend */ -irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_ONESHOT , +IRQF_ONESHOT |IRQF_NO_AUTOEN ,"qcom_dwc3 HS" , qcom);if (ret) {dev_err (qcom->dev,"hs_phy_irq failed: %d\n" , ret);
@@ -561,10 +560,9 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev) irq =dwc3_qcom_get_irq (pdev,"dp_hs_phy_irq" , pdata ? pdata->dp_hs_phy_irq_index :-1 );if (irq >0 ) { -irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_ONESHOT , +IRQF_ONESHOT |IRQF_NO_AUTOEN ,"qcom_dwc3 DP_HS" , qcom);if (ret) {dev_err (qcom->dev,"dp_hs_phy_irq failed: %d\n" , ret);
@@ -576,10 +574,9 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev) irq =dwc3_qcom_get_irq (pdev,"dm_hs_phy_irq" , pdata ? pdata->dm_hs_phy_irq_index :-1 );if (irq >0 ) { -irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_ONESHOT , +IRQF_ONESHOT |IRQF_NO_AUTOEN ,"qcom_dwc3 DM_HS" , qcom);if (ret) {dev_err (qcom->dev,"dm_hs_phy_irq failed: %d\n" , ret);
@@ -591,10 +588,9 @@ static int dwc3_qcom_setup_irq(struct platform_device *pdev) irq =dwc3_qcom_get_irq (pdev,"ss_phy_irq" , pdata ? pdata->ss_phy_irq_index :-1 );if (irq >0 ) { -irq_set_status_flags (irq,IRQ_NOAUTOEN ); ret =devm_request_threaded_irq (qcom->dev, irq,NULL , qcom_dwc3_resume_irq, -IRQF_ONESHOT , +IRQF_ONESHOT |IRQF_NO_AUTOEN ,"qcom_dwc3 SS" , qcom);if (ret) {dev_err (qcom->dev,"ss_phy_irq failed: %d\n" , ret);
Signature · 1 line
2.41.0
Quoted 15 lines · Johan Hovold
When testing a recent series that addresses resource leaks on probe deferral [1] I realised that probe deferral can break wakeup from suspend due to how the wakeup interrupts are currently requested.
I'll send a separate series for the Qualcomm devicetrees that used incorrect trigger types for the wakeup interrupts. Included here is just a patch fixing the binding example which hopefully will make it less likely that more of these gets introduced. Fortunately, there should be no dependency between this series and the devicetree one.
Note also that I decided to include a related trivial cleanup patch.
Johan
Quoted 7 lines
[1] https://lore.kernel.org/lkml/[email protected]/
Johan Hovold (3):
dt-bindings: usb: qcom,dwc3: fix example wakeup interrupt types
USB: dwc3: qcom: fix wakeup after probe deferral
USB: dwc3: qcom: simplify wakeup interrupt setup
For the series:
Quoted 9 lines
Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 4 ++-- drivers/usb/dwc3/dwc3-qcom.c | 12 ++++-------- 2 files changed, 6 insertions(+), 10 deletions(-)Signature · 1 line
2.41.0