All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Masters <jcm@redhat.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	Tomasz Nowicki <tn@semihalf.com>,
	"helgaas@kernel.org" <helgaas@kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
	"okaya@codeaurora.org" <okaya@codeaurora.org>,
	"jchandra@broadcom.com" <jchandra@broadcom.com>,
	"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"dhdang@apm.com" <dhdang@apm.com>,
	"Liviu.Dudau@arm.com" <Liviu.Dudau@arm.com>,
	"ddaney@caviumnetworks.com" <ddaney@caviumnetworks.com>,
	"jeremy.linton@arm.com" <jeremy.linton@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	robert.
Subject: Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller
Date: Tue, 24 May 2016 00:20:55 -0400	[thread overview]
Message-ID: <f9c8b16b-3027-d90d-c0d1-6afcd45c1e0f@redhat.com> (raw)
In-Reply-To: <20160523105655.GA22902@red-moon>

On 05/23/2016 06:56 AM, Lorenzo Pieralisi wrote:

> The only way this can be implemented is by pretending that the
> ACPI/PCI arch/arm64 implementation is generic code (that's what this
> series does), move it to /drivers (where it is in this series), and
> implement _DSD vendor specific bindings (per HID) to set-up the pci
> operations; whether this solution should go upstream, given that it
> is just a short-term solution for early platforms bugs, it is another
> story and my personal answer is no.

Just for completeness, let me also followup to this one.

We have real, shipping, systems in the field based on ARMv8. For
example, HPE Moonshot ProLiant m400. Not everyone loves the first
generation of anything (Applied get a lot of stick, but the reality is
that someone had to go first, and whoever that was was going to learn
all of the lessons that others don't need to) but it is out there and we
need an upstream kernel solution that includes support for that.

In the server world, we (speaking as a major distro vendor here) are not
going to entertain a situation in which non-upstream patches are needed
to even boot a platform. That simply won't do. We need to separate out
the issue of getting the core in place from the quirks, but then we need
quirks that include support for all early ARMv8 platforms that are out
there today. If we can't get to a point where a Moonshot[0] cartridge
boots out of the box with an upstream kernel, let's just give up and do
something else instead :) (joke)

Jon.

[0] HPE have been *amazingly* patient with this stuff. They've reworked
the firmware when someone (cough) pointed out that the early stuff
they'd been fed was not built according to the standards (U-Boot). They
have *really good* UEFI and ACPI enabled firmware that is running
RHEL(SA) great. But that's not good enough. We don't ship a distro with
hacks. We ship a distro derived from upstream code (although we might
have to backport a lot of stuff later). There's wiggle room, but there
is not wiggle room for core platforms. On ARM, users and developers
*will* be able to take an upstream kernel and boot it on their RHEL
install. And they *will* be able to reproduce problems against upstream,
and help develop against upstream, and further the upstream first
mentality in the ARM ecosystem. There will not be "oh well, it runs RHEL
so that's good enough for the early generation...".

-- 
Computer Architect | Sent from my Fedora powered laptop

WARNING: multiple messages have this Message-ID (diff)
From: Jon Masters <jcm@redhat.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	Tomasz Nowicki <tn@semihalf.com>,
	"helgaas@kernel.org" <helgaas@kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
	"okaya@codeaurora.org" <okaya@codeaurora.org>,
	"jchandra@broadcom.com" <jchandra@broadcom.com>,
	"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"dhdang@apm.com" <dhdang@apm.com>,
	"Liviu.Dudau@arm.com" <Liviu.Dudau@arm.com>,
	"ddaney@caviumnetworks.com" <ddaney@caviumnetworks.com>,
	"jeremy.linton@arm.com" <jeremy.linton@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"robert.richter@caviumnetworks.com" 
	<robert.richter@caviumnetworks.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"msalter@redhat.com" <msalter@redhat.com>,
	Wangyijing <wangyijing@huawei.com>,
	"mw@semihalf.com" <mw@semihalf.com>,
	"andrea.gallo@linaro.org" <andrea.gallo@linaro.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller
