All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Robin Murphy <robin.murphy@arm.com>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	Jingoo Han <jingoohan1@gmail.com>,
	Will Deacon <will.deacon@arm.com>,
	Russell King <linux@armlinux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Sealey <neko@bakuhatsu.net>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: framebuffer corruption due to overlapping stp instructions on arm64
Date: Mon, 6 Aug 2018 15:54:33 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.1808061552090.11930@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <CAKv+Gu_8Rq6X24ZOYvG7+kQQGSGYAZuu_co4k1nJS8K7rkrWMA@mail.gmail.com>



On Mon, 6 Aug 2018, Ard Biesheuvel wrote:

> On 6 August 2018 at 19:09, Mikulas Patocka <mpatocka@redhat.com> wrote:
> >
> >
> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> >
> >> On 6 August 2018 at 14:42, Robin Murphy <robin.murphy@arm.com> wrote:
> >> > On 06/08/18 11:25, Mikulas Patocka wrote:
> >> > [...]
> >> >>>
> >> >>> None of this explains why some transactions fail to make it across
> >> >>> entirely. The overlapping writes in question write the same data to
> >> >>> the memory locations that are covered by both, and so the ordering in
> >> >>> which the transactions are received should not affect the outcome.
> >> >>
> >> >>
> >> >> You're right that the corruption couldn't be explained just by reordering
> >> >> writes. My hypothesis is that the PCIe controller tries to disambiguate
> >> >> the overlapping writes, but the disambiguation logic was not tested and it
> >> >> is buggy. If there's a barrier between the overlapping writes, the PCIe
> >> >> controller won't see any overlapping writes, so it won't trigger the
> >> >> faulty disambiguation logic and it works.
> >> >>
> >> >> Could the ARM engineers look if there's some chicken bit in Cortex-A72
> >> >> that could insert barriers between non-cached writes automatically?
> >> >
> >> >
> >> > I don't think there is, and even if there was I imagine it would have a
> >> > pretty hideous effect on non-coherent DMA buffers and the various other
> >> > places in which we have Normal-NC mappings of actual system RAM.
> >> >
> >>
> >> Looking at the A72 manual, there is one chicken bit that looks like it
> >> may be related:
> >>
> >> CPUACTLR_EL1 bit #50:
> >>
> >> 0 Enables store streaming on NC/GRE memory type. This is the reset value.
> >> 1 Disables store streaming on NC/GRE memory type.
> >>
> >> so putting something like
> >>
> >> mrs x0, S3_1_C15_C2_0
> >> orr x0, x0, #(1 << 50)
> >> msr S3_1_C15_C2_0, x0
> >>
> >> in __cpu_setup() would be worth a try.
> >
> > It won't boot.
> >
> > But if i write the same value that was read, it also won't boot.
> >
> > I created a simple kernel module that reads this register and it has bit
> > 32 set, all other bits clear. But when I write the same value into it, the
> > core that does the write is stuck in infinite loop.
> >
> > So, it seems that we are writing this register from a wrong place.
> >
> 
> Ah, my bad. I didn't look closely enough at the description:
> 
> """
> The accessibility to the CPUACTLR_EL1 by Exception level is:
> 
> EL0              -
> EL1(NS)          RW (a)
> EL1(S)           RW (a)
> EL2              RW (b)
> EL3(SCR.NS = 1)  RW
> EL3(SCR.NS = 0)  RW
> 
> (a) Write access if ACTLR_EL3.CPUACTLR is 1 and ACTLR_EL2.CPUACTLR is
> 1, or ACTLR_EL3.CPUACTLR is 1 and SCR.NS is 0.
> """
> 
> so you'll have to do this from ARM Trusted Firmware. If you're
> comfortable rebuilding that:
> 
> diff --git a/include/lib/cpus/aarch64/cortex_a72.h
> b/include/lib/cpus/aarch64/cortex_a72.h
> index bfd64918625b..a7b8cf4be0c6 100644
> --- a/include/lib/cpus/aarch64/cortex_a72.h
> +++ b/include/lib/cpus/aarch64/cortex_a72.h
> @@ -31,6 +31,7 @@
>  #define CORTEX_A72_ACTLR_EL1                   S3_1_C15_C2_0
> 
>  #define CORTEX_A72_ACTLR_DISABLE_L1_DCACHE_HW_PFTCH    (1 << 56)
> +#define CORTEX_A72_ACTLR_DIS_NC_GRE_STORE_STREAMING    (1 << 50)
>  #define CORTEX_A72_ACTLR_NO_ALLOC_WBWA         (1 << 49)
>  #define CORTEX_A72_ACTLR_DCC_AS_DCCI           (1 << 44)
>  #define CORTEX_A72_ACTLR_EL1_DIS_INSTR_PREFETCH                (1 << 32)
> diff --git a/lib/cpus/aarch64/cortex_a72.S b/lib/cpus/aarch64/cortex_a72.S
> index 55e508678284..5914d6ee3ba6 100644
> --- a/lib/cpus/aarch64/cortex_a72.S
> +++ b/lib/cpus/aarch64/cortex_a72.S
> @@ -133,6 +133,15 @@ func cortex_a72_reset_func
>         orr     x0, x0, #CORTEX_A72_ECTLR_SMP_BIT
>         msr     CORTEX_A72_ECTLR_EL1, x0
>         isb
> +
> +       /* ---------------------------------------------
> +        * Disables store streaming on NC/GRE memory type.
> +        * ---------------------------------------------
> +        */
> +       mrs     x0, CORTEX_A72_ACTLR_EL1
> +       orr     x0, x0, #CORTEX_A72_ACTLR_DIS_NC_GRE_STORE_STREAMING
> +       msr     CORTEX_A72_ACTLR_EL1, x0
> +       isb
>         ret x19
>  endfunc cortex_a72_reset_func

