[PATCH v3 3/3] Revert "xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue"

This reverts commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7. Now that we can properly reset the uPD72020x without a hard PCI reset, let's get rid of the existing quirks. Tested-by: Domenico Andreoli <domenico.andre...@linux.com> Signed-off-by: Marc Zyngier <marc.zyng...@arm.com>

[PATCH v3 2/3] xhci: Add quirk to zero 64bit registers on Renesas PCIe controllers

that this is the case. Can you say "broken"? This is an alternative method to the one introduced in 8466489ef5ba ("xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue"), which will subsequently be removed. Tested-by: Domenico Andreoli <domenico.andre...@linux.com> S

[PATCH v3 1/3] xhci: Allow more than 32 quirks

_ULL(x). Tested-by: Domenico Andreoli <domenico.andre...@linux.com> Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- drivers/usb/host/xhci.c | 6 ++--- drivers/usb/host/xhci.h | 66 - 2 files changed, 36 insertions(+), 36 deleti

[PATCH v3 0/3] Revised Renesas uPD72020x workaround for 32bit DMA issue

: - Moved zeroing code to its own function - Also perform the zeroing on hibernate Marc Zyngier (3): xhci: Allow more than 32 quirks xhci: Add quirk to zero 64bit registers on Renesas PCIe controllers Revert "xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue" d

Re: [PATCH v2 2/3] xhci: Add quirk to zero 64bit registers on Renesas PCIe controllers

