All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20201214054419.GA185506@bjorn-Precision-5520>

diff --git a/a/1.txt b/N1/1.txt
index 278942f..8fd97ed 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,6 +1,6 @@
 [+cc Jesse, Tony, David, Jakub, Heiner, lists in case there's an ASPM
 issue with I211 or Realtek NICs.  Beginning of thread:
-https://lore.kernel.org/r/20201024205548.1837770-1-ian.kumlien at gmail.com
+https://lore.kernel.org/r/20201024205548.1837770-1-ian.kumlien@gmail.com
 
 Short story: Ian has:
 
@@ -20,7 +20,7 @@ On Sun, Dec 13, 2020 at 10:39:53PM +0100, Ian Kumlien wrote:
 > > > "5.4.1.2.2. Exit from the L1 State"
 > > >
 > > > Which makes it clear that each switch is required to initiate a
-> > > transition within 1?s from receiving it, accumulating this latency and
+> > > transition within 1μs from receiving it, accumulating this latency and
 > > > then we have to wait for the slowest link along the path before
 > > > entering L0 state from L1.
 > > > ...
@@ -58,7 +58,7 @@ On Sun, Dec 13, 2020 at 10:39:53PM +0100, Ian Kumlien wrote:
 > >    not a Link).
 > 
 > >    The Ports advertise L1 exit latencies of <32us, <32us, <32us,
-> >    <16us.  If both Links are in L1 and 03:00.0 initiates L1 exit@T,
+> >    <16us.  If both Links are in L1 and 03:00.0 initiates L1 exit at T,
 > >    01:00.0 initiates L1 exit at T + 1.  A TLP from 03:00.0 may see up
 > >    to 1 + 32 = 33us of L1 exit latency.
 > >
@@ -306,7 +306,7 @@ Obviously *you* understand this, so hopefully it's just a matter of
 pounding it through my thick skull :)
 
 > > [1] https://bugzilla.kernel.org/attachment.cgi?id=293047
-> > [2] https://lore.kernel.org/linux-pci/20201007132808.647589-1-ian.kumlien at gmail.com/
+> > [2] https://lore.kernel.org/linux-pci/20201007132808.647589-1-ian.kumlien@gmail.com/
 > > [3] https://bugzilla.kernel.org/attachment.cgi?id=292955
 > > [4] https://bugzilla.kernel.org/attachment.cgi?id=292957
 > >
@@ -341,7 +341,7 @@ pounding it through my thick skull :)
 > > > +              *
 > > > +              * PCIe r5.0, sec 5.4.1.2.2 states:
 > > > +              * A Switch is required to initiate an L1 exit transition on its
-> > > +              * Upstream Port Link after no more than 1 ?s from the beginning of an
+> > > +              * Upstream Port Link after no more than 1 μs from the beginning of an
 > > > +              * L1 exit transition on any of its Downstream Port Links.
 > > >                *
 > > >                * The exit latencies for L1 substates are not advertised
diff --git a/a/content_digest b/N1/content_digest
index 539a7cf..b627b21 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,13 +1,26 @@
  "ref\0CAA85sZuuS=UHzhk0DabN45jCu-GYD-DxMOY8dd68Znnk5wsXVg@mail.gmail.com\0"
  "From\0Bjorn Helgaas <helgaas@kernel.org>\0"
- "Subject\0[Intel-wired-lan] [PATCH 1/3] PCI/ASPM: Use the path max in L1 ASPM latency check\0"
+ "Subject\0Re: [PATCH 1/3] PCI/ASPM: Use the path max in L1 ASPM latency check\0"
  "Date\0Sun, 13 Dec 2020 23:44:19 -0600\0"