Unfortunatelly, it doesn't work. I verified that the bit is set after 
booting Linux, but the memcpy corruption was still present.

I also tried the other chicken bits, it slowed down the system noticeably, 
but had no effect on the memcpy corruption.

Mikulas

WARNING: multiple messages have this Message-ID (diff)
From: Mikulas Patocka <mpatocka@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-pci <linux-pci@vger.kernel.org>,
	Will Deacon <will.deacon@arm.com>,
	Russell King <linux@armlinux.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Matt Sealey <neko@bakuhatsu.net>,
	Jingoo Han <jingoohan1@gmail.com>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: framebuffer corruption due to overlapping stp instructions on arm64
Date: Mon, 6 Aug 2018 15:54:33 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.1808061552090.11930@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <CAKv+Gu_8Rq6X24ZOYvG7+kQQGSGYAZuu_co4k1nJS8K7rkrWMA@mail.gmail.com>



On Mon, 6 Aug 2018, Ard Biesheuvel wrote:

> On 6 August 2018 at 19:09, Mikulas Patocka <mpatocka@redhat.com> wrote:
> >
> >
> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> >
> >> On 6 August 2018 at 14:42, Robin Murphy <robin.murphy@arm.com> wrote:
> >> > On 06/08/18 11:25, Mikulas Patocka wrote:
> >> > [...]
> >> >>>
> >> >>> None of this explains why some transactions fail to make it across
> >> >>> entirely. The overlapping writes in question write the same data to
> >> >>> the memory locations that are covered by both, and so the ordering in
> >> >>> which the transactions are received should not affect the outcome.
> >> >>
> >> >>
> >> >> You're right that the corruption couldn't be explained just by reordering
> >> >> writes. My hypothesis is that the PCIe controller tries to disambiguate
> >> >> the overlapping writes, but the disambiguation logic was not tested and it
> >> >> is buggy. If there's a barrier between the overlapping writes, the PCIe
> >> >> controller won't see any overlapping writes, so it won't trigger the
> >> >> faulty disambiguation logic and it works.
> >> >>
> >> >> Could the ARM engineers look if there's some chicken bit in Cortex-A72
> >> >> that could insert barriers between non-cached writes automatically?
> >> >
> >> >
> >> > I don't think there is, and even if there was I imagine it would have a
> >> > pretty hideous effect on non-coherent DMA buffers and the various other
> >> > places in which we have Normal-NC mappings of actual system RAM.
> >> >
> >>
> >> Looking at the A72 manual, there is one chicken bit that looks like it
> >> may be related:
> >>
> >> CPUACTLR_EL1 bit #50:
> >>
> >> 0 Enables store streaming on NC/GRE memory type. This is the reset value.
> >> 1 Disables store streaming on NC/GRE memory type.
> >>
> >> so putting something like
> >>
> >> mrs x0, S3_1_C15_C2_0
> >> orr x0, x0, #(1 << 50)
> >> msr S3_1_C15_C2_0, x0
> >>
> >> in __cpu_setup() would be worth a try.
> >
> > It won't boot.
> >
> > But if i write the same value that was read, it also won't boot.
> >
> > I created a simple kernel module that reads this register and it has bit
> > 32 set, all other bits clear. But when I write the same value into it, the
> > core that does the write is stuck in infinite loop.
> >
> > So, it seems that we are writing this register from a wrong place.
> >
> 
> Ah, my bad. I didn't look closely enough at the description:
> 
> """
> The accessibility to the CPUACTLR_EL1 by Exception level is:
> 
> EL0              -
> EL1(NS)          RW (a)
> EL1(S)           RW (a)
> EL2              RW (b)
> EL3(SCR.NS = 1)  RW
> EL3(SCR.NS = 0)  RW
> 
> (a) Write access if ACTLR_EL3.CPUACTLR is 1 and ACTLR_EL2.CPUACTLR is
> 1, or ACTLR_EL3.CPUACTLR is 1 and SCR.NS is 0.
> """
> 
> so you'll have to do this from ARM Trusted Firmware. If you're
> comfortable rebuilding that:
> 
> diff --git a/include/lib/cpus/aarch64/cortex_a72.h
> b/include/lib/cpus/aarch64/cortex_a72.h
> index bfd64918625b..a7b8cf4be0c6 100644
> --- a/include/lib/cpus/aarch64/cortex_a72.h
> +++ b/include/lib/cpus/aarch64/cortex_a72.h
> @@ -31,6 +31,7 @@
>  #define CORTEX_A72_ACTLR_EL1                   S3_1_C15_C2_0
> 
>  #define CORTEX_A72_ACTLR_DISABLE_L1_DCACHE_HW_PFTCH    (1 << 56)
> +#define CORTEX_A72_ACTLR_DIS_NC_GRE_STORE_STREAMING    (1 << 50)
>  #define CORTEX_A72_ACTLR_NO_ALLOC_WBWA         (1 << 49)
>  #define CORTEX_A72_ACTLR_DCC_AS_DCCI           (1 << 44)
>  #define CORTEX_A72_ACTLR_EL1_DIS_INSTR_PREFETCH                (1 << 32)
> diff --git a/lib/cpus/aarch64/cortex_a72.S b/lib/cpus/aarch64/cortex_a72.S
> index 55e508678284..5914d6ee3ba6 100644
> --- a/lib/cpus/aarch64/cortex_a72.S
> +++ b/lib/cpus/aarch64/cortex_a72.S
> @@ -133,6 +133,15 @@ func cortex_a72_reset_func
>         orr     x0, x0, #CORTEX_A72_ECTLR_SMP_BIT
>         msr     CORTEX_A72_ECTLR_EL1, x0
>         isb
> +
> +       /* ---------------------------------------------
> +        * Disables store streaming on NC/GRE memory type.
> +        * ---------------------------------------------
> +        */
> +       mrs     x0, CORTEX_A72_ACTLR_EL1
> +       orr     x0, x0, #CORTEX_A72_ACTLR_DIS_NC_GRE_STORE_STREAMING
> +       msr     CORTEX_A72_ACTLR_EL1, x0
> +       isb
>         ret x19
>  endfunc cortex_a72_reset_func

