linux-kernel - Re: [PATCH v6 0/5] usb: xhci: Add support for Renesas USB controllers

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:   Sun, 26 Jan 2020 14:07:42 +0100
From:   Christian Lamparter <chunkeey@...il.com>
To:     Andreas Böhler <dev@...ehler.at>
Cc:     Vinod Koul <vkoul@...nel.org>,
        Mathias Nyman <mathias.nyman@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-arm-msm@...r.kernel.org,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Christian Lamparter <chunkeey@...glemail.com>,
        linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 0/5] usb: xhci: Add support for Renesas USB controllers

On Sunday, 26 January 2020 01:11:35 CET Andreas Böhler wrote:
> 
> On 13/01/2020 09:40, Vinod Koul wrote:
> > This series add support for Renesas USB controllers uPD720201 and uPD720202.
> > These require firmware to be loaded and in case devices have ROM those can
> > also be programmed if empty. If ROM is programmed, it runs from ROM as well.
> > 
> > This includes two patches from Christian which supported these controllers
> > w/o ROM and later my patches for ROM support and multiple firmware versions,
> > debugfs hook for rom erase and export of xhci-pci functions.
> > 
> I tested this on an AVM FRITZ!Box 3490, backported to 4.19: Firmware
> upload works fine.
> 
> However, I'm seeing read errors afterwards which, I suppose, are a
> different story.
> 
> Here is the log:
> 
> [  498.115808] ifx_pcie_bios_map_irq port 0 dev 0000:01:00.0 slot 0 pin 1
> [  498.121154] ifx_pcie_bios_map_irq dev 0000:01:00.0 irq 144 assigned
> [  498.488541] renesas xhci 0000:01:00.0: xHCI Host Controller
> [  498.492820] renesas xhci 0000:01:00.0: new USB bus registered,
> assigned bus number 1
> [  498.506123] renesas xhci 0000:01:00.0: hcc params 0x014051cf hci
> version 0x100 quirks 0x0000000101000090
> [  498.516869] hub 1-0:1.0: USB hub found
> [  498.519631] hub 1-0:1.0: 2 ports detected
> [  498.525641] renesas xhci 0000:01:00.0: xHCI Host Controller
> [  498.530217] renesas xhci 0000:01:00.0: new USB bus registered,
> assigned bus number 2
> [  498.537846] renesas xhci 0000:01:00.0: Host supports USB 3.0 SuperSpeed
> [  498.545095] usb usb2: We don't know the algorithms for LPM for this
> host, disabling LPM.
> [  498.554921] hub 2-0:1.0: USB hub found
> [  498.557588] hub 2-0:1.0: 2 ports detected
> [  523.013361] usb 1-1: new full-speed USB device number 2 using renesas
> xhci
> [  523.182725] usb 1-1: no configurations
> [  523.185085] usb 1-1: can't read configurations, error -22
> [  523.317423] usb 1-1: new full-speed USB device number 3 using renesas
> xhci
> [  523.493710] usb 1-1: no configurations
> [  523.496069] usb 1-1: can't read configurations, error -22
> [  523.501951] usb usb1-port1: attempt power cycle
> 
Hm, I don't think lantiq's PCI code is upstream... And now that I've seen
more errors from your forum post at: 
<https://forum.openwrt.org/t/fix-xhci-errors-on-renesas-upd70202-fritz-box-3490/53620>

I wonder if this has something to do with a similar issue I was facing with
the ath9k chip loader in commit:
5a4f2040fd07 ("ath9k: add loader for AR92XX (and older) pci(e)")

which later needed a fix for a specifc lantiq byteswap problem in commit:
22d0d5ae7a08 ("ath9k: use iowrite32 over __raw_writel"):
|    This patch changes the ath9k_pci_owl_loader to use the
|    same iowrite32 memory accessor that ath9k_pci is using
|    to communicate with the PCI(e) chip.
|   
|   This will fix endian issues that came up during testing
|   with loaned AVM Fritz!Box 7360 (Lantiq MIPS SoCs + AR9287).


The reason was that apparently (I gave back the loaned device), the lantiq
PCI silicon does some sneaky byteswaps in special cases. Could this be
related? You mentioned in another post that AVM did changes to the xhci
driver, can you look if they added changes to the memory accessors?
Because this would explain why the APM82181 (PowerPC which is also a
BigEndian) had no issues (as it's using a entirely different pcie hardware
and code).

Cheers,
Christian