[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YuvjrAUorQdC7U2k@hovoldconsulting.com>
Date: Thu, 4 Aug 2022 17:20:12 +0200
From: Johan Hovold <johan@...nel.org>
To: Krishna Kurapati <quic_kriskura@...cinc.com>
Cc: Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Konrad Dybcio <konrad.dybcio@...ainline.org>,
Felipe Balbi <balbi@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Randy Dunlap <rdunlap@...radead.org>,
linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] usb: dwc3: qcom: Provide stubs for
dwc3_qcom_read_usb2_speed function
On Tue, Aug 02, 2022 at 06:33:36PM +0200, Johan Hovold wrote:
> On Mon, Aug 01, 2022 at 12:30:15PM +0530, Krishna Kurapati wrote:
> > Dwc3 Qcom driver makes use of usb_hub_find_child API in its efforts
> > to get speed of connected devices (HS/LS/FS) and enable interrupts
> > accordingly.
>
> > usb_hub_find_child API is a part of usb core compiled
> > either into the kernel or as a module (CONFIG_USB= Y or M). In some
> > builds (make randconfig for i386) CONFIG_USB is not enabled and the
> > usb core is not compiled resulting in linking errors.
>
> Please replace the above with something more succinct. Whether USB core
> is built as a module or not is completely irrelevant. The problem is
> that the qcom dwc3 driver can be built and used without host support.
>
> > Provide stubs for dwc3_qcom_read_usb2_speed function to use
> > usb_hub_find_child API only if CONFIG_USB is enabled. Else return
> > USB_SPEED_UNKNOWN.
>
> The fact that you need to do this is an indication that something is
> wrong with the current implementation. The glue driver shouldn't be
> touching the host driver internal state directly like this.
>
> As pointed out here:
>
> https://lore.kernel.org/all/20220802151404.1797-4-johan+linaro@kernel.org/
>
> dwc3_qcom_read_usb2_speed() is indeed broken and currently triggers a
> NULL-pointer dereference when the controller is used in peripheral mode.
>
> But for now I guess something like this is needed even if we try to
> avoid stubs in implementation files.
This is how I think this should be fixed instead:
https://lore.kernel.org/all/20220804151001.23612-4-johan+linaro@kernel.org/
and which keeps the ifdeffery minimal. I included the patch in v2 of the
series that addresses the other problems with this code.
Johan
Powered by blists - more mailing lists