All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <Z36vIB-JrF5Ddhuf@phenom.ffwll.local>

diff --git a/a/1.txt b/N1/1.txt
index 2da2bec..71b828f 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -6,7 +6,7 @@ On Thu, Dec 26, 2024 at 12:26:29PM +0100, Lukas Wunner wrote:
 > > > but the crypto accelerator can access it just fine.
 > > >
 > > > I did raise a concern about this to the maintainer, but to no avail:
-> > > https://lore.kernel.org/r/Z1Kym1-9ka8kGHrM@wunner.de/
+> > > https://lore.kernel.org/r/Z1Kym1-9ka8kGHrM(a)wunner.de/
 > > 
 > > Herbert's point is valid that there isn't any point for mapping
 > > restricted memory in the kernel virtual address space as any kernel
@@ -19,7 +19,7 @@ On Thu, Dec 26, 2024 at 12:26:29PM +0100, Lukas Wunner wrote:
 > crypto_sig_verify()) no longer accepts scatterlists, only buffers in
 > virtual address space:
 > 
-> https://lore.kernel.org/all/ZIrnPcPj9Zbq51jK@gondor.apana.org.au/
+> https://lore.kernel.org/all/ZIrnPcPj9Zbq51jK(a)gondor.apana.org.au/
 > 
 > Hence in order to use buffers in restricted memory for signature
 > generation/verification, you'd need to map them into virtual address
diff --git a/a/content_digest b/N1/content_digest
index 62b3d5e..a4ee5c9 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,35 +1,9 @@
- "ref\020241217100809.3962439-1-jens.wiklander@linaro.org\0"
- "ref\0Z2KsuAs-Dd4ZDaXR@phenom.ffwll.local\0"
- "ref\0CAFA6WYNVHu7_-bNAuTYBRBdoJwfk2VrW5M4aFVkb_UWQ=uxTvQ@mail.gmail.com\0"
- "ref\0Z2p-v-xjhzhPso6u@wunner.de\0"
- "ref\0CAFA6WYMEjT5EAG3AL8NpbET6L=M86LBgnhLnWirvDZg9cUUiuA@mail.gmail.com\0"
  "ref\0Z209ZegsmgN1xlNG@wunner.de\0"
  "From\0Simona Vetter <simona.vetter@ffwll.ch>\0"
  "Subject\0Re: [PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations\0"
- "Date\0Wed, 8 Jan 2025 18:00:16 +0100\0"
- "To\0Lukas Wunner <lukas@wunner.de>\0"
- "Cc\0Sumit Garg <sumit.garg@linaro.org>"
-  simona.vetter@ffwll.ch
-  Jens Wiklander <jens.wiklander@linaro.org>
-  linux-kernel@vger.kernel.org
-  linux-media@vger.kernel.org
-  dri-devel@lists.freedesktop.org
-  linaro-mm-sig@lists.linaro.org
-  op-tee@lists.trustedfirmware.org
-  linux-arm-kernel@lists.infradead.org
-  Olivier Masse <olivier.masse@nxp.com>
-  Thierry Reding <thierry.reding@gmail.com>
-  Yong Wu <yong.wu@mediatek.com>
-  Sumit Semwal <sumit.semwal@linaro.org>
-  Benjamin Gaignard <benjamin.gaignard@collabora.com>
-  Brian Starkey <Brian.Starkey@arm.com>
-  John Stultz <jstultz@google.com>
-  T . J . Mercier <tjmercier@google.com>
- " Christian K\303\266nig <christian.koenig@amd.com>"
-  Matthias Brugger <matthias.bgg@gmail.com>
-  AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
- " azarrabi@qti.qualcomm.com\0"
- "\00:1\0"
+ "Date\0Wed, 08 Jan 2025 18:00:16 +0100\0"
+ "To\0op-tee@lists.trustedfirmware.org\0"
+ "\01:1\0"
  "b\0"
  "On Thu, Dec 26, 2024 at 12:26:29PM +0100, Lukas Wunner wrote:\n"
  "> On Thu, Dec 26, 2024 at 11:29:23AM +0530, Sumit Garg wrote:\n"
@@ -39,7 +13,7 @@
  "> > > but the crypto accelerator can access it just fine.\n"
  "> > >\n"
  "> > > I did raise a concern about this to the maintainer, but to no avail:\n"
- "> > > https://lore.kernel.org/r/Z1Kym1-9ka8kGHrM@wunner.de/\n"
+ "> > > https://lore.kernel.org/r/Z1Kym1-9ka8kGHrM(a)wunner.de/\n"
  "> > \n"
  "> > Herbert's point is valid that there isn't any point for mapping\n"
  "> > restricted memory in the kernel virtual address space as any kernel\n"
@@ -52,7 +26,7 @@
  "> crypto_sig_verify()) no longer accepts scatterlists, only buffers in\n"
  "> virtual address space:\n"
  "> \n"
- "> https://lore.kernel.org/all/ZIrnPcPj9Zbq51jK@gondor.apana.org.au/\n"
+ "> https://lore.kernel.org/all/ZIrnPcPj9Zbq51jK(a)gondor.apana.org.au/\n"
  "> \n"
  "> Hence in order to use buffers in restricted memory for signature\n"
  "> generation/verification, you'd need to map them into virtual address\n"
@@ -66,4 +40,4 @@
  "Software Engineer, Intel Corporation\n"
  http://blog.ffwll.ch
 
-fca63655964d4e29935d93f9e21543e33e19ebf404953910089c60a11167962f
+5356a80450490da13fbf6e9da0bfbe04927179a0cf75ee94a9e6ce6c91bca096

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.