All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Masters <jcm@redhat.com>
To: Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Nowicki <tn@semihalf.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
	"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
	"Lorenzo.Pieralisi@arm.com" <Lorenzo.Pieralisi@arm.com>,
	"okaya@codeaurora.org" <okaya@codeaurora.org>,
	"jiang.liu@linux.intel.com" <jiang.liu@linux.intel.com>,
	"Stefano.Stabellini@eu.citrix.com"
	<Stefano.Stabellini@eu.citrix.com>,
	"robert.richter@caviumnetworks.com"
	<robert.richter@caviumnetworks.com>,
	"mw@semihalf.com" <mw@semihalf.com>,
	"Liviu.Dudau@arm.com" <Liviu.Dudau@arm.com>,
	"ddaney@caviumnetworks.com" <ddaney@caviumnetworks.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	Wangyijing <wangyijing@huawei.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>
Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
Date: Tue, 22 Dec 2015 11:45:20 -0500	[thread overview]
Message-ID: <56797E20.2080107@redhat.com> (raw)
In-Reply-To: <56797C16.2020802@redhat.com>

On 12/22/2015 11:36 AM, Jon Masters wrote:
> On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
>> Hi Jon, thanks for replying
>>
>>> -----Original Message-----
>>> From: Jon Masters [mailto:jcm@redhat.com]
>>> Sent: 21 December 2015 23:11
>>> To: Arnd Bergmann
>>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelgaas@google.com;
>>> will.deacon@arm.com; catalin.marinas@arm.com; rjw@rjwysocki.net;
>>> hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com; okaya@codeaurora.org;
>>> jiang.liu@linux.intel.com; Stefano.Stabellini@eu.citrix.com;
>>> robert.richter@caviumnetworks.com; mw@semihalf.com; Liviu.Dudau@arm.com;
>>> ddaney@caviumnetworks.com; tglx@linutronix.de; Wangyijing;
>>> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
>>> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>>> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
>>> acpi@lists.linaro.org; jchandra@broadcom.com
>>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
>>> accessors against platfrom specific quirks.
>>>
>>> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
>>> it can be presumed that compliant platforms will provide quirks via DMI.
>>
>> Ok so you completely clarified my question 1). Many Thanks for this
> 
> No problem. One of the (many) reasons I pushed for requiring SMBIOS/DMI
> in SBBR (I was lead author of one of the early drafts of that document)
> was to make the experience ultimately equivalent across architectures.
> We already know how to do quirks and handle platform deviations, and the
> major Operating System vendors did not want to reinvent the wheel.

Additional: it is clear that more prescription is required to get the
vendors onto the bandwagon that we have with other architectures (e.g.
that other one). So there will be a Red Hat "ARM server whitepaper"
coming in the early new year that will include the kind of "server 101"
material we want to make sure people know. Things like making sure you
implement and test PCIe correctly, handle backward compatibility (you
will build hardware in the future that runs my existing OS release),
design the hardware to allow for workarounds later, etc. I expect some
other Operating System vendors to be involved in reviewing that.

Ultimately my objective is to make this whole thing dull and boring. You
will get RHEL(SA)/upstream kernels and it will either boot or it will
not. If it does not boot, vendor X screwed up their hardware. We know
this story, it's been this way for over a decade already, and that is
exactly how it is going to be with ARM servers shortly.

Jon.

