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
Signed-off-by: Marc Zyngier
---
drivers/usb/host/pci-quirks.c
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
Signed-off-by: Marc Zyngier
-
o BIT_ULL(x).
Tested-by: Domenico Andreoli
Signed-off-by: Marc Zyngier
---
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/
:
- 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
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
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
---
drivers/usb/host/xhci-pci.c
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
---
drivers/usb/host/pci-quirks.c | 20
drivers/usb/host/pci-quirks.h
o BIT_ULL(x).
Signed-off-by: Marc Zyngier
---
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/xhci.c
index 7
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
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 e
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 un
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
---
drivers/usb/host/xhci-pci.c
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
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
---
drivers/usb/host/pci-quirks.c | 20
drivers/usb/host/pci-quirks.h
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
---
drivers/usb/host/xhci.c | 6 +++---
dr
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 (because it
On 03/05/18 11:41, Ard Biesheuvel wrote:
> On 3 May 2018 at 11:41, Marc Zyngier wrote:
>> 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:
>
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,
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
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 becau
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 changed, 31 insertions(+), 106 d
[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 function.
> The v2 patch
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 changed, 31 inse
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 insertions(+), 86 deletions(-
On 25/03/18 15:39, Ard Biesheuvel wrote:
>
>
>> On 25 Mar 2018, at 15:14, Marc Zyngier wrote:
>>
>> On Sun, 25 Mar 2018 14:26:58 +0100
>> Ard Biesheuvel wrote:
>>
>>>> On 25 March 2018 at 13:52, Marc Zyngier wrote:
>>>> O
On Sun, 25 Mar 2018 14:26:58 +0100
Ard Biesheuvel wrote:
> On 25 March 2018 at 13:52, Marc Zyngier wrote:
> > On Sun, 25 Mar 2018 13:38:19 +0100,
> > Ard Biesheuvel wrote:
> >>
> >> On 25 March 2018 at 13:31, Marc Zyngier wrote:
> >> > O
On Sun, 25 Mar 2018 13:38:19 +0100,
Ard Biesheuvel wrote:
>
> On 25 March 2018 at 13:31, Marc Zyngier wrote:
> > On Sun, 25 Mar 2018 12:57:55 +0100,
> > Ard Biesheuvel wrote:
> >>
> >> On 25 March 2018 at 12:51, Marc Zyngier wrote:
> >> >
On Sun, 25 Mar 2018 12:57:55 +0100,
Ard Biesheuvel wrote:
>
> On 25 March 2018 at 12:51, Marc Zyngier wrote:
> > On Sun, 25 Mar 2018 11:48:35 +0100,
> > Ard Biesheuvel wrote:
> >
> > Hi Ard,
> >
> > [...]
> >
> >> > I
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 con
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
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
e same. I've narrowed it
> down to the following patch:
>
> commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7
> Author: Marc Zyngier mailto:marc.zyng...@arm.com>>
> Date: Tue Aug 1 20:11:08 2017 -0500
>
> xhci: Reset Renesas uPD72020x USB controller for 32-bit
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 +,
>>>>
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
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
On Sun, 24 Dec 2017 23:01:33 +,
Troy Kisky wrote:
>
> commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7
> Author: Marc Zyngier
> Date: Tue Aug 1 20:11:08 2017 -0500
>
> xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA issue
> ...
> ...
> ...
&g
ompletely 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
M.
--
To unsubscribe from this list: send the line "un
On Mon, Sep 18 2017 at 3:01:32 pm BST, Albert Weichselbraun
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
>> > - Booting with a kernel that does n
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 Corpor
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,
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 wrote:
>>>> On Mon, Jul 10, 2017 at 04:52:28PM +0100, Marc Zyngier wrote:
On 13/07/17 07:48, Ard Biesheuvel wrote:
> On 13 July 2017 at 04:12, Bjorn Helgaas 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 in the DMA code which wa
.
So far, the only solution we have for this lovely piece of kit is to
force a PCI reset at probe time, which puts it right. The patches are
pretty ugly, but that's the best I could come up with so far.
Tested on a pair of AMD Opteron 1100 boxes with Renesas uPD720201 and
uPD720202 controll
, 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
---
drivers/pci/pci.c | 35 +++
include/linux/pci.h | 1 +
2 files changed, 36 insertions(+)
diff --git a
ne 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
---
drivers/usb/host/pci-quirks.c | 20
drivers/usb/host/pci-quirks.h | 1 +
drivers/usb/host/xhci-pci.c | 7 +
45 matches
Mail list logo