Date: Tue, 24 May 2016 00:20:55 -0400	[thread overview]
Message-ID: <f9c8b16b-3027-d90d-c0d1-6afcd45c1e0f@redhat.com> (raw)
In-Reply-To: <20160523105655.GA22902@red-moon>

On 05/23/2016 06:56 AM, Lorenzo Pieralisi wrote:

> The only way this can be implemented is by pretending that the
> ACPI/PCI arch/arm64 implementation is generic code (that's what this
> series does), move it to /drivers (where it is in this series), and
> implement _DSD vendor specific bindings (per HID) to set-up the pci
> operations; whether this solution should go upstream, given that it
> is just a short-term solution for early platforms bugs, it is another
> story and my personal answer is no.

Just for completeness, let me also followup to this one.

We have real, shipping, systems in the field based on ARMv8. For
example, HPE Moonshot ProLiant m400. Not everyone loves the first
generation of anything (Applied get a lot of stick, but the reality is
that someone had to go first, and whoever that was was going to learn
all of the lessons that others don't need to) but it is out there and we
need an upstream kernel solution that includes support for that.

In the server world, we (speaking as a major distro vendor here) are not
going to entertain a situation in which non-upstream patches are needed
to even boot a platform. That simply won't do. We need to separate out
the issue of getting the core in place from the quirks, but then we need
quirks that include support for all early ARMv8 platforms that are out
there today. If we can't get to a point where a Moonshot[0] cartridge
boots out of the box with an upstream kernel, let's just give up and do
something else instead :) (joke)

Jon.

[0] HPE have been *amazingly* patient with this stuff. They've reworked
the firmware when someone (cough) pointed out that the early stuff
they'd been fed was not built according to the standards (U-Boot). They
have *really good* UEFI and ACPI enabled firmware that is running
RHEL(SA) great. But that's not good enough. We don't ship a distro with
hacks. We ship a distro derived from upstream code (although we might
have to backport a lot of stuff later). There's wiggle room, but there
is not wiggle room for core platforms. On ARM, users and developers
*will* be able to take an upstream kernel and boot it on their RHEL
install. And they *will* be able to reproduce problems against upstream,
and help develop against upstream, and further the upstream first
mentality in the ARM ecosystem. There will not be "oh well, it runs RHEL
so that's good enough for the early generation...".

-- 
Computer Architect | Sent from my Fedora powered laptop

WARNING: multiple messages have this Message-ID (diff)
From: Jon Masters <jcm@redhat.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	Tomasz Nowicki <tn@semihalf.com>,
	"helgaas@kernel.org" <helgaas@kernel.org>,
	"arnd@arndb.de" <arnd@arndb.de>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"rafael@kernel.org" <rafael@kernel.org>,
	"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
	"okaya@codeaurora.org" <okaya@codeaurora.org>,
	"jchandra@broadcom.com" <jchandra@broadcom.com>,
	"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"dhdang@apm.com" <dhdang@apm.com>,
	"Liviu.Dudau@arm.com" <Liviu.Dudau@arm.com>,
	"ddaney@caviumnetworks.com" <ddaney@caviumnetworks.com>,
	"jeremy.linton@arm.com" <jeremy.linton@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"robert.richter@caviumnetworks.com"
	<robert.richter@caviumnetworks.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"msalter@redhat.com" <msalter@redhat.com>,
	Wangyijing <wangyijing@huawei.com>,
	"mw@semihalf.com" <mw@semihalf.com>,
	"andrea.gallo@linaro.org" <andrea.gallo@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH V7 00/11] Support for generic ACPI based PCI host controller
Date: Tue, 24 May 2016 00:20:55 -0400	[thread overview]
Message-ID: <f9c8b16b-3027-d90d-c0d1-6afcd45c1e0f@redhat.com> (raw)
In-Reply-To: <20160523105655.GA22902@red-moon>

