All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Jeremy Linton <jeremy.linton@arm.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Mark Rutland <Mark.Rutland@arm.com>,
	austinwc@codeaurora.org, tnowicki@caviumnetworks.com,
	Palmer Dabbelt <palmer@sifive.com>,
	linux-riscv@lists.infradead.org, Morten.Rasmussen@arm.com,
	vkilari@codeaurora.org,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	jhugo@codeaurora.org, Al Stone <ahs3@redhat.com>,
	Len Brown <lenb@kernel.org>, John Garry <john.garry@huawei.com>,
	wangxiongfeng2@huawei.com,
	Dietmar Eggemann <Dietmar.Eggemann@arm.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	Rafael J. Wysocki
Subject: Re: [PATCH v9 00/12] Support PPTT for ARM64
Date: Tue, 29 May 2018 21:16:24 +0100	[thread overview]
Message-ID: <20180529201623.GA591@arm.com> (raw)
In-Reply-To: <CAMuHMdU0yET6+-FfS8e9HJdKB7h0gDn7kzWGpJZV=UiWn5fLkA@mail.gmail.com>

Hi Geert,

On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> >> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >> >>> System supend still works fine on systems with big cores only:
> >> >>>
> >> >>>     R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >> >>>     R-Car M3-N (2xCA57)
> >> >>>
> >> >>> Reverting this commit fixes the issue for me.
> >> >>
> >> >> I can't find anything that relates to system suspend in these patches
> >> >> unless they are messing with something during CPU hot plug-in back
> >> >> during resume.
> >> >
> >> > It's only the last patch that introduces the breakage.
> >> >
> >>
> >> As specified in the commit log, it won't change any behavior for DT
> >> systems if it's non-NUMA or single node system. So I am still wondering
> >> what could trigger this regression.
> >
> > I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> > to the scheduler, although I can't see how this would happen.
> >
> > Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> > do you see anything shouting in dmesg?
> 
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.

Damn, sorry for wasting your time. For the record, Catalin's been seeing
boot failures under KVM on a non-big/LITTLE machine that bisect reliably
to this patch, but we've also not been able to explain them. Worse, adding
so much as a printk makes the problem disappear.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Jeremy Linton <jeremy.linton@arm.com>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Mark Rutland <Mark.Rutland@arm.com>,
	austinwc@codeaurora.org, tnowicki@caviumnetworks.com,
	Palmer Dabbelt <palmer@sifive.com>,
	linux-riscv@lists.infradead.org, Morten.Rasmussen@arm.com,
	vkilari@codeaurora.org,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	jhugo@codeaurora.org, Al Stone <ahs3@redhat.com>,
	Len Brown <lenb@kernel.org>, John Garry <john.garry@huawei.com>,
	wangxiongfeng2@huawei.com,
	Dietmar Eggemann <Dietmar.Eggemann@arm.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Hanjun Guo <hanjun.guo@linaro.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH v9 00/12] Support PPTT for ARM64
Date: Tue, 29 May 2018 21:16:24 +0100	[thread overview]
Message-ID: <20180529201623.GA591@arm.com> (raw)
In-Reply-To: <CAMuHMdU0yET6+-FfS8e9HJdKB7h0gDn7kzWGpJZV=UiWn5fLkA@mail.gmail.com>

Hi Geert,

On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> >> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >> >>> System supend still works fine on systems with big cores only:
> >> >>>
> >> >>>     R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >> >>>     R-Car M3-N (2xCA57)
> >> >>>
> >> >>> Reverting this commit fixes the issue for me.
> >> >>
> >> >> I can't find anything that relates to system suspend in these patches
> >> >> unless they are messing with something during CPU hot plug-in back
> >> >> during resume.
> >> >
> >> > It's only the last patch that introduces the breakage.
> >> >
> >>
> >> As specified in the commit log, it won't change any behavior for DT
> >> systems if it's non-NUMA or single node system. So I am still wondering
> >> what could trigger this regression.
> >
> > I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> > to the scheduler, although I can't see how this would happen.
> >
> > Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> > do you see anything shouting in dmesg?
> 
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.

Damn, sorry for wasting your time. For the record, Catalin's been seeing
boot failures under KVM on a non-big/LITTLE machine that bisect reliably
to this patch, but we've also not been able to explain them. Worse, adding
so much as a printk makes the problem disappear.

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-riscv@lists.infradead.org
Subject: [PATCH v9 00/12] Support PPTT for ARM64
Date: Tue, 29 May 2018 21:16:24 +0100	[thread overview]
Message-ID: <20180529201623.GA591@arm.com> (raw)
In-Reply-To: <CAMuHMdU0yET6+-FfS8e9HJdKB7h0gDn7kzWGpJZV=UiWn5fLkA@mail.gmail.com>