WARNING: multiple messages have this Message-ID (diff)
From: Jon Masters <jcm@redhat.com>
To: Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Nowicki <tn@semihalf.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
	"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
	"Lorenzo.Pieralisi@arm.com" <Lorenzo.Pieralisi@arm.com>,
	"okaya@codeaurora.org" <okaya@codeaurora.org>,
	"jiang.liu@linux.intel.com" <jiang.liu@linux.intel.com>,
	"Stefano.Stabellini@eu.citrix.com"
	<Stefano.Stabellini@eu.citrix.com>,
	"robert.richter@caviumnetworks.com" 
	<robert.richter@caviumnetworks.com>,
	"mw@semihalf.com" <mw@semihalf.com>,
	"Liviu.Dudau@arm.com" <Liviu.Dudau@arm.com>,
	"ddaney@caviumnetworks.com" <ddaney@caviumnetworks.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	Wangyijing <wangyijing@huawei.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"msalter@redhat.com" <msalter@redhat.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
	"jchandra@broadcom.com" <jchandra@broadcom.com>
Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
Date: Tue, 22 Dec 2015 11:45:20 -0500	[thread overview]
Message-ID: <56797E20.2080107@redhat.com> (raw)
In-Reply-To: <56797C16.2020802@redhat.com>

On 12/22/2015 11:36 AM, Jon Masters wrote:
> On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
>> Hi Jon, thanks for replying
>>
>>> -----Original Message-----
>>> From: Jon Masters [mailto:jcm@redhat.com]
>>> Sent: 21 December 2015 23:11
>>> To: Arnd Bergmann
>>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelgaas@google.com;
>>> will.deacon@arm.com; catalin.marinas@arm.com; rjw@rjwysocki.net;
>>> hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com; okaya@codeaurora.org;
>>> jiang.liu@linux.intel.com; Stefano.Stabellini@eu.citrix.com;
>>> robert.richter@caviumnetworks.com; mw@semihalf.com; Liviu.Dudau@arm.com;
>>> ddaney@caviumnetworks.com; tglx@linutronix.de; Wangyijing;
>>> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
>>> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>>> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
>>> acpi@lists.linaro.org; jchandra@broadcom.com
>>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
>>> accessors against platfrom specific quirks.
>>>
>>> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
>>> it can be presumed that compliant platforms will provide quirks via DMI.
>>
>> Ok so you completely clarified my question 1). Many Thanks for this
> 
> No problem. One of the (many) reasons I pushed for requiring SMBIOS/DMI
> in SBBR (I was lead author of one of the early drafts of that document)
> was to make the experience ultimately equivalent across architectures.
> We already know how to do quirks and handle platform deviations, and the
> major Operating System vendors did not want to reinvent the wheel.

Additional: it is clear that more prescription is required to get the
vendors onto the bandwagon that we have with other architectures (e.g.
that other one). So there will be a Red Hat "ARM server whitepaper"
coming in the early new year that will include the kind of "server 101"
material we want to make sure people know. Things like making sure you
implement and test PCIe correctly, handle backward compatibility (you
will build hardware in the future that runs my existing OS release),
design the hardware to allow for workarounds later, etc. I expect some
other Operating System vendors to be involved in reviewing that.

Ultimately my objective is to make this whole thing dull and boring. You
will get RHEL(SA)/upstream kernels and it will either boot or it will
not. If it does not boot, vendor X screwed up their hardware. We know
this story, it's been this way for over a decade already, and that is
exactly how it is going to be with ARM servers shortly.

Jon.


WARNING: multiple messages have this Message-ID (diff)
From: Jon Masters <jcm@redhat.com>
To: Gabriele Paoloni <gabriele.paoloni@huawei.com>,
	Arnd Bergmann <arnd@arndb.de>
Cc: Tomasz Nowicki <tn@semihalf.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
	"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
	"Lorenzo.Pieralisi@arm.com" <Lorenzo.Pieralisi@arm.com>,
	"okaya@codeaurora.org" <okaya@codeaurora.org>,
	"jiang.liu@linux.intel.com" <jiang.liu@linux.intel.com>,
	"Stefano.Stabellini@eu.citrix.com"
	<Stefano.Stabellini@eu.citrix.com>,
	"robert.richter@caviumnetworks.com"
	<robert.richter@caviumnetworks.com>,
	"mw@semihalf.com" <mw@semihalf.com>,
	"Liviu.Dudau@arm.com" <Liviu.Dudau@arm.com>,
	"ddaney@caviumnetworks.com" <ddaney@caviumnetworks.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	Wangyijing <wangyijing@huawei.com>,
	"Suravee.Suthikulpanit@amd.com" <Suravee.Suthikulpanit@amd.com>,
	"msalter@redhat.com" <msalter@redhat.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linaro-acpi@lists.linaro.org" <linaro-acpi@lists.linaro.org>,
	"jchandra@broadcom.com" <jchandra@broadcom.com>
Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
Date: Tue, 22 Dec 2015 11:45:20 -0500	[thread overview]
Message-ID: <56797E20.2080107@redhat.com> (raw)
In-Reply-To: <56797C16.2020802@redhat.com>

