linux-kernel - Re: [PATCH] usb: host: xhci: parameterize Renesas delay/retry

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: <03b73c54-5500-0b8b-c45e-b57320cc6bb8@gmail.com>
Date:   Wed, 21 Jun 2023 22:20:09 +0200
From:   Christian Lamparter <chunkeey@...il.com>
To:     Anne Macedo <retpolanne@...teo.net>
Cc:     Mathias Nyman <mathias.nyman@...el.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
        Vinod Koul <vkoul@...nel.org>, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: host: xhci: parameterize Renesas delay/retry

On 6/19/23 12:12, Anne Macedo wrote:
> On 19.06.2023 10:19, Christian Lamparter wrote:
>> On 6/19/23 00:46, Anne Macedo wrote:
>>> Cards based on Renesas uPD720202 have their firmware downloaded during
>>> boot by xhci-pci. At this step, the status of the firmware is read and
>>> it takes a while for this read to happen (up to a few seconds). The
>>> macros RENESAS_RETRY and RENESAS_DELAY are used to retry reading this
>>> status byte from PCI a few times. If it can't read the status byte in
>>> RENESAS_RETRY tries, it times out.
>>>
>>> However, since this may vary from card to card, these retry and delay
>>> values need to be tweaked. In order to avoid having to patch the code to
>>> change these values, CONFIG_USB_XHCI_PCI_RENESAS_RETRY and
>>> CONFIG_USB_XHCI_PCI_RENESAS_DELAY are introduced.
>>>
>>> If applied, this patch helps to fix errors such as:
>>>
>>> ROM Download Step 34 failed at position 136 bytes
>>> Firmware Download Step 2 failed at position 8 bytes with (-110)
>>>
>>> while loading xhci-pci when using these cards.
>>>
>>> This error in particular has been noticed by this e-mail [1].
>>>
>>> [1] https://lore.kernel.org/lkml/20190626070658.GP2962@vkoul-mobl/
>>
>> Can you tell me on what hardware (is it something older, with maybe
>> a Synopsys/Designware PCIe host controller?) do you experience these
>> errors and what delay+retry values are you configuring in order to
>> get your DUT up an running?
> 
> It's a PH61 Rev 1.2 board with the Renesas uPD720201 host controller.
> I'm using 10 as the delay and 6000 as the retry.

Oh? Is this an old MSI PH61 mainboard or is this an add-in pcie card
(found something on amazon with that name and rev too)?

If it's an add-in pcie card, could it be that the EEPROM chip on it
is (getting) a bit wonky? Or do you have a really fast machine?
(Latest crop of i7/i9 Alder/Raptor Lake or Ryzen 5000/7000 Series)

>> From what I can tell, the quoted [1] link to Vinod's mail was just
>> an update during development. This was v3 of the patch series back
>> then (and it went on to v10 I think, so this wasn't an issue with
>> what's in the kernel right now).
>>
> 
> I see. That was the only reference I found to the timeout error I was
> seeing, so that's why I decided to tweak these retry+delay values.
> 
>> Note: If you are interested I still got the "uPD720201/uPD720202 User's
>> Manual" back then from Renesas site. (Nowadays they want you to
>> register or something.). This document was the base for the code and
>> maybe there's something in there you can quote to extend the
>> retries/delays.
> 
> Definitely interested! I did find a .pdf on Google though, I can check it.

There's also Renesas loader code floating around on github.

>>
>> (From what I vaguely remember. Most of the transfer was fast and
>> no retries where necessary, but some register write took so long.
>> Vinod  also posted hints about a newer firmware for the
>> uPD720201/uPD720202. Have you tried that as well?)
> 
> I was using the upd72020x-fw AUR package on my Arch Linux build,
> if that's any relevant. However, it's quite old and I don't really know
> how it works. I missed these hints, sorry, could you point me to
> them?

Yes, I was talking about "K2026090.mem". I didn't know this version existed,
but Vinod knew about it:
https://patches.linaro.org/project/linux-arm-msm/patch/20200113084005.849071-5-vkoul@kernel.org/

Looking on google leads to startech.com and they have/had this as a product:
https://www.startech.com/en-de/cards-adapters/pciusb3s22

The K2026090.mem Firmware file is in the "[renesas upd72020x] firmware update.zip"
(see in the "RE202.A10" folder).

I don't know how it works with pcie cards that are supposed to have the firmware
stored on the EEPROM chip. In my case of the WNDR4700 - there is no extra chip and
the driver has to upload the firmware - I just have to put the file renamed as
renesas_usb_fw.mem into /lib/firmware/ and it works.

Regards,
Christian