linux-kernel - Re: [PATCH v2 3/9] usb: dwc3: qcom: fix gadget-only builds

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 8 Aug 2022 15:34:10 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Johan Hovold <johan+linaro@...nel.org>,
        Felipe Balbi <balbi@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Krishna Kurapati <quic_kriskura@...cinc.com>,
        Stephen Boyd <swboyd@...omium.org>,
        Doug Anderson <dianders@...omium.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        Pavankumar Kondeti <quic_pkondeti@...cinc.com>,
        quic_ppratap@...cinc.com, quic_vpulyala@...cinc.com,
        linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v2 3/9] usb: dwc3: qcom: fix gadget-only builds

On Mon, Aug 08, 2022 at 03:05:36PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 04, 2022 at 05:09:55PM +0200, Johan Hovold wrote:
> > A recent change added a dependency to the USB host stack and broke
> > gadget-only builds of the driver.
> > 
> > Fixes: 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup interrupts during suspend")
> > Reported-by: Randy Dunlap <rdunlap@...radead.org>
> > Signed-off-by: Johan Hovold <johan+linaro@...nel.org>
> > ---
> > 
> > Changes in v2
> >  - new patch
> > 
> >  drivers/usb/dwc3/dwc3-qcom.c | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> > index be2e3dd36440..e9364141661b 100644
> > --- a/drivers/usb/dwc3/dwc3-qcom.c
> > +++ b/drivers/usb/dwc3/dwc3-qcom.c
> > @@ -310,8 +310,11 @@ static enum usb_device_speed dwc3_qcom_read_usb2_speed(struct dwc3_qcom *qcom)
> >  	 * currently supports only 1 port per controller. So
> >  	 * this is sufficient.
> >  	 */
> > +#ifdef CONFIG_USB
> >  	udev = usb_hub_find_child(hcd->self.root_hub, 1);
> 
> If a gadget driver needs this for some reason, then the #ifdef should be
> put in a .h file, not in a .c file.

Yeah, if we're keeping this long-term then yes, and possibly also
otherwise.

> But step back a minute and ask why a host-config-only function is being
> called when a device is in gadget-only mode?  This feels like a
> design/logic issue in this file, NOT something to paper over with a
> #ifdef in a .c file

We're not as I'm fixing that bug in later in the series. I should
probably have put this one after that fix, but figured fixing the build
was more important than a harder-to-hit NULL-deref due to non-host mode
not being considered when the offending series was merged.

> This implies that if this device is NOT in a host configuration, then
> the suspend path of it is not configured properly at all, as why would
> it be checking or caring about this at all if this is in gadget-only
> mode?

Right, so see path 6/9 which addresses this by only calling this hack
when in host mode:

	https://lore.kernel.org/all/20220804151001.23612-7-johan+linaro@kernel.org/

> Something else is wrong here, let's fix the root problem please.  Maybe
> this driver should just never be built in gadget-only mode, as it is
> never intended to support that option?

The problem is commit 6895ea55c385 ("usb: dwc3: qcom: Configure wakeup
interrupts during suspend"), which I considered simply reverting but as
that breaks suspend completely on some boards I decided to try and fix
it up while we work on a proper long-term solution (i.e. for how the
dwc/xhci layers should be communicating to implement this).

Remember that it took two years and 21 revisions to get to the state
we're at now after you merged the wakeup series in June.

Johan