On 12/22/2015 11:36 AM, Jon Masters wrote:
> On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
>> Hi Jon, thanks for replying
>>
>>> -----Original Message-----
>>> From: Jon Masters [mailto:jcm@redhat.com]
>>> Sent: 21 December 2015 23:11
>>> To: Arnd Bergmann
>>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelgaas@google.com;
>>> will.deacon@arm.com; catalin.marinas@arm.com; rjw@rjwysocki.net;
>>> hanjun.guo@linaro.org; Lorenzo.Pieralisi@arm.com; okaya@codeaurora.org;
>>> jiang.liu@linux.intel.com; Stefano.Stabellini@eu.citrix.com;
>>> robert.richter@caviumnetworks.com; mw@semihalf.com; Liviu.Dudau@arm.com;
>>> ddaney@caviumnetworks.com; tglx@linutronix.de; Wangyijing;
>>> Suravee.Suthikulpanit@amd.com; msalter@redhat.com; linux-
>>> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
>>> acpi@vger.kernel.org; linux-kernel@vger.kernel.org; linaro-
>>> acpi@lists.linaro.org; jchandra@broadcom.com
>>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
>>> accessors against platfrom specific quirks.
>>>
>>> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
>>> it can be presumed that compliant platforms will provide quirks via DMI.
>>
>> Ok so you completely clarified my question 1). Many Thanks for this
> 
> No problem. One of the (many) reasons I pushed for requiring SMBIOS/DMI
> in SBBR (I was lead author of one of the early drafts of that document)
> was to make the experience ultimately equivalent across architectures.
> We already know how to do quirks and handle platform deviations, and the
> major Operating System vendors did not want to reinvent the wheel.

Additional: it is clear that more prescription is required to get the
vendors onto the bandwagon that we have with other architectures (e.g.
that other one). So there will be a Red Hat "ARM server whitepaper"
coming in the early new year that will include the kind of "server 101"
material we want to make sure people know. Things like making sure you
implement and test PCIe correctly, handle backward compatibility (you
will build hardware in the future that runs my existing OS release),
design the hardware to allow for workarounds later, etc. I expect some
other Operating System vendors to be involved in reviewing that.

Ultimately my objective is to make this whole thing dull and boring. You
will get RHEL(SA)/upstream kernels and it will either boot or it will
not. If it does not boot, vendor X screwed up their hardware. We know
this story, it's been this way for over a decade already, and that is
exactly how it is going to be with ARM servers shortly.

Jon.


WARNING: multiple messages have this Message-ID (diff)
From: jcm@redhat.com (Jon Masters)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
Date: Tue, 22 Dec 2015 11:45:20 -0500	[thread overview]
Message-ID: <56797E20.2080107@redhat.com> (raw)
In-Reply-To: <56797C16.2020802@redhat.com>