On 05/23/2016 06:56 AM, Lorenzo Pieralisi wrote:

> The only way this can be implemented is by pretending that the
> ACPI/PCI arch/arm64 implementation is generic code (that's what this
> series does), move it to /drivers (where it is in this series), and
> implement _DSD vendor specific bindings (per HID) to set-up the pci
> operations; whether this solution should go upstream, given that it
> is just a short-term solution for early platforms bugs, it is another
> story and my personal answer is no.

Just for completeness, let me also followup to this one.

We have real, shipping, systems in the field based on ARMv8. For
example, HPE Moonshot ProLiant m400. Not everyone loves the first
generation of anything (Applied get a lot of stick, but the reality is
that someone had to go first, and whoever that was was going to learn
all of the lessons that others don't need to) but it is out there and we
need an upstream kernel solution that includes support for that.

In the server world, we (speaking as a major distro vendor here) are not
going to entertain a situation in which non-upstream patches are needed
to even boot a platform. That simply won't do. We need to separate out
the issue of getting the core in place from the quirks, but then we need
quirks that include support for all early ARMv8 platforms that are out
there today. If we can't get to a point where a Moonshot[0] cartridge
boots out of the box with an upstream kernel, let's just give up and do
something else instead :) (joke)

Jon.

[0] HPE have been *amazingly* patient with this stuff. They've reworked
the firmware when someone (cough) pointed out that the early stuff
they'd been fed was not built according to the standards (U-Boot). They
have *really good* UEFI and ACPI enabled firmware that is running
RHEL(SA) great. But that's not good enough. We don't ship a distro with
hacks. We ship a distro derived from upstream code (although we might
have to backport a lot of stuff later). There's wiggle room, but there
is not wiggle room for core platforms. On ARM, users and developers
*will* be able to take an upstream kernel and boot it on their RHEL
install. And they *will* be able to reproduce problems against upstream,
and help develop against upstream, and further the upstream first
mentality in the ARM ecosystem. There will not be "oh well, it runs RHEL
so that's good enough for the early generation...".

-- 
Computer Architect | Sent from my Fedora powered laptop

WARNING: multiple messages have this Message-ID (diff)
From: jcm@redhat.com (Jon Masters)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V7 00/11] Support for generic ACPI based PCI host controller
Date: Tue, 24 May 2016 00:20:55 -0400	[thread overview]
Message-ID: <f9c8b16b-3027-d90d-c0d1-6afcd45c1e0f@redhat.com> (raw)
In-Reply-To: <20160523105655.GA22902@red-moon>

On 05/23/2016 06:56 AM, Lorenzo Pieralisi wrote:

> The only way this can be implemented is by pretending that the
> ACPI/PCI arch/arm64 implementation is generic code (that's what this
> series does), move it to /drivers (where it is in this series), and
> implement _DSD vendor specific bindings (per HID) to set-up the pci
> operations; whether this solution should go upstream, given that it
> is just a short-term solution for early platforms bugs, it is another
> story and my personal answer is no.

Just for completeness, let me also followup to this one.

We have real, shipping, systems in the field based on ARMv8. For
example, HPE Moonshot ProLiant m400. Not everyone loves the first
generation of anything (Applied get a lot of stick, but the reality is
that someone had to go first, and whoever that was was going to learn
all of the lessons that others don't need to) but it is out there and we
need an upstream kernel solution that includes support for that.

In the server world, we (speaking as a major distro vendor here) are not
going to entertain a situation in which non-upstream patches are needed
to even boot a platform. That simply won't do. We need to separate out
the issue of getting the core in place from the quirks, but then we need
quirks that include support for all early ARMv8 platforms that are out
there today. If we can't get to a point where a Moonshot[0] cartridge
boots out of the box with an upstream kernel, let's just give up and do
something else instead :) (joke)

Jon.

