From: retpolanne@posteo.net
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mathias Nyman <mathias.nyman@intel.com>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
Vinod Koul <vkoul@kernel.org>,
Christian Lamparter <chunkeey@googlemail.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: host: xhci: parameterize Renesas delay/retry
Date: Mon, 19 Jun 2023 09:59:44 +0000 [thread overview]
Message-ID: <0627e991f2c446cd7e265188523607da@posteo.net> (raw)
In-Reply-To: <2023061951-taekwondo-unsoiled-faf2@gregkh>
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
next prev parent reply other threads:[~2023-06-19 10:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-18 22:46 [PATCH] usb: host: xhci: parameterize Renesas delay/retry Anne Macedo
2023-06-19 5:46 ` Greg Kroah-Hartman
2023-06-19 9:59 ` retpolanne [this message]
2023-06-19 8:19 ` Christian Lamparter
2023-06-19 10:12 ` Anne Macedo
2023-06-21 20:20 ` Christian Lamparter
2023-06-21 22:21 ` Anne Macedo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0627e991f2c446cd7e265188523607da@posteo.net \
--to=retpolanne@posteo.net \
--cc=chunkeey@googlemail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=vkoul@kernel.org \
--cc=yoshihiro.shimoda.uh@renesas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.