From: Tomasz Nowicki <tn@semihalf.com> To: Bjorn Helgaas <helgaas@kernel.org>, ddaney@caviumnetworks.com Cc: will.deacon@arm.com, catalin.marinas@arm.com, rafael@kernel.org, Lorenzo.Pieralisi@arm.com, arnd@arndb.de, hanjun.guo@linaro.org, okaya@codeaurora.org, jchandra@broadcom.com, cov@codeaurora.org, dhdang@apm.com, ard.biesheuvel@linaro.org, robert.richter@caviumnetworks.com, mw@semihalf.com, Liviu.Dudau@arm.com, wangyijing@huawei.com, msalter@redhat.com, linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linaro-acpi@lists.linaro.org, jcm@redhat.com, andrea.gallo@linaro.org, jeremy.linton@arm.com, liudongdong3@huawei.com, gabriele.paoloni@huawei.com, jhugo@codeaurora.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case Date: Tue, 20 Sep 2016 09:23:21 +0200 [thread overview] Message-ID: <49f53bfc-4421-a8b0-694c-bce7e61e1c9e@semihalf.com> (raw) In-Reply-To: <20160919180900.GB13775@localhost> On 19.09.2016 20:09, Bjorn Helgaas wrote: > On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote: >> thunder-pem driver stands for being ACPI based PCI host controller. >> However, there is no standard way to describe its PEM-specific register >> ranges in ACPI tables. Thus we add thunder_pem_init() ACPI extension >> to obtain hardcoded addresses from static resource array. >> Although it is not pretty, it prevents from creating standard mechanism to >> handle similar cases in future. >> >> Signed-off-by: Tomasz Nowicki <tn@semihalf.com> >> --- >> drivers/pci/host/pci-thunder-pem.c | 61 ++++++++++++++++++++++++++++++-------- >> 1 file changed, 48 insertions(+), 13 deletions(-) >> >> diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c >> index 6abaf80..b048761 100644 >> --- a/drivers/pci/host/pci-thunder-pem.c >> +++ b/drivers/pci/host/pci-thunder-pem.c >> @@ -18,6 +18,7 @@ >> #include <linux/init.h> >> #include <linux/of_address.h> >> #include <linux/of_pci.h> >> +#include <linux/pci-acpi.h> >> #include <linux/pci-ecam.h> >> #include <linux/platform_device.h> >> >> @@ -284,6 +285,40 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn, >> return pci_generic_config_write(bus, devfn, where, size, val); >> } >> >> +#ifdef CONFIG_ACPI >> +static struct resource thunder_pem_reg_res[] = { >> + [4] = DEFINE_RES_MEM(0x87e0c0000000UL, SZ_16M), >> + [5] = DEFINE_RES_MEM(0x87e0c1000000UL, SZ_16M), >> + [6] = DEFINE_RES_MEM(0x87e0c2000000UL, SZ_16M), >> + [7] = DEFINE_RES_MEM(0x87e0c3000000UL, SZ_16M), >> + [8] = DEFINE_RES_MEM(0x87e0c4000000UL, SZ_16M), >> + [9] = DEFINE_RES_MEM(0x87e0c5000000UL, SZ_16M), >> + [14] = DEFINE_RES_MEM(0x97e0c0000000UL, SZ_16M), >> + [15] = DEFINE_RES_MEM(0x97e0c1000000UL, SZ_16M), >> + [16] = DEFINE_RES_MEM(0x97e0c2000000UL, SZ_16M), >> + [17] = DEFINE_RES_MEM(0x97e0c3000000UL, SZ_16M), >> + [18] = DEFINE_RES_MEM(0x97e0c4000000UL, SZ_16M), >> + [19] = DEFINE_RES_MEM(0x97e0c5000000UL, SZ_16M), > > 1) The "correct" way to discover the resources consumed by an ACPI > device is to use the _CRS method. I know there are some issues > there for bridges (not the fault of ThunderX!) because there's not > a good way to distinguish windows from resources consumed directly > by the bridge. > > But we should either do this correctly, or include a comment about > why we're doing it wrong, so we don't give the impression that this > is the right way to do it. > > I seem to recall some discussion about why we're doing it this way, > but I don't remember the details. It'd be nice to include a > summary here. OK I will. The reason why we cannot use _CRS for this case is that CONSUMER flag was not use consistently for the bridge so far. > > 2) This is a little weird because here we define the resource size as > 16MB, in the OF case we get the resource size from OF, in either > case we ioremap 64K of it, and then as far as I can tell, we only > ever access PEM_CFG_WR and PEM_CFG_RD, at offsets 0x28 and 0x30 > into the space. > > If the hardware actually decodes the entire 16MB, we should ioremap > the whole 16MB. (Strictly speaking, drivers only need to ioremap > the parts they're using, but in this case nobody claims the entire > resource because of deficiencies in the ACPI and OF cores, so the > driver should ioremap the entire thing to help prevent conflicts > with other devices.) > > It'd be nice if we didn't have the 64KB magic number. I think > using devm_ioremap_resource() would be nice. I agree. David, is there anything which prevents us from using devm_ioremap_resource() here with SZ_16M size? Tomasz
WARNING: multiple messages have this Message-ID (diff)
From: tn@semihalf.com (Tomasz Nowicki) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case Date: Tue, 20 Sep 2016 09:23:21 +0200 [thread overview] Message-ID: <49f53bfc-4421-a8b0-694c-bce7e61e1c9e@semihalf.com> (raw) In-Reply-To: <20160919180900.GB13775@localhost> On 19.09.2016 20:09, Bjorn Helgaas wrote: > On Fri, Sep 09, 2016 at 09:24:05PM +0200, Tomasz Nowicki wrote: >> thunder-pem driver stands for being ACPI based PCI host controller. >> However, there is no standard way to describe its PEM-specific register >> ranges in ACPI tables. Thus we add thunder_pem_init() ACPI extension >> to obtain hardcoded addresses from static resource array. >> Although it is not pretty, it prevents from creating standard mechanism to >> handle similar cases in future. >> >> Signed-off-by: Tomasz Nowicki <tn@semihalf.com> >> --- >> drivers/pci/host/pci-thunder-pem.c | 61 ++++++++++++++++++++++++++++++-------- >> 1 file changed, 48 insertions(+), 13 deletions(-) >> >> diff --git a/drivers/pci/host/pci-thunder-pem.c b/drivers/pci/host/pci-thunder-pem.c >> index 6abaf80..b048761 100644 >> --- a/drivers/pci/host/pci-thunder-pem.c >> +++ b/drivers/pci/host/pci-thunder-pem.c >> @@ -18,6 +18,7 @@ >> #include <linux/init.h> >> #include <linux/of_address.h> >> #include <linux/of_pci.h> >> +#include <linux/pci-acpi.h> >> #include <linux/pci-ecam.h> >> #include <linux/platform_device.h> >> >> @@ -284,6 +285,40 @@ static int thunder_pem_config_write(struct pci_bus *bus, unsigned int devfn, >> return pci_generic_config_write(bus, devfn, where, size, val); >> } >> >> +#ifdef CONFIG_ACPI >> +static struct resource thunder_pem_reg_res[] = { >> + [4] = DEFINE_RES_MEM(0x87e0c0000000UL, SZ_16M), >> + [5] = DEFINE_RES_MEM(0x87e0c1000000UL, SZ_16M), >> + [6] = DEFINE_RES_MEM(0x87e0c2000000UL, SZ_16M), >> + [7] = DEFINE_RES_MEM(0x87e0c3000000UL, SZ_16M), >> + [8] = DEFINE_RES_MEM(0x87e0c4000000UL, SZ_16M), >> + [9] = DEFINE_RES_MEM(0x87e0c5000000UL, SZ_16M), >> + [14] = DEFINE_RES_MEM(0x97e0c0000000UL, SZ_16M), >> + [15] = DEFINE_RES_MEM(0x97e0c1000000UL, SZ_16M), >> + [16] = DEFINE_RES_MEM(0x97e0c2000000UL, SZ_16M), >> + [17] = DEFINE_RES_MEM(0x97e0c3000000UL, SZ_16M), >> + [18] = DEFINE_RES_MEM(0x97e0c4000000UL, SZ_16M), >> + [19] = DEFINE_RES_MEM(0x97e0c5000000UL, SZ_16M), > > 1) The "correct" way to discover the resources consumed by an ACPI > device is to use the _CRS method. I know there are some issues > there for bridges (not the fault of ThunderX!) because there's not > a good way to distinguish windows from resources consumed directly > by the bridge. > > But we should either do this correctly, or include a comment about > why we're doing it wrong, so we don't give the impression that this > is the right way to do it. > > I seem to recall some discussion about why we're doing it this way, > but I don't remember the details. It'd be nice to include a > summary here. OK I will. The reason why we cannot use _CRS for this case is that CONSUMER flag was not use consistently for the bridge so far. > > 2) This is a little weird because here we define the resource size as > 16MB, in the OF case we get the resource size from OF, in either > case we ioremap 64K of it, and then as far as I can tell, we only > ever access PEM_CFG_WR and PEM_CFG_RD, at offsets 0x28 and 0x30 > into the space. > > If the hardware actually decodes the entire 16MB, we should ioremap > the whole 16MB. (Strictly speaking, drivers only need to ioremap > the parts they're using, but in this case nobody claims the entire > resource because of deficiencies in the ACPI and OF cores, so the > driver should ioremap the entire thing to help prevent conflicts > with other devices.) > > It'd be nice if we didn't have the 64KB magic number. I think > using devm_ioremap_resource() would be nice. I agree. David, is there anything which prevents us from using devm_ioremap_resource() here with SZ_16M size? Tomasz
next prev parent reply other threads:[~2016-09-20 7:23 UTC|newest] Thread overview: 234+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-09-09 19:24 [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms Tomasz Nowicki 2016-09-09 19:24 ` Tomasz Nowicki 2016-09-09 19:24 ` [PATCH V6 1/5] PCI/ACPI: Extend pci_mcfg_lookup() responsibilities Tomasz Nowicki 2016-09-09 19:24 ` Tomasz Nowicki 2016-09-09 19:24 ` [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks Tomasz Nowicki 2016-09-09 19:24 ` Tomasz Nowicki 2016-09-12 22:24 ` Duc Dang 2016-09-12 22:24 ` Duc Dang 2016-09-12 22:24 ` Duc Dang 2016-09-12 22:47 ` Duc Dang 2016-09-12 22:47 ` Duc Dang 2016-09-12 22:47 ` Duc Dang 2016-09-13 5:58 ` Tomasz Nowicki 2016-09-13 5:58 ` Tomasz Nowicki 2016-09-13 5:58 ` Tomasz Nowicki 2016-09-13 6:37 ` Tomasz Nowicki 2016-09-13 6:37 ` Tomasz Nowicki 2016-09-13 6:37 ` Tomasz Nowicki 2016-09-13 2:36 ` Dongdong Liu 2016-09-13 2:36 ` Dongdong Liu 2016-09-13 2:36 ` Dongdong Liu 2016-09-13 6:32 ` Tomasz Nowicki 2016-09-13 6:32 ` Tomasz Nowicki 2016-09-13 11:38 ` Dongdong Liu 2016-09-13 11:38 ` Dongdong Liu 2016-09-13 11:38 ` Dongdong Liu 2016-09-14 12:40 ` Lorenzo Pieralisi 2016-09-14 12:40 ` Lorenzo Pieralisi 2016-09-15 10:58 ` Lorenzo Pieralisi 2016-09-15 10:58 ` Lorenzo Pieralisi 2016-09-16 9:02 ` Gabriele Paoloni 2016-09-16 9:02 ` Gabriele Paoloni 2016-09-16 9:02 ` Gabriele Paoloni 2016-09-16 9:02 ` Gabriele Paoloni 2016-09-16 12:27 ` Christopher Covington 2016-09-16 12:27 ` Christopher Covington 2016-09-16 12:27 ` Christopher Covington 2016-09-16 12:27 ` Christopher Covington 2016-09-16 13:42 ` Gabriele Paoloni 2016-09-16 13:42 ` Gabriele Paoloni 2016-09-16 13:42 ` Gabriele Paoloni 2016-09-16 13:42 ` Gabriele Paoloni 2016-09-09 19:24 ` [PATCH V6 3/5] PCI: thunder-pem: Allow to probe PEM-specific register range for ACPI case Tomasz Nowicki 2016-09-09 19:24 ` Tomasz Nowicki 2016-09-19 18:09 ` Bjorn Helgaas 2016-09-19 18:09 ` Bjorn Helgaas 2016-09-20 7:23 ` Tomasz Nowicki [this message] 2016-09-20 7:23 ` Tomasz Nowicki 2016-09-20 13:33 ` Bjorn Helgaas 2016-09-20 13:33 ` Bjorn Helgaas 2016-09-20 13:33 ` Bjorn Helgaas 2016-09-20 13:40 ` Ard Biesheuvel 2016-09-20 13:40 ` Ard Biesheuvel 2016-09-20 13:40 ` Ard Biesheuvel 2016-09-20 13:40 ` Ard Biesheuvel 2016-09-20 14:05 ` Bjorn Helgaas 2016-09-20 14:05 ` Bjorn Helgaas 2016-09-20 14:05 ` Bjorn Helgaas 2016-09-20 14:05 ` Bjorn Helgaas 2016-09-20 15:09 ` Ard Biesheuvel 2016-09-20 15:09 ` Ard Biesheuvel 2016-09-20 15:09 ` Ard Biesheuvel 2016-09-20 15:09 ` Ard Biesheuvel 2016-09-20 19:17 ` Bjorn Helgaas 2016-09-20 19:17 ` Bjorn Helgaas 2016-09-20 19:17 ` Bjorn Helgaas 2016-09-20 19:17 ` Bjorn Helgaas 2016-09-21 14:05 ` Lorenzo Pieralisi 2016-09-21 14:05 ` Lorenzo Pieralisi 2016-09-21 14:05 ` Lorenzo Pieralisi 2016-09-21 14:05 ` Lorenzo Pieralisi 2016-09-21 18:04 ` Bjorn Helgaas 2016-09-21 18:04 ` Bjorn Helgaas 2016-09-21 18:04 ` Bjorn Helgaas 2016-09-21 18:04 ` Bjorn Helgaas 2016-09-21 18:58 ` Duc Dang 2016-09-21 18:58 ` Duc Dang 2016-09-21 18:58 ` Duc Dang 2016-09-21 18:58 ` Duc Dang 2016-09-21 19:18 ` Bjorn Helgaas 2016-09-21 19:18 ` Bjorn Helgaas 2016-09-21 19:18 ` Bjorn Helgaas 2016-09-21 19:18 ` Bjorn Helgaas 2016-09-23 10:53 ` Tomasz Nowicki 2016-09-23 10:53 ` Tomasz Nowicki 2016-09-23 10:53 ` Tomasz Nowicki 2016-09-23 10:53 ` Tomasz Nowicki 2016-09-22 9:49 ` Lorenzo Pieralisi 2016-09-22 9:49 ` Lorenzo Pieralisi 2016-09-22 9:49 ` Lorenzo Pieralisi 2016-09-22 9:49 ` Lorenzo Pieralisi 2016-09-22 11:10 ` Gabriele Paoloni 2016-09-22 11:10 ` Gabriele Paoloni 2016-09-22 11:10 ` Gabriele Paoloni 2016-09-22 11:10 ` Gabriele Paoloni 2016-09-22 12:44 ` Lorenzo Pieralisi 2016-09-22 12:44 ` Lorenzo Pieralisi 2016-09-22 12:44 ` Lorenzo Pieralisi 2016-09-22 12:44 ` Lorenzo Pieralisi 2016-09-22 18:31 ` Bjorn Helgaas 2016-09-22 18:31 ` Bjorn Helgaas 2016-09-22 18:31 ` Bjorn Helgaas 2016-09-22 18:31 ` Bjorn Helgaas 2016-09-22 22:10 ` Bjorn Helgaas 2016-09-22 22:10 ` Bjorn Helgaas 2016-09-22 22:10 ` Bjorn Helgaas 2016-09-22 22:10 ` Bjorn Helgaas 2016-09-23 10:11 ` Lorenzo Pieralisi 2016-09-23 10:11 ` Lorenzo Pieralisi 2016-09-23 10:11 ` Lorenzo Pieralisi 2016-09-23 10:11 ` Lorenzo Pieralisi 2016-09-23 10:58 ` Gabriele Paoloni 2016-09-23 10:58 ` Gabriele Paoloni 2016-09-23 10:58 ` Gabriele Paoloni 2016-09-23 10:58 ` Gabriele Paoloni 2017-09-14 14:06 ` Ard Biesheuvel 2017-09-14 14:06 ` Ard Biesheuvel 2017-09-14 14:06 ` Ard Biesheuvel 2017-09-26 8:23 ` Gabriele Paoloni 2017-09-26 8:23 ` Gabriele Paoloni 2017-09-26 8:23 ` Gabriele Paoloni 2017-09-26 8:23 ` Gabriele Paoloni 2016-09-22 14:20 ` Christopher Covington 2016-09-22 14:20 ` Christopher Covington 2016-09-22 14:20 ` Christopher Covington 2016-09-22 14:20 ` Christopher Covington 2016-09-21 14:10 ` Gabriele Paoloni 2016-09-21 14:10 ` Gabriele Paoloni 2016-09-21 14:10 ` Gabriele Paoloni 2016-09-21 14:10 ` Gabriele Paoloni 2016-09-21 18:59 ` Bjorn Helgaas 2016-09-21 18:59 ` Bjorn Helgaas 2016-09-21 18:59 ` Bjorn Helgaas 2016-09-21 18:59 ` Bjorn Helgaas 2016-09-22 11:12 ` Gabriele Paoloni 2016-09-22 11:12 ` Gabriele Paoloni 2016-09-22 11:12 ` Gabriele Paoloni 2016-09-22 11:12 ` Gabriele Paoloni 2016-09-09 19:24 ` [PATCH V6 4/5] PCI: thunder: Enable ACPI PCI controller for ThunderX pass2.x silicon version Tomasz Nowicki 2016-09-09 19:24 ` Tomasz Nowicki 2016-09-19 15:45 ` Bjorn Helgaas 2016-09-19 15:45 ` Bjorn Helgaas 2016-09-20 7:06 ` Tomasz Nowicki 2016-09-20 7:06 ` Tomasz Nowicki 2016-09-20 13:08 ` Bjorn Helgaas 2016-09-20 13:08 ` Bjorn Helgaas 2016-09-20 13:08 ` Bjorn Helgaas 2016-09-21 8:05 ` Tomasz Nowicki 2016-09-21 8:05 ` Tomasz Nowicki 2016-09-09 19:24 ` [PATCH V6 5/5] PCI: thunder: Enable ACPI PCI controller for ThunderX pass1.x " Tomasz Nowicki 2016-09-09 19:24 ` Tomasz Nowicki 2016-09-09 19:30 ` [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms Tomasz Nowicki 2016-09-09 19:30 ` Tomasz Nowicki 2016-09-20 19:26 ` Bjorn Helgaas 2016-09-20 19:26 ` Bjorn Helgaas 2016-09-21 1:15 ` cov 2016-09-21 1:15 ` cov at codeaurora.org 2016-09-21 13:11 ` Bjorn Helgaas 2016-09-21 13:11 ` Bjorn Helgaas 2016-09-21 14:07 ` Sinan Kaya 2016-09-21 14:07 ` Sinan Kaya 2016-09-21 17:31 ` Bjorn Helgaas 2016-09-21 17:31 ` Bjorn Helgaas 2016-09-21 17:31 ` Bjorn Helgaas 2016-09-21 17:34 ` Sinan Kaya 2016-09-21 17:34 ` Sinan Kaya 2016-09-21 22:38 ` [PATCHv2] PCI: QDF2432 32 bit config space accessors Christopher Covington 2016-09-21 22:38 ` Christopher Covington 2016-10-31 21:48 ` Bjorn Helgaas 2016-10-31 21:48 ` Bjorn Helgaas 2016-11-01 13:06 ` cov 2016-11-01 13:06 ` cov at codeaurora.org 2016-11-02 16:08 ` Bjorn Helgaas 2016-11-02 16:08 ` Bjorn Helgaas 2016-11-02 16:36 ` Sinan Kaya 2016-11-02 16:36 ` Sinan Kaya 2016-11-03 14:00 ` Bjorn Helgaas 2016-11-03 14:00 ` Bjorn Helgaas 2016-11-03 16:58 ` Sinan Kaya 2016-11-03 16:58 ` Sinan Kaya 2016-11-03 17:06 ` Sinan Kaya 2016-11-03 17:06 ` Sinan Kaya 2016-11-03 20:43 ` Bjorn Helgaas 2016-11-03 20:43 ` Bjorn Helgaas 2016-11-03 23:49 ` Sinan Kaya 2016-11-03 23:49 ` Sinan Kaya 2016-12-02 4:58 ` Jon Masters 2016-12-02 4:58 ` Jon Masters 2016-11-02 16:41 ` Bjorn Helgaas 2016-11-02 16:41 ` Bjorn Helgaas 2016-11-09 19:25 ` Christopher Covington 2016-11-09 19:25 ` Christopher Covington 2016-11-09 20:06 ` Bjorn Helgaas 2016-11-09 20:06 ` Bjorn Helgaas 2016-11-09 20:29 ` Ard Biesheuvel 2016-11-09 20:29 ` Ard Biesheuvel 2016-11-09 20:29 ` Ard Biesheuvel 2016-11-09 20:29 ` Ard Biesheuvel 2016-11-09 22:49 ` Bjorn Helgaas 2016-11-09 22:49 ` Bjorn Helgaas 2016-11-09 22:49 ` Bjorn Helgaas 2016-11-09 22:49 ` Bjorn Helgaas 2016-11-10 10:25 ` Ard Biesheuvel 2016-11-10 10:25 ` Ard Biesheuvel 2016-11-10 10:25 ` Ard Biesheuvel 2016-11-10 10:25 ` Ard Biesheuvel 2016-11-10 13:57 ` Lorenzo Pieralisi 2016-11-10 13:57 ` Lorenzo Pieralisi 2016-11-10 13:57 ` Lorenzo Pieralisi 2016-11-10 13:57 ` Lorenzo Pieralisi 2016-11-10 17:42 ` Bjorn Helgaas 2016-11-10 17:42 ` Bjorn Helgaas 2016-11-10 17:42 ` Bjorn Helgaas 2016-11-10 17:42 ` Bjorn Helgaas 2016-12-02 5:12 ` Jon Masters 2016-12-02 5:12 ` Jon Masters 2016-12-02 5:12 ` Jon Masters 2016-12-02 5:12 ` Jon Masters 2016-09-21 22:40 ` [PATCH V6 0/5] ECAM quirks handling for ARM64 platforms Christopher Covington 2016-09-21 22:40 ` Christopher Covington 2016-09-22 23:08 ` Bjorn Helgaas 2016-09-22 23:08 ` Bjorn Helgaas 2016-09-23 18:41 ` Christopher Covington 2016-09-23 18:41 ` Christopher Covington 2016-09-23 19:17 ` Bjorn Helgaas 2016-09-23 19:17 ` Bjorn Helgaas 2016-09-23 19:17 ` Bjorn Helgaas 2016-09-23 19:22 ` Christopher Covington 2016-09-23 19:22 ` Christopher Covington 2016-09-28 16:44 ` Christopher Covington 2016-11-24 11:05 ` [PATCH V6 1/1] ARM64/PCI: Manage controller-specific information on the host controller basis Tomasz Nowicki 2016-11-24 11:05 ` Tomasz Nowicki 2016-11-29 23:40 ` Bjorn Helgaas 2016-11-29 23:40 ` Bjorn Helgaas
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=49f53bfc-4421-a8b0-694c-bce7e61e1c9e@semihalf.com \ --to=tn@semihalf.com \ --cc=Liviu.Dudau@arm.com \ --cc=Lorenzo.Pieralisi@arm.com \ --cc=andrea.gallo@linaro.org \ --cc=ard.biesheuvel@linaro.org \ --cc=arnd@arndb.de \ --cc=catalin.marinas@arm.com \ --cc=cov@codeaurora.org \ --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=jcm@redhat.com \ --cc=jeremy.linton@arm.com \ --cc=jhugo@codeaurora.org \ --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=liudongdong3@huawei.com \ --cc=msalter@redhat.com \ --cc=mw@semihalf.com \ --cc=okaya@codeaurora.org \ --cc=rafael@kernel.org \ --cc=robert.richter@caviumnetworks.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: linkBe 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.