Unfortunatelly, it doesn't work. I verified that the bit is set after 
booting Linux, but the memcpy corruption was still present.

I also tried the other chicken bits, it slowed down the system noticeably, 
but had no effect on the memcpy corruption.

Mikulas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: mpatocka@redhat.com (Mikulas Patocka)
To: linux-arm-kernel@lists.infradead.org
Subject: framebuffer corruption due to overlapping stp instructions on arm64
Date: Mon, 6 Aug 2018 15:54:33 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LRH.2.02.1808061552090.11930@file01.intranet.prod.int.rdu2.redhat.com> (raw)
In-Reply-To: <CAKv+Gu_8Rq6X24ZOYvG7+kQQGSGYAZuu_co4k1nJS8K7rkrWMA@mail.gmail.com>



On Mon, 6 Aug 2018, Ard Biesheuvel wrote:

> On 6 August 2018 at 19:09, Mikulas Patocka <mpatocka@redhat.com> wrote:
> >
> >
> > On Mon, 6 Aug 2018, Ard Biesheuvel wrote:
> >
> >> On 6 August 2018 at 14:42, Robin Murphy <robin.murphy@arm.com> wrote:
> >> > On 06/08/18 11:25, Mikulas Patocka wrote:
> >> > [...]
> >> >>>
> >> >>> None of this explains why some transactions fail to make it across
> >> >>> entirely. The overlapping writes in question write the same data to
> >> >>> the memory locations that are covered by both, and so the ordering in
> >> >>> which the transactions are received should not affect the outcome.
> >> >>
> >> >>
> >> >> You're right that the corruption couldn't be explained just by reordering
> >> >> writes. My hypothesis is that the PCIe controller tries to disambiguate
> >> >> the overlapping writes, but the disambiguation logic was not tested and it
> >> >> is buggy. If there's a barrier between the overlapping writes, the PCIe
> >> >> controller won't see any overlapping writes, so it won't trigger the
> >> >> faulty disambiguation logic and it works.
> >> >>
> >> >> Could the ARM engineers look if there's some chicken bit in Cortex-A72
> >> >> that could insert barriers between non-cached writes automatically?
> >> >
> >> >
> >> > I don't think there is, and even if there was I imagine it would have a
> >> > pretty hideous effect on non-coherent DMA buffers and the various other
> >> > places in which we have Normal-NC mappings of actual system RAM.
> >> >
> >>
> >> Looking at the A72 manual, there is one chicken bit that looks like it
> >> may be related:
> >>
> >> CPUACTLR_EL1 bit #50:
> >>
> >> 0 Enables store streaming on NC/GRE memory type. This is the reset value.
> >> 1 Disables store streaming on NC/GRE memory type.
> >>
> >> so putting something like
> >>
> >> mrs x0, S3_1_C15_C2_0
> >> orr x0, x0, #(1 << 50)
> >> msr S3_1_C15_C2_0, x0
> >>
> >> in __cpu_setup() would be worth a try.
> >
> > It won't boot.
> >
> > But if i write the same value that was read, it also won't boot.
> >
> > I created a simple kernel module that reads this register and it has bit
> > 32 set, all other bits clear. But when I write the same value into it, the
> > core that does the write is stuck in infinite loop.
> >
> > So, it seems that we are writing this register from a wrong place.
> >
> 
> Ah, my bad. I didn't look closely enough at the description:
> 
> """
> The accessibility to the CPUACTLR_EL1 by Exception level is:
> 
> EL0              -
> EL1(NS)          RW (a)
> EL1(S)           RW (a)
> EL2              RW (b)
> EL3(SCR.NS = 1)  RW
> EL3(SCR.NS = 0)  RW
> 
> (a) Write access if ACTLR_EL3.CPUACTLR is 1 and ACTLR_EL2.CPUACTLR is
> 1, or ACTLR_EL3.CPUACTLR is 1 and SCR.NS is 0.
> """
> 
> so you'll have to do this from ARM Trusted Firmware. If you're
> comfortable rebuilding that:
> 
> diff --git a/include/lib/cpus/aarch64/cortex_a72.h
> b/include/lib/cpus/aarch64/cortex_a72.h
> index bfd64918625b..a7b8cf4be0c6 100644
> --- a/include/lib/cpus/aarch64/cortex_a72.h
> +++ b/include/lib/cpus/aarch64/cortex_a72.h
> @@ -31,6 +31,7 @@
>  #define CORTEX_A72_ACTLR_EL1                   S3_1_C15_C2_0
> 
>  #define CORTEX_A72_ACTLR_DISABLE_L1_DCACHE_HW_PFTCH    (1 << 56)
> +#define CORTEX_A72_ACTLR_DIS_NC_GRE_STORE_STREAMING    (1 << 50)
>  #define CORTEX_A72_ACTLR_NO_ALLOC_WBWA         (1 << 49)
>  #define CORTEX_A72_ACTLR_DCC_AS_DCCI           (1 << 44)
>  #define CORTEX_A72_ACTLR_EL1_DIS_INSTR_PREFETCH                (1 << 32)
> diff --git a/lib/cpus/aarch64/cortex_a72.S b/lib/cpus/aarch64/cortex_a72.S
> index 55e508678284..5914d6ee3ba6 100644
> --- a/lib/cpus/aarch64/cortex_a72.S
> +++ b/lib/cpus/aarch64/cortex_a72.S
> @@ -133,6 +133,15 @@ func cortex_a72_reset_func
>         orr     x0, x0, #CORTEX_A72_ECTLR_SMP_BIT
>         msr     CORTEX_A72_ECTLR_EL1, x0
>         isb
> +
> +       /* ---------------------------------------------
> +        * Disables store streaming on NC/GRE memory type.
> +        * ---------------------------------------------
> +        */
> +       mrs     x0, CORTEX_A72_ACTLR_EL1
> +       orr     x0, x0, #CORTEX_A72_ACTLR_DIS_NC_GRE_STORE_STREAMING
> +       msr     CORTEX_A72_ACTLR_EL1, x0
> +       isb
>         ret x19
>  endfunc cortex_a72_reset_func