On 12/22/2015 11:36 AM, Jon Masters wrote:
> On 12/22/2015 04:29 AM, Gabriele Paoloni wrote:
>> Hi Jon, thanks for replying
>>
>>> -----Original Message-----
>>> From: Jon Masters [mailto:jcm at redhat.com]
>>> Sent: 21 December 2015 23:11
>>> To: Arnd Bergmann
>>> Cc: Gabriele Paoloni; Tomasz Nowicki; bhelgaas at google.com;
>>> will.deacon at arm.com; catalin.marinas at arm.com; rjw at rjwysocki.net;
>>> hanjun.guo at linaro.org; Lorenzo.Pieralisi at arm.com; okaya at codeaurora.org;
>>> jiang.liu at linux.intel.com; Stefano.Stabellini at eu.citrix.com;
>>> robert.richter at caviumnetworks.com; mw at semihalf.com; Liviu.Dudau at arm.com;
>>> ddaney at caviumnetworks.com; tglx at linutronix.de; Wangyijing;
>>> Suravee.Suthikulpanit at amd.com; msalter at redhat.com; linux-
>>> pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
>>> acpi at vger.kernel.org; linux-kernel at vger.kernel.org; linaro-
>>> acpi at lists.linaro.org; jchandra at broadcom.com
>>> Subject: Re: [PATCH V2 22/23] pci, acpi: Match PCI config space
>>> accessors against platfrom specific quirks.
>>>
>>> Sorry for top-posting. A quick note that SMBIOS3 is required by SBBR so
>>> it can be presumed that compliant platforms will provide quirks via DMI.
>>
>> Ok so you completely clarified my question 1). Many Thanks for this
> 
> No problem. One of the (many) reasons I pushed for requiring SMBIOS/DMI
> in SBBR (I was lead author of one of the early drafts of that document)
> was to make the experience ultimately equivalent across architectures.
> We already know how to do quirks and handle platform deviations, and the
> major Operating System vendors did not want to reinvent the wheel.

Additional: it is clear that more prescription is required to get the
vendors onto the bandwagon that we have with other architectures (e.g.
that other one). So there will be a Red Hat "ARM server whitepaper"
coming in the early new year that will include the kind of "server 101"
material we want to make sure people know. Things like making sure you
implement and test PCIe correctly, handle backward compatibility (you
will build hardware in the future that runs my existing OS release),
design the hardware to allow for workarounds later, etc. I expect some
other Operating System vendors to be involved in reviewing that.

Ultimately my objective is to make this whole thing dull and boring. You
will get RHEL(SA)/upstream kernels and it will either boot or it will
not. If it does not boot, vendor X screwed up their hardware. We know
this story, it's been this way for over a decade already, and that is
exactly how it is going to be with ARM servers shortly.

Jon.

  reply	other threads:[~2015-12-22 16:45 UTC|newest]

