Thread (74 messages) 74 messages, 6 authors, 2023-08-12

Re: [PATCH v8 3/9] usb: dwc3: core: Access XHCI address space temporarily to read port info

From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Date: 2023-05-17 23:22:22
Also in: linux-arm-msm, linux-usb, lkml

On Wed, May 17, 2023, Johan Hovold wrote:
On Wed, May 17, 2023 at 03:21:24AM +0000, Thinh Nguyen wrote:
quoted
On Wed, May 17, 2023, Krishna Kurapati PSSNV wrote:
quoted
On 5/16/2023 8:32 PM, Krishna Kurapati PSSNV wrote:
quoted
On 5/16/2023 5:41 PM, Johan Hovold wrote:
quoted
quoted
quoted
quoted
You should not make another copy of xhci_find_next_ext_cap(), but rather
use it directly.

We already have drivers outside of usb/host using this function so it
should be fine to do the same for now:

    #include "../host/xhci-ext-caps.h"
quoted
quoted
quoted
   This was the approach which we followed when we first introduced the
patch [1]. But Thinh suggested to duplicate code so that we can avoid
any dependency on xhci (which seems to be right). So since its just one
function, I duplicated it here.
quoted
quoted
  Would like to know your opinion here on how to proceed further.
quoted
Please keep them separated. The xhci-ext-caps.h is for xhci driver only.
It's not meant to be exposed to other drivers. Same with other *.h files
under drivers/usb/host.
As I mentioned earlier, it is already used by the xdbc earlyprintk
driver which lives outside of drivers/usb/host, even if such a debug
driver could be considered a special case.

If it turns out that there's no way to avoid mapping those registers
from the qcom glue driver, then I think at least the register defines
need to be provided in a global header rather than being copied
verbatim.
It would be good to properly define the global header with common
offset/interface that can be public for other drivers.
But hopefully that can be avoided too as the xhci driver already parses
these registers and stores the port information, even if accessing that
data may require a bit more work currently.
Not many drivers outside of xhci should care about its registers except
for some special cases. Even for those special cases, only a small
subset of xhci registers are used. So we may not need a global header
for that.

What we may need is a global header that holds all the xhci
quirks/configs with defined interface for drivers outside of xhci can
use and pass those configs to xhci (such as from dwc3). This requires
some work.

Thanks,
Thinh
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help