Hi Geert,

On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> >> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >> >>> System supend still works fine on systems with big cores only:
> >> >>>
> >> >>>     R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >> >>>     R-Car M3-N (2xCA57)
> >> >>>
> >> >>> Reverting this commit fixes the issue for me.
> >> >>
> >> >> I can't find anything that relates to system suspend in these patches
> >> >> unless they are messing with something during CPU hot plug-in back
> >> >> during resume.
> >> >
> >> > It's only the last patch that introduces the breakage.
> >> >
> >>
> >> As specified in the commit log, it won't change any behavior for DT
> >> systems if it's non-NUMA or single node system. So I am still wondering
> >> what could trigger this regression.
> >
> > I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> > to the scheduler, although I can't see how this would happen.
> >
> > Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> > do you see anything shouting in dmesg?
> 
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.

Damn, sorry for wasting your time. For the record, Catalin's been seeing
boot failures under KVM on a non-big/LITTLE machine that bisect reliably
to this patch, but we've also not been able to explain them. Worse, adding
so much as a printk makes the problem disappear.

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 00/12] Support PPTT for ARM64
Date: Tue, 29 May 2018 21:16:24 +0100	[thread overview]
Message-ID: <20180529201623.GA591@arm.com> (raw)
In-Reply-To: <CAMuHMdU0yET6+-FfS8e9HJdKB7h0gDn7kzWGpJZV=UiWn5fLkA@mail.gmail.com>

Hi Geert,

On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> >> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >> >>> System supend still works fine on systems with big cores only:
> >> >>>
> >> >>>     R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >> >>>     R-Car M3-N (2xCA57)
> >> >>>
> >> >>> Reverting this commit fixes the issue for me.
> >> >>
> >> >> I can't find anything that relates to system suspend in these patches
> >> >> unless they are messing with something during CPU hot plug-in back
> >> >> during resume.
> >> >
> >> > It's only the last patch that introduces the breakage.
> >> >
> >>
> >> As specified in the commit log, it won't change any behavior for DT
> >> systems if it's non-NUMA or single node system. So I am still wondering
> >> what could trigger this regression.
> >
> > I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> > to the scheduler, although I can't see how this would happen.
> >
> > Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> > do you see anything shouting in dmesg?
> 
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.

Damn, sorry for wasting your time. For the record, Catalin's been seeing
boot failures under KVM on a non-big/LITTLE machine that bisect reliably
to this patch, but we've also not been able to explain them. Worse, adding
so much as a printk makes the problem disappear.

Will

  parent reply	other threads:[~2018-05-29 20:16 UTC|newest]