Thread overview: 171+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16 15:16 [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Tomasz Nowicki
2015-12-16 15:16 ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 01/23] x86, pci: Reorder logic of pci_mmconfig_insert() function Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 02/23] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 03/23] pci, acpi, mcfg: Provide generic implementation of MCFG code initialization Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 04/23] x86, pci: mmconfig_{32,64}.c code refactoring - remove code duplication Tomasz Nowicki
2015-12-16 15:16   ` [PATCH V2 04/23] x86, pci: mmconfig_{32, 64}.c " Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 05/23] x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM driver Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-17 10:25   ` Tomasz Nowicki
2015-12-17 10:25     ` Tomasz Nowicki
2015-12-17 10:40     ` Tomasz Nowicki
2015-12-17 10:40       ` Tomasz Nowicki
2015-12-21 18:12   ` Stefano Stabellini
2015-12-21 18:12     ` Stefano Stabellini
2015-12-21 18:12     ` Stefano Stabellini
2015-12-22  8:34     ` Tomasz Nowicki
2015-12-22  8:34       ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 07/23] pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 08/23] arm64, acpi: Use empty PCI config space accessors from mcfg.c file Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 09/23] pci, acpi, ecam: Add flag to indicate whether ECAM region was hot added or not Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 10/23] x86, pci: Cleanup platform specific MCFG data using previously added ECAM hot_added flag Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 11/23] arm64, pci: Remove useless boot time IRQ assignment when booting with DT Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2016-01-12 13:50   ` Lorenzo Pieralisi
2016-01-12 13:50     ` Lorenzo Pieralisi
2016-01-12 16:13     ` Tomasz Nowicki
2016-01-12 16:13       ` Tomasz Nowicki
2016-01-12 17:56       ` David Daney
2016-01-12 17:56         ` David Daney
2016-01-12 17:56         ` David Daney
2016-01-13  9:43         ` Tomasz Nowicki
2016-01-13  9:43           ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 12/23] pci, acpi: Move ACPI host bridge device companion assignment to core code Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 13/23] x86, ia64, pci: Remove ACPI companion device from platform specific data Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 14/23] pci, acpi: Provide generic way to assign bus domain number Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 15/23] x86, ia64, pci: Convert arches to use PCI_DOMAINS_GENERIC Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 16/23] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 17/23] acpi, mcfg: Implement two calls that might be used to inject/remove MCFG region Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 18/23] x86, acpi, pci: Use equivalent function introduced in previous patch Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 19/23] acpi, mcfg: Add default PCI config accessors implementation and initial support for related quirks Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 20/23] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 21/23] pci, acpi: Support for ACPI based PCI hostbridge init Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-18 12:40   ` Arnd Bergmann
2015-12-18 12:40     ` Arnd Bergmann
2015-12-21 10:21     ` Tomasz Nowicki
2015-12-21 10:21       ` Tomasz Nowicki
2015-12-16 15:16 ` [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-21 11:47   ` Gabriele Paoloni
2015-12-21 11:47     ` Gabriele Paoloni
2015-12-21 11:47     ` Gabriele Paoloni
2015-12-21 14:10     ` Arnd Bergmann
2015-12-21 14:10       ` Arnd Bergmann
2015-12-21 14:10       ` Arnd Bergmann
2015-12-21 14:10       ` Arnd Bergmann
2015-12-21 17:29       ` David Daney
2015-12-21 17:29         ` David Daney
2015-12-21 17:29         ` David Daney
2015-12-21 17:29         ` David Daney
2015-12-21 22:42         ` Arnd Bergmann
2015-12-21 22:42           ` Arnd Bergmann
2015-12-21 22:42           ` Arnd Bergmann
2015-12-21 22:42           ` Arnd Bergmann
2015-12-21 23:24           ` Jon Masters
2015-12-21 23:24             ` Jon Masters
2015-12-21 23:24             ` Jon Masters
2015-12-21 23:24             ` Jon Masters
2015-12-21 23:10       ` Jon Masters
2015-12-21 23:10         ` Jon Masters
2015-12-21 23:10         ` Jon Masters
2015-12-21 23:10         ` Jon Masters
2015-12-22  8:45         ` Tomasz Nowicki
2015-12-22  8:45           ` Tomasz Nowicki
2015-12-22  8:45           ` Tomasz Nowicki
2015-12-22  8:45           ` Tomasz Nowicki
2015-12-22  9:29         ` Gabriele Paoloni
2015-12-22  9:29           ` Gabriele Paoloni
2015-12-22  9:29           ` Gabriele Paoloni
2015-12-22  9:29           ` Gabriele Paoloni
2015-12-22 16:36           ` Jon Masters
2015-12-22 16:36             ` Jon Masters
2015-12-22 16:36             ` Jon Masters
2015-12-22 16:36             ` Jon Masters
2015-12-22 16:45             ` Jon Masters [this message]
2015-12-22 16:45               ` Jon Masters
2015-12-22 16:45               ` Jon Masters
2015-12-22 16:45               ` Jon Masters
2015-12-22 17:49               ` Gabriele Paoloni
2015-12-22 17:49                 ` Gabriele Paoloni
2015-12-22 17:49                 ` Gabriele Paoloni
2015-12-22 17:49                 ` Gabriele Paoloni
2015-12-22 10:20     ` Tomasz Nowicki
2015-12-22 10:20       ` Tomasz Nowicki
2015-12-22 10:20       ` Tomasz Nowicki
2015-12-22 14:48       ` Gabriele Paoloni
2015-12-22 14:48         ` Gabriele Paoloni
2015-12-22 14:48         ` Gabriele Paoloni
2015-12-23  9:38         ` Hanjun Guo
2015-12-23  9:38           ` Hanjun Guo
2015-12-23  9:38           ` Hanjun Guo
2016-01-08 14:16   ` Mark Salter
2016-01-08 14:16     ` Mark Salter
2016-01-08 14:36     ` Tomasz Nowicki
2016-01-08 14:36       ` Tomasz Nowicki
2016-01-08 14:51       ` Mark Salter
2016-01-08 14:51         ` Mark Salter
2016-01-08 14:42     ` Jeremy Linton
2016-01-08 14:42       ` Jeremy Linton
2016-01-08 14:42       ` Jeremy Linton
2016-01-08 15:01     ` Mark Rutland
2016-01-08 15:01       ` Mark Rutland
2016-01-08 15:01       ` Mark Rutland
2016-01-08 15:12       ` Mark Rutland
2016-01-08 15:12         ` Mark Rutland
2016-01-08 16:07         ` Mark Salter
2016-01-08 16:07           ` Mark Salter
2015-12-16 15:16 ` [PATCH V2 23/23] arm64, pci, acpi: Start using ACPI based PCI host bridge driver for ARM64 Tomasz Nowicki
2015-12-16 15:16   ` Tomasz Nowicki
2015-12-17 21:24 ` [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Sinan Kaya
2015-12-17 21:24   ` Sinan Kaya
2015-12-18 12:26   ` Tomasz Nowicki
2015-12-18 12:26     ` Tomasz Nowicki
2015-12-18 18:56     ` okaya
2015-12-18 18:56       ` okaya at codeaurora.org
2015-12-21 10:37       ` Tomasz Nowicki
2015-12-21 10:37         ` Tomasz Nowicki
2015-12-21 12:10       ` Lorenzo Pieralisi
2015-12-21 12:10         ` Lorenzo Pieralisi
2015-12-21 12:42         ` Tomasz Nowicki
2015-12-21 12:42           ` Tomasz Nowicki
2015-12-21 14:15           ` Arnd Bergmann
2015-12-21 14:15             ` Arnd Bergmann
2015-12-21 15:26             ` Okaya
2015-12-21 15:26               ` Okaya at codeaurora.org
2015-12-21 22:39               ` Arnd Bergmann
2015-12-21 22:39                 ` Arnd Bergmann
2016-01-11 15:39               ` Lorenzo Pieralisi
2016-01-11 15:39                 ` Lorenzo Pieralisi
2016-01-11 15:56                 ` Sinan Kaya
2016-01-11 15:56                   ` Sinan Kaya
2016-01-12 14:30                   ` Arnd Bergmann
2016-01-12 14:30                     ` Arnd Bergmann
2016-01-12 18:38                     ` Lorenzo Pieralisi
2016-01-12 18:38                       ` Lorenzo Pieralisi
2016-01-12 21:37                       ` Arnd Bergmann
2016-01-12 21:37                         ` Arnd Bergmann
2016-01-11 16:09             ` Lorenzo Pieralisi
2016-01-11 16:09               ` Lorenzo Pieralisi

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=56797E20.2080107@redhat.com \
    --to=jcm@redhat.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=Lorenzo.Pieralisi@arm.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=ddaney@caviumnetworks.com \
    --cc=gabriele.paoloni@huawei.com \
    --cc=hanjun.guo@linaro.org \
    --cc=jiang.liu@linux.intel.com \
    --cc=mw@semihalf.com \
    --cc=okaya@codeaurora.org \
    --cc=rjw@rjwysocki.net \
    --cc=robert.richter@caviumnetworks.com \
    --cc=tglx@linutronix.de \
    --cc=tn@semihalf.com \
    --cc=wangyijing@huawei.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.