diff for duplicates of <mafs08qt75nkw.fsf@kernel.org> diff --git a/a/1.txt b/N1/1.txt index b099602..1f9027b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -65,7 +65,7 @@ something that was already discussed. > Update MTD-CONCAT to create virtual concatinated mtd devices as defined > in the device tree. ->From a very quick look, it seems mtdconcat should already do most of +From a very quick look, it seems mtdconcat should already do most of what you want with "stacked mode". The tricky bits might be devicetree design, but from the software perspective, I think mtdconcat makes perfect sense. You leave all the complexity to the SPI NOR layer since @@ -111,7 +111,7 @@ yet another "cost" parallel mode support has -- it adds another thing to SPI MEM (I'm not saying the cost isn't necessarily worth it -- just pointing it out). ->From the SPI NOR side, this layer would have to make sure both flashes +From the SPI NOR side, this layer would have to make sure both flashes get configured with the exact same settings. That would need SPI NOR to export how it configured a flash, ideally in a stable, well-defined format. It would also have to ask SPI NOR to construct the SPI MEM ops diff --git a/a/content_digest b/N1/content_digest index 52207c3..5efe49c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,30 +3,29 @@ "Subject\0Re: [RFC PATCH 0/2] Add support for stacked and parallel memories\0" "Date\0Mon, 25 Nov 2024 15:40:15 +0000\0" "To\0Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>\0" - "Cc\0<tudor.ambarus@linaro.org>" - <michael@walle.cc> - <broonie@kernel.org> - <pratyush@kernel.org> - <richard@nod.at> - <vigneshr@ti.com> - <miquel.raynal@bootlin.com> - <robh@kernel.org> - <conor+dt@kernel.org> - <krzk+dt@kernel.org> - <venkatesh.abbarapu@amd.com> - <linux-spi@vger.kernel.org> - <linux-kernel@vger.kernel.org> - <linux-mtd@lists.infradead.org> - <nicolas.ferre@microchip.com> - <alexandre.belloni@bootlin.com> - <claudiu.beznea@tuxon.dev> - <michal.simek@amd.com> - <linux-arm-kernel@lists.infradead.org> - <alsa-devel@alsa-project.org> - <patches@opensource.cirrus.com> - <git@amd.com> - <amitrkcian2002@gmail.com> - " <beanhuo@micron.com>\0" + "Cc\0alexandre.belloni@bootlin.com" + vigneshr@ti.com + alsa-devel@alsa-project.org + linux-kernel@vger.kernel.org + linux-mtd@lists.infradead.org + miquel.raynal@bootlin.com + beanhuo@micron.com + git@amd.com + robh@kernel.org + richard@nod.at + amitrkcian2002@gmail.com + tudor.ambarus@linaro.org + conor+dt@kernel.org + broonie@kernel.org + venkatesh.abbarapu@amd.com + michal.simek@amd.com + linux-arm-kernel@lists.infradead.org + patches@opensource.cirrus.com + claudiu.beznea@tuxon.dev + linux-spi@vger.kernel.org + michael@walle.cc + krzk+dt@kernel.org + " pratyush@kernel.org\0" "\00:1\0" "b\0" "On Sat, Oct 26 2024, Amit Kumar Mahapatra wrote:\n" @@ -96,7 +95,7 @@ "> Update MTD-CONCAT to create virtual concatinated mtd devices as defined\n" "> in the device tree.\n" "\n" - ">From a very quick look, it seems mtdconcat should already do most of\n" + "From a very quick look, it seems mtdconcat should already do most of\n" "what you want with \"stacked mode\". The tricky bits might be devicetree\n" "design, but from the software perspective, I think mtdconcat makes\n" "perfect sense. You leave all the complexity to the SPI NOR layer since\n" @@ -142,7 +141,7 @@ "SPI MEM (I'm not saying the cost isn't necessarily worth it -- just\n" "pointing it out).\n" "\n" - ">From the SPI NOR side, this layer would have to make sure both flashes\n" + "From the SPI NOR side, this layer would have to make sure both flashes\n" "get configured with the exact same settings. That would need SPI NOR to\n" "export how it configured a flash, ideally in a stable, well-defined\n" "format. It would also have to ask SPI NOR to construct the SPI MEM ops\n" @@ -159,4 +158,4 @@ "Regards,\n" Pratyush Yadav -dcc40c0e77b106e84382f7f18f883995eb3fbbc5cc1c516b3b6929c8b431b097 +6116122ff7a04133ac045bca18f7fda647d619d410efe97c3f17138e763bc8b5
diff --git a/a/1.txt b/N2/1.txt index b099602..45f1683 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -65,7 +65,7 @@ something that was already discussed. > Update MTD-CONCAT to create virtual concatinated mtd devices as defined > in the device tree. ->From a very quick look, it seems mtdconcat should already do most of +From a very quick look, it seems mtdconcat should already do most of what you want with "stacked mode". The tricky bits might be devicetree design, but from the software perspective, I think mtdconcat makes perfect sense. You leave all the complexity to the SPI NOR layer since @@ -111,7 +111,7 @@ yet another "cost" parallel mode support has -- it adds another thing to SPI MEM (I'm not saying the cost isn't necessarily worth it -- just pointing it out). ->From the SPI NOR side, this layer would have to make sure both flashes +From the SPI NOR side, this layer would have to make sure both flashes get configured with the exact same settings. That would need SPI NOR to export how it configured a flash, ideally in a stable, well-defined format. It would also have to ask SPI NOR to construct the SPI MEM ops @@ -127,3 +127,7 @@ much intrusion in the core. -- Regards, Pratyush Yadav + +______________________________________________________ +Linux MTD discussion mailing list +http://lists.infradead.org/mailman/listinfo/linux-mtd/ diff --git a/a/content_digest b/N2/content_digest index 52207c3..bc63f7a 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -96,7 +96,7 @@ "> Update MTD-CONCAT to create virtual concatinated mtd devices as defined\n" "> in the device tree.\n" "\n" - ">From a very quick look, it seems mtdconcat should already do most of\n" + "From a very quick look, it seems mtdconcat should already do most of\n" "what you want with \"stacked mode\". The tricky bits might be devicetree\n" "design, but from the software perspective, I think mtdconcat makes\n" "perfect sense. You leave all the complexity to the SPI NOR layer since\n" @@ -142,7 +142,7 @@ "SPI MEM (I'm not saying the cost isn't necessarily worth it -- just\n" "pointing it out).\n" "\n" - ">From the SPI NOR side, this layer would have to make sure both flashes\n" + "From the SPI NOR side, this layer would have to make sure both flashes\n" "get configured with the exact same settings. That would need SPI NOR to\n" "export how it configured a flash, ideally in a stable, well-defined\n" "format. It would also have to ask SPI NOR to construct the SPI MEM ops\n" @@ -157,6 +157,10 @@ "\n" "-- \n" "Regards,\n" - Pratyush Yadav + "Pratyush Yadav\n" + "\n" + "______________________________________________________\n" + "Linux MTD discussion mailing list\n" + http://lists.infradead.org/mailman/listinfo/linux-mtd/ -dcc40c0e77b106e84382f7f18f883995eb3fbbc5cc1c516b3b6929c8b431b097 +7993c69eedcbe938ffd3992c7714f9eeca0ed77cc72c1253d8a9ce65c84bfc06
diff --git a/a/1.txt b/N3/1.txt index b099602..1f9027b 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -65,7 +65,7 @@ something that was already discussed. > Update MTD-CONCAT to create virtual concatinated mtd devices as defined > in the device tree. ->From a very quick look, it seems mtdconcat should already do most of +From a very quick look, it seems mtdconcat should already do most of what you want with "stacked mode". The tricky bits might be devicetree design, but from the software perspective, I think mtdconcat makes perfect sense. You leave all the complexity to the SPI NOR layer since @@ -111,7 +111,7 @@ yet another "cost" parallel mode support has -- it adds another thing to SPI MEM (I'm not saying the cost isn't necessarily worth it -- just pointing it out). ->From the SPI NOR side, this layer would have to make sure both flashes +From the SPI NOR side, this layer would have to make sure both flashes get configured with the exact same settings. That would need SPI NOR to export how it configured a flash, ideally in a stable, well-defined format. It would also have to ask SPI NOR to construct the SPI MEM ops diff --git a/a/content_digest b/N3/content_digest index 52207c3..4c8069d 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -96,7 +96,7 @@ "> Update MTD-CONCAT to create virtual concatinated mtd devices as defined\n" "> in the device tree.\n" "\n" - ">From a very quick look, it seems mtdconcat should already do most of\n" + "From a very quick look, it seems mtdconcat should already do most of\n" "what you want with \"stacked mode\". The tricky bits might be devicetree\n" "design, but from the software perspective, I think mtdconcat makes\n" "perfect sense. You leave all the complexity to the SPI NOR layer since\n" @@ -142,7 +142,7 @@ "SPI MEM (I'm not saying the cost isn't necessarily worth it -- just\n" "pointing it out).\n" "\n" - ">From the SPI NOR side, this layer would have to make sure both flashes\n" + "From the SPI NOR side, this layer would have to make sure both flashes\n" "get configured with the exact same settings. That would need SPI NOR to\n" "export how it configured a flash, ideally in a stable, well-defined\n" "format. It would also have to ask SPI NOR to construct the SPI MEM ops\n" @@ -159,4 +159,4 @@ "Regards,\n" Pratyush Yadav -dcc40c0e77b106e84382f7f18f883995eb3fbbc5cc1c516b3b6929c8b431b097 +9be9bbfe416e23642e8a9c8ce49f725658fed60025b866b46dc5dae257385051
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.