Unfortunatelly, it doesn't work. I verified that the bit is set after 
booting Linux, but the memcpy corruption was still present.

I also tried the other chicken bits, it slowed down the system noticeably, 
but had no effect on the memcpy corruption.

Mikulas

  reply	other threads:[~2018-08-06 19:54 UTC|newest]

Thread overview: 238+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-02 19:31 framebuffer corruption due to overlapping stp instructions on arm64 Mikulas Patocka
2018-08-02 19:31 ` Mikulas Patocka
     [not found] ` <CAHCPf3tFGqkYEcWNN4LaWThw_rVqT316pzLv6T7RfxwO-eZ0EA@mail.gmail.com>
2018-08-03  6:35   ` Mikulas Patocka
2018-08-03  6:35     ` Mikulas Patocka
2018-08-03  7:16     ` Ard Biesheuvel
2018-08-03  7:16       ` Ard Biesheuvel
2018-08-03  9:41       ` Will Deacon
2018-08-03  9:41         ` Will Deacon
2018-08-03 17:09         ` Mikulas Patocka
2018-08-03 17:09           ` Mikulas Patocka
2018-08-03 17:09           ` Mikulas Patocka
2018-08-03 17:32           ` Sinan Kaya
2018-08-03 17:32             ` Sinan Kaya
2018-08-03 17:32             ` Sinan Kaya
2018-08-03 17:33           ` Ard Biesheuvel
2018-08-03 17:33             ` Ard Biesheuvel
2018-08-03 17:33             ` Ard Biesheuvel
2018-08-03 18:25             ` Mikulas Patocka
2018-08-03 18:25               ` Mikulas Patocka
2018-08-03 18:25               ` Mikulas Patocka
2018-08-03 20:44               ` Matt Sealey
2018-08-03 20:44                 ` Matt Sealey
2018-08-03 20:44                 ` Matt Sealey
2018-08-03 21:20                 ` Ard Biesheuvel
2018-08-03 21:20                   ` Ard Biesheuvel
2018-08-03 21:20                   ` Ard Biesheuvel
2018-08-06 10:25                   ` Mikulas Patocka
2018-08-06 10:25                     ` Mikulas Patocka
2018-08-06 10:25                     ` Mikulas Patocka
2018-08-06 12:42                     ` Robin Murphy
2018-08-06 12:42                       ` Robin Murphy
2018-08-06 12:42                       ` Robin Murphy
2018-08-06 12:53                       ` Ard Biesheuvel
2018-08-06 12:53                         ` Ard Biesheuvel
2018-08-06 12:53                         ` Ard Biesheuvel
2018-08-06 13:41                       ` Marcin Wojtas
2018-08-06 13:41                         ` Marcin Wojtas
2018-08-06 13:41                         ` Marcin Wojtas
2018-08-06 13:48                         ` Ard Biesheuvel
2018-08-06 13:48                           ` Ard Biesheuvel
2018-08-06 13:48                           ` Ard Biesheuvel
2018-08-06 14:07                           ` Marcin Wojtas
2018-08-06 14:07                             ` Marcin Wojtas
2018-08-06 14:07                             ` Marcin Wojtas
2018-08-06 14:13                             ` Mikulas Patocka
2018-08-06 14:13                               ` Mikulas Patocka
2018-08-06 14:13                               ` Mikulas Patocka
2018-08-06 15:47                       ` Ard Biesheuvel
2018-08-06 15:47                         ` Ard Biesheuvel
2018-08-06 15:47                         ` Ard Biesheuvel
2018-08-06 17:09                         ` Mikulas Patocka
2018-08-06 17:09                           ` Mikulas Patocka
2018-08-06 17:09                           ` Mikulas Patocka
2018-08-06 17:21                           ` Ard Biesheuvel
2018-08-06 17:21                             ` Ard Biesheuvel
2018-08-06 17:21                             ` Ard Biesheuvel
2018-08-06 19:54                             ` Mikulas Patocka [this message]
2018-08-06 19:54                               ` Mikulas Patocka
2018-08-06 19:54                               ` Mikulas Patocka
2018-08-06 20:11                               ` Ard Biesheuvel
2018-08-06 20:11                                 ` Ard Biesheuvel
2018-08-06 20:11                                 ` Ard Biesheuvel
2018-08-06 20:31                                 ` Mikulas Patocka
2018-08-06 20:31                                   ` Mikulas Patocka
2018-08-06 20:31                                   ` Mikulas Patocka
2018-08-07 16:40                                 ` Marcin Wojtas
2018-08-07 16:40                                   ` Marcin Wojtas
2018-08-07 16:40                                   ` Marcin Wojtas
2018-08-07 17:39                                   ` Mikulas Patocka
2018-08-07 17:39                                     ` Mikulas Patocka
2018-08-07 17:39                                     ` Mikulas Patocka
2018-08-07 18:07                                     ` Ard Biesheuvel
2018-08-07 18:07                                       ` Ard Biesheuvel
2018-08-07 18:07                                       ` Ard Biesheuvel
2018-08-07 18:17                                       ` Mikulas Patocka
2018-08-07 18:17                                         ` Mikulas Patocka
2018-08-07 18:17                                         ` Mikulas Patocka
     [not found]                                     ` <CAPv3WKcKoEe=Qysp6Oac2C=G9bUhUQf1twSRCY+_qJ6XEC-iag@mail.gmail.com>
