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

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]

Message-ID: <20230517232147.4ds4rvvexwzqbzdx@synopsys.com>
Date:   Wed, 17 May 2023 23:21:50 +0000
From:   Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To:     Johan Hovold <johan@...nel.org>
CC:     Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Felipe Balbi <balbi@...nel.org>,
        "linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "quic_pkondeti@...cinc.com" <quic_pkondeti@...cinc.com>,
        "quic_ppratap@...cinc.com" <quic_ppratap@...cinc.com>,
        "quic_wcheng@...cinc.com" <quic_wcheng@...cinc.com>,
        "quic_jackp@...cinc.com" <quic_jackp@...cinc.com>,
        "quic_harshq@...cinc.com" <quic_harshq@...cinc.com>,
        "ahalaney@...hat.com" <ahalaney@...hat.com>
Subject: Re: [PATCH v8 3/9] usb: dwc3: core: Access XHCI address space
 temporarily to read port info

On Wed, May 17, 2023, Johan Hovold wrote:
> On Wed, May 17, 2023 at 03:21:24AM +0000, Thinh Nguyen wrote:
> > On Wed, May 17, 2023, Krishna Kurapati PSSNV wrote:
> > > On 5/16/2023 8:32 PM, Krishna Kurapati PSSNV wrote:
> > > > On 5/16/2023 5:41 PM, Johan Hovold wrote:
> 
> > > > > 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"
> 
> > > >    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.
> 
> > >   Would like to know your opinion here on how to proceed further.
> 
> > 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