From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Yijing Wang <wangyijing@huawei.com>,
Liviu Dudau <liviu@dudau.co.uk>, Tony Luck <tony.luck@intel.com>,
Russell King <linux@arm.linux.org.uk>,
linux-pci@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, Xinwei Hu <huxinwei@huawei.com>,
Thierry Reding <thierry.reding@gmail.com>,
Suravee.Suthikulpanit@amd.com,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-ia64@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Wuyun <wuyun.wu@huawei.com>,
linuxppc-dev@lists.ozlabs.org,
Yijing Wang <wangyijing0307@gmail.com>
Subject: Re: [RFC PATCH 01/16] PCI: Enhance pci_scan_root_bus() to support default IO/MEM resources
Date: Tue, 18 Nov 2014 09:36:34 +0000 [thread overview]
Message-ID: <2447172.ADYWdCTnMP@wuerfel> (raw)
In-Reply-To: <546AF8D7.9010103@huawei.com>
On Tuesday 18 November 2014 15:44:23 Yijing Wang wrote:
> On 2014/11/17 18:08, Arnd Bergmann wrote:
> > On Monday 17 November 2014 18:21:35 Yijing Wang wrote:
> >> - list_for_each_entry(window, resources, list)
> >> - if (window->res->flags & IORESOURCE_BUS) {
> >> - found = true;
> >> - break;
> >> - }
> >> + if (!resources) {
> >> + pci_add_resource(&default_res, &ioport_resource);
> >> + pci_add_resource(&default_res, &iomem_resource);
> >> + pci_add_resource(&default_res, &busn_resource);
> >> + } else {
> >>
> >
> > Isn't it almost always wrong to do this? You are adding all of the
> > I/O ports and memory to the host bridge, which will prevent you from
> > adding another host bridge, and the iomem_resource normally
> > includes a lot of addresses that are not accessible by the PCI host.
>
> Hi Arnd, pci host bridge windows are the ranges allow child devices to setup
> from. Add all of IO/MEM here just a limit to child devices, no request for these
> resources, so it won't hurt another host bridge. Some platforms have no dts or ACPI
> report host bridge resources, in this case, we directly assign ioport/iomem_resources
> as the root resources of PCI devices.
But it would be wrong to allow hosts to allocate a device BAR that is not
visible through the host bridge. I think we need to keep these separate
from the general case: if you call any of the modern interfaces you have
to provide the resources and a device. I notice that there is only one
caller of pci_scan_bus_parented(), we should probably change that over to
pci_scan_root_bus() or your new interface and remove the old one, but
keep pci_scan_bus() as the only entry point for all of the legacy users
that do not know about the resources.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Yijing Wang <wangyijing@huawei.com>,
Liviu Dudau <liviu@dudau.co.uk>, Tony Luck <tony.luck@intel.com>,
Russell King <linux@arm.linux.org.uk>,
linux-pci@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, Xinwei Hu <huxinwei@huawei.com>,
Thierry Reding <thierry.reding@gmail.com>,
Suravee.Suthikulpanit@amd.com,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Bjorn Helgaas <bhelgaas@google.com>,
linux-ia64@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Wuyun <wuyun.wu@huawei.com>,
linuxppc-dev@lists.ozlabs.org,
Yijing Wang <wangyijing0307@gmail.com>
Subject: Re: [RFC PATCH 01/16] PCI: Enhance pci_scan_root_bus() to support default IO/MEM resources
Date: Tue, 18 Nov 2014 10:36:34 +0100 [thread overview]
Message-ID: <2447172.ADYWdCTnMP@wuerfel> (raw)
In-Reply-To: <546AF8D7.9010103@huawei.com>
On Tuesday 18 November 2014 15:44:23 Yijing Wang wrote:
> On 2014/11/17 18:08, Arnd Bergmann wrote:
> > On Monday 17 November 2014 18:21:35 Yijing Wang wrote:
> >> - list_for_each_entry(window, resources, list)
> >> - if (window->res->flags & IORESOURCE_BUS) {
> >> - found = true;
> >> - break;
> >> - }
> >> + if (!resources) {
> >> + pci_add_resource(&default_res, &ioport_resource);
> >> + pci_add_resource(&default_res, &iomem_resource);
> >> + pci_add_resource(&default_res, &busn_resource);
> >> + } else {
> >>
> >
> > Isn't it almost always wrong to do this? You are adding all of the
> > I/O ports and memory to the host bridge, which will prevent you from
> > adding another host bridge, and the iomem_resource normally
> > includes a lot of addresses that are not accessible by the PCI host.
>
> Hi Arnd, pci host bridge windows are the ranges allow child devices to setup
> from. Add all of IO/MEM here just a limit to child devices, no request for these
> resources, so it won't hurt another host bridge. Some platforms have no dts or ACPI
> report host bridge resources, in this case, we directly assign ioport/iomem_resources
> as the root resources of PCI devices.
But it would be wrong to allow hosts to allocate a device BAR that is not
visible through the host bridge. I think we need to keep these separate
from the general case: if you call any of the modern interfaces you have
to provide the resources and a device. I notice that there is only one
caller of pci_scan_bus_parented(), we should probably change that over to
pci_scan_root_bus() or your new interface and remove the old one, but
keep pci_scan_bus() as the only entry point for all of the legacy users
that do not know about the resources.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Liviu Dudau <liviu@dudau.co.uk>, Tony Luck <tony.luck@intel.com>,
Russell King <linux@arm.linux.org.uk>,
linux-pci@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, Xinwei Hu <huxinwei@huawei.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Thierry Reding <thierry.reding@gmail.com>,
Suravee.Suthikulpanit@amd.com,
Yijing Wang <wangyijing@huawei.com>,
linux-ia64@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Wuyun <wuyun.wu@huawei.com>,
linuxppc-dev@lists.ozlabs.org,
Yijing Wang <wangyijing0307@gmail.com>
Subject: Re: [RFC PATCH 01/16] PCI: Enhance pci_scan_root_bus() to support default IO/MEM resources
Date: Tue, 18 Nov 2014 10:36:34 +0100 [thread overview]
Message-ID: <2447172.ADYWdCTnMP@wuerfel> (raw)
In-Reply-To: <546AF8D7.9010103@huawei.com>
On Tuesday 18 November 2014 15:44:23 Yijing Wang wrote:
> On 2014/11/17 18:08, Arnd Bergmann wrote:
> > On Monday 17 November 2014 18:21:35 Yijing Wang wrote:
> >> - list_for_each_entry(window, resources, list)
> >> - if (window->res->flags & IORESOURCE_BUS) {
> >> - found = true;
> >> - break;
> >> - }
> >> + if (!resources) {
> >> + pci_add_resource(&default_res, &ioport_resource);
> >> + pci_add_resource(&default_res, &iomem_resource);
> >> + pci_add_resource(&default_res, &busn_resource);
> >> + } else {
> >>
> >
> > Isn't it almost always wrong to do this? You are adding all of the
> > I/O ports and memory to the host bridge, which will prevent you from
> > adding another host bridge, and the iomem_resource normally
> > includes a lot of addresses that are not accessible by the PCI host.
>
> Hi Arnd, pci host bridge windows are the ranges allow child devices to setup
> from. Add all of IO/MEM here just a limit to child devices, no request for these
> resources, so it won't hurt another host bridge. Some platforms have no dts or ACPI
> report host bridge resources, in this case, we directly assign ioport/iomem_resources
> as the root resources of PCI devices.
But it would be wrong to allow hosts to allocate a device BAR that is not
visible through the host bridge. I think we need to keep these separate
from the general case: if you call any of the modern interfaces you have
to provide the resources and a device. I notice that there is only one
caller of pci_scan_bus_parented(), we should probably change that over to
pci_scan_root_bus() or your new interface and remove the old one, but
keep pci_scan_bus() as the only entry point for all of the legacy users
that do not know about the resources.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 01/16] PCI: Enhance pci_scan_root_bus() to support default IO/MEM resources
Date: Tue, 18 Nov 2014 10:36:34 +0100 [thread overview]
Message-ID: <2447172.ADYWdCTnMP@wuerfel> (raw)
In-Reply-To: <546AF8D7.9010103@huawei.com>
On Tuesday 18 November 2014 15:44:23 Yijing Wang wrote:
> On 2014/11/17 18:08, Arnd Bergmann wrote:
> > On Monday 17 November 2014 18:21:35 Yijing Wang wrote:
> >> - list_for_each_entry(window, resources, list)
> >> - if (window->res->flags & IORESOURCE_BUS) {
> >> - found = true;
> >> - break;
> >> - }
> >> + if (!resources) {
> >> + pci_add_resource(&default_res, &ioport_resource);
> >> + pci_add_resource(&default_res, &iomem_resource);
> >> + pci_add_resource(&default_res, &busn_resource);
> >> + } else {
> >>
> >
> > Isn't it almost always wrong to do this? You are adding all of the
> > I/O ports and memory to the host bridge, which will prevent you from
> > adding another host bridge, and the iomem_resource normally
> > includes a lot of addresses that are not accessible by the PCI host.
>
> Hi Arnd, pci host bridge windows are the ranges allow child devices to setup
> from. Add all of IO/MEM here just a limit to child devices, no request for these
> resources, so it won't hurt another host bridge. Some platforms have no dts or ACPI
> report host bridge resources, in this case, we directly assign ioport/iomem_resources
> as the root resources of PCI devices.
But it would be wrong to allow hosts to allocate a device BAR that is not
visible through the host bridge. I think we need to keep these separate
from the general case: if you call any of the modern interfaces you have
to provide the resources and a device. I notice that there is only one
caller of pci_scan_bus_parented(), we should probably change that over to
pci_scan_root_bus() or your new interface and remove the old one, but
keep pci_scan_bus() as the only entry point for all of the legacy users
that do not know about the resources.
Arnd
next prev parent reply other threads:[~2014-11-18 9:36 UTC|newest]
Thread overview: 253+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-17 9:43 [RFC PATCH 00/16] Refine PCI host bridge scan interfaces Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:40 ` [RFC PATCH 03/16] PCI: Clean up pci_scan_bus() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:40 ` [RFC PATCH 12/16] ia64/PCI: Remove the redundant bus variable Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:40 ` [RFC PATCH 05/16] PCI: Use pci_scan_root_bus() instead of pci_scan_bus_parented() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:42 ` [RFC PATCH 16/16] powerpc/PCI: Use pci_scan_host_bridge() to scan PCI bus Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:43 ` [RFC PATCH 15/16] arm/PCI: Use pci_scan_host_bridge() instead of pci_scan_root_bus() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:43 ` [RFC PATCH 14/16] arm/PCI: Introduce pci_get_domain_nr() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 12:08 ` Lorenzo Pieralisi
2014-11-17 12:08 ` Lorenzo Pieralisi
2014-11-17 12:08 ` Lorenzo Pieralisi
2014-11-18 0:55 ` Yijing Wang
2014-11-18 0:55 ` Yijing Wang
2014-11-18 0:55 ` Yijing Wang
2014-11-18 0:55 ` Yijing Wang
2014-11-17 9:43 ` [RFC PATCH 13/16] ia64/PCI: Use pci_scan_host_bridge() to refactor pci_acpi_scan_root() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:43 ` [RFC PATCH 09/16] PCI: Associate .get_msi_ctrl() with pci_host_bridge Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 15:03 ` Lorenzo Pieralisi
2014-11-17 15:03 ` Lorenzo Pieralisi
2014-11-17 15:03 ` Lorenzo Pieralisi
2014-11-17 9:43 ` [RFC PATCH 10/16] PCI: Add of_scan_bus() to pci_host_info Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:43 ` [RFC PATCH 04/16] PCI: Rip out pci_bus_add_devices() from pci_scan_root_bus() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-18 14:34 ` Liviu Dudau
2014-11-18 14:34 ` Liviu Dudau
2014-11-18 14:34 ` Liviu Dudau
2014-11-18 14:34 ` Liviu Dudau
2014-11-19 1:21 ` Yijing Wang
2014-11-19 1:21 ` Yijing Wang
2014-11-19 1:21 ` Yijing Wang
2014-11-19 1:21 ` Yijing Wang
2014-11-17 9:45 ` [RFC PATCH 06/16] PCI: Use u32 type to combine PCI domain and bus number Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:45 ` [RFC PATCH 02/16] PCI: Use pci_scan_root_bus() instead of pci_scan_bus() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-18 14:28 ` Liviu Dudau
2014-11-18 14:28 ` Liviu Dudau
2014-11-18 14:28 ` Liviu Dudau
2014-11-18 14:28 ` Liviu Dudau
2014-11-19 1:19 ` Yijing Wang
2014-11-19 1:19 ` Yijing Wang
2014-11-19 1:19 ` Yijing Wang
2014-11-19 1:19 ` Yijing Wang
2014-11-17 9:45 ` [RFC PATCH 01/16] PCI: Enhance pci_scan_root_bus() to support default IO/MEM resources Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:08 ` Arnd Bergmann
2014-11-17 10:08 ` Arnd Bergmann
2014-11-17 10:08 ` Arnd Bergmann
2014-11-17 10:08 ` Arnd Bergmann
2014-11-18 7:44 ` Yijing Wang
2014-11-18 7:44 ` Yijing Wang
2014-11-18 7:44 ` Yijing Wang
2014-11-18 7:44 ` Yijing Wang
2014-11-18 9:36 ` Arnd Bergmann [this message]
2014-11-18 9:36 ` Arnd Bergmann
2014-11-18 9:36 ` Arnd Bergmann
2014-11-18 9:36 ` Arnd Bergmann
2014-11-18 11:46 ` Yijing Wang
2014-11-18 11:46 ` Yijing Wang
2014-11-18 11:46 ` Yijing Wang
2014-11-18 11:46 ` Yijing Wang
2014-11-18 14:23 ` Liviu Dudau
2014-11-18 14:23 ` Liviu Dudau
2014-11-18 14:23 ` Liviu Dudau
2014-11-18 14:23 ` Liviu Dudau
2014-11-19 1:15 ` Yijing Wang
2014-11-19 1:15 ` Yijing Wang
2014-11-19 1:15 ` Yijing Wang
2014-11-19 1:15 ` Yijing Wang
2014-11-17 9:45 ` [RFC PATCH 08/16] PCI: Introduce pci_scan_host_bridge() and pci_host_info Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-18 15:42 ` Liviu Dudau
2014-11-18 15:42 ` Liviu Dudau
2014-11-18 15:42 ` Liviu Dudau
2014-11-18 15:42 ` Liviu Dudau
2014-11-19 2:09 ` Yijing Wang
2014-11-19 2:09 ` Yijing Wang
2014-11-19 2:09 ` Yijing Wang
2014-11-19 2:09 ` Yijing Wang
2014-11-19 16:41 ` Liviu Dudau
2014-11-19 16:41 ` Liviu Dudau
2014-11-19 16:41 ` Liviu Dudau
2014-11-19 16:41 ` Liviu Dudau
2014-11-20 2:54 ` Yijing Wang
2014-11-20 2:54 ` Yijing Wang
2014-11-20 2:54 ` Yijing Wang
2014-11-20 2:54 ` Yijing Wang
2014-11-17 9:45 ` [RFC PATCH 11/16] x86/PCI: Use pci_scan_host_bridge() instead of pci_create_root_bus() Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 9:45 ` [RFC PATCH 07/16] PCI: Separate pci_host_bridge creation out " Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:21 ` Yijing Wang
2014-11-17 10:56 ` Arnd Bergmann
2014-11-17 10:56 ` Arnd Bergmann
2014-11-17 10:56 ` Arnd Bergmann
2014-11-17 10:56 ` Arnd Bergmann
2014-11-18 8:32 ` Yijing Wang
2014-11-18 8:32 ` Yijing Wang
2014-11-18 8:32 ` Yijing Wang
2014-11-18 8:32 ` Yijing Wang
2014-11-18 9:30 ` Arnd Bergmann
2014-11-18 9:30 ` Arnd Bergmann
2014-11-18 9:30 ` Arnd Bergmann
2014-11-18 9:30 ` Arnd Bergmann
2014-11-18 11:44 ` Yijing Wang
2014-11-18 11:44 ` Yijing Wang
2014-11-18 11:44 ` Yijing Wang
2014-11-18 11:44 ` Yijing Wang
2014-11-18 12:25 ` Arnd Bergmann
2014-11-18 12:25 ` Arnd Bergmann
2014-11-18 12:25 ` Arnd Bergmann
2014-11-18 12:25 ` Arnd Bergmann
2014-11-18 12:41 ` Yijing Wang
2014-11-18 12:41 ` Yijing Wang
2014-11-18 12:41 ` Yijing Wang
2014-11-18 12:41 ` Yijing Wang
2014-11-18 14:48 ` Liviu Dudau
2014-11-18 14:48 ` Liviu Dudau
2014-11-18 14:48 ` Liviu Dudau
2014-11-18 14:48 ` Liviu Dudau
2014-11-19 2:24 ` Yijing Wang
2014-11-19 2:24 ` Yijing Wang
2014-11-19 2:24 ` Yijing Wang
2014-11-19 2:24 ` Yijing Wang
2014-11-19 16:29 ` Liviu Dudau
2014-11-19 16:29 ` Liviu Dudau
2014-11-19 16:29 ` Liviu Dudau
2014-11-20 2:00 ` Yijing Wang
2014-11-20 2:00 ` Yijing Wang
2014-11-20 2:00 ` Yijing Wang
2014-11-20 2:00 ` Yijing Wang
2014-11-18 15:30 ` Liviu Dudau
2014-11-18 15:30 ` Liviu Dudau
2014-11-18 15:30 ` Liviu Dudau
2014-11-18 15:30 ` Liviu Dudau
2014-11-19 1:42 ` Yijing Wang
2014-11-19 1:42 ` Yijing Wang
2014-11-19 1:42 ` Yijing Wang
2014-11-19 1:42 ` Yijing Wang
2014-11-19 16:37 ` Liviu Dudau
2014-11-19 16:37 ` Liviu Dudau
2014-11-19 16:37 ` Liviu Dudau
2014-11-19 16:37 ` Liviu Dudau
2014-11-20 2:47 ` Yijing Wang
2014-11-20 2:47 ` Yijing Wang
2014-11-20 2:47 ` Yijing Wang
2014-11-20 2:47 ` Yijing Wang
2014-11-20 9:47 ` Liviu Dudau
2014-11-20 9:47 ` Liviu Dudau
2014-11-20 9:47 ` Liviu Dudau
2014-11-20 9:47 ` Liviu Dudau
2014-11-21 2:53 ` Yijing Wang
2014-11-21 2:53 ` Yijing Wang
2014-11-21 2:53 ` Yijing Wang
2014-11-21 2:53 ` Yijing Wang
2014-11-21 9:53 ` Liviu Dudau
2014-11-21 9:53 ` Liviu Dudau
2014-11-21 9:53 ` Liviu Dudau
2014-11-21 9:53 ` Liviu Dudau
2014-11-17 14:13 ` [RFC PATCH 00/16] Refine PCI host bridge scan interfaces Arnd Bergmann
2014-11-17 14:13 ` Arnd Bergmann
2014-11-17 14:13 ` Arnd Bergmann
2014-11-17 14:13 ` Arnd Bergmann
2014-11-18 11:17 ` Yijing Wang
2014-11-18 11:17 ` Yijing Wang
2014-11-18 11:17 ` Yijing Wang
2014-11-18 11:17 ` Yijing Wang
2014-11-18 11:30 ` Arnd Bergmann
2014-11-18 11:30 ` Arnd Bergmann
2014-11-18 11:30 ` Arnd Bergmann
2014-11-18 11:30 ` Arnd Bergmann
2014-11-18 11:45 ` Lorenzo Pieralisi
2014-11-18 11:45 ` Lorenzo Pieralisi
2014-11-18 11:45 ` Lorenzo Pieralisi
2014-11-18 12:14 ` Yijing Wang
2014-11-18 12:14 ` Yijing Wang
2014-11-18 12:14 ` Yijing Wang
2014-11-18 12:17 ` Yijing Wang
2014-11-18 12:17 ` Yijing Wang
2014-11-18 12:17 ` Yijing Wang
2014-11-18 12:17 ` Yijing Wang
2014-11-18 12:27 ` Arnd Bergmann
2014-11-18 12:27 ` Arnd Bergmann
2014-11-18 12:27 ` Arnd Bergmann
2014-11-18 12:27 ` Arnd Bergmann
2014-11-20 12:01 ` Tomasz Nowicki
2014-11-20 12:01 ` Tomasz Nowicki
2014-11-20 12:01 ` Tomasz Nowicki
2014-11-20 12:01 ` Tomasz Nowicki
2014-11-20 13:15 ` Arnd Bergmann
2014-11-20 13:15 ` Arnd Bergmann
2014-11-20 13:15 ` Arnd Bergmann
2014-11-20 13:15 ` Arnd Bergmann
2014-11-20 11:54 ` Tomasz Nowicki
2014-11-20 11:54 ` Tomasz Nowicki
2014-11-20 11:54 ` Tomasz Nowicki
2014-11-20 11:54 ` Tomasz Nowicki
2014-11-20 12:08 ` Liviu Dudau
2014-11-20 12:08 ` Liviu Dudau
2014-11-20 12:08 ` Liviu Dudau
2014-11-20 12:53 ` Tomasz Nowicki
2014-11-20 12:53 ` Tomasz Nowicki
2014-11-20 12:53 ` Tomasz Nowicki
2014-11-20 12:53 ` Tomasz Nowicki
2014-11-20 16:39 ` Liviu Dudau
2014-11-20 16:39 ` Liviu Dudau
2014-11-20 16:39 ` Liviu Dudau
2014-11-21 2:58 ` Yijing Wang
2014-11-21 2:58 ` Yijing Wang
2014-11-21 2:58 ` Yijing Wang
2014-11-21 2:58 ` Yijing Wang
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=2447172.ADYWdCTnMP@wuerfel \
--to=arnd@arndb.de \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=huxinwei@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=liviu@dudau.co.uk \
--cc=tglx@linutronix.de \
--cc=thierry.reding@gmail.com \
--cc=tony.luck@intel.com \
--cc=wangyijing0307@gmail.com \
--cc=wangyijing@huawei.com \
--cc=wuyun.wu@huawei.com \
--cc=x86@kernel.org \
/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.