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!
Fix this by not overriding the firmware provided trigger types when requesting the wakeup interrupts.
Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Johan Hovold johan+linaro@kernel.org --- drivers/usb/dwc3/dwc3-qcom.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c index 10fb481d943b..82544374110b 100644 --- a/drivers/usb/dwc3/dwc3-qcom.c +++ b/drivers/usb/dwc3/dwc3-qcom.c @@ -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);
On Mon, Nov 20, 2023 at 05:16:06PM +0100, Johan Hovold wrote:
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!
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
Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Johan Hovold johan+linaro@kernel.org
drivers/usb/dwc3/dwc3-qcom.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c index 10fb481d943b..82544374110b 100644 --- a/drivers/usb/dwc3/dwc3-qcom.c +++ b/drivers/usb/dwc3/dwc3-qcom.c @@ -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);@@ -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);@@ -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);@@ -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);-- 2.41.0
On Mon, Nov 20, 2023 at 11:39:07AM -0600, Andrew Halaney wrote:
On Mon, Nov 20, 2023 at 05:16:06PM +0100, Johan Hovold wrote:
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!
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. */
Thanks, Andrew
Fixes: a4333c3a6ba9 ("usb: dwc3: Add Qualcomm DWC3 glue driver") Cc: stable@vger.kernel.org # 4.18 Signed-off-by: Johan Hovold johan+linaro@kernel.org
drivers/usb/dwc3/dwc3-qcom.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c index 10fb481d943b..82544374110b 100644 --- a/drivers/usb/dwc3/dwc3-qcom.c +++ b/drivers/usb/dwc3/dwc3-qcom.c @@ -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);@@ -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);@@ -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);@@ -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);-- 2.41.0
On Mon, Nov 20, 2023 at 02:50:52PM -0600, Andrew Halaney wrote:
On Mon, Nov 20, 2023 at 11:39:07AM -0600, Andrew Halaney wrote:
On Mon, Nov 20, 2023 at 05:16:06PM +0100, Johan Hovold wrote:
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!
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.
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.
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.
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.
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. */
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
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. */
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.
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/20231120161607.7405-3-johan+linaro@kernel.org/
Regards, Krishna,
On Tue, Nov 21, 2023 at 06:25:37PM +0530, Krishna Kurapati PSSNV wrote:
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.
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
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.
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 ?
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,
On Tue, Nov 21, 2023 at 07:38:18PM +0530, Krishna Kurapati PSSNV wrote:
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.
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
linux-stable-mirror@lists.linaro.org
-
Andrew Halaney -
Johan Hovold -
Johan Hovold -
Krishna Kurapati PSSNV