2018-08-08 14:10                                       ` Mikulas Patocka
2018-08-08 14:10                                         ` Mikulas Patocka
2018-08-08 14:10                                         ` Mikulas Patocka
2018-08-06 17:13                         ` Catalin Marinas
2018-08-06 17:13                           ` Catalin Marinas
2018-08-06 17:13                           ` Catalin Marinas
2018-08-06 17:19                           ` Mikulas Patocka
2018-08-06 17:19                             ` Mikulas Patocka
2018-08-06 17:19                             ` Mikulas Patocka
2018-08-08 18:31                       ` Mikulas Patocka
2018-08-08 18:31                         ` Mikulas Patocka
2018-08-08 18:31                         ` Mikulas Patocka
2018-08-04 13:29                 ` Mikulas Patocka
2018-08-04 13:29                   ` Mikulas Patocka
2018-08-04 13:29                   ` Mikulas Patocka
2018-08-08 12:16                 ` Catalin Marinas
2018-08-08 12:16                   ` Catalin Marinas
2018-08-08 12:16                   ` Catalin Marinas
2018-08-08 13:02                   ` David Laight
2018-08-08 13:02                     ` David Laight
2018-08-08 13:02                     ` David Laight
2018-08-08 13:46                     ` Mikulas Patocka
2018-08-08 13:46                       ` Mikulas Patocka
2018-08-08 13:46                       ` Mikulas Patocka
2018-08-08 14:26                       ` David Laight
2018-08-08 14:26                         ` David Laight
2018-08-08 14:26                         ` David Laight
2018-08-08 14:50                         ` Catalin Marinas
2018-08-08 14:50                           ` Catalin Marinas
2018-08-08 14:50                           ` Catalin Marinas
2018-08-08 16:21                           ` Mikulas Patocka
2018-08-08 16:21                             ` Mikulas Patocka
2018-08-08 16:21                             ` Mikulas Patocka
2018-08-08 16:31                             ` Arnd Bergmann
2018-08-08 16:31                               ` Arnd Bergmann
2018-08-08 16:31                               ` Arnd Bergmann
2018-08-08 16:43                               ` David Laight
2018-08-08 16:43                                 ` David Laight
2018-08-08 16:43                                 ` David Laight
2018-08-08 18:56                                 ` Mikulas Patocka
2018-08-08 18:56                                   ` Mikulas Patocka
2018-08-08 18:56                                   ` Mikulas Patocka
2018-08-08 18:37                         ` Mikulas Patocka
2018-08-08 18:37                           ` Mikulas Patocka
2018-08-08 18:37                           ` Mikulas Patocka
2018-08-08 11:39           ` Catalin Marinas
2018-08-08 11:39             ` Catalin Marinas
2018-08-08 11:39             ` Catalin Marinas
2018-08-08 14:12             ` Mikulas Patocka
2018-08-08 14:12               ` Mikulas Patocka
2018-08-08 14:12               ` Mikulas Patocka
2018-08-08 14:28               ` Catalin Marinas
2018-08-08 14:28                 ` Catalin Marinas
2018-08-08 14:28                 ` Catalin Marinas
2018-08-08 18:40                 ` Mikulas Patocka
2018-08-08 18:40                   ` Mikulas Patocka
2018-08-08 18:40                   ` Mikulas Patocka
2018-08-08 15:01               ` Richard Earnshaw (lists)
2018-08-08 15:01                 ` Richard Earnshaw (lists)
2018-08-08 15:01                 ` Richard Earnshaw (lists)
2018-08-08 15:14                 ` Catalin Marinas
2018-08-08 15:14                   ` Catalin Marinas
2018-08-08 15:14                   ` Catalin Marinas
2018-08-08 16:01                   ` Arnd Bergmann
2018-08-08 16:01                     ` Arnd Bergmann
2018-08-08 16:01                     ` Arnd Bergmann
2018-08-08 18:25                     ` Mikulas Patocka
2018-08-08 18:25                       ` Mikulas Patocka
2018-08-08 18:25                       ` Mikulas Patocka
2018-08-08 21:51                       ` Arnd Bergmann
2018-08-08 21:51                         ` Arnd Bergmann
2018-08-08 21:51                         ` Arnd Bergmann
2018-08-09 15:29                         ` Arnd Bergmann
2018-08-09 15:29                           ` Arnd Bergmann
2018-08-09 15:29                           ` Arnd Bergmann
2018-08-03  7:11 ` Andrew Pinski
2018-08-03  7:11   ` Andrew Pinski
2018-08-03  7:53   ` Florian Weimer
2018-08-03  7:53     ` Florian Weimer
2018-08-03  9:12     ` Szabolcs Nagy
2018-08-03  9:12       ` Szabolcs Nagy
2018-08-03  9:15     ` Ramana Radhakrishnan
2018-08-03  9:15       ` Ramana Radhakrishnan
2018-08-03  9:29       ` Ard Biesheuvel
2018-08-03  9:29         ` Ard Biesheuvel
2018-08-03  9:37         ` Ramana Radhakrishnan
2018-08-03  9:37           ` Ramana Radhakrishnan
2018-08-03  9:42         ` Richard Earnshaw (lists)
2018-08-03  9:42           ` Richard Earnshaw (lists)
2018-08-04  0:58           ` Mikulas Patocka
2018-08-04  0:58             ` Mikulas Patocka
2018-08-04  1:13             ` Andrew Pinski
2018-08-04  1:13               ` Andrew Pinski
2018-08-04 11:04               ` Mikulas Patocka
2018-08-04 11:04                 ` Mikulas Patocka
2018-08-05 18:33                 ` Florian Weimer
2018-08-05 18:33                   ` Florian Weimer
2018-08-06  8:02                   ` Mikulas Patocka
2018-08-06  8:02                     ` Mikulas Patocka
2018-08-06  8:10                     ` Ard Biesheuvel
2018-08-06  8:10                       ` Ard Biesheuvel
2018-08-06 10:31                       ` Mikulas Patocka
2018-08-06 10:31                         ` Mikulas Patocka
2018-08-06 10:37                         ` Ard Biesheuvel
2018-08-06 10:37                           ` Ard Biesheuvel
2018-08-06 10:42                           ` Mikulas Patocka
2018-08-06 10:42                             ` Mikulas Patocka
2018-08-06 10:48                             ` Ard Biesheuvel
2018-08-06 10:48                               ` Ard Biesheuvel
2018-08-06 12:09                               ` Mikulas Patocka
2018-08-06 12:09                                 ` Mikulas Patocka
2018-08-06 12:19                                 ` Ard Biesheuvel
2018-08-06 12:19                                   ` Ard Biesheuvel
2018-08-06 12:22                                   ` Ard Biesheuvel
2018-08-06 12:22                                     ` Ard Biesheuvel
2018-08-07 14:14                                   ` Mikulas Patocka
2018-08-07 14:14                                     ` Mikulas Patocka
2018-08-07 14:40                                     ` Ard Biesheuvel
2018-08-07 14:40                                       ` Ard Biesheuvel
2018-08-08 19:15                                   ` Mikulas Patocka
2018-08-08 19:15                                     ` Mikulas Patocka
2018-08-06 11:19                         ` Siddhesh Poyarekar
2018-08-06 11:19                           ` Siddhesh Poyarekar
2018-08-06 11:29                           ` Ard Biesheuvel
2018-08-06 11:29                             ` Ard Biesheuvel
2018-08-06 14:26                   ` Tulio Magno Quites Machado Filho
2018-08-06 14:26                     ` Tulio Magno Quites Machado Filho
2018-08-05 21:51                 ` Pavel Machek
2018-08-05 21:51                   ` Pavel Machek
2018-08-06 14:30                   ` Mikulas Patocka
2018-08-06 14:30                     ` Mikulas Patocka
2018-08-03 11:24         ` David Laight
2018-08-03 11:24           ` David Laight
2018-08-03 12:04           ` Mikulas Patocka
2018-08-03 12:04             ` Mikulas Patocka
2018-08-03 13:04             ` David Laight
2018-08-03 13:04               ` David Laight
2018-08-05 14:36               ` Mikulas Patocka
2018-08-05 14:36                 ` Mikulas Patocka
2018-08-06 10:18                 ` David Laight
2018-08-06 10:18                   ` David Laight
2018-08-07 14:07                   ` Mikulas Patocka
2018-08-07 14:07                     ` Mikulas Patocka
2018-08-07 14:33                     ` David Laight
2018-08-07 14:33                       ` David Laight
2018-08-08 14:21                       ` Mikulas Patocka
2018-08-08 14:21                         ` Mikulas Patocka
2018-08-03 13:20     ` Mikulas Patocka
2018-08-03 13:20       ` Mikulas Patocka
2018-08-03 13:31   ` Mikulas Patocka
2018-08-03 13:31     ` Mikulas Patocka
2018-08-03 14:17     ` Richard Earnshaw (lists)
2018-08-03 14:17       ` Richard Earnshaw (lists)
2018-08-05 21:36   ` Pavel Machek
2018-08-05 21:36     ` Pavel Machek
2018-08-06  8:04     ` Ramana Radhakrishnan
2018-08-06  8:04       ` Ramana Radhakrishnan
2018-08-06  8:44       ` Pavel Machek
2018-08-06  8:44         ` Pavel Machek
2018-08-06  9:11         ` Ard Biesheuvel
2018-08-06  9:11           ` Ard Biesheuvel

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=alpine.LRH.2.02.1808061552090.11930@file01.intranet.prod.int.rdu2.redhat.com \
    --to=mpatocka@redhat.com \
    --cc=Joao.Pinto@synopsys.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=jingoohan1@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=neko@bakuhatsu.net \
    --cc=robin.murphy@arm.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=will.deacon@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.