| Message ID | 20230618224656.2476-2-retpolanne@posteo.net |
|---|---|
| State | New |
| Headers | show |
| Series | usb: host: xhci: parameterize Renesas delay/retry | expand |
On Sun, Jun 18, 2023 at 10:46:57PM +0000, 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. No, a build-time option that affects all devices controlled by this driver is not how you handle this, sorry. Make this a dynamic value, either determined automatically by the device itself (as you know what device is being controlled), or worst case, a sysfs attribute that you can modify if things are not working properly. But a build-time option will never work, as it will never be changed, and it would not allow for multiple devices in the system that are different. thanks, greg k-h
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? 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). 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. (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?) Regards, Christian
On 19.06.2023 07:46, Greg Kroah-Hartman wrote: > On Sun, Jun 18, 2023 at 10:46:57PM +0000, 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. > > No, a build-time option that affects all devices controlled by this > driver is not how you handle this, sorry. Sorry, I completely forgot that other environments might have multiple cards. Mine only has one and I was focused on making it work. > > Make this a dynamic value, either determined automatically by the > device > itself (as you know what device is being controlled), or worst case, a > sysfs attribute that you can modify if things are not working properly. > I'll follow Christian's tip and check the uPD720202 user manual and see if there's something I can look for in order to make this value dynamic. > But a build-time option will never work, as it will never be changed, > and it would not allow for multiple devices in the system that are > different. > > thanks, > > greg k-h
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. > > 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. > > (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? > > Regards, > Christian
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
On 21.06.2023 22:20, Christian Lamparter wrote: > 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)? It's the add-in pcie card, exactly the one that's available on Amazon. > > 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) > I do have a fast machine, but I believe the EEPROM chip might have gone wonky for sure. It was the first card I found on my local retailer for adding USB-C headers to my setup. >>> 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. ACK - I believe I saw this one as well. > >>> >>> (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). Will try that! > > 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. > I wrote a bpf program to trace the PCI read/write calls from this specific Renesas device [1]. On the manual you mentioned, there's a step on the firmware download where a register is changed when the firmware download finishes. On my bpftrace, I see that it takes a long while for it to actually change, so I'm not sure what could be the problem. I also wrote a patch for my dev environment to allow me to erase the ROM as needed [2], but it hangs for a long time as well until the timeout is reached. I *think* that the kernel module erases the ROM at some point when starting up and then polls if the ROM has been reset. I've been thinking about Greg's suggestion of setting this timeout dynamically, and I was taking a look at different ways to deal with waiting and timeouts on kernel modules. Do you think it's worth it to implement something like a better waiting logic for this module? I didn't find anything on the card and in the manual that could point me to a way of discovering how long to set the timeout on it. [1] https://github.com/retpolanne/kernel-workspace/blob/main/bpf/renesas-pci-trace.bt [2] https://github.com/retpolanne/kernel-workspace/blob/main/patches/erase-rom.patch > Regards, > Christian
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index c170672f847e..8a255e3b0f03 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -51,6 +51,16 @@ config USB_XHCI_PCI_RENESAS installed on your system for this device to work. If unsure, say 'N'. +config USB_XHCI_PCI_RENESAS_DELAY + int "Renesas firmware download delay for setting DATAX" + depends on USB_XHCI_PCI_RENESAS + default 10 + +config USB_XHCI_PCI_RENESAS_RETRY + int "Renesas firmware download number of retries for setting DATAX" + depends on USB_XHCI_PCI_RENESAS + default 1000 + config USB_XHCI_PLATFORM tristate "Generic xHCI driver for a platform device" help diff --git a/drivers/usb/host/xhci-pci-renesas.c b/drivers/usb/host/xhci-pci-renesas.c index 93f8b355bc70..009f5878fe6f 100644 --- a/drivers/usb/host/xhci-pci-renesas.c +++ b/drivers/usb/host/xhci-pci-renesas.c @@ -47,9 +47,6 @@ #define RENESAS_ROM_ERASE_MAGIC 0x5A65726F #define RENESAS_ROM_WRITE_MAGIC 0x53524F4D -#define RENESAS_RETRY 10000 -#define RENESAS_DELAY 10 - static int renesas_fw_download_image(struct pci_dev *dev, const u32 *fw, size_t step, bool rom) { @@ -73,7 +70,7 @@ static int renesas_fw_download_image(struct pci_dev *dev, data0_or_data1 = (step & 1) == 1; /* step+1. Read "Set DATAX" and confirm it is cleared. */ - for (i = 0; i < RENESAS_RETRY; i++) { + for (i = 0; i < CONFIG_USB_XHCI_PCI_RENESAS_RETRY; i++) { err = pci_read_config_byte(dev, status_reg, &fw_status); if (err) { dev_err(&dev->dev, "Read Status failed: %d\n", @@ -83,9 +80,9 @@ static int renesas_fw_download_image(struct pci_dev *dev, if (!(fw_status & BIT(data0_or_data1))) break; - udelay(RENESAS_DELAY); + udelay(CONFIG_USB_XHCI_PCI_RENESAS_DELAY); } - if (i == RENESAS_RETRY) { + if (i == CONFIG_USB_XHCI_PCI_RENESAS_RETRY) { dev_err(&dev->dev, "Timeout for Set DATAX step: %zd\n", step); return -ETIMEDOUT; } @@ -321,7 +318,7 @@ static int renesas_fw_download(struct pci_dev *pdev, * "DATA0" or "DATA1". Naturally, we wait until "SET DATA0/1" * is cleared by the hardware beforehand. */ - for (i = 0; i < RENESAS_RETRY; i++) { + for (i = 0; i < CONFIG_USB_XHCI_PCI_RENESAS_RETRY; i++) { err = pci_read_config_byte(pdev, RENESAS_FW_STATUS_MSB, &fw_status); if (err) @@ -329,9 +326,9 @@ static int renesas_fw_download(struct pci_dev *pdev, if (!(fw_status & (BIT(0) | BIT(1)))) break; - udelay(RENESAS_DELAY); + udelay(CONFIG_USB_XHCI_PCI_RENESAS_DELAY); } - if (i == RENESAS_RETRY) + if (i == CONFIG_USB_XHCI_PCI_RENESAS_RETRY) dev_warn(&pdev->dev, "Final Firmware Download step timed out."); /* @@ -343,16 +340,16 @@ static int renesas_fw_download(struct pci_dev *pdev, return pcibios_err_to_errno(err); /* 12. Read "Result Code" and confirm it is good. */ - for (i = 0; i < RENESAS_RETRY; i++) { + for (i = 0; i < CONFIG_USB_XHCI_PCI_RENESAS_RETRY; i++) { err = pci_read_config_byte(pdev, RENESAS_FW_STATUS, &fw_status); if (err) return pcibios_err_to_errno(err); if (fw_status & RENESAS_FW_STATUS_SUCCESS) break; - udelay(RENESAS_DELAY); + udelay(CONFIG_USB_XHCI_PCI_RENESAS_DELAY); } - if (i == RENESAS_RETRY) { + if (i == CONFIG_USB_XHCI_PCI_RENESAS_RETRY) { /* Timed out / Error - let's see if we can fix this */ err = renesas_fw_check_running(pdev); switch (err) { @@ -405,17 +402,17 @@ static void renesas_rom_erase(struct pci_dev *pdev) /* sleep a bit while ROM is erased */ msleep(20); - for (i = 0; i < RENESAS_RETRY; i++) { + for (i = 0; i < CONFIG_USB_XHCI_PCI_RENESAS_RETRY; i++) { retval = pci_read_config_byte(pdev, RENESAS_ROM_STATUS, &status); status &= RENESAS_ROM_STATUS_ERASE; if (!status) break; - mdelay(RENESAS_DELAY); + mdelay(CONFIG_USB_XHCI_PCI_RENESAS_DELAY); } - if (i == RENESAS_RETRY) + if (i == CONFIG_USB_XHCI_PCI_RENESAS_RETRY) dev_dbg(&pdev->dev, "Chip erase timedout: %x\n", status); dev_dbg(&pdev->dev, "ROM Erase... Done success\n"); @@ -464,7 +461,7 @@ static bool renesas_setup_rom(struct pci_dev *pdev, const struct firmware *fw) /* * wait till DATA0/1 is cleared */ - for (i = 0; i < RENESAS_RETRY; i++) { + for (i = 0; i < CONFIG_USB_XHCI_PCI_RENESAS_RETRY; i++) { err = pci_read_config_byte(pdev, RENESAS_ROM_STATUS_MSB, &status); if (err) @@ -472,9 +469,9 @@ static bool renesas_setup_rom(struct pci_dev *pdev, const struct firmware *fw) if (!(status & (BIT(0) | BIT(1)))) break; - udelay(RENESAS_DELAY); + udelay(CONFIG_USB_XHCI_PCI_RENESAS_DELAY); } - if (i == RENESAS_RETRY) { + if (i == CONFIG_USB_XHCI_PCI_RENESAS_RETRY) { dev_err(&pdev->dev, "Final Firmware ROM Download step timed out\n"); goto remove_bypass; } @@ -487,7 +484,7 @@ static bool renesas_setup_rom(struct pci_dev *pdev, const struct firmware *fw) udelay(10); /* 18. check result */ - for (i = 0; i < RENESAS_RETRY; i++) { + for (i = 0; i < CONFIG_USB_XHCI_PCI_RENESAS_RETRY; i++) { err = pci_read_config_byte(pdev, RENESAS_ROM_STATUS, &status); if (err) { dev_err(&pdev->dev, "Read ROM status failed:%d\n", @@ -499,9 +496,9 @@ static bool renesas_setup_rom(struct pci_dev *pdev, const struct firmware *fw) dev_dbg(&pdev->dev, "Download ROM success\n"); break; } - udelay(RENESAS_DELAY); + udelay(CONFIG_USB_XHCI_PCI_RENESAS_DELAY); } - if (i == RENESAS_RETRY) { /* Timed out */ + if (i == CONFIG_USB_XHCI_PCI_RENESAS_RETRY) { /* Timed out */ dev_err(&pdev->dev, "Download to external ROM TO: %x\n", status); return false; @@ -521,16 +518,16 @@ static bool renesas_setup_rom(struct pci_dev *pdev, const struct firmware *fw) /* * wait till Reload is cleared */ - for (i = 0; i < RENESAS_RETRY; i++) { + for (i = 0; i < CONFIG_USB_XHCI_PCI_RENESAS_RETRY; i++) { err = pci_read_config_byte(pdev, RENESAS_ROM_STATUS, &status); if (err) return false; if (!(status & RENESAS_ROM_STATUS_RELOAD)) break; - udelay(RENESAS_DELAY); + udelay(CONFIG_USB_XHCI_PCI_RENESAS_DELAY); } - if (i == RENESAS_RETRY) { + if (i == CONFIG_USB_XHCI_PCI_RENESAS_RETRY) { dev_err(&pdev->dev, "ROM Exec timed out: %x\n", status); return false; }
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/ Signed-off-by: Anne Macedo <retpolanne@posteo.net> --- drivers/usb/host/Kconfig | 10 +++++++ drivers/usb/host/xhci-pci-renesas.c | 45 ++++++++++++++--------------- 2 files changed, 31 insertions(+), 24 deletions(-)