Message-ID: <ZVx1wRefjNaN0byk@hovoldconsulting.com>
Date:   Tue, 21 Nov 2023 10:17:53 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Andrew Halaney <ahalaney@...hat.com>
Cc:     Johan Hovold <johan+linaro@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Wesley Cheng <quic_wcheng@...cinc.com>,
        Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>,
        linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org
Subject: Re: [PATCH 2/3] USB: dwc3: qcom: fix wakeup after probe deferral

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@...0000!
> > > 	irq: type mismatch, failed to map hwirq-15 for interrupt-controller@...0000!
> > > 
> > > 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.

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

Powered by blists - more mailing lists