[0] HPE have been *amazingly* patient with this stuff. They've reworked
the firmware when someone (cough) pointed out that the early stuff
they'd been fed was not built according to the standards (U-Boot). They
have *really good* UEFI and ACPI enabled firmware that is running
RHEL(SA) great. But that's not good enough. We don't ship a distro with
hacks. We ship a distro derived from upstream code (although we might
have to backport a lot of stuff later). There's wiggle room, but there
is not wiggle room for core platforms. On ARM, users and developers
*will* be able to take an upstream kernel and boot it on their RHEL
install. And they *will* be able to reproduce problems against upstream,
and help develop against upstream, and further the upstream first
mentality in the ARM ecosystem. There will not be "oh well, it runs RHEL
so that's good enough for the early generation...".

-- 
Computer Architect | Sent from my Fedora powered laptop

  parent reply	other threads:[~2016-05-24  4:21 UTC|newest]

Thread overview: 239+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10 15:19 [PATCH V7 00/11] Support for generic ACPI based PCI host controller Tomasz Nowicki
2016-05-10 15:19 ` Tomasz Nowicki
2016-05-10 15:19 ` [PATCH V7 01/11] PCI: Provide common functions for ECAM mapping Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-10 15:19 ` [PATCH V7 02/11] PCI: generic, thunder: update to use generic ECAM API Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-10 15:19 ` [PATCH V7 03/11] pci, of: Move the PCI I/O space management to PCI core code Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-10 17:59   ` Rafael J. Wysocki
2016-05-10 17:59     ` Rafael J. Wysocki
2016-05-10 17:59     ` Rafael J. Wysocki
2016-05-10 17:59     ` Rafael J. Wysocki
2016-05-11  7:36     ` Tomasz Nowicki
2016-05-11  7:36       ` Tomasz Nowicki
2016-05-11  7:36       ` Tomasz Nowicki
2016-05-11  7:36       ` Tomasz Nowicki
2016-05-11 11:01       ` Arnd Bergmann
2016-05-11 11:01         ` Arnd Bergmann
2016-05-11 11:01         ` Arnd Bergmann
2016-05-11 11:01         ` Arnd Bergmann
2016-05-10 15:19 ` [PATCH V7 04/11] pci: Add new function to unmap IO resources Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-23  8:28   ` Jayachandran C
2016-05-23  8:28     ` Jayachandran C
2016-05-23  8:28     ` Jayachandran C
2016-05-10 15:19 ` [PATCH V7 05/11] acpi, pci: Support IO resources when parsing PCI host bridge resources Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-10 18:20   ` Rafael J. Wysocki
2016-05-10 18:20     ` Rafael J. Wysocki
2016-05-10 18:20     ` Rafael J. Wysocki
2016-05-10 18:20     ` Rafael J. Wysocki
2016-05-11  7:39     ` Tomasz Nowicki
2016-05-11  7:39       ` Tomasz Nowicki
2016-05-11  7:39       ` Tomasz Nowicki
2016-05-11  7:39       ` Tomasz Nowicki
2016-05-10 15:19 ` [PATCH V7 06/11] pci, acpi: Provide a way to assign bus domain number Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-10 15:19 ` [PATCH V7 07/11] pci, acpi: Handle ACPI companion assignment Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-10 18:37   ` Rafael J. Wysocki
2016-05-10 18:37     ` Rafael J. Wysocki
2016-05-10 18:37     ` Rafael J. Wysocki
2016-05-10 18:37     ` Rafael J. Wysocki
2016-05-10 18:43     ` Rafael J. Wysocki
2016-05-10 18:43       ` Rafael J. Wysocki
2016-05-10 18:43       ` Rafael J. Wysocki
2016-05-10 18:43       ` Rafael J. Wysocki
2016-05-11 10:11     ` Lorenzo Pieralisi
2016-05-11 10:11       ` Lorenzo Pieralisi
2016-05-11 10:11       ` Lorenzo Pieralisi
2016-05-11 10:11       ` Lorenzo Pieralisi
2016-05-11 20:30       ` Rafael J. Wysocki
2016-05-11 20:30         ` Rafael J. Wysocki
2016-05-11 20:30         ` Rafael J. Wysocki
2016-05-11 20:30         ` Rafael J. Wysocki
2016-05-11 22:43         ` Bjorn Helgaas
2016-05-11 22:43           ` Bjorn Helgaas
2016-05-11 22:43           ` Bjorn Helgaas
2016-05-11 22:43           ` Bjorn Helgaas
2016-05-12 10:01           ` Lorenzo Pieralisi
2016-05-12 10:01             ` Lorenzo Pieralisi
2016-05-12 10:01             ` Lorenzo Pieralisi
2016-05-12 10:01             ` Lorenzo Pieralisi
2016-05-12 10:43           ` Jayachandran C
2016-05-12 10:43             ` Jayachandran C
2016-05-12 10:43             ` Jayachandran C
2016-05-12 10:43             ` Jayachandran C
2016-05-12 11:27             ` Rafael J. Wysocki
2016-05-12 11:27               ` Rafael J. Wysocki
2016-05-12 11:27               ` Rafael J. Wysocki
2016-05-12 11:27               ` Rafael J. Wysocki
2016-05-13 10:32               ` Lorenzo Pieralisi
2016-05-13 10:32                 ` Lorenzo Pieralisi
2016-05-13 10:32                 ` Lorenzo Pieralisi
2016-05-13 10:32                 ` Lorenzo Pieralisi
2016-05-12 10:50           ` Tomasz Nowicki
2016-05-12 10:50             ` Tomasz Nowicki
2016-05-12 10:50             ` Tomasz Nowicki
2016-05-12 10:50             ` Tomasz Nowicki
2016-05-12 12:08             ` Bjorn Helgaas
2016-05-12 12:08               ` Bjorn Helgaas
2016-05-12 12:08               ` Bjorn Helgaas
2016-05-12 12:08               ` Bjorn Helgaas
2016-05-17  3:11   ` Dongdong Liu
2016-05-17  3:11     ` Dongdong Liu
2016-05-17  3:11     ` Dongdong Liu
2016-05-17 13:44     ` Tomasz Nowicki
2016-05-17 13:44       ` Tomasz Nowicki
2016-05-10 15:19 ` [PATCH V7 08/11] pci, acpi: Support for ACPI based generic PCI host controller Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-10 17:54   ` Rafael J. Wysocki
2016-05-10 17:54     ` Rafael J. Wysocki
2016-05-10 17:54     ` Rafael J. Wysocki
2016-05-10 17:54     ` Rafael J. Wysocki
2016-05-10 18:18   ` Rafael J. Wysocki
2016-05-10 18:18     ` Rafael J. Wysocki
2016-05-10 18:18     ` Rafael J. Wysocki
2016-05-10 18:18     ` Rafael J. Wysocki
2016-05-13 11:25   ` Jayachandran C
2016-05-13 11:25     ` Jayachandran C
2016-05-13 11:25     ` Jayachandran C
2016-05-13 11:31     ` Rafael J. Wysocki
2016-05-13 11:31       ` Rafael J. Wysocki
2016-05-13 11:31       ` Rafael J. Wysocki
2016-05-13 11:31       ` Rafael J. Wysocki
2016-05-13 11:42       ` Tomasz Nowicki
2016-05-13 11:42         ` Tomasz Nowicki
2016-05-13 11:42         ` Tomasz Nowicki
2016-05-13 11:42         ` Tomasz Nowicki
2016-05-14  9:07   ` Jayachandran C
2016-05-14  9:07     ` Jayachandran C
2016-05-14  9:07     ` Jayachandran C
2016-05-23 11:34     ` Tomasz Nowicki
2016-05-23 11:34       ` Tomasz Nowicki
2016-05-23 11:34       ` Tomasz Nowicki
2016-05-19 16:56   ` Matthias Brugger
2016-05-19 16:56     ` Matthias Brugger
2016-05-10 15:19 ` [PATCH V7 09/11] arm64, pci, acpi: ACPI support for legacy IRQs parsing and consolidation with DT code Tomasz Nowicki
2016-05-10 15:19   ` Tomasz Nowicki
2016-05-10 15:20 ` [PATCH V7 10/11] arm64, pci, acpi: Provide ACPI-specific prerequisites for PCI bus enumeration Tomasz Nowicki
2016-05-10 15:20   ` Tomasz Nowicki
2016-05-10 15:20 ` [PATCH V7 11/11] arm64, pci, acpi: Start using ACPI based PCI host controller driver for ARM64 Tomasz Nowicki
2016-05-10 15:20   ` Tomasz Nowicki
2016-05-11 10:41 ` [PATCH V7 00/11] Support for generic ACPI based PCI host controller Gabriele Paoloni
2016-05-11 10:41   ` Gabriele Paoloni
2016-05-11 10:41   ` Gabriele Paoloni
2016-05-11 10:41   ` Gabriele Paoloni
2016-05-11 11:08   ` Tomasz Nowicki
2016-05-11 11:08     ` Tomasz Nowicki
2016-05-11 11:08     ` Tomasz Nowicki
2016-05-11 11:08     ` Tomasz Nowicki
2016-05-11 12:53     ` Gabriele Paoloni
2016-05-11 12:53       ` Gabriele Paoloni
2016-05-11 12:53       ` Gabriele Paoloni
2016-05-11 12:53       ` Gabriele Paoloni
2016-05-20  4:41     ` Jon Masters
2016-05-20  4:41       ` Jon Masters
2016-05-20  4:41       ` Jon Masters
2016-05-20  7:37       ` Ard Biesheuvel
2016-05-20  7:37         ` Ard Biesheuvel
2016-05-20  7:37         ` Ard Biesheuvel
2016-05-20  7:37         ` Ard Biesheuvel
2016-05-20  8:01         ` Jon Masters
2016-05-20  8:01           ` Jon Masters
2016-05-20  8:01           ` Jon Masters
2016-05-20  8:01           ` Jon Masters
2016-05-20  8:28           ` Ard Biesheuvel
2016-05-20  8:28             ` Ard Biesheuvel
2016-05-20  8:28             ` Ard Biesheuvel
2016-05-20  8:28             ` Ard Biesheuvel
2016-05-20  8:40             ` Gabriele Paoloni
2016-05-20  8:40               ` Gabriele Paoloni
2016-05-20  8:40               ` Gabriele Paoloni
2016-05-20  8:40               ` Gabriele Paoloni
2016-05-20  9:14               ` Ard Biesheuvel
2016-05-20  9:14                 ` Ard Biesheuvel
2016-05-20  9:14                 ` Ard Biesheuvel
2016-05-20  9:14                 ` Ard Biesheuvel
2016-05-23 10:56                 ` Lorenzo Pieralisi
2016-05-23 10:56                   ` Lorenzo Pieralisi
2016-05-23 10:56                   ` Lorenzo Pieralisi
2016-05-23 10:56                   ` Lorenzo Pieralisi
2016-05-23 15:16                   ` Gabriele Paoloni
2016-05-23 15:16                     ` Gabriele Paoloni
2016-05-23 15:16                     ` Gabriele Paoloni
2016-05-23 15:16                     ` Gabriele Paoloni
2016-05-23 23:39                     ` Bjorn Helgaas
2016-05-23 23:39                       ` Bjorn Helgaas
2016-05-23 23:39                       ` Bjorn Helgaas
2016-05-23 23:39                       ` Bjorn Helgaas
2016-05-24  1:11                       ` Jon Masters
2016-05-24  1:11                         ` Jon Masters
2016-05-24  1:11                         ` Jon Masters
2016-05-24  1:11                         ` Jon Masters
2016-05-24  1:48                         ` Jon Masters
2016-05-24  1:48                           ` Jon Masters
2016-05-24  1:48                           ` Jon Masters
2016-05-24  1:48                           ` Jon Masters
2016-05-24 14:33                         ` Gabriele Paoloni
2016-05-24 14:33                           ` Gabriele Paoloni
2016-05-24 14:33                           ` Gabriele Paoloni
2016-05-24 14:33                           ` Gabriele Paoloni
2016-05-24  7:23                       ` Gabriele Paoloni
2016-05-24  7:23                         ` Gabriele Paoloni
2016-05-24  7:23                         ` Gabriele Paoloni
2016-05-24  7:23                         ` Gabriele Paoloni
2016-05-24 14:38                         ` Jon Masters
2016-05-24 14:38                           ` Jon Masters
2016-05-24 14:38                           ` Jon Masters
2016-05-24 14:38                           ` Jon Masters
2016-05-24 17:24                       ` Lorenzo Pieralisi
2016-05-24 17:24                         ` Lorenzo Pieralisi
2016-05-24 17:24                         ` Lorenzo Pieralisi
2016-05-24 17:24                         ` Lorenzo Pieralisi
2016-05-24 17:35                         ` Jon Masters
2016-05-24 17:35                           ` Jon Masters
2016-05-24 17:35                           ` Jon Masters
2016-05-24 17:35                           ` Jon Masters
2016-05-24 19:00                         ` Bjorn Helgaas
2016-05-24 19:00                           ` Bjorn Helgaas
2016-05-24 19:00                           ` Bjorn Helgaas
2016-05-24 19:00                           ` Bjorn Helgaas
2016-05-26  9:58                           ` Gabriele Paoloni
2016-05-26  9:58                             ` Gabriele Paoloni
2016-05-26  9:58                             ` Gabriele Paoloni
2016-05-26  9:58                             ` Gabriele Paoloni
2016-05-25  6:31                         ` Gabriele Paoloni
2016-05-25  6:31                           ` Gabriele Paoloni
2016-05-25  6:31                           ` Gabriele Paoloni
2016-05-25  6:31                           ` Gabriele Paoloni
2016-05-24  4:20                   ` Jon Masters [this message]
2016-05-24  4:20                     ` Jon Masters
2016-05-24  4:20                     ` Jon Masters
2016-05-24  4:20                     ` Jon Masters
2016-05-20  8:11         ` Gabriele Paoloni
2016-05-20  8:11           ` Gabriele Paoloni
2016-05-20  8:11           ` Gabriele Paoloni
2016-05-20  8:11           ` Gabriele Paoloni
2016-05-20  8:24           ` Jon Masters
2016-05-20  8:24             ` Jon Masters
2016-05-20  8:24             ` Jon Masters
2016-05-20  8:24             ` Jon Masters
2016-05-13  2:55 ` Duc Dang
2016-05-13  2:55   ` Duc Dang
2016-05-13  2:55   ` Duc Dang
2016-05-19 18:18 ` Jeremy Linton
2016-05-19 18:18   ` Jeremy Linton
2016-05-20  7:46 ` Jon Masters
2016-05-20  7:46   ` Jon Masters
2016-05-20  7:46   ` Jon Masters
2016-05-23 11:25 ` Dongdong Liu
2016-05-23 11:25   ` Dongdong Liu
2016-05-23 11:25   ` Dongdong Liu
2016-05-23 15:36 ` Sinan Kaya
2016-05-23 15:36   ` Sinan Kaya

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=f9c8b16b-3027-d90d-c0d1-6afcd45c1e0f@redhat.com \
    --to=jcm@redhat.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=ddaney@caviumnetworks.com \
    --cc=dhdang@apm.com \
    --cc=gabriele.paoloni@huawei.com \
    --cc=hanjun.guo@linaro.org \
    --cc=helgaas@kernel.org \
    --cc=jchandra@broadcom.com \
    --cc=jeremy.linton@arm.com \
    --cc=linaro-acpi@lists.linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=okaya@codeaurora.org \
    --cc=rafael@kernel.org \
    --cc=tn@semihalf.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.