On 21/05/18 09:23, Mathias Nyman wrote: > On 18.05.2018 19:29, Marc Zyngier wrote: >> Some Renesas controllers get into a weird state if they are reset while >> programmed with 64bit addresses (they will preserve the top half of the >> address in internal, non visible registe

[PATCH v2 2/3] xhci: Add quirk to zero 64bit registers on Renesas PCIe controllers

that this is the case. Can you say "broken"? This is an alternative method to the one introduced in 8466489ef5ba ("xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue"), which will subsequently be removed. Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- d

[PATCH v2 3/3] Revert "xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue"

This reverts commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7. Now that we can properly reset the uPD72020x without a hard PCI reset, let's get rid of the existing quirks. Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- drivers/usb/host/pci-quirks.c | 20 drive

[PATCH v2 1/3] xhci: Allow more than 32 quirks

_ULL(x). Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- drivers/usb/host/xhci.c | 6 ++--- drivers/usb/host/xhci.h | 66 - 2 files changed, 36 insertions(+), 36 deletions(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/

[PATCH v2 0/3] Revised Renesas uPD72020x workaround for 32bit DMA issue

will be effective. It must be noted that in the absence of an IOMMU (and maybe even in its presence), this device is completely unsafe, and may silently corrupt memory. * From v1: - Fixed stupid hunk misplacement, now properly moved back to patch 2 - Converted all quirks to BIT_ULL() Marc Zyngier

Re: [PATCH 3/3] Revert "xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue"

On 17/05/18 14:29, Greg KH wrote: > On Thu, May 17, 2018 at 01:58:36PM +0100, Marc Zyngier wrote: >> This reverts commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7. >> >> Now that we can properly reset the uPD72020x without a hard PCI reset, >> let's get rid of the existi

Re: [PATCH 1/3] xhci: Allow more than 32 quirks

On 17/05/18 14:28, Greg KH wrote: > On Thu, May 17, 2018 at 01:58:34PM +0100, Marc Zyngier wrote: >> We now have 32 different quirks, and the field that holds them >> is full. Let's bump it up to the next stage so that we can handle >> some more... The type is now an unsi

[PATCH 2/3] xhci: Add quirk to zero 64bit registers on Renesas PCIe controllers

that this is the case. Can you say "broken"? This is an alternative method to the one introduced in 8466489ef5ba ("xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue"), which will subsequently be removed. Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- d

[PATCH 0/3] Revised Renesas uPD72020x workaround for 32bit DMA issue

will be effective. It must be noted that in the absence of an IOMMU (and maybe even in its presence), this device is completely unsafe, and may silently corrupt memory. Marc Zyngier (3): xhci: Allow more than 32 quirks xhci: Add quirk to zero 64bit registers on Renesas PCIe controllers

[PATCH 3/3] Revert "xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue"

This reverts commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7. Now that we can properly reset the uPD72020x without a hard PCI reset, let's get rid of the existing quirks. Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- drivers/usb/host/pci-quirks.c | 20 drive

[PATCH 1/3] xhci: Allow more than 32 quirks

We now have 32 different quirks, and the field that holds them is full. Let's bump it up to the next stage so that we can handle some more... The type is now an unsigned long long, which is 64bit on most architectures. Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- drivers/us

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

On Mon, 07 May 2018 06:00:56 +0100, Bockholdt Arne wrote: > > > > On Thu, 2018-05-03 at 10:41 +0100, Marc Zyngier wrote: > > I'm talking about making the whole workaround dependent on the USB > > controller being behind an iommu. No iommu, no workaround (beca

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

On 03/05/18 11:41, Ard Biesheuvel wrote: > On 3 May 2018 at 11:41, Marc Zyngier <marc.zyng...@arm.com> wrote: >> On 03/05/18 09:42, Faiz Abbas wrote: >>> Hi Marc, >>> >>> On Thursday 03 May 2018 01:44 PM, Marc Zyngier wrote: >>>>

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

On 03/05/18 09:42, Faiz Abbas wrote: > Hi Marc, > > On Thursday 03 May 2018 01:44 PM, Marc Zyngier wrote: >> On 03/05/18 05:49, Faiz Abbas wrote: >>> Hi Everyone, >>> >>> On Wednesday 11 April 2018 07:32 PM, Marc Zyngier wrote: >>>> On Wed,

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

On 03/05/18 05:49, Faiz Abbas wrote: > Hi Everyone, > > On Wednesday 11 April 2018 07:32 PM, Marc Zyngier wrote: >> On Wed, 11 Apr 2018 14:11:52 +0100, >> Bockholdt Arne wrote: >>> >>> Hi all, >>> >>> is there anything new, I've just

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

On Wed, 11 Apr 2018 14:11:52 +0100, Bockholdt Arne wrote: > > Hi all, > > is there anything new, I've just tried the new stable 4.16.1 kernel > without any change. The Renesys USB3 controller is still not > functional. I'm willing to test any patch that is based on a stable > kernel version

Re: [PATCH v3 2/2] net: usb: asix88179_178a: de-duplicate code

On Mon, 2 Apr 2018 07:43:49 + Alexander Kurz wrote: > Remove the duplicated code for asix88179_178a bind and reset methods. > > Signed-off-by: Alexander Kurz > --- > drivers/net/usb/ax88179_178a.c | 137 > ++--- > 1 file

Re: [PATCH v3 2/2] net: usb: asix88179_178a: de-duplicate code

[dropping Freddy as I'm getting bounces from asix.com.tw] On Mon, 2 Apr 2018 15:21:08 + Alexander Kurz wrote: Alexander, > Hi Marc, David, > with the v2 patch ("net: usb: asix88179_178a: de-duplicate code") > I made an embarrasly stupid mistake of removing the wrong

Re: [PATCH v3 2/2] net: usb: asix88179_178a: de-duplicate code

On Mon, 02 Apr 2018 08:43:49 +0100, Alexander Kurz wrote: Alexander, > > Remove the duplicated code for asix88179_178a bind and reset methods. > > Signed-off-by: Alexander Kurz > --- > drivers/net/usb/ax88179_178a.c | 137 > ++--- > 1 file

Re: [PATCH v2 2/2] net: usb: asix88179_178a: de-duplicate code

Alexander, David, On 2018-03-08 11:19, Alexander Kurz wrote: Remove the duplicated code for asix88179_178a bind and reset methods. Signed-off-by: Alexander Kurz --- drivers/net/usb/ax88179_178a.c | 117 +++-- 1 file changed, 31

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

On 25/03/18 15:39, Ard Biesheuvel wrote: > > >> On 25 Mar 2018, at 15:14, Marc Zyngier <marc.zyng...@arm.com> wrote: >> >> On Sun, 25 Mar 2018 14:26:58 +0100 >> Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >> >>>> On 25 Ma

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

On Sun, 25 Mar 2018 14:26:58 +0100 Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 25 March 2018 at 13:52, Marc Zyngier <marc.zyng...@arm.com> wrote: > > On Sun, 25 Mar 2018 13:38:19 +0100, > > Ard Biesheuvel wrote: > >> > >> On 25 March 2018

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

On Sun, 25 Mar 2018 13:38:19 +0100, Ard Biesheuvel wrote: > > On 25 March 2018 at 13:31, Marc Zyngier <marc.zyng...@arm.com> wrote: > > On Sun, 25 Mar 2018 12:57:55 +0100, > > Ard Biesheuvel wrote: > >> > >> On 25 March 2018 at 12:51, Marc Zyngier <m

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

On Sun, 25 Mar 2018 12:57:55 +0100, Ard Biesheuvel wrote: > > On 25 March 2018 at 12:51, Marc Zyngier <marc.zyng...@arm.com> wrote: > > On Sun, 25 Mar 2018 11:48:35 +0100, > > Ard Biesheuvel wrote: > > > > Hi Ard, > > > > [...] > > > &g

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

On Sun, 25 Mar 2018 11:48:35 +0100, Ard Biesheuvel wrote: Hi Ard, [...] > > I finally found some time to work on this, and came up with an > > alternative approach (it turns out that this chip is even more > > braindead than I thought). > > > > It is slightly scary, in the sense that the USB

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

On Fri, 02 Mar 2018 17:38:26 +, Bockholdt Arne wrote: Hi Arne, > > On Thu, 2018-03-01 at 17:37 +, Marc Zyngier wrote: > > On 01/03/18 08:01, Bockholdt Arne wrote: > > > > > > On Thu, 2018-02-15 at 19:29 +, Marc Zyngier wrote: > > > > [+ Ar

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

On 01/03/18 08:01, Bockholdt Arne wrote: > > On Thu, 2018-02-15 at 19:29 +, Marc Zyngier wrote: >> [+ Ard, who helped me chasing the initial issue] >> >> On 15/02/18 06:43, Bockholdt Arne wrote: >>> Hi all, >>> >>> on our Intel Atom C2578 ser

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

rrowed it > down to the following patch: > > commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 > Author: Marc Zyngier <marc.zyng...@arm.com <mailto:marc.zyng...@arm.com>> > Date:   Tue Aug 1 20:11:08 2017 -0500 > > xhci: Reset Renesas uPD72020x USB contro

Re: xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

On 05/01/18 02:09, Troy Kisky wrote: > On 12/29/2017 3:34 AM, Marc Zyngier wrote: >> On Wed, 27 Dec 2017 20:37:07 +, >> Troy Kisky wrote: >>> >>> On 12/27/2017 2:37 AM, Marc Zyngier wrote: >>>> On Tue, 26 Dec 2017 21:57:58 +, >>>>

Re: xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

On Wed, 27 Dec 2017 20:37:07 +, Troy Kisky wrote: > > On 12/27/2017 2:37 AM, Marc Zyngier wrote: > > On Tue, 26 Dec 2017 21:57:58 +, > > Troy Kisky wrote: > >> > >> On 12/26/2017 1:52 PM, Troy Kisky wrote: > >>> On 12/25/2017 2:10 AM, Marc

Re: xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

On Tue, 26 Dec 2017 21:57:58 +, Troy Kisky wrote: > > On 12/26/2017 1:52 PM, Troy Kisky wrote: > > On 12/25/2017 2:10 AM, Marc Zyngier wrote: > >> On Sun, 24 Dec 2017 23:01:33 +, > >> Troy Kisky wrote: > >>> > >>> commit 8466489ef5ba4

Re: xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue

On Sun, 24 Dec 2017 23:01:33 +, Troy Kisky wrote: > > commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 > Author: Marc Zyngier <marc.zyng...@arm.com> > Date: Tue Aug 1 20:11:08 2017 -0500 > > xhci: Reset Renesas uPD72020x USB control

Re: [PATCH v5 77/78] irqdomain: Convert to XArray

myself that the code under CONFIG_IRQ_DOMAIN_DEBUG is now completely superseded by CONFIG_GENERIC_IRQ_DEBUGFS, and that there would be more value in getting rid of it rather than keeping it on life support. Until then, the 1:1 replacement is good enough. Acked-by: Marc Zyngier <marc.zyng...@arm.com&

Re: [regression] Force hard reset of Renesas uPD72020x USB controller

On Mon, Sep 18 2017 at 3:01:32 pm BST, Albert Weichselbraun <alb...@weichselbraun.net> wrote: > On Mon, 2017-09-18 at 12:46 +0100, Marc Zyngier wrote: >> On 18/09/17 09:49, Albert Weichselbraun wrote: >> > Hi Marc, >> > >> > 100% ack >> > -

Re: [regression] Force hard reset of Renesas uPD72020x USB controller

On 18/09/17 09:49, Albert Weichselbraun wrote: > Hi Marc, > > 100% ack > - Booting with a kernel that does not do a PCI reset yields the > following topology: > > > -[:00] - > +-00.0 Intel Corporation 2nd Generation Core Processor Family DRAM > Controller > +-02.0 Intel

Re: [regression] Force hard reset of Renesas uPD72020x USB controller

Hi Albert, On 17/09/17 13:39, Albert Weichselbraun wrote: > Dear all, > > I ran into a regression with an ExpressCard/54 USB 3.0 expansion card > that uses the Renesas uPD72020x chipset on a Lenovo X220i Laptop (the > described behavior has been reproduced with kernel versions 4.12.8, > 4.12.13,

Re: [PATCH 0/2] Workaround for uPD72020x USB3 chips

On 13/07/17 12:36, Bjorn Helgaas wrote: > On Thu, Jul 13, 2017 at 08:46:45AM +0100, Marc Zyngier wrote: >> On 13/07/17 07:48, Ard Biesheuvel wrote: >>> On 13 July 2017 at 04:12, Bjorn Helgaas <helg...@kernel.org> wrote: >>>> On Mon, Jul 10, 2017 at 04:52:28PM

Re: [PATCH 0/2] Workaround for uPD72020x USB3 chips

On 13/07/17 07:48, Ard Biesheuvel wrote: > On 13 July 2017 at 04:12, Bjorn Helgaas <helg...@kernel.org> wrote: >> On Mon, Jul 10, 2017 at 04:52:28PM +0100, Marc Zyngier wrote: >>> Ard and myself have just spent quite some time lately trying to pin >>> down an issue

[PATCH 1/2] PCI: Implement pci_reset_function_locked

, which is the equivalent of pci_reset_function, except that it requires the PCI device lock to be already held by the caller. Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- drivers/pci/pci.c | 35 +++ include/linux/pci.h | 1 + 2 files chang

[PATCH 2/2] usb: host: pci_quirks: Force hard reset of Renesas uPD72020x USB controller

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.zyng...@arm.com> --- drivers/usb/host/pci-quirks.c | 20 drivers/usb/host/pci-quirks.h | 1 + drivers/usb/hos