- "To\0intel-wired-lan@osuosl.org\0"
+ "To\0Ian Kumlien <ian.kumlien@gmail.com>\0"
+ "Cc\0Kai-Heng Feng <kai.heng.feng@canonical.com>"
+  linux-pci <linux-pci@vger.kernel.org>
+  Alexander Duyck <alexander.duyck@gmail.com>
+  Saheed O. Bolarinwa <refactormyself@gmail.com>
+  Puranjay Mohan <puranjay12@gmail.com>
+  Jesse Brandeburg <jesse.brandeburg@intel.com>
+  Tony Nguyen <anthony.l.nguyen@intel.com>
+  David S. Miller <davem@davemloft.net>
+  Jakub Kicinski <kuba@kernel.org>
+  Heiner Kallweit <hkallweit1@gmail.com>
+  intel-wired-lan@lists.osuosl.org
+  netdev@vger.kernel.org
+ " linux-kernel@vger.kernel.org\0"
  "\00:1\0"
  "b\0"
  "[+cc Jesse, Tony, David, Jakub, Heiner, lists in case there's an ASPM\n"
  "issue with I211 or Realtek NICs.  Beginning of thread:\n"
- "https://lore.kernel.org/r/20201024205548.1837770-1-ian.kumlien at gmail.com\n"
+ "https://lore.kernel.org/r/20201024205548.1837770-1-ian.kumlien@gmail.com\n"
  "\n"
  "Short story: Ian has:\n"
  "\n"
@@ -27,7 +40,7 @@
  "> > > \"5.4.1.2.2. Exit from the L1 State\"\n"
  "> > >\n"
  "> > > Which makes it clear that each switch is required to initiate a\n"
- "> > > transition within 1?s from receiving it, accumulating this latency and\n"
+ "> > > transition within 1\316\274s from receiving it, accumulating this latency and\n"
  "> > > then we have to wait for the slowest link along the path before\n"
  "> > > entering L0 state from L1.\n"
  "> > > ...\n"
@@ -65,7 +78,7 @@
  "> >    not a Link).\n"
  "> \n"
  "> >    The Ports advertise L1 exit latencies of <32us, <32us, <32us,\n"
- "> >    <16us.  If both Links are in L1 and 03:00.0 initiates L1 exit@T,\n"
+ "> >    <16us.  If both Links are in L1 and 03:00.0 initiates L1 exit at T,\n"
  "> >    01:00.0 initiates L1 exit at T + 1.  A TLP from 03:00.0 may see up\n"
  "> >    to 1 + 32 = 33us of L1 exit latency.\n"
  "> >\n"
@@ -313,7 +326,7 @@
  "pounding it through my thick skull :)\n"
  "\n"
  "> > [1] https://bugzilla.kernel.org/attachment.cgi?id=293047\n"
- "> > [2] https://lore.kernel.org/linux-pci/20201007132808.647589-1-ian.kumlien at gmail.com/\n"
+ "> > [2] https://lore.kernel.org/linux-pci/20201007132808.647589-1-ian.kumlien@gmail.com/\n"
  "> > [3] https://bugzilla.kernel.org/attachment.cgi?id=292955\n"
  "> > [4] https://bugzilla.kernel.org/attachment.cgi?id=292957\n"
  "> >\n"
@@ -348,7 +361,7 @@
  "> > > +              *\n"
  "> > > +              * PCIe r5.0, sec 5.4.1.2.2 states:\n"
  "> > > +              * A Switch is required to initiate an L1 exit transition on its\n"
- "> > > +              * Upstream Port Link after no more than 1 ?s from the beginning of an\n"
+ "> > > +              * Upstream Port Link after no more than 1 \316\274s from the beginning of an\n"
  "> > > +              * L1 exit transition on any of its Downstream Port Links.\n"
  "> > >                *\n"
  "> > >                * The exit latencies for L1 substates are not advertised\n"
@@ -376,4 +389,4 @@
  "> > > 2.29.1\n"
  > > >
 
-4c131d46956cc1bec34a40265d11da5184a7cf5a671fc5e9b040908d6587ed44
+f5cedce093cc04fd729043cfc7674628949b3db0ab52c5a645f7e1678fd1e993

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.