From: Mark Salter <msalter@redhat.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Sinan Kaya <okaya@codeaurora.org>
Cc: Tomasz Nowicki <tn@semihalf.com>,
bhelgaas@google.com, arnd@arndb.de, will.deacon@arm.com,
catalin.marinas@arm.com, rjw@rjwysocki.net,
hanjun.guo@linaro.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@huawei.com,
Suravee.Suthikulpanit@amd.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, jcm@redhat.com
Subject: Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Date: Thu, 14 Jan 2016 11:38:44 -0500 [thread overview]
Message-ID: <1452789524.28109.24.camel@redhat.com> (raw)
In-Reply-To: <20160114161238.GA20706@red-moon>
On Thu, 2016-01-14 at 16:12 +0000, Lorenzo Pieralisi wrote:
> On Thu, Jan 14, 2016 at 10:38:19AM -0500, Sinan Kaya wrote:
> > On 1/14/2016 10:29 AM, Mark Salter wrote:
> > On Wed, 2016-01-13 at 14:20 +0100, Tomasz Nowicki wrote:
> > > IO resources on Mustang get disabled unless I do:
> > >
> > > @@ -126,9 +126,10 @@ static void acpi_dev_ioresource_flags(struct
> > > resource *res, u64 len, if (!acpi_dev_resource_len_valid(res->start,
> > > res->end, len, true)) res->flags |= IORESOURCE_DISABLED |
> > > IORESOURCE_UNSET;
> > >
> > > +#if 0 if (res->end >= 0x10003) res->flags |= IORESOURCE_DISABLED |
> > > IORESOURCE_UNSET; - +#endif
> > >
> > > res->end is way beyond 0x10003 on Mustang:
> > >
> > > pci_bus 0000:00: root bus resource [io 0x0000-0xffff window] (bus
> > > address [0x10000000-0x1000ffff])
> > >
> > >
> >
> > Join the club. I complained about this and I got the message that we
> > just do what Intel does. See Arnd Bergmann's reply.
> >
> > [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI
> > hostbridge init based on ACPI
> >
> > 1/12/2016 9:30 AM
> >
> > It is an artificial limit coming from the x86 world introduced into
> > common code.
>
> Guys, I think you are mixing things up here, we discussed this to
> death, read the archives please.
>
> The ACPI IO descriptors AddressMinimum/AddressMaximum describe
> the IO space PCI bus addresses. The AddressTranslation field
> provides the PCI IO space -> CPU physical address translation, or
> put it differently, the secondary to primary bus translation in
> ACPI jargon, that's how ACPI tables must be written for IO space,
> at least that's what IA64 does (and on ia64 IO space is memory
> mapped, as on arm64).
>
> I bet APM IO descriptors specify the *CPU* physical address in
> the AddressMinimum field, and that's where the problem lies.
>
You would lose that bet. AddressMinimum/Maximum describe the
PCI bus addresses.
QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
0x0000000000000000, // Granularity
0x0000000010000000, // Range Minimum
0x000000001000FFFF, // Range Maximum
0x000000E000000000, // Translation Offset
0x0000000000010000, // Length
,, , TypeStatic)
> Jiang's patch:
>
> https://lkml.org/lkml/2015/12/16/249
>
> parses the IO descriptors and stores the AddressMinimum, AddressMaximum
> in the IO resource (with AddressTranslation as offset which must be the
> *CPU* physical address mapping IO), from the log above it seems to me in
> AddressMinimum APM specifies the *CPU* physical address generating IO
> cycles.
>
> All in all, I was right to fear this would happen, and I already
> raised the point within the ACPI spec working group, ACPI IO
> descriptors specification is ambiguous and we must agree on how
> they have to be specified once for all.
>
> Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Mark Salter <msalter@redhat.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Sinan Kaya <okaya@codeaurora.org>
Cc: Tomasz Nowicki <tn@semihalf.com>,
bhelgaas@google.com, arnd@arndb.de, will.deacon@arm.com,
catalin.marinas@arm.com, rjw@rjwysocki.net,
hanjun.guo@linaro.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@huawei.com,
Suravee.Suthikulpanit@amd.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, jcm@redhat.com
Subject: Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Date: Thu, 14 Jan 2016 11:38:44 -0500 [thread overview]
Message-ID: <1452789524.28109.24.camel@redhat.com> (raw)
In-Reply-To: <20160114161238.GA20706@red-moon>
On Thu, 2016-01-14 at 16:12 +0000, Lorenzo Pieralisi wrote:
> On Thu, Jan 14, 2016 at 10:38:19AM -0500, Sinan Kaya wrote:
> > On 1/14/2016 10:29 AM, Mark Salter wrote:
> > On Wed, 2016-01-13 at 14:20 +0100, Tomasz Nowicki wrote:
> > > IO resources on Mustang get disabled unless I do:
> > >
> > > @@ -126,9 +126,10 @@ static void acpi_dev_ioresource_flags(struct
> > > resource *res, u64 len, if (!acpi_dev_resource_len_valid(res->start,
> > > res->end, len, true)) res->flags |= IORESOURCE_DISABLED |
> > > IORESOURCE_UNSET;
> > >
> > > +#if 0 if (res->end >= 0x10003) res->flags |= IORESOURCE_DISABLED |
> > > IORESOURCE_UNSET; - +#endif
> > >
> > > res->end is way beyond 0x10003 on Mustang:
> > >
> > > pci_bus 0000:00: root bus resource [io 0x0000-0xffff window] (bus
> > > address [0x10000000-0x1000ffff])
> > >
> > >
> >
> > Join the club. I complained about this and I got the message that we
> > just do what Intel does. See Arnd Bergmann's reply.
> >
> > [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI
> > hostbridge init based on ACPI
> >
> > 1/12/2016 9:30 AM
> >
> > It is an artificial limit coming from the x86 world introduced into
> > common code.
>
> Guys, I think you are mixing things up here, we discussed this to
> death, read the archives please.
>
> The ACPI IO descriptors AddressMinimum/AddressMaximum describe
> the IO space PCI bus addresses. The AddressTranslation field
> provides the PCI IO space -> CPU physical address translation, or
> put it differently, the secondary to primary bus translation in
> ACPI jargon, that's how ACPI tables must be written for IO space,
> at least that's what IA64 does (and on ia64 IO space is memory
> mapped, as on arm64).
>
> I bet APM IO descriptors specify the *CPU* physical address in
> the AddressMinimum field, and that's where the problem lies.
>
You would lose that bet. AddressMinimum/Maximum describe the
PCI bus addresses.
QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
0x0000000000000000, // Granularity
0x0000000010000000, // Range Minimum
0x000000001000FFFF, // Range Maximum
0x000000E000000000, // Translation Offset
0x0000000000010000, // Length
,, , TypeStatic)
> Jiang's patch:
>
> https://lkml.org/lkml/2015/12/16/249
>
> parses the IO descriptors and stores the AddressMinimum, AddressMaximum
> in the IO resource (with AddressTranslation as offset which must be the
> *CPU* physical address mapping IO), from the log above it seems to me in
> AddressMinimum APM specifies the *CPU* physical address generating IO
> cycles.
>
> All in all, I was right to fear this would happen, and I already
> raised the point within the ACPI spec working group, ACPI IO
> descriptors specification is ambiguous and we must agree on how
> they have to be specified once for all.
>
> Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: msalter@redhat.com (Mark Salter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Date: Thu, 14 Jan 2016 11:38:44 -0500 [thread overview]
Message-ID: <1452789524.28109.24.camel@redhat.com> (raw)
In-Reply-To: <20160114161238.GA20706@red-moon>
On Thu, 2016-01-14 at 16:12 +0000, Lorenzo Pieralisi wrote:
> On Thu, Jan 14, 2016 at 10:38:19AM -0500, Sinan Kaya wrote:
> > On 1/14/2016 10:29 AM, Mark Salter wrote:
> > On Wed, 2016-01-13 at 14:20 +0100, Tomasz Nowicki wrote:
> > > IO resources on Mustang get disabled unless I do:
> > >
> > > @@ -126,9 +126,10 @@ static void acpi_dev_ioresource_flags(struct
> > > resource *res, u64 len, if (!acpi_dev_resource_len_valid(res->start,
> > > res->end, len, true)) res->flags |= IORESOURCE_DISABLED |
> > > IORESOURCE_UNSET;
> > >
> > > +#if 0 if (res->end >= 0x10003) res->flags |= IORESOURCE_DISABLED |
> > > IORESOURCE_UNSET; - +#endif
> > >
> > > res->end is way beyond 0x10003 on Mustang:
> > >
> > > pci_bus 0000:00: root bus resource [io??0x0000-0xffff window] (bus
> > > address [0x10000000-0x1000ffff])
> > >
> > >
> >
> > Join the club. I complained about this and I got the message that we
> > just do what Intel does.??See Arnd Bergmann's reply.
> >
> > [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI
> > hostbridge init based on ACPI
> >
> > 1/12/2016 9:30 AM
> >
> > It is an artificial limit coming from the x86 world introduced into
> > common code.
>
> Guys, I think you are mixing things up here, we discussed this to
> death, read the archives please.
>
> The ACPI IO descriptors AddressMinimum/AddressMaximum describe
> the IO space PCI bus addresses. The AddressTranslation field
> provides the PCI IO space -> CPU physical address translation, or
> put it differently, the secondary to primary bus translation in
> ACPI jargon, that's how ACPI tables must be written for IO space,
> at least that's what IA64 does (and on ia64 IO space is memory
> mapped, as on arm64).
>
> I bet APM IO descriptors specify the *CPU* physical address in
> the AddressMinimum field, and that's where the problem lies.
>
You would lose that bet. AddressMinimum/Maximum describe the
PCI bus addresses.
? ? ? ? ? ? ? ? QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
????????????????????0x0000000000000000, // Granularity
????????????????????0x0000000010000000, // Range Minimum
????????????????????0x000000001000FFFF, // Range Maximum
????????????????????0x000000E000000000, // Translation Offset
????????????????????0x0000000000010000, // Length
????????????????????,, , TypeStatic)
> Jiang's patch:
>
> https://lkml.org/lkml/2015/12/16/249
>
> parses the IO descriptors and stores the AddressMinimum, AddressMaximum
> in the IO resource (with AddressTranslation as offset which must be the
> *CPU* physical address mapping IO), from the log above it seems to me in
> AddressMinimum APM specifies the *CPU* physical address generating IO
> cycles.
>
> All in all, I was right to fear this would happen, and I already
> raised the point within the ACPI spec working group, ACPI IO
> descriptors specification is ambiguous and we must agree on how
> they have to be specified once for all.
>
> Lorenzo
next prev parent reply other threads:[~2016-01-14 16:38 UTC|newest]
Thread overview: 184+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 13:20 [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 01/21] x86, pci: Reorder logic of pci_mmconfig_insert() function Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 02/21] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 03/21] pci, acpi, mcfg: Provide generic implementation of MCFG code initialization Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 04/21] x86, pci: mmconfig_{32,64}.c code refactoring - remove code duplication Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 04/21] x86, pci: mmconfig_{32, 64}.c " Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 05/21] x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM driver Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 06/21] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 07/21] pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 08/21] arm64, acpi: Use empty PCI config space accessors from mcfg.c file Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 09/21] pci, acpi, ecam: Add flag to indicate whether ECAM region was hot added or not Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 10/21] x86, pci: Cleanup platform specific MCFG data using previously added ECAM hot_added flag Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-19 16:02 ` Lorenzo Pieralisi
2016-01-19 16:02 ` Lorenzo Pieralisi
2016-01-20 11:20 ` Tomasz Nowicki
2016-01-20 11:20 ` Tomasz Nowicki
2016-01-20 12:38 ` Lorenzo Pieralisi
2016-01-20 12:38 ` Lorenzo Pieralisi
2016-01-20 13:40 ` Tomasz Nowicki
2016-01-20 13:40 ` Tomasz Nowicki
2016-01-20 14:22 ` Lorenzo Pieralisi
2016-01-20 14:22 ` Lorenzo Pieralisi
2016-01-20 14:41 ` Tomasz Nowicki
2016-01-20 14:41 ` Tomasz Nowicki
2016-01-27 17:42 ` Lorenzo Pieralisi
2016-01-27 17:42 ` Lorenzo Pieralisi
2016-01-27 17:42 ` Lorenzo Pieralisi
2016-01-13 13:20 ` [PATCH V3 12/21] x86, ia64, pci: Remove ACPI companion device from platform specific data Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-13 13:20 ` [PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number Tomasz Nowicki
2016-01-13 13:20 ` Tomasz Nowicki
2016-01-21 18:22 ` Lorenzo Pieralisi
2016-01-21 18:22 ` Lorenzo Pieralisi
2016-01-21 18:38 ` Tomasz Nowicki
2016-01-21 18:38 ` Tomasz Nowicki
2016-01-22 11:25 ` Lorenzo Pieralisi
2016-01-22 11:25 ` Lorenzo Pieralisi
2016-01-13 13:21 ` [PATCH V3 14/21] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation Tomasz Nowicki
2016-01-13 13:21 ` Tomasz Nowicki
2016-01-14 16:33 ` Lorenzo Pieralisi
2016-01-14 16:33 ` Lorenzo Pieralisi
2016-01-14 17:45 ` Tomasz Nowicki
2016-01-14 17:45 ` Tomasz Nowicki
2016-01-13 13:21 ` [PATCH V3 15/21] acpi, mcfg: Implement two calls that might be used to inject/remove MCFG region Tomasz Nowicki
2016-01-13 13:21 ` Tomasz Nowicki
2016-01-13 13:21 ` [PATCH V3 16/21] x86, acpi, pci: Use equivalent function introduced in previous patch Tomasz Nowicki
2016-01-13 13:21 ` Tomasz Nowicki
2016-01-13 13:21 ` [PATCH V3 17/21] acpi, mcfg: Add default PCI config accessors implementation and initial support for related quirks Tomasz Nowicki
2016-01-13 13:21 ` Tomasz Nowicki
2016-01-13 13:21 ` [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources Tomasz Nowicki
2016-01-13 13:21 ` Tomasz Nowicki
2016-01-14 12:13 ` Lorenzo Pieralisi
2016-01-14 12:13 ` Lorenzo Pieralisi
2016-01-14 12:13 ` Lorenzo Pieralisi
2016-01-19 12:20 ` Lorenzo Pieralisi
2016-01-19 12:20 ` Lorenzo Pieralisi
2016-01-19 12:20 ` Lorenzo Pieralisi
2016-01-25 9:52 ` Lorenzo Pieralisi
2016-01-25 9:52 ` Lorenzo Pieralisi
2016-01-25 16:57 ` Mark Salter
2016-01-25 16:57 ` Mark Salter
2016-01-25 16:57 ` Mark Salter
2016-01-28 10:23 ` Hanjun Guo
2016-01-28 10:23 ` Hanjun Guo
2016-01-13 13:21 ` [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init Tomasz Nowicki
2016-01-13 13:21 ` Tomasz Nowicki
2016-01-15 9:57 ` Hanjun Guo
2016-01-15 9:57 ` Hanjun Guo
2016-01-18 9:57 ` Tomasz Nowicki
2016-01-18 9:57 ` Tomasz Nowicki
2016-01-18 9:25 ` liudongdong (C)
2016-01-18 9:25 ` liudongdong (C)
2016-01-18 9:25 ` liudongdong (C)
2016-01-18 10:34 ` Tomasz Nowicki
2016-01-18 10:34 ` Tomasz Nowicki
2016-01-19 11:58 ` Lorenzo Pieralisi
2016-01-19 11:58 ` Lorenzo Pieralisi
2016-01-20 15:01 ` Tomasz Nowicki
2016-01-20 15:01 ` Tomasz Nowicki
2016-01-13 13:21 ` [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks Tomasz Nowicki
2016-01-13 13:21 ` Tomasz Nowicki
2016-01-14 15:36 ` Mark Salter
2016-01-14 15:36 ` Mark Salter
2016-01-18 12:41 ` Tomasz Nowicki
2016-01-18 12:41 ` Tomasz Nowicki
2016-01-19 1:49 ` liudongdong (C)
2016-01-19 1:49 ` liudongdong (C)
2016-01-19 1:49 ` liudongdong (C)
2016-01-19 7:55 ` Tomasz Nowicki
2016-01-19 7:55 ` Tomasz Nowicki
2016-01-19 7:55 ` Tomasz Nowicki
2016-01-19 8:52 ` liudongdong (C)
2016-01-19 8:52 ` liudongdong (C)
2016-01-19 8:52 ` liudongdong (C)
2016-01-19 19:54 ` [PATCH] pci, acpi: QDF2xxx 32 bit config space accessors Christopher Covington
2016-01-19 20:19 ` Christopher Covington
2016-02-05 16:00 ` [PATCH v2] acpi: pci: QDF2432 " Christopher Covington
2016-01-13 13:21 ` [PATCH V3 21/21] arm64, pci, acpi: Start using ACPI based PCI host bridge driver for ARM64 Tomasz Nowicki
2016-01-13 13:21 ` Tomasz Nowicki
2016-01-13 15:24 ` [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Sinan Kaya
2016-01-13 15:24 ` Sinan Kaya
2016-01-13 15:27 ` Tomasz Nowicki
2016-01-13 15:27 ` Tomasz Nowicki
2016-01-14 13:44 ` Graeme Gregory
2016-01-14 13:44 ` Graeme Gregory
2016-01-14 14:00 ` Catalin Marinas
2016-01-14 14:00 ` Catalin Marinas
2016-01-14 14:09 ` Mark Salter
2016-01-14 14:09 ` Mark Salter
2016-01-14 14:09 ` Mark Salter
2016-01-14 14:50 ` Catalin Marinas
2016-01-14 14:50 ` Catalin Marinas
2016-01-14 14:50 ` Catalin Marinas
2016-01-14 14:59 ` Mark Salter
2016-01-14 14:59 ` Mark Salter
2016-01-14 14:01 ` Mark Salter
2016-01-14 14:01 ` Mark Salter
2016-01-14 14:15 ` Graeme Gregory
2016-01-14 14:15 ` Graeme Gregory
2016-01-14 14:24 ` Mark Salter
2016-01-14 14:24 ` Mark Salter
2016-01-15 12:12 ` Graeme Gregory
2016-01-15 12:12 ` Graeme Gregory
2016-01-15 12:12 ` Graeme Gregory
2016-01-18 14:04 ` Graeme Gregory
2016-01-18 14:04 ` Graeme Gregory
2016-01-18 14:04 ` Graeme Gregory
2016-01-19 20:25 ` Bjorn Helgaas
2016-01-19 20:25 ` Bjorn Helgaas
2016-01-19 20:40 ` Russell King - ARM Linux
2016-01-19 20:40 ` Russell King - ARM Linux
2016-01-19 23:37 ` Mark Salter
2016-01-19 23:37 ` Mark Salter
2016-01-19 23:37 ` Mark Salter
2016-01-14 15:29 ` Mark Salter
2016-01-14 15:29 ` Mark Salter
2016-01-14 15:38 ` Sinan Kaya
2016-01-14 15:38 ` Sinan Kaya
2016-01-14 16:12 ` Lorenzo Pieralisi
2016-01-14 16:12 ` Lorenzo Pieralisi
2016-01-14 16:38 ` Mark Salter [this message]
2016-01-14 16:38 ` Mark Salter
2016-01-14 16:38 ` Mark Salter
2016-01-14 17:07 ` Lorenzo Pieralisi
2016-01-14 17:07 ` Lorenzo Pieralisi
2016-01-14 17:32 ` Mark Salter
2016-01-14 17:32 ` Mark Salter
2016-01-14 17:59 ` Lorenzo Pieralisi
2016-01-14 17:59 ` Lorenzo Pieralisi
2016-01-14 17:59 ` Lorenzo Pieralisi
2016-01-14 18:44 ` Mark Salter
2016-01-14 18:44 ` Mark Salter
2016-01-14 22:51 ` Jeremy Linton
2016-01-14 22:51 ` Jeremy Linton
2016-01-14 22:55 ` Jeremy Linton
2016-01-14 22:55 ` Jeremy Linton
2016-01-15 11:00 ` Hanjun Guo
2016-01-15 11:00 ` Hanjun Guo
2016-01-18 14:37 ` Hanjun Guo
2016-01-18 14:37 ` Hanjun Guo
2016-01-29 6:43 ` liudongdong (C)
2016-01-29 6:43 ` liudongdong (C)
2016-01-29 6:43 ` liudongdong (C)
2016-02-01 19:58 ` Duc Dang
2016-02-01 19:58 ` Duc Dang
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=1452789524.28109.24.camel@redhat.com \
--to=msalter@redhat.com \
--cc=Liviu.Dudau@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=hanjun.guo@linaro.org \
--cc=jchandra@broadcom.com \
--cc=jcm@redhat.com \
--cc=jiang.liu@linux.intel.com \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.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.