From: Alan Stern <stern@rowland.harvard.edu>
To: Eugene Korenevsky <ekorenevsky@astralinux.ru>
Cc: linux-usb@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v3] ehci: fix EHCI host controller initialization sequence
Date: Sun, 10 Jan 2021 11:44:04 -0500 [thread overview]
Message-ID: <20210110164404.GB1161376@rowland.harvard.edu> (raw)
In-Reply-To: <20210110073737.GA10541@himera.home>
On Sun, Jan 10, 2021 at 10:37:37AM +0300, Eugene Korenevsky wrote:
> > > - ehci_readl(ehci, &ehci->regs->command); /* unblock posted writes */
>
> > You should not remove the ehci_readl call above. With that line gone,
> > the PCI bus might not send the new value of configured_flag to the
> > controller until after the 5-ms sleep has ended, which makes the msleep
> > useless.
>
> Could not find reads from USBCMD in similar drivers (for
> example here: https://github.com/NetBSD/src/blob/trunk/sys/dev/usb/ehci.c#L625).
I don't know why NetBSD doesn't do this. However, note that the
following poll loop does a read every millisecond, so the first time
through the loop, the earlier writes will be unblocked.
> Is this feature (reading from USBCMD for unblocking posted writes)
> documented anywhere or it is found empirically?
USBCMD is nothing special; it's just a convenient register to read. Any
other register in the controller would do just as well.
This is part of the PCI spec. Writes are posted (meaning they aren't
delivered to the device right away), but a read will cause all
previously posted writes for any address on the same device to be
delivered before the read finishes.
Alan Stern
prev parent reply other threads:[~2021-01-10 16:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-09 18:18 [PATCH v3] ehci: fix EHCI host controller initialization sequence Eugene Korenevsky
2021-01-09 21:04 ` Alan Stern
2021-01-10 7:37 ` Eugene Korenevsky
2021-01-10 16:44 ` Alan Stern [this message]
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=20210110164404.GB1161376@rowland.harvard.edu \
--to=stern@rowland.harvard.edu \
--cc=ekorenevsky@astralinux.ru \
--cc=gregkh@linuxfoundation.org \
--cc=linux-usb@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox