From: Mathias Nyman <mathias.nyman@intel.com>
To: Marc Zyngier <marc.zyngier@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH 2/2] usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB controller
Date: Mon, 17 Jul 2017 15:02:58 +0300 [thread overview]
Message-ID: <596CA772.2010603@intel.com> (raw)
In-Reply-To: <20170710155230.8622-3-marc.zyngier@arm.com>
On 10.07.2017 18:52, Marc Zyngier wrote:
> The Renesas uPD72020x XHCI controller seems to suffer from a
> really annoying bug, where it may retain some of its DMA programming
> across a XHCI reset, and despite the driver correctly programming new
> DMA addresses. This is visible if the device has been using 64bit DMA
> addresses, and is then switched to using 32bit DMA addresses. The top
> 32bits of the address (now zero) are ignored are replaced by the 32bit
> from the *previous* programming. Sticking with 64bit DMA always works,
> but doesn't seem very appropriate.
>
> A PCI reset of the device restores the normal functionnality, which
> is done at probe time. Unfortunately, this has to be done before
> any quirk has been discovered, hence the intrusive nature of the fix.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> drivers/usb/host/pci-quirks.c | 20 ++++++++++++++++++++
> drivers/usb/host/pci-quirks.h | 1 +
> drivers/usb/host/xhci-pci.c | 7 +++++++
> 3 files changed, 28 insertions(+)
>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
next prev parent reply other threads:[~2017-07-17 12:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-10 15:52 [PATCH 0/2] Workaround for uPD72020x USB3 chips Marc Zyngier
2017-07-10 15:52 ` [PATCH 1/2] PCI: Implement pci_reset_function_locked Marc Zyngier
2017-07-10 15:52 ` [PATCH 2/2] usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB controller Marc Zyngier
2017-07-17 12:02 ` Mathias Nyman [this message]
2017-07-10 17:21 ` [PATCH 0/2] Workaround for uPD72020x USB3 chips Ard Biesheuvel
2017-07-12 19:04 ` Ard Biesheuvel
2017-07-13 3:12 ` Bjorn Helgaas
2017-07-13 6:48 ` Ard Biesheuvel
2017-07-13 7:46 ` Marc Zyngier
2017-07-13 11:36 ` Bjorn Helgaas
2017-07-13 12:18 ` Marc Zyngier
2017-07-13 8:26 ` Greg Kroah-Hartman
2017-07-13 11:37 ` Bjorn Helgaas
2017-08-01 21:44 ` Bjorn Helgaas
2017-08-01 21:53 ` Ard Biesheuvel
2017-08-02 1:12 ` Bjorn Helgaas
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=596CA772.2010603@intel.com \
--to=mathias.nyman@intel.com \
--cc=ard.biesheuvel@linaro.org \
--cc=bhelgaas@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=marc.zyngier@arm.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.