Thread overview: 185+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-11 23:57 [PATCH v9 00/12] Support PPTT for ARM64 Jeremy Linton
2018-05-11 23:57 ` Jeremy Linton
2018-05-11 23:57 ` Jeremy Linton
2018-05-11 23:57 ` [PATCH v9 01/12] drivers: base: cacheinfo: move cache_setup_of_node() Jeremy Linton
2018-05-11 23:57   ` Jeremy Linton
2018-05-11 23:57   ` Jeremy Linton
2018-05-11 23:57 ` [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early Jeremy Linton
2018-05-11 23:57   ` Jeremy Linton
2018-05-11 23:57   ` Jeremy Linton
2018-05-11 23:57   ` Jeremy Linton
2018-05-15 17:15   ` Jeremy Linton
2018-05-15 17:15     ` Jeremy Linton
2018-05-15 17:15     ` Jeremy Linton
2018-05-15 19:32     ` Andy Shevchenko
2018-05-15 19:32       ` Andy Shevchenko
2018-05-15 19:32       ` Andy Shevchenko
2018-05-15 19:32       ` Andy Shevchenko
2018-05-16 10:56       ` Sudeep Holla
2018-05-16 10:56         ` Sudeep Holla
2018-05-16 10:56         ` Sudeep Holla
2018-05-16 10:56         ` Sudeep Holla
2018-05-17 15:47         ` Sudeep Holla
2018-05-17 15:47           ` Sudeep Holla
2018-05-17 15:47           ` Sudeep Holla
2018-05-17 15:47           ` Sudeep Holla
2018-05-18 21:50           ` Andy Shevchenko
2018-05-18 21:50             ` Andy Shevchenko
2018-05-18 21:50             ` Andy Shevchenko
2018-05-18 21:50             ` Andy Shevchenko
2018-05-21  9:27             ` Sudeep Holla
2018-05-21  9:27               ` Sudeep Holla
2018-05-21  9:27               ` Sudeep Holla
2018-05-21  9:27               ` Sudeep Holla
2018-05-21 10:15               ` Sudeep Holla
2018-05-21 10:15                 ` Sudeep Holla
2018-05-21 10:15                 ` Sudeep Holla
2018-05-21 10:15                 ` Sudeep Holla
2018-05-21 10:32       ` [PATCH] drivers: base: cacheinfo: use OF property_read_u64 instead of get_property,read_number Sudeep Holla
2018-05-21 10:32         ` [PATCH] drivers: base: cacheinfo: use OF property_read_u64 instead of get_property, read_number Sudeep Holla
2018-05-21 12:53         ` [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number Sudeep Holla
2018-05-21 12:53           ` [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property, read_number Sudeep Holla
2018-06-05 16:21           ` [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number Andy Shevchenko
2018-06-05 16:21             ` Andy Shevchenko
2018-06-05 16:26             ` Sudeep Holla
2018-06-05 16:26               ` Sudeep Holla
2018-06-05 16:34               ` Andy Shevchenko
2018-06-05 16:34                 ` Andy Shevchenko
2018-05-17  6:54     ` [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early Greg KH
2018-05-17  6:54       ` Greg KH
2018-05-17  6:54       ` Greg KH
2018-05-17  9:08       ` Sudeep Holla
2018-05-17  9:08         ` Sudeep Holla
2018-05-17  9:08         ` Sudeep Holla
2018-05-17  9:35         ` Greg KH
2018-05-17  9:35           ` Greg KH
2018-05-17  9:35           ` Greg KH
2018-05-11 23:57 ` [PATCH v9 03/12] cacheinfo: rename of_node to fw_token Jeremy Linton
2018-05-11 23:57   ` Jeremy Linton
2018-05-11 23:57   ` Jeremy Linton
2018-05-11 23:57 ` [PATCH v9 04/12] arm64/acpi: Create arch specific cpu to acpi id helper Jeremy Linton
2018-05-11 23:57   ` Jeremy Linton
2018-05-11 23:57   ` Jeremy Linton
2018-05-14 14:41   ` Sudeep Holla
2018-05-14 14:41     ` Sudeep Holla
2018-05-14 14:41     ` Sudeep Holla
2018-05-11 23:58 ` [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-12 10:09   ` Rafael J. Wysocki
2018-05-12 10:09     ` Rafael J. Wysocki
2018-05-12 10:09     ` Rafael J. Wysocki
2018-05-12 10:09     ` Rafael J. Wysocki
2018-05-15 21:42     ` Jeremy Linton
2018-05-15 21:42       ` Jeremy Linton
2018-05-15 21:42       ` Jeremy Linton
2018-05-15 21:42       ` Jeremy Linton
2018-05-16  8:24       ` Rafael J. Wysocki
2018-05-16  8:24         ` Rafael J. Wysocki
2018-05-16  8:24         ` Rafael J. Wysocki
2018-05-16  8:24         ` Rafael J. Wysocki
2018-05-11 23:58 ` [PATCH v9 06/12] ACPI: Enable PPTT support on ARM64 Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58 ` [PATCH v9 07/12] drivers: base cacheinfo: Add support for ACPI based firmware tables Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58 ` [PATCH v9 08/12] arm64: " Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58 ` [PATCH v9 09/12] arm64: topology: rename cluster_id Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58 ` [PATCH v9 10/12] arm64: topology: enable ACPI/PPTT based CPU topology Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58 ` [PATCH v9 11/12] ACPI: Add PPTT to injectable table list Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-12 10:10   ` Rafael J. Wysocki
2018-05-12 10:10     ` Rafael J. Wysocki
2018-05-12 10:10     ` Rafael J. Wysocki
2018-05-12 10:10     ` Rafael J. Wysocki
2018-05-11 23:58 ` [PATCH v9 12/12] arm64: topology: divorce MC scheduling domain from core_siblings Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-11 23:58   ` Jeremy Linton
2018-05-17 17:05 ` [PATCH v9 00/12] Support PPTT for ARM64 Catalin Marinas
2018-05-17 17:05   ` Catalin Marinas
2018-05-17 17:05   ` Catalin Marinas
2018-05-29 10:48   ` Geert Uytterhoeven
2018-05-29 10:48     ` Geert Uytterhoeven
2018-05-29 10:48     ` Geert Uytterhoeven
2018-05-29 10:48     ` Geert Uytterhoeven
2018-05-29 11:14     ` Sudeep Holla
2018-05-29 11:14       ` Sudeep Holla
2018-05-29 11:14       ` Sudeep Holla
2018-05-29 11:14       ` Sudeep Holla
2018-05-29 11:56       ` Geert Uytterhoeven
2018-05-29 11:56         ` Geert Uytterhoeven
2018-05-29 11:56         ` Geert Uytterhoeven
2018-05-29 11:56         ` Geert Uytterhoeven
2018-05-29 13:18         ` Sudeep Holla
2018-05-29 13:18           ` Sudeep Holla
2018-05-29 13:18           ` Sudeep Holla
2018-05-29 13:18           ` Sudeep Holla
2018-05-29 15:08           ` Will Deacon
2018-05-29 15:08             ` Will Deacon
2018-05-29 15:08             ` Will Deacon
2018-05-29 15:08             ` Will Deacon
2018-05-29 15:51             ` Geert Uytterhoeven
2018-05-29 15:51               ` Geert Uytterhoeven
2018-05-29 15:51               ` Geert Uytterhoeven
2018-05-29 15:51               ` Geert Uytterhoeven
2018-05-29 17:08               ` Robin Murphy
2018-05-29 17:08                 ` Robin Murphy
2018-05-29 17:08                 ` Robin Murphy
2018-05-29 17:08                 ` Robin Murphy
2018-05-29 17:18                 ` Geert Uytterhoeven
2018-05-29 17:18                   ` Geert Uytterhoeven
2018-05-29 17:18                   ` Geert Uytterhoeven
2018-05-29 17:18                   ` Geert Uytterhoeven
2018-05-29 17:31                 ` Sudeep Holla
2018-05-29 17:31                   ` Sudeep Holla
2018-05-29 17:31                   ` Sudeep Holla
2018-05-29 17:31                   ` Sudeep Holla
2018-05-29 20:16               ` Will Deacon [this message]
2018-05-29 20:16                 ` Will Deacon
2018-05-29 20:16                 ` Will Deacon
2018-05-29 20:16                 ` Will Deacon
2018-05-29 20:48                 ` Jeremy Linton
2018-05-29 20:48                   ` Jeremy Linton
2018-05-29 20:48                   ` Jeremy Linton
2018-05-29 20:48                   ` Jeremy Linton
2018-05-29 21:52               ` Jeremy Linton
2018-05-29 21:52                 ` Jeremy Linton
2018-05-29 21:52                 ` Jeremy Linton
2018-05-29 21:52                 ` Jeremy Linton
2018-05-30 13:24                 ` Sudeep Holla
2018-05-30 13:24                   ` Sudeep Holla
2018-05-30 13:24                   ` Sudeep Holla
2018-05-30 13:24                   ` Sudeep Holla
2018-05-29 15:23           ` Jeremy Linton
2018-05-29 15:23             ` Jeremy Linton
2018-05-29 15:23             ` Jeremy Linton
2018-05-29 15:23             ` Jeremy Linton
2018-05-29 15:50           ` Geert Uytterhoeven
2018-05-29 15:50             ` Geert Uytterhoeven
2018-05-29 15:50             ` Geert Uytterhoeven
2018-05-29 15:50             ` Geert Uytterhoeven
2018-05-30  8:52             ` Morten Rasmussen
2018-05-30  8:52               ` Morten Rasmussen
2018-05-30  8:52               ` Morten Rasmussen
2018-05-30  8:52               ` Morten Rasmussen
2018-06-05 13:55     ` [PATCH 1/3] Revert "arm64: topology: divorce MC scheduling domain from core_siblings" Sudeep Holla
2018-06-05 13:55       ` Sudeep Holla
2018-06-05 13:55       ` [PATCH 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled Sudeep Holla
2018-06-05 13:55         ` Sudeep Holla
2018-06-05 13:55       ` [PATCH 3/3] arm64: disable ACPI PPTT support temporarily Sudeep Holla
2018-06-05 13:55         ` Sudeep Holla
2018-06-05 14:09       ` [PATCH 1/3] Revert "arm64: topology: divorce MC scheduling domain from core_siblings" Geert Uytterhoeven
2018-06-05 14:09         ` Geert Uytterhoeven
2018-06-05 14:12         ` Sudeep Holla
2018-06-05 14:12           ` Sudeep Holla
2018-06-04 15:12   ` [PATCH v9 00/12] Support PPTT for ARM64 Catalin Marinas
2018-06-04 15:12     ` Catalin Marinas
2018-06-04 15:12     ` Catalin Marinas

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=20180529201623.GA591@arm.com \
    --to=will.deacon@arm.com \
    --cc=Dietmar.Eggemann@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=Mark.Rutland@arm.com \
    --cc=Morten.Rasmussen@arm.com \
    --cc=ahs3@redhat.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=austinwc@codeaurora.org \
    --cc=catalin.marinas@arm.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeremy.linton@arm.com \
    --cc=jhugo@codeaurora.org \
    --cc=john.garry@huawei.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@sifive.com \
    --cc=sudeep.holla@arm.com \
    --cc=tnowicki@caviumnetworks.com \
    --cc=vkilari@codeaurora.org \
    --cc=wangxiongfeng2@huawei.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.