diff for duplicates of <1480620053.4751.30.camel@redhat.com> diff --git a/a/1.txt b/N1/1.txt index bd268dd..33b9d78 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -17,27 +17,27 @@ On Thu, 2016-12-01 at 12:33 -0600, Bjorn Helgaas wrote: > > Signed-off-by: Duc Dang <dhdang@apm.com> > > --- > > v3: -> > - Rebase on top of pci/ecam-v6 tree. -> > - Use DEFINE_RES_MEM_NAMED to declare controller register space -> > with name "PCIe CSR" +> > ? - Rebase on top of pci/ecam-v6 tree. +> > ? - Use DEFINE_RES_MEM_NAMED to declare controller register space +> > ? with name "PCIe CSR" > > v2: -> > RFC v2: https://patchwork.ozlabs.org/patch/686846/ +> > ? RFC v2: https://patchwork.ozlabs.org/patch/686846/ > > v1: -> > RFC v1: https://patchwork.kernel.org/patch/9337115/ +> > ? RFC v1: https://patchwork.kernel.org/patch/9337115/ > > -> > drivers/acpi/pci_mcfg.c | 31 ++++++++ -> > drivers/pci/host/pci-xgene.c | 165 ++++++++++++++++++++++++++++++++++++++++++- -> > include/linux/pci-ecam.h | 7 ++ -> > 3 files changed, 200 insertions(+), 3 deletions(-) +> > ?drivers/acpi/pci_mcfg.c??????|??31 ++++++++ +> > ?drivers/pci/host/pci-xgene.c | 165 ++++++++++++++++++++++++++++++++++++++++++- +> > ?include/linux/pci-ecam.h?????|???7 ++ +> > ?3 files changed, 200 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c > > index ac21db3..eb6125b 100644 > > --- a/drivers/acpi/pci_mcfg.c > > +++ b/drivers/acpi/pci_mcfg.c > > @@ -57,6 +57,37 @@ struct mcfg_fixup { -> > { "QCOM ", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops }, -> > { "QCOM ", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops }, -> > { "QCOM ", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops }, +> > ? { "QCOM??", "QDF2432 ", 1, 5, MCFG_BUS_ANY, &pci_32b_ops }, +> > ? { "QCOM??", "QDF2432 ", 1, 6, MCFG_BUS_ANY, &pci_32b_ops }, +> > ? { "QCOM??", "QDF2432 ", 1, 7, MCFG_BUS_ANY, &pci_32b_ops }, > > + > > +#ifdef CONFIG_PCI_XGENE > As you've no doubt noticed, I'm proposing to add these quirks without @@ -53,13 +53,13 @@ On Thu, 2016-12-01 at 12:33 -0600, Bjorn Helgaas wrote: > > > > > +#define XGENE_V1_ECAM_MCFG(rev, seg) \ -> > + {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \ +> > + {"APM???", "XGENE???", rev, seg, MCFG_BUS_ANY, \ > > + &xgene_v1_pcie_ecam_ops } > > +#define XGENE_V2_1_ECAM_MCFG(rev, seg) \ -> > + {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \ +> > + {"APM???", "XGENE???", rev, seg, MCFG_BUS_ANY, \ > > + &xgene_v2_1_pcie_ecam_ops } > > +#define XGENE_V2_2_ECAM_MCFG(rev, seg) \ -> > + {"APM ", "XGENE ", rev, seg, MCFG_BUS_ANY, \ +> > + {"APM???", "XGENE???", rev, seg, MCFG_BUS_ANY, \ > > + &xgene_v2_2_pcie_ecam_ops } > > + > > + /* X-Gene SoC with v1 PCIe controller */ @@ -67,16 +67,16 @@ On Thu, 2016-12-01 at 12:33 -0600, Bjorn Helgaas wrote: > > + XGENE_V1_ECAM_MCFG(1, 1), > > > > @@ -64,6 +66,7 @@ -> > /* PCIe IP version */ -> > #define XGENE_PCIE_IP_VER_UNKN 0 -> > #define XGENE_PCIE_IP_VER_1 1 +> > ?/* PCIe IP version */ +> > ?#define XGENE_PCIE_IP_VER_UNKN 0 +> > ?#define XGENE_PCIE_IP_VER_1 1 > > +#define XGENE_PCIE_IP_VER_2 2 > This isn't used anywhere, which makes me wonder whether it's worth > keeping it. > > > -> > static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus) -> > { +> > ?static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus) +> > ?{ > > - struct xgene_pcie_port *port = bus->sysdata; > > + struct pci_config_window *cfg; > > + struct xgene_pcie_port *port; @@ -88,7 +88,7 @@ On Thu, 2016-12-01 at 12:33 -0600, Bjorn Helgaas wrote: > > + port = cfg->priv; > > + } > I would really, really like to figure out a way to get rid of these -> "if (acpi_disabled)" checks sprinkled through here. Is there any way +> "if (acpi_disabled)" checks sprinkled through here.??Is there any way > we can set up bus->sysdata to be the same, regardless of whether we're > using this as a platform driver or an ACPI quirk? > @@ -96,10 +96,10 @@ On Thu, 2016-12-01 at 12:33 -0600, Bjorn Helgaas wrote: > > +#ifdef CONFIG_ACPI > You've probably noticed that I've been using > -> #if defined(CONFIG_ACPI) && defined(CONFIG_PCI_QUIRKS) +> ? #if defined(CONFIG_ACPI) && defined(CONFIG_PCI_QUIRKS) > > in this situation, mostly to make it clear that this is part of a -> workaround. I don't want people to blindly copy this stuff without +> workaround.??I don't want people to blindly copy this stuff without > realizing that it's a workaround for a hardware issue. > > > @@ -155,8 +155,8 @@ static int xgene_pcie_get_csr(struct device *dev, struct resource *r) INIT_LIST_HEAD(&list); flags = IORESOURCE_MEM; ret = acpi_dev_get_resources(adev, &list, - acpi_dev_filter_resource_type_cb, - (void *)flags); + ?????acpi_dev_filter_resource_type_cb, + ?????(void *)flags); if (ret < 0) { dev_err(dev, "failed to parse _CRS, error: %d\n", ret); return ret; @@ -183,11 +183,11 @@ static int xgene_pcie_get_csr(struct device *dev, struct resource *r) > > + port->version = XGENE_PCIE_IP_VER_1; > > + > > + cfg->priv = port; -> All these init functions are almost identical. Can we factor this out +> All these init functions are almost identical.??Can we factor this out > by having wrappers that do nothing more than pass in the table and > version, and put the kzalloc and ioremap in a shared back-end? > -> We're so close I can taste it! I can't wait to see all this work come +> We're so close I can taste it!??I can't wait to see all this work come > to fruition. > > Bjorn diff --git a/a/content_digest b/N1/content_digest index 085f87c..2129604 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,19 +1,9 @@ "ref\01480549373-2123-1-git-send-email-dhdang@apm.com\0" "ref\020161201183350.GF30746@bhelgaas-glaptop.roam.corp.google.com\0" - "From\0Mark Salter <msalter@redhat.com>\0" - "Subject\0Re: [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller\0" + "From\0msalter@redhat.com (Mark Salter)\0" + "Subject\0[PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller\0" "Date\0Thu, 01 Dec 2016 14:20:53 -0500\0" - "To\0Bjorn Helgaas <helgaas@kernel.org>" - " Duc Dang <dhdang@apm.com>\0" - "Cc\0Rafael Wysocki <rafael@kernel.org>" - Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com> - Arnd Bergmann <arnd@arndb.de> - linux-pci@vger.kernel.org - linux-arm <linux-arm-kernel@lists.infradead.org> - Linux Kernel Mailing List <linux-kernel@vger.kernel.org> - Jon Masters <jcm@redhat.com> - Tomasz Nowicki <tn@semihalf.com> - " patches <patches@apm.com>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Thu, 2016-12-01 at 12:33 -0600, Bjorn Helgaas wrote:\n" @@ -35,27 +25,27 @@ "> > Signed-off-by: Duc Dang <dhdang@apm.com>\n" "> > ---\n" "> > v3:\n" - "> > \302\240 - Rebase on top of pci/ecam-v6 tree.\n" - "> > \302\240 - Use DEFINE_RES_MEM_NAMED to declare controller register space\n" - "> > \302\240 with name \"PCIe CSR\"\n" + "> > ? - Rebase on top of pci/ecam-v6 tree.\n" + "> > ? - Use DEFINE_RES_MEM_NAMED to declare controller register space\n" + "> > ? with name \"PCIe CSR\"\n" "> > v2:\n" - "> > \302\240 RFC v2: https://patchwork.ozlabs.org/patch/686846/\n" + "> > ? RFC v2: https://patchwork.ozlabs.org/patch/686846/\n" "> > v1:\n" - "> > \302\240 RFC v1: https://patchwork.kernel.org/patch/9337115/\n" + "> > ? RFC v1: https://patchwork.kernel.org/patch/9337115/\n" "> > \n" - "> > \302\240drivers/acpi/pci_mcfg.c\302\240\302\240\302\240\302\240\302\240\302\240|\302\240\302\24031 ++++++++\n" - "> > \302\240drivers/pci/host/pci-xgene.c | 165 ++++++++++++++++++++++++++++++++++++++++++-\n" - "> > \302\240include/linux/pci-ecam.h\302\240\302\240\302\240\302\240\302\240|\302\240\302\240\302\2407 ++\n" - "> > \302\2403 files changed, 200 insertions(+), 3 deletions(-)\n" + "> > ?drivers/acpi/pci_mcfg.c??????|??31 ++++++++\n" + "> > ?drivers/pci/host/pci-xgene.c | 165 ++++++++++++++++++++++++++++++++++++++++++-\n" + "> > ?include/linux/pci-ecam.h?????|???7 ++\n" + "> > ?3 files changed, 200 insertions(+), 3 deletions(-)\n" "> > \n" "> > diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c\n" "> > index ac21db3..eb6125b 100644\n" "> > --- a/drivers/acpi/pci_mcfg.c\n" "> > +++ b/drivers/acpi/pci_mcfg.c\n" "> > @@ -57,6 +57,37 @@ struct mcfg_fixup {\n" - "> > \302\240\t{ \"QCOM\302\240\302\240\", \"QDF2432 \", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },\n" - "> > \302\240\t{ \"QCOM\302\240\302\240\", \"QDF2432 \", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },\n" - "> > \302\240\t{ \"QCOM\302\240\302\240\", \"QDF2432 \", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },\n" + "> > ?\t{ \"QCOM??\", \"QDF2432 \", 1, 5, MCFG_BUS_ANY, &pci_32b_ops },\n" + "> > ?\t{ \"QCOM??\", \"QDF2432 \", 1, 6, MCFG_BUS_ANY, &pci_32b_ops },\n" + "> > ?\t{ \"QCOM??\", \"QDF2432 \", 1, 7, MCFG_BUS_ANY, &pci_32b_ops },\n" "> > +\n" "> > +#ifdef CONFIG_PCI_XGENE\n" "> As you've no doubt noticed, I'm proposing to add these quirks without\n" @@ -71,13 +61,13 @@ "> \n" "> > \n" "> > +#define XGENE_V1_ECAM_MCFG(rev, seg) \\\n" - "> > +\t{\"APM\302\240\302\240\302\240\", \"XGENE\302\240\302\240\302\240\", rev, seg, MCFG_BUS_ANY, \\\n" + "> > +\t{\"APM???\", \"XGENE???\", rev, seg, MCFG_BUS_ANY, \\\n" "> > +\t\t&xgene_v1_pcie_ecam_ops }\n" "> > +#define XGENE_V2_1_ECAM_MCFG(rev, seg) \\\n" - "> > +\t{\"APM\302\240\302\240\302\240\", \"XGENE\302\240\302\240\302\240\", rev, seg, MCFG_BUS_ANY, \\\n" + "> > +\t{\"APM???\", \"XGENE???\", rev, seg, MCFG_BUS_ANY, \\\n" "> > +\t\t&xgene_v2_1_pcie_ecam_ops }\n" "> > +#define XGENE_V2_2_ECAM_MCFG(rev, seg) \\\n" - "> > +\t{\"APM\302\240\302\240\302\240\", \"XGENE\302\240\302\240\302\240\", rev, seg, MCFG_BUS_ANY, \\\n" + "> > +\t{\"APM???\", \"XGENE???\", rev, seg, MCFG_BUS_ANY, \\\n" "> > +\t\t&xgene_v2_2_pcie_ecam_ops }\n" "> > +\n" "> > +\t/* X-Gene SoC with v1 PCIe controller */\n" @@ -85,16 +75,16 @@ "> > +\tXGENE_V1_ECAM_MCFG(1, 1),\n" "> > \n" "> > @@ -64,6 +66,7 @@\n" - "> > \302\240/* PCIe IP version */\n" - "> > \302\240#define XGENE_PCIE_IP_VER_UNKN\t\t0\n" - "> > \302\240#define XGENE_PCIE_IP_VER_1\t\t1\n" + "> > ?/* PCIe IP version */\n" + "> > ?#define XGENE_PCIE_IP_VER_UNKN\t\t0\n" + "> > ?#define XGENE_PCIE_IP_VER_1\t\t1\n" "> > +#define XGENE_PCIE_IP_VER_2\t\t2\n" "> This isn't used anywhere, which makes me wonder whether it's worth\n" "> keeping it.\n" "> \n" "> > \n" - "> > \302\240static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)\n" - "> > \302\240{\n" + "> > ?static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)\n" + "> > ?{\n" "> > -\tstruct xgene_pcie_port *port = bus->sysdata;\n" "> > +\tstruct pci_config_window *cfg;\n" "> > +\tstruct xgene_pcie_port *port;\n" @@ -106,7 +96,7 @@ "> > +\t\tport = cfg->priv;\n" "> > +\t}\n" "> I would really, really like to figure out a way to get rid of these\n" - "> \"if (acpi_disabled)\" checks sprinkled through here.\302\240\302\240Is there any way\n" + "> \"if (acpi_disabled)\" checks sprinkled through here.??Is there any way\n" "> we can set up bus->sysdata to be the same, regardless of whether we're\n" "> using this as a platform driver or an ACPI quirk?\n" "> \n" @@ -114,10 +104,10 @@ "> > +#ifdef CONFIG_ACPI\n" "> You've probably noticed that I've been using\n" "> \n" - "> \302\240 #if defined(CONFIG_ACPI) && defined(CONFIG_PCI_QUIRKS)\n" + "> ? #if defined(CONFIG_ACPI) && defined(CONFIG_PCI_QUIRKS)\n" "> \n" "> in this situation, mostly to make it clear that this is part of a\n" - "> workaround.\302\240\302\240I don't want people to blindly copy this stuff without\n" + "> workaround.??I don't want people to blindly copy this stuff without\n" "> realizing that it's a workaround for a hardware issue.\n" "> \n" "> > \n" @@ -173,8 +163,8 @@ "\tINIT_LIST_HEAD(&list);\n" "\tflags = IORESOURCE_MEM;\n" "\tret = acpi_dev_get_resources(adev, &list,\n" - "\t\t\t\t\302\240\302\240\302\240\302\240\302\240acpi_dev_filter_resource_type_cb,\n" - "\t\t\t\t\302\240\302\240\302\240\302\240\302\240(void *)flags);\n" + "\t\t\t\t?????acpi_dev_filter_resource_type_cb,\n" + "\t\t\t\t?????(void *)flags);\n" "\tif (ret < 0) {\n" "\t\tdev_err(dev, \"failed to parse _CRS, error: %d\\n\", ret);\n" "\t\treturn ret;\n" @@ -201,13 +191,13 @@ "> > +\tport->version = XGENE_PCIE_IP_VER_1;\n" "> > +\n" "> > +\tcfg->priv = port;\n" - "> All these init functions are almost identical.\302\240\302\240Can we factor this out\n" + "> All these init functions are almost identical.??Can we factor this out\n" "> by having wrappers that do nothing more than pass in the table and\n" "> version, and put the kzalloc and ioremap in a shared back-end?\n" "> \n" - "> We're so close I can taste it!\302\240\302\240I can't wait to see all this work come\n" + "> We're so close I can taste it!??I can't wait to see all this work come\n" "> to fruition.\n" "> \n" > Bjorn -0a68b8adc444497088f60f0d83c01849ed626fdc81c2701b79236227a1398e02 +81b488c54b4bfcc65769ce96be8fb8bec339cee1672ee14ce91f299b177e7c41
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.