diff for duplicates of <3706958.XeRFmKM0K5@wuerfel> diff --git a/a/1.txt b/N1/1.txt index 881b883..553e31a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -38,3 +38,7 @@ this hasn't happened then, but I'd still prefer that over yet another vendor-specific way of dealing with the generic issue. Arnd +_______________________________________________ +iommu mailing list +iommu@lists.linux-foundation.org +https://lists.linuxfoundation.org/mailman/listinfo/iommu diff --git a/a/content_digest b/N1/content_digest index 7522ccd..3529f7d 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,31 +1,28 @@ "ref\01457518131-11339-1-git-send-email-yangbo.lu@nxp.com\0" "ref\0DB5PR0401MB19286B2D23D07F5C60DB799D91880@DB5PR0401MB1928.eurprd04.prod.outlook.com\0" "ref\020160317170101.GA21009@rob-hp-laptop\0" - "From\0Arnd Bergmann <arnd@arndb.de>\0" + "From\0Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>\0" "Subject\0Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0\0" "Date\0Thu, 17 Mar 2016 18:06:09 +0100\0" - "To\0Rob Herring <robh@kernel.org>\0" - "Cc\0Scott Wood <scott.wood@nxp.com>" - Yangbo Lu <yangbo.lu@nxp.com> - linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> - devicetree@vger.kernel.org <devicetree@vger.kernel.org> - ulf.hansson@linaro.org <ulf.hansson@linaro.org> - Zhao Qiang <qiang.zhao@freescale.com> - Russell King <linux@arm.linux.org.uk> - Bhupesh Sharma <bhupesh.sharma@freescale.com> - netdev@vger.kernel.org <netdev@vger.kernel.org> - Joerg Roedel <joro@8bytes.org> - Kumar Gala <galak@codeaurora.org> - linux-mmc@vger.kernel.org <linux-mmc@vger.kernel.org> - linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> - Yang-Leo Li <leoyang.li@nxp.com> - iommu@lists.linux-foundation.org <iommu@lists.linux-foundation.org> - linux-i2c@vger.kernel.org <linux-i2c@vger.kernel.org> - Claudiu Manoil <claudiu.manoil@freescale.com> - Santosh Shilimkar <ssantosh@kernel.org> - Xiaobo Xie <xiaobo.xie@nxp.com> - linux-clk@vger.kernel.org <linux-clk@vger.kernel.org> - " linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>\0" + "To\0Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>\0" + "Cc\0linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>" + devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> + ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> + Zhao Qiang <qiang.zhao-KZfg59tc24xl57MIdRCFDg@public.gmane.org> + Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> + Santosh Shilimkar <ssantosh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> + Bhupesh Sharma <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org> + netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> + Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> + linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> + linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> + Scott Wood <scott.wood-3arQi8VN3Tc@public.gmane.org> + iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org> + linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> + Claudiu Manoil <claudiu.manoil-KZfg59tc24xl57MIdRCFDg@public.gmane.org> + Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org> + Yang-Leo Li <leoyang.li-3arQi8VN3Tc@public.gmane.org> + " linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org <linuxppc-dev>\0" "\00:1\0" "b\0" "On Thursday 17 March 2016 12:01:01 Rob Herring wrote:\n" @@ -67,6 +64,10 @@ "this hasn't happened then, but I'd still prefer that over yet another\n" "vendor-specific way of dealing with the generic issue.\n" "\n" - "\tArnd" + "\tArnd\n" + "_______________________________________________\n" + "iommu mailing list\n" + "iommu@lists.linux-foundation.org\n" + https://lists.linuxfoundation.org/mailman/listinfo/iommu -d0a249b3abfaac0dc26c8281fe73a54229c20ae8e05bb82e42e6c9f38a97035a +d896b6ad74ba280ce4a082f7a301fdc51fc44a9d605c9ed8ff0a3879fcae5b85
diff --git a/a/1.txt b/N2/1.txt index 881b883..20a4915 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,35 +1,46 @@ On Thursday 17 March 2016 12:01:01 Rob Herring wrote: > On Mon, Mar 14, 2016 at 05:45:43PM +0000, Scott Wood wrote: -> > >> This makes the driver non-portable. Better identify the specific -> > >> workarounds based on the compatible string for this device, or add a +> > >> This makes the driver non-portable. Better identify the specific= + +> > >> workarounds based on the compatible string for this device, or a= +dd a > > >> boolean DT property for the quirk. > > >> > > >> Arnd -> > > -> > > [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in v1 before. +> > >=20 +> > > [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using = +DTS in v1 before. > > > https://patchwork.kernel.org/patch/6834221/ -> > > -> > > We don’t have a separate DTS file for each revision of an SOC and if we did, we'd constantly have people using the wrong one. -> > > In addition, the device tree is stable ABI and errata are often discovered after device tree are deployed. +> > >=20 +> > > We don=E2=80=99t have a separate DTS file for each revision of an= + SOC and if we did, we'd constantly have people using the wrong one. +> > > In addition, the device tree is stable ABI and errata are often d= +iscovered after device tree are deployed. > > > See the link for details. -> > > -> > > So we decide to read SVR from the device-config/guts MMIO block other than using DTS. +> > >=20 +> > > So we decide to read SVR from the device-config/guts MMIO block o= +ther than using DTS. > > > Thanks. -> > -> > Also note that this driver is already only for fsl-specific hardware, -> > and it will still work even if fsl_guts doesn't find anything to bind to -> > -- it just wouldn't be able to detect errata based on SVR in that case. -> -> IIRC, it is the same IP block as i.MX and Arnd's point is this won't -> even compile on !PPC. It is things like this that prevent sharing the +> >=20 +> > Also note that this driver is already only for fsl-specific hardwar= +e, +> > and it will still work even if fsl_guts doesn't find anything to bi= +nd to +> > -- it just wouldn't be able to detect errata based on SVR in that c= +ase. +>=20 +> IIRC, it is the same IP block as i.MX and Arnd's point is this won't=20= + +> even compile on !PPC. It is things like this that prevent sharing the= +=20 > driver. I think the first four patches take care of building for ARM, but the problem remains if you want to enable COMPILE_TEST as we need for certain automated checking. -> Dealing with Si revs is a common problem. We should have a +> Dealing with Si revs is a common problem. We should have a=20 > common solution. There is soc_device for this purpose. Exactly. The last time this came up, I think we agreed to implement a @@ -37,4 +48,4 @@ helper using glob_match() on the soc_device strings. Unfortunately this hasn't happened then, but I'd still prefer that over yet another vendor-specific way of dealing with the generic issue. - Arnd +=09Arnd diff --git a/a/content_digest b/N2/content_digest index 7522ccd..3598210 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -31,35 +31,46 @@ "On Thursday 17 March 2016 12:01:01 Rob Herring wrote:\n" "> On Mon, Mar 14, 2016 at 05:45:43PM +0000, Scott Wood wrote:\n" "\n" - "> > >> This makes the driver non-portable. Better identify the specific\n" - "> > >> workarounds based on the compatible string for this device, or add a\n" + "> > >> This makes the driver non-portable. Better identify the specific=\n" + "\n" + "> > >> workarounds based on the compatible string for this device, or a=\n" + "dd a\n" "> > >> boolean DT property for the quirk.\n" "> > >>\n" "> > >> Arnd\n" - "> > > \n" - "> > > [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in v1 before.\n" + "> > >=20\n" + "> > > [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using =\n" + "DTS in v1 before.\n" "> > > https://patchwork.kernel.org/patch/6834221/\n" - "> > > \n" - "> > > We don\342\200\231t have a separate DTS file for each revision of an SOC and if we did, we'd constantly have people using the wrong one.\n" - "> > > In addition, the device tree is stable ABI and errata are often discovered after device tree are deployed.\n" + "> > >=20\n" + "> > > We don=E2=80=99t have a separate DTS file for each revision of an=\n" + " SOC and if we did, we'd constantly have people using the wrong one.\n" + "> > > In addition, the device tree is stable ABI and errata are often d=\n" + "iscovered after device tree are deployed.\n" "> > > See the link for details.\n" - "> > > \n" - "> > > So we decide to read SVR from the device-config/guts MMIO block other than using DTS.\n" + "> > >=20\n" + "> > > So we decide to read SVR from the device-config/guts MMIO block o=\n" + "ther than using DTS.\n" "> > > Thanks.\n" - "> > \n" - "> > Also note that this driver is already only for fsl-specific hardware,\n" - "> > and it will still work even if fsl_guts doesn't find anything to bind to\n" - "> > -- it just wouldn't be able to detect errata based on SVR in that case.\n" - "> \n" - "> IIRC, it is the same IP block as i.MX and Arnd's point is this won't \n" - "> even compile on !PPC. It is things like this that prevent sharing the \n" + "> >=20\n" + "> > Also note that this driver is already only for fsl-specific hardwar=\n" + "e,\n" + "> > and it will still work even if fsl_guts doesn't find anything to bi=\n" + "nd to\n" + "> > -- it just wouldn't be able to detect errata based on SVR in that c=\n" + "ase.\n" + ">=20\n" + "> IIRC, it is the same IP block as i.MX and Arnd's point is this won't=20=\n" + "\n" + "> even compile on !PPC. It is things like this that prevent sharing the=\n" + "=20\n" "> driver.\n" "\n" "I think the first four patches take care of building for ARM,\n" "but the problem remains if you want to enable COMPILE_TEST as\n" "we need for certain automated checking.\n" "\n" - "> Dealing with Si revs is a common problem. We should have a \n" + "> Dealing with Si revs is a common problem. We should have a=20\n" "> common solution. There is soc_device for this purpose.\n" "\n" "Exactly. The last time this came up, I think we agreed to implement a\n" @@ -67,6 +78,6 @@ "this hasn't happened then, but I'd still prefer that over yet another\n" "vendor-specific way of dealing with the generic issue.\n" "\n" - "\tArnd" + =09Arnd -d0a249b3abfaac0dc26c8281fe73a54229c20ae8e05bb82e42e6c9f38a97035a +9729f07eb721eaf08f584485bd139daeab5cce5a6587377dbbebc47bdbcc21b1
diff --git a/a/1.txt b/N3/1.txt index 881b883..d2be21a 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -10,7 +10,7 @@ On Thursday 17 March 2016 12:01:01 Rob Herring wrote: > > > [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in v1 before. > > > https://patchwork.kernel.org/patch/6834221/ > > > -> > > We don’t have a separate DTS file for each revision of an SOC and if we did, we'd constantly have people using the wrong one. +> > > We don?t have a separate DTS file for each revision of an SOC and if we did, we'd constantly have people using the wrong one. > > > In addition, the device tree is stable ABI and errata are often discovered after device tree are deployed. > > > See the link for details. > > > diff --git a/a/content_digest b/N3/content_digest index 7522ccd..823122d 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -1,31 +1,10 @@ "ref\01457518131-11339-1-git-send-email-yangbo.lu@nxp.com\0" "ref\0DB5PR0401MB19286B2D23D07F5C60DB799D91880@DB5PR0401MB1928.eurprd04.prod.outlook.com\0" "ref\020160317170101.GA21009@rob-hp-laptop\0" - "From\0Arnd Bergmann <arnd@arndb.de>\0" - "Subject\0Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0\0" + "From\0arnd@arndb.de (Arnd Bergmann)\0" + "Subject\0[v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0\0" "Date\0Thu, 17 Mar 2016 18:06:09 +0100\0" - "To\0Rob Herring <robh@kernel.org>\0" - "Cc\0Scott Wood <scott.wood@nxp.com>" - Yangbo Lu <yangbo.lu@nxp.com> - linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> - devicetree@vger.kernel.org <devicetree@vger.kernel.org> - ulf.hansson@linaro.org <ulf.hansson@linaro.org> - Zhao Qiang <qiang.zhao@freescale.com> - Russell King <linux@arm.linux.org.uk> - Bhupesh Sharma <bhupesh.sharma@freescale.com> - netdev@vger.kernel.org <netdev@vger.kernel.org> - Joerg Roedel <joro@8bytes.org> - Kumar Gala <galak@codeaurora.org> - linux-mmc@vger.kernel.org <linux-mmc@vger.kernel.org> - linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> - Yang-Leo Li <leoyang.li@nxp.com> - iommu@lists.linux-foundation.org <iommu@lists.linux-foundation.org> - linux-i2c@vger.kernel.org <linux-i2c@vger.kernel.org> - Claudiu Manoil <claudiu.manoil@freescale.com> - Santosh Shilimkar <ssantosh@kernel.org> - Xiaobo Xie <xiaobo.xie@nxp.com> - linux-clk@vger.kernel.org <linux-clk@vger.kernel.org> - " linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "On Thursday 17 March 2016 12:01:01 Rob Herring wrote:\n" @@ -40,7 +19,7 @@ "> > > [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in v1 before.\n" "> > > https://patchwork.kernel.org/patch/6834221/\n" "> > > \n" - "> > > We don\342\200\231t have a separate DTS file for each revision of an SOC and if we did, we'd constantly have people using the wrong one.\n" + "> > > We don?t have a separate DTS file for each revision of an SOC and if we did, we'd constantly have people using the wrong one.\n" "> > > In addition, the device tree is stable ABI and errata are often discovered after device tree are deployed.\n" "> > > See the link for details.\n" "> > > \n" @@ -69,4 +48,4 @@ "\n" "\tArnd" -d0a249b3abfaac0dc26c8281fe73a54229c20ae8e05bb82e42e6c9f38a97035a +6267ec5560487540ac95c8ffba93f66f47b1785445c3560493cd15fc233d5b0e
diff --git a/a/1.txt b/N4/1.txt index 881b883..553e31a 100644 --- a/a/1.txt +++ b/N4/1.txt @@ -38,3 +38,7 @@ this hasn't happened then, but I'd still prefer that over yet another vendor-specific way of dealing with the generic issue. Arnd +_______________________________________________ +iommu mailing list +iommu@lists.linux-foundation.org +https://lists.linuxfoundation.org/mailman/listinfo/iommu diff --git a/a/content_digest b/N4/content_digest index 7522ccd..e4ccaac 100644 --- a/a/content_digest +++ b/N4/content_digest @@ -1,31 +1,28 @@ "ref\01457518131-11339-1-git-send-email-yangbo.lu@nxp.com\0" "ref\0DB5PR0401MB19286B2D23D07F5C60DB799D91880@DB5PR0401MB1928.eurprd04.prod.outlook.com\0" "ref\020160317170101.GA21009@rob-hp-laptop\0" - "From\0Arnd Bergmann <arnd@arndb.de>\0" + "From\0Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>\0" "Subject\0Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0\0" "Date\0Thu, 17 Mar 2016 18:06:09 +0100\0" - "To\0Rob Herring <robh@kernel.org>\0" - "Cc\0Scott Wood <scott.wood@nxp.com>" - Yangbo Lu <yangbo.lu@nxp.com> - linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> - devicetree@vger.kernel.org <devicetree@vger.kernel.org> - ulf.hansson@linaro.org <ulf.hansson@linaro.org> - Zhao Qiang <qiang.zhao@freescale.com> - Russell King <linux@arm.linux.org.uk> - Bhupesh Sharma <bhupesh.sharma@freescale.com> - netdev@vger.kernel.org <netdev@vger.kernel.org> - Joerg Roedel <joro@8bytes.org> - Kumar Gala <galak@codeaurora.org> - linux-mmc@vger.kernel.org <linux-mmc@vger.kernel.org> - linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> - Yang-Leo Li <leoyang.li@nxp.com> - iommu@lists.linux-foundation.org <iommu@lists.linux-foundation.org> - linux-i2c@vger.kernel.org <linux-i2c@vger.kernel.org> - Claudiu Manoil <claudiu.manoil@freescale.com> - Santosh Shilimkar <ssantosh@kernel.org> - Xiaobo Xie <xiaobo.xie@nxp.com> - linux-clk@vger.kernel.org <linux-clk@vger.kernel.org> - " linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>\0" + "To\0Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>\0" + "Cc\0linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>" + devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> + ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org <ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> + Zhao Qiang <qiang.zhao-KZfg59tc24xl57MIdRCFDg@public.gmane.org> + Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> + Santosh Shilimkar <ssantosh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> + Bhupesh Sharma <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org> + netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> + Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> + linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> + linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> + Scott Wood <scott.wood-3arQi8VN3Tc@public.gmane.org> + iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org <iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org> + linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> + Claudiu Manoil <claudiu.manoil-KZfg59tc24xl57MIdRCFDg@public.gmane.org> + Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org> + Yang-Leo Li <leoyang.li-3arQi8VN3Tc@public.gmane.org> + " linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org <linuxppc-dev\0" "\00:1\0" "b\0" "On Thursday 17 March 2016 12:01:01 Rob Herring wrote:\n" @@ -67,6 +64,10 @@ "this hasn't happened then, but I'd still prefer that over yet another\n" "vendor-specific way of dealing with the generic issue.\n" "\n" - "\tArnd" + "\tArnd\n" + "_______________________________________________\n" + "iommu mailing list\n" + "iommu@lists.linux-foundation.org\n" + https://lists.linuxfoundation.org/mailman/listinfo/iommu -d0a249b3abfaac0dc26c8281fe73a54229c20ae8e05bb82e42e6c9f38a97035a +ed38768e62291c8ad26583492fd59d56e4ea36e99b2a253d0d151e4a6f75ce92
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.