diff for duplicates of <1452264683.31901.32.camel@redhat.com> diff --git a/a/1.txt b/N1/1.txt index 11095ce..7d1b217 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -11,16 +11,16 @@ On Fri, 2016-01-08 at 15:36 +0100, Tomasz Nowicki wrote: > > > example: > > > > > > static const struct dmi_system_id yyy[] = { -> > > { -> > > .ident = "<Platform ident string>", -> > > .callback = <handler>, -> > > .matches = { -> > > DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"), -> > > DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"), -> > > DMI_MATCH(DMI_PRODUCT_VERSION, "product version"), -> > > }, -> > > }, -> > > { } +> > > ?????????{ +> > > ?????????????????.ident = "<Platform ident string>", +> > > ?????????????????.callback = <handler>, +> > > ?????????????????.matches = { +> > > ?????????????????????????DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"), +> > > ?????????????????????????DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"), +> > > ?????????????????????????DMI_MATCH(DMI_PRODUCT_VERSION, "product version"), +> > > ?????????????????}, +> > > ?????????}, +> > > ?????????{ } > > > }; > > > > > @@ -30,10 +30,10 @@ On Fri, 2016-01-08 at 15:36 +0100, Tomasz Nowicki wrote: > > right. In that case, I think it'd be better to check CPUID and possibly > > some SoC register to cover all platforms affected. > -> Right, my next version already has alternative to DMI match handler, so +> Right, my next version already has alternative to DMI match handler, so? > there will be two ways to match: > 1. DMI, like in this patch set -> 2. int (*match)(struct pci_mcfg_fixup *) where you can read CPUID, and +> 2. int (*match)(struct pci_mcfg_fixup *) where you can read CPUID, and? > whatever is necessary. > @@ -46,9 +46,9 @@ Great. Thanks. > > default ecam ops? > > > -> Then we can identify them using <domain:bus>. I was wondering to pass -> acpi device handler to match handler for the case where we need e.g. -> extra properties from related DSDT device descriptor. Does it make sense +> Then we can identify them using <domain:bus>. I was wondering to pass? +> acpi device handler to match handler for the case where we need e.g.? +> extra properties from related DSDT device descriptor. Does it make sense? > to you? > diff --git a/a/content_digest b/N1/content_digest index 797f0f8..f3c0000 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,34 +2,10 @@ "ref\01450278993-12664-23-git-send-email-tn@semihalf.com\0" "ref\01452262581.31901.26.camel@redhat.com\0" "ref\0568FC969.8060909@semihalf.com\0" - "From\0Mark Salter <msalter@redhat.com>\0" - "Subject\0Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.\0" + "From\0msalter@redhat.com (Mark Salter)\0" + "Subject\0[PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks.\0" "Date\0Fri, 08 Jan 2016 09:51:23 -0500\0" - "To\0Tomasz 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 - Lorenzo.Pieralisi@arm.com - okaya@codeaurora.org - jiang.liu@linux.intel.com - " Stefano.Stabellini@eu.citrix.com\0" - "Cc\0robert.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\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Fri, 2016-01-08 at 15:36 +0100, Tomasz Nowicki wrote:\n" @@ -45,16 +21,16 @@ "> > > example:\n" "> > > \n" "> > > static const struct dmi_system_id yyy[] = {\n" - "> > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240{\n" - "> > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240.ident = \"<Platform ident string>\",\n" - "> > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240.callback = <handler>,\n" - "> > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240.matches = {\n" - "> > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240DMI_MATCH(DMI_SYS_VENDOR, \"<system vendor>\"),\n" - "> > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240DMI_MATCH(DMI_PRODUCT_NAME, \"<product name>\"),\n" - "> > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240DMI_MATCH(DMI_PRODUCT_VERSION, \"product version\"),\n" - "> > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240},\n" - "> > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240},\n" - "> > > \302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240\302\240{ }\n" + "> > > ?????????{\n" + "> > > ?????????????????.ident = \"<Platform ident string>\",\n" + "> > > ?????????????????.callback = <handler>,\n" + "> > > ?????????????????.matches = {\n" + "> > > ?????????????????????????DMI_MATCH(DMI_SYS_VENDOR, \"<system vendor>\"),\n" + "> > > ?????????????????????????DMI_MATCH(DMI_PRODUCT_NAME, \"<product name>\"),\n" + "> > > ?????????????????????????DMI_MATCH(DMI_PRODUCT_VERSION, \"product version\"),\n" + "> > > ?????????????????},\n" + "> > > ?????????},\n" + "> > > ?????????{ }\n" "> > > };\n" "> > > \n" "> > \n" @@ -64,10 +40,10 @@ "> > right. In that case, I think it'd be better to check CPUID and possibly\n" "> > some SoC register to cover all platforms affected.\n" "> \n" - "> Right, my next version already has alternative to DMI match handler, so\302\240\n" + "> Right, my next version already has alternative to DMI match handler, so?\n" "> there will be two ways to match:\n" "> 1. DMI, like in this patch set\n" - "> 2. int (*match)(struct pci_mcfg_fixup *) where you can read CPUID, and\302\240\n" + "> 2. int (*match)(struct pci_mcfg_fixup *) where you can read CPUID, and?\n" "> whatever is necessary.\n" "> \n" "\n" @@ -80,9 +56,9 @@ "> > default ecam ops?\n" "> > \n" "> \n" - "> Then we can identify them using <domain:bus>. I was wondering to pass\302\240\n" - "> acpi device handler to match handler for the case where we need e.g.\302\240\n" - "> extra properties from related DSDT device descriptor. Does it make sense\302\240\n" + "> Then we can identify them using <domain:bus>. I was wondering to pass?\n" + "> acpi device handler to match handler for the case where we need e.g.?\n" + "> extra properties from related DSDT device descriptor. Does it make sense?\n" "> to you?\n" "> \n" "\n" @@ -92,4 +68,4 @@ "easier for the match handler to find out which hw dev it is being asked to\n" match. -4e99554d056620b56a42e2bed3c32072f68501afc0d07308367f2c0caa6de8e8 +fe5971afe33f58320681ad39fb203fc95ba28f75212cac3f6986ddc4d77beb18
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.