diff for duplicates of <20180104185210.afsvsofq7q35psa6@flea.lan> diff --git a/a/1.txt b/N1/1.txt index 9fb6454..8ae9dad 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,53 +1,46 @@ -On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej =C5=A0krabec wrote: +On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej ?krabec wrote: > Hi Rob, ->=20 +> > Dne sreda, 03. januar 2018 ob 21:21:54 CET je Rob Herring napisal(a): > > On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote: > > > This commit adds all necessary compatibles and descriptions needed to > > > implement A83T HDMI pipeline. -> > >=20 +> > > > > > Mixer is already properly described, so only compatible is added. -> > >=20 -> > > However, A83T TCON1, which is connected to HDMI, doesn't have channel= - 0, +> > > +> > > However, A83T TCON1, which is connected to HDMI, doesn't have channel 0, > > > contrary to all TCONs currently described. Because of that, TCON > > > documentation is extended. -> > >=20 -> > > A83T features Synopsys DW HDMI controller with a custom PHY which loo= -ks +> > > +> > > A83T features Synopsys DW HDMI controller with a custom PHY which looks > > > like Synopsys Gen2 PHY with few additions. Since there is no -> > > documentation, needed properties were found out through experimentati= -on +> > > documentation, needed properties were found out through experimentation > > > and reading BSP code. -> > >=20 +> > > > > > At the end, example is added for newer SoCs, which features DE2 and DW > > > HDMI. -> > >=20 +> > > > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> > > > --- -> > >=20 +> > > > > > .../bindings/display/sunxi/sun4i-drm.txt | 188 -> > > ++++++++++++++++++++- 1 file changed, 181 insertions(+), 7 deletions= -(-) -> > >=20 -> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-dr= -m.txt +> > > ++++++++++++++++++++- 1 file changed, 181 insertions(+), 7 deletions(-) +> > > +> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index > > > 9f073af4c711..3eca258096a5 100644 > > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt -> > >=20 +> > > > > > @@ -64,6 +64,40 @@ Required properties: > > > first port should be the input endpoint. The second should be the > > > output, usually to an HDMI connector. -> > >=20 +> > > > > > +DWC HDMI TX Encoder > > > +----------------------------- > > > + -> > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller= - IP -> > > +with Allwinner's own PHY IP. It supports audio and video outputs and= - CEC. +> > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP +> > > +with Allwinner's own PHY IP. It supports audio and video outputs and CEC. > > > + > > > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in > > > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the @@ -61,33 +54,24 @@ m.txt > > > first > > > + for controller and second for PHY > > > + registers. -> >=20 +> > > > Seems like the phy should be a separate node and use the phy binding. > > You can use the phy binding even if you don't use the kernel phy > > framework... ->=20 -> Unfortunately, it's not so straighforward. Phy is actually accessed throu= -gh=20 -> I2C implemented in HDMI controller. Second memory region in this case has= -=20 -> small influence on phy. However, it has big influence on controller. For= -=20 -> example, magic number has to be written in one register in second memory= -=20 -> region in order to unlock read access to any register from first memory r= -egion=20 -> (controller). However, they shouldn't be merged to one region, because fi= -rst=20 -> memory region requires byte access while second memory region can be acce= -ssed=20 +> +> Unfortunately, it's not so straighforward. Phy is actually accessed through +> I2C implemented in HDMI controller. Second memory region in this case has +> small influence on phy. However, it has big influence on controller. For +> example, magic number has to be written in one register in second memory +> region in order to unlock read access to any register from first memory region +> (controller). However, they shouldn't be merged to one region, because first +> memory region requires byte access while second memory region can be accessed > per byte or word. ->=20 -> To complicate things more, later I want to add support for another SoC wh= -ich=20 -> has same glue layer (unlocking read access, etc.) and uses memory mapped = -phy=20 +> +> To complicate things more, later I want to add support for another SoC which +> has same glue layer (unlocking read access, etc.) and uses memory mapped phy > registers in second memory region. ->=20 +> > I think current binding is the least complicated way to represent this. I agree with Rob here. I did a similar thing for the DSI patches I've @@ -96,7 +80,7 @@ I'm sure you can come up with something :) Maxime ---=20 +-- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com diff --git a/a/content_digest b/N1/content_digest index e691914..1648e66 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,79 +2,55 @@ "ref\020171230210203.24115-7-jernej.skrabec@siol.net\0" "ref\020180103202154.eeajt3234w3adqjq@rob-hp-laptop\0" "ref\01645801.yZU0HLsLbk@jernej-laptop\0" - "From\0Maxime Ripard <maxime.ripard@free-electrons.com>\0" - "Subject\0Re: [PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline\0" + "From\0maxime.ripard@free-electrons.com (Maxime Ripard)\0" + "Subject\0[PATCH 06/11] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline\0" "Date\0Thu, 4 Jan 2018 19:52:10 +0100\0" - "To\0Jernej \305\240krabec <jernej.skrabec@siol.net>\0" - "Cc\0Rob Herring <robh@kernel.org>" - airlied@linux.ie - mark.rutland@arm.com - wens@csie.org - architt@codeaurora.org - a.hajda@samsung.com - Laurent.pinchart@ideasonboard.com - mturquette@baylibre.com - sboyd@codeaurora.org - Jose.Abreu@synopsys.com - narmstrong@baylibre.com - dri-devel@lists.freedesktop.org - devicetree@vger.kernel.org - linux-arm-kernel@lists.infradead.org - linux-kernel@vger.kernel.org - linux-clk@vger.kernel.org - " linux-sunxi@googlegroups.com\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" - "On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej =C5=A0krabec wrote:\n" + "On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej ?krabec wrote:\n" "> Hi Rob,\n" - ">=20\n" + "> \n" "> Dne sreda, 03. januar 2018 ob 21:21:54 CET je Rob Herring napisal(a):\n" "> > On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote:\n" "> > > This commit adds all necessary compatibles and descriptions needed to\n" "> > > implement A83T HDMI pipeline.\n" - "> > >=20\n" + "> > > \n" "> > > Mixer is already properly described, so only compatible is added.\n" - "> > >=20\n" - "> > > However, A83T TCON1, which is connected to HDMI, doesn't have channel=\n" - " 0,\n" + "> > > \n" + "> > > However, A83T TCON1, which is connected to HDMI, doesn't have channel 0,\n" "> > > contrary to all TCONs currently described. Because of that, TCON\n" "> > > documentation is extended.\n" - "> > >=20\n" - "> > > A83T features Synopsys DW HDMI controller with a custom PHY which loo=\n" - "ks\n" + "> > > \n" + "> > > A83T features Synopsys DW HDMI controller with a custom PHY which looks\n" "> > > like Synopsys Gen2 PHY with few additions. Since there is no\n" - "> > > documentation, needed properties were found out through experimentati=\n" - "on\n" + "> > > documentation, needed properties were found out through experimentation\n" "> > > and reading BSP code.\n" - "> > >=20\n" + "> > > \n" "> > > At the end, example is added for newer SoCs, which features DE2 and DW\n" "> > > HDMI.\n" - "> > >=20\n" + "> > > \n" "> > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>\n" "> > > ---\n" - "> > >=20\n" + "> > > \n" "> > > .../bindings/display/sunxi/sun4i-drm.txt | 188\n" - "> > > ++++++++++++++++++++- 1 file changed, 181 insertions(+), 7 deletions=\n" - "(-)\n" - "> > >=20\n" - "> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-dr=\n" - "m.txt\n" + "> > > ++++++++++++++++++++- 1 file changed, 181 insertions(+), 7 deletions(-)\n" + "> > > \n" + "> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt\n" "> > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index\n" "> > > 9f073af4c711..3eca258096a5 100644\n" "> > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt\n" "> > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt\n" - "> > >=20\n" + "> > > \n" "> > > @@ -64,6 +64,40 @@ Required properties:\n" "> > > first port should be the input endpoint. The second should be the\n" "> > > output, usually to an HDMI connector.\n" - "> > >=20\n" + "> > > \n" "> > > +DWC HDMI TX Encoder\n" "> > > +-----------------------------\n" "> > > +\n" - "> > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller=\n" - " IP\n" - "> > > +with Allwinner's own PHY IP. It supports audio and video outputs and=\n" - " CEC.\n" + "> > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP\n" + "> > > +with Allwinner's own PHY IP. It supports audio and video outputs and CEC.\n" "> > > +\n" "> > > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in\n" "> > > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the\n" @@ -88,33 +64,24 @@ "> > > first\n" "> > > + for controller and second for PHY\n" "> > > + registers.\n" - "> >=20\n" + "> > \n" "> > Seems like the phy should be a separate node and use the phy binding.\n" "> > You can use the phy binding even if you don't use the kernel phy\n" "> > framework...\n" - ">=20\n" - "> Unfortunately, it's not so straighforward. Phy is actually accessed throu=\n" - "gh=20\n" - "> I2C implemented in HDMI controller. Second memory region in this case has=\n" - "=20\n" - "> small influence on phy. However, it has big influence on controller. For=\n" - "=20\n" - "> example, magic number has to be written in one register in second memory=\n" - "=20\n" - "> region in order to unlock read access to any register from first memory r=\n" - "egion=20\n" - "> (controller). However, they shouldn't be merged to one region, because fi=\n" - "rst=20\n" - "> memory region requires byte access while second memory region can be acce=\n" - "ssed=20\n" + "> \n" + "> Unfortunately, it's not so straighforward. Phy is actually accessed through \n" + "> I2C implemented in HDMI controller. Second memory region in this case has \n" + "> small influence on phy. However, it has big influence on controller. For \n" + "> example, magic number has to be written in one register in second memory \n" + "> region in order to unlock read access to any register from first memory region \n" + "> (controller). However, they shouldn't be merged to one region, because first \n" + "> memory region requires byte access while second memory region can be accessed \n" "> per byte or word.\n" - ">=20\n" - "> To complicate things more, later I want to add support for another SoC wh=\n" - "ich=20\n" - "> has same glue layer (unlocking read access, etc.) and uses memory mapped =\n" - "phy=20\n" + "> \n" + "> To complicate things more, later I want to add support for another SoC which \n" + "> has same glue layer (unlocking read access, etc.) and uses memory mapped phy \n" "> registers in second memory region.\n" - ">=20\n" + "> \n" "> I think current binding is the least complicated way to represent this.\n" "\n" "I agree with Rob here. I did a similar thing for the DSI patches I've\n" @@ -123,9 +90,9 @@ "\n" "Maxime\n" "\n" - "--=20\n" + "-- \n" "Maxime Ripard, Free Electrons\n" "Embedded Linux and Kernel engineering\n" http://free-electrons.com -2896fef8b4deb5a2cd2d0336562a905bb85ddba3ff51ee411f0736f525006ffe +cee465a27c984e58bfc5488c976b53a509002fa63a1f0a9802b90eaec47ff579
diff --git a/a/1.txt b/N2/1.txt index 9fb6454..802344d 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,53 +1,46 @@ -On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej =C5=A0krabec wrote: +On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej Škrabec wrote: > Hi Rob, ->=20 +> > Dne sreda, 03. januar 2018 ob 21:21:54 CET je Rob Herring napisal(a): > > On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote: > > > This commit adds all necessary compatibles and descriptions needed to > > > implement A83T HDMI pipeline. -> > >=20 +> > > > > > Mixer is already properly described, so only compatible is added. -> > >=20 -> > > However, A83T TCON1, which is connected to HDMI, doesn't have channel= - 0, +> > > +> > > However, A83T TCON1, which is connected to HDMI, doesn't have channel 0, > > > contrary to all TCONs currently described. Because of that, TCON > > > documentation is extended. -> > >=20 -> > > A83T features Synopsys DW HDMI controller with a custom PHY which loo= -ks +> > > +> > > A83T features Synopsys DW HDMI controller with a custom PHY which looks > > > like Synopsys Gen2 PHY with few additions. Since there is no -> > > documentation, needed properties were found out through experimentati= -on +> > > documentation, needed properties were found out through experimentation > > > and reading BSP code. -> > >=20 +> > > > > > At the end, example is added for newer SoCs, which features DE2 and DW > > > HDMI. -> > >=20 +> > > > > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> > > > --- -> > >=20 +> > > > > > .../bindings/display/sunxi/sun4i-drm.txt | 188 -> > > ++++++++++++++++++++- 1 file changed, 181 insertions(+), 7 deletions= -(-) -> > >=20 -> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-dr= -m.txt +> > > ++++++++++++++++++++- 1 file changed, 181 insertions(+), 7 deletions(-) +> > > +> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index > > > 9f073af4c711..3eca258096a5 100644 > > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt -> > >=20 +> > > > > > @@ -64,6 +64,40 @@ Required properties: > > > first port should be the input endpoint. The second should be the > > > output, usually to an HDMI connector. -> > >=20 +> > > > > > +DWC HDMI TX Encoder > > > +----------------------------- > > > + -> > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller= - IP -> > > +with Allwinner's own PHY IP. It supports audio and video outputs and= - CEC. +> > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP +> > > +with Allwinner's own PHY IP. It supports audio and video outputs and CEC. > > > + > > > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in > > > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the @@ -61,33 +54,24 @@ m.txt > > > first > > > + for controller and second for PHY > > > + registers. -> >=20 +> > > > Seems like the phy should be a separate node and use the phy binding. > > You can use the phy binding even if you don't use the kernel phy > > framework... ->=20 -> Unfortunately, it's not so straighforward. Phy is actually accessed throu= -gh=20 -> I2C implemented in HDMI controller. Second memory region in this case has= -=20 -> small influence on phy. However, it has big influence on controller. For= -=20 -> example, magic number has to be written in one register in second memory= -=20 -> region in order to unlock read access to any register from first memory r= -egion=20 -> (controller). However, they shouldn't be merged to one region, because fi= -rst=20 -> memory region requires byte access while second memory region can be acce= -ssed=20 +> +> Unfortunately, it's not so straighforward. Phy is actually accessed through +> I2C implemented in HDMI controller. Second memory region in this case has +> small influence on phy. However, it has big influence on controller. For +> example, magic number has to be written in one register in second memory +> region in order to unlock read access to any register from first memory region +> (controller). However, they shouldn't be merged to one region, because first +> memory region requires byte access while second memory region can be accessed > per byte or word. ->=20 -> To complicate things more, later I want to add support for another SoC wh= -ich=20 -> has same glue layer (unlocking read access, etc.) and uses memory mapped = -phy=20 +> +> To complicate things more, later I want to add support for another SoC which +> has same glue layer (unlocking read access, etc.) and uses memory mapped phy > registers in second memory region. ->=20 +> > I think current binding is the least complicated way to represent this. I agree with Rob here. I did a similar thing for the DSI patches I've @@ -96,7 +80,7 @@ I'm sure you can come up with something :) Maxime ---=20 +-- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com diff --git a/a/content_digest b/N2/content_digest index e691914..c0a735f 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -25,56 +25,49 @@ " linux-sunxi@googlegroups.com\0" "\00:1\0" "b\0" - "On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej =C5=A0krabec wrote:\n" + "On Wed, Jan 03, 2018 at 10:32:26PM +0100, Jernej \305\240krabec wrote:\n" "> Hi Rob,\n" - ">=20\n" + "> \n" "> Dne sreda, 03. januar 2018 ob 21:21:54 CET je Rob Herring napisal(a):\n" "> > On Sat, Dec 30, 2017 at 10:01:58PM +0100, Jernej Skrabec wrote:\n" "> > > This commit adds all necessary compatibles and descriptions needed to\n" "> > > implement A83T HDMI pipeline.\n" - "> > >=20\n" + "> > > \n" "> > > Mixer is already properly described, so only compatible is added.\n" - "> > >=20\n" - "> > > However, A83T TCON1, which is connected to HDMI, doesn't have channel=\n" - " 0,\n" + "> > > \n" + "> > > However, A83T TCON1, which is connected to HDMI, doesn't have channel 0,\n" "> > > contrary to all TCONs currently described. Because of that, TCON\n" "> > > documentation is extended.\n" - "> > >=20\n" - "> > > A83T features Synopsys DW HDMI controller with a custom PHY which loo=\n" - "ks\n" + "> > > \n" + "> > > A83T features Synopsys DW HDMI controller with a custom PHY which looks\n" "> > > like Synopsys Gen2 PHY with few additions. Since there is no\n" - "> > > documentation, needed properties were found out through experimentati=\n" - "on\n" + "> > > documentation, needed properties were found out through experimentation\n" "> > > and reading BSP code.\n" - "> > >=20\n" + "> > > \n" "> > > At the end, example is added for newer SoCs, which features DE2 and DW\n" "> > > HDMI.\n" - "> > >=20\n" + "> > > \n" "> > > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>\n" "> > > ---\n" - "> > >=20\n" + "> > > \n" "> > > .../bindings/display/sunxi/sun4i-drm.txt | 188\n" - "> > > ++++++++++++++++++++- 1 file changed, 181 insertions(+), 7 deletions=\n" - "(-)\n" - "> > >=20\n" - "> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-dr=\n" - "m.txt\n" + "> > > ++++++++++++++++++++- 1 file changed, 181 insertions(+), 7 deletions(-)\n" + "> > > \n" + "> > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt\n" "> > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index\n" "> > > 9f073af4c711..3eca258096a5 100644\n" "> > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt\n" "> > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt\n" - "> > >=20\n" + "> > > \n" "> > > @@ -64,6 +64,40 @@ Required properties:\n" "> > > first port should be the input endpoint. The second should be the\n" "> > > output, usually to an HDMI connector.\n" - "> > >=20\n" + "> > > \n" "> > > +DWC HDMI TX Encoder\n" "> > > +-----------------------------\n" "> > > +\n" - "> > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller=\n" - " IP\n" - "> > > +with Allwinner's own PHY IP. It supports audio and video outputs and=\n" - " CEC.\n" + "> > > +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP\n" + "> > > +with Allwinner's own PHY IP. It supports audio and video outputs and CEC.\n" "> > > +\n" "> > > +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in\n" "> > > +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the\n" @@ -88,33 +81,24 @@ "> > > first\n" "> > > + for controller and second for PHY\n" "> > > + registers.\n" - "> >=20\n" + "> > \n" "> > Seems like the phy should be a separate node and use the phy binding.\n" "> > You can use the phy binding even if you don't use the kernel phy\n" "> > framework...\n" - ">=20\n" - "> Unfortunately, it's not so straighforward. Phy is actually accessed throu=\n" - "gh=20\n" - "> I2C implemented in HDMI controller. Second memory region in this case has=\n" - "=20\n" - "> small influence on phy. However, it has big influence on controller. For=\n" - "=20\n" - "> example, magic number has to be written in one register in second memory=\n" - "=20\n" - "> region in order to unlock read access to any register from first memory r=\n" - "egion=20\n" - "> (controller). However, they shouldn't be merged to one region, because fi=\n" - "rst=20\n" - "> memory region requires byte access while second memory region can be acce=\n" - "ssed=20\n" + "> \n" + "> Unfortunately, it's not so straighforward. Phy is actually accessed through \n" + "> I2C implemented in HDMI controller. Second memory region in this case has \n" + "> small influence on phy. However, it has big influence on controller. For \n" + "> example, magic number has to be written in one register in second memory \n" + "> region in order to unlock read access to any register from first memory region \n" + "> (controller). However, they shouldn't be merged to one region, because first \n" + "> memory region requires byte access while second memory region can be accessed \n" "> per byte or word.\n" - ">=20\n" - "> To complicate things more, later I want to add support for another SoC wh=\n" - "ich=20\n" - "> has same glue layer (unlocking read access, etc.) and uses memory mapped =\n" - "phy=20\n" + "> \n" + "> To complicate things more, later I want to add support for another SoC which \n" + "> has same glue layer (unlocking read access, etc.) and uses memory mapped phy \n" "> registers in second memory region.\n" - ">=20\n" + "> \n" "> I think current binding is the least complicated way to represent this.\n" "\n" "I agree with Rob here. I did a similar thing for the DSI patches I've\n" @@ -123,9 +107,9 @@ "\n" "Maxime\n" "\n" - "--=20\n" + "-- \n" "Maxime Ripard, Free Electrons\n" "Embedded Linux and Kernel engineering\n" http://free-electrons.com -2896fef8b4deb5a2cd2d0336562a905bb85ddba3ff51ee411f0736f525006ffe +aee7bfda8b74550c43969841a6b6362823a6f13183ca89247db7c29d7203e819
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.