[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAD=FV=Vzf8H=+MAMA895Csb1aU9h6LR8afOut2WqdUvKjF7QgA@mail.gmail.com>
Date: Tue, 7 Dec 2021 09:46:01 -0800
From: Doug Anderson <dianders@...omium.org>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Stephen Boyd <swboyd@...omium.org>,
Felipe Balbi <balbi@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Sandeep Maheswaram <quic_c_sanm@...cinc.com>,
Wesley Cheng <quic_wcheng@...cinc.com>, robdclark@...omium.org,
linux-arm-msm@...r.kernel.org, Andy Gross <agross@...nel.org>,
Wesley Cheng <wcheng@...eaurora.org>,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH] usb: dwc3: dwc3-qcom: Avoid use-after-free when USB
defers or unbinds
Hi,
On Mon, Dec 6, 2021 at 6:32 PM Bjorn Andersson
<bjorn.andersson@...aro.org> wrote:
>
> On Mon 06 Dec 16:37 PST 2021, Stephen Boyd wrote:
> > Quoting Douglas Anderson (2021-12-06 15:28:47)
> [..]
> > > + goto node_put;
> > > + }
> > >
> > > - prop->name = "tx-fifo-resize";
> > > - ret = of_add_property(dwc3_np, prop);
> >
> > I don't understand why we can't tell dwc3 that we want to use
> > tx-fifo-resize without adding a DT property. DT isn't the only way we
> > could probe this qcom dwc3 device, there's also ACPI. And in dwc3 core
> > where we check for this property couldn't we add a compatible check for
> > qcom,dwc3 and then force the property? I see that a lot of this was
> > already discussed when these patches got applied by gregkh directly[1].
> >
>
> When the tx-fifo-resize property was introduced I made an effort to
> convince the people involved about the prospect of passing this
> information in the code, rather than using DT as some sort of parameter
> store to pass information between the devices.
>
> And I still would like us to come up with some sort of code-level
> mechanism for passing some state between dwc3-qcom and the dwc3-core,
> because I really want to register some callback with the core so that we
> don't need to duplicate extcon and usb_role_switch in both the core and
> platform glue.
>
> See this discussion:
> https://lore.kernel.org/linux-arm-msm/YSZCmDEedJaJyI0u@ripper/
>
> > Can we revert out this bad code instead?
> >
>
> You definitely have my vote for that!
Sure. I've posted a revert up, so either the revert or ${SUBJECT}
patch will fix the problem. For the revert, see:
https://lore.kernel.org/r/20211207094327.1.Ie3cde3443039342e2963262a4c3ac36dc2c08b30@changeid
-Doug
Powered by blists - more mailing lists