[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200618165151.GE4525@google.com>
Date: Thu, 18 Jun 2020 09:51:51 -0700
From: Matthias Kaehlcke <mka@...omium.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Sandeep Maheswaram <sanm@...eaurora.org>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Felipe Balbi <balbi@...nel.org>,
Stephen Boyd <swboyd@...omium.org>,
Doug Anderson <dianders@...omium.org>, rafael@...nel.org,
linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, Manu Gautam <mgautam@...eaurora.org>
Subject: Re: [PATCH] driver core:Export the symbol device_is_bound
On Thu, Jun 18, 2020 at 05:58:20PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jun 18, 2020 at 08:45:55AM -0700, Matthias Kaehlcke wrote:
> > Hi Greg,
> >
> > On Thu, Jun 18, 2020 at 10:14:43AM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Jun 03, 2020 at 12:09:52AM +0530, Sandeep Maheswaram wrote:
> > > > Export the symbol device_is_bound so that it can be used by the modules.
> > >
> > > What modules need this?
> >
> > drivers/usb/dwc3/dwc3-qcom.c (and probably other dwc3 'wrappers').
>
> Why wasn't that said here? No context is not good :(
Agreed, this patch should probably have been part of a series to establish
the context.
> > Short summary: QCOM dwc3 support is split in two drivers, the core dwc3
> > driver and the QCOM specific parts. dwc3-qcom is probed first (through
> > a DT entry or ACPI), dwc3_qcom_probe() then calls of_platform_populate()
> > to probe the core part. After a successful return from _populate() the
> > driver assumes that the core device is fully initialized. However the
> > latter is not correct, the driver core doesn't propagate errors from
> > probe() to platform_populate(). The dwc3-qcom driver would use
> > device_is_bound() to make sure the core device was probed successfully.
>
> why does the dwc3-qcom driver care?
Currently the dwc3-qcom driver uses the core device to determine if the
controller is used in peripheral mode and it runtime resumes the XHCI
device when it sees a wakeup interrupt.
The WIP patch to add interconnect support relies on the core driver
to determine the max speed of the controller.
> And why is the driver split in a way that requires such "broken"
> structures? Why can't that be fixed instead?
It seems determining the mode could be easily changed by getting it through
the pdev, as in st_dwc3_probe(). Not sure about the other two parts,
determining the maximum speed can involve evaluating hardware registers,
which currently are 'owned' by the core driver.
Manu or Sandeep who know the hardware and the driver better than me might
have ideas on how to improve things.
Powered by blists - more mailing lists