All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <000301d2ffee$6c2db5c0$44892140$@dell.com>

diff --git a/a/1.txt b/N1/1.txt
index 220ced7..077bc2e 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,12 +1,11 @@
 From: Logan Gunthorpe
 > Changes since v1:
->=20
+> 
 > - Rebased onto latest ntb-next branch (with v4.13-rc1)
 > - Reworked ntb_mw_count() function so that it can be called all the
 >   time (per discussion with Allen)
 > - Various spelling and formatting cleanups from Bjorn
-> - Added request_module() call such that the NTB module is =
-automatically
+> - Added request_module() call such that the NTB module is automatically
 >   loaded when appropriate hardware exists.
 
 Patches 5..16:
@@ -17,27 +16,17 @@ Should the order of 6 and 7 be swapped?
 
 
 
-While I still have some objections to this series, we have already been =
-over them, and I won't let these stand in the way:
+While I still have some objections to this series, we have already been over them, and I won't let these stand in the way:
 
-6 - I think just the comment is best.  Rather than prohibit the use of =
-functionality for hardware that does support the calls, in my opinion it =
-should be left to specific hardware drivers to return an error.
+6 - I think just the comment is best.  Rather than prohibit the use of functionality for hardware that does support the calls, in my opinion it should be left to specific hardware drivers to return an error.
 
-14 - I would prefer that a non-hardware-supported implementation of =
-spads via a memory window should be common code, not reinvented in each =
-specific hardware driver that lacks hardware spads.  You pointed out =
-that the spads implemented here use the shared_mw construct, which is =
-specific to this driver.  I am concerned that spads in the shared_mw =
-(really anything in shared_mw, including this driver's indication of the =
-peer link state) limits the applicability of this driver to just =
-configurations of two ntb ports.  You stated this limitation upfront.
+14 - I would prefer that a non-hardware-supported implementation of spads via a memory window should be common code, not reinvented in each specific hardware driver that lacks hardware spads.  You pointed out that the spads implemented here use the shared_mw construct, which is specific to this driver.  I am concerned that spads in the shared_mw (really anything in shared_mw, including this driver's indication of the peer link state) limits the applicability of this driver to just configurations of two ntb ports.  You stated this limitation upfront.
 
->=20
+> 
 > --
->=20
+> 
 > Changes since the rfc:
->=20
+> 
 > - Rebased on ntb-next
 > - Switched ntb_part_op to use sleep instead of delay
 > - Dropped a number of useless dbg __func__ prints
@@ -45,37 +34,36 @@ configurations of two ntb ports.  You stated this limitation upfront.
 > - Swapped the notifier block for a simple callback
 > - Modified the new ntb api so that a couple functions with pidx
 >   now must be called after link up. Per our discussion on the list.
->=20
+> 
 > --
->=20
+> 
 > This patchset implements Non-Transparent Bridge (NTB) support for the
 > Microsemi Switchtec series of switches. We're looking for some
 > review from the community at this point but hope to get it upstreamed
 > for v4.14.
->=20
+> 
 > Switchtec NTB support is configured over the same function and bar
 > as the management endpoint. Thus, the new driver hooks into the
 > management driver which we had merged in v4.12. We use the class
 > interface API to register an NTB device for every switchtec device
 > which supports NTB (not all do).
->=20
-> The Switchtec hardware supports doorbells, memory windows and =
-messages.
+> 
+> The Switchtec hardware supports doorbells, memory windows and messages.
 > Seeing there is no native scratchpad support, 128 spads are emulated
 > through the use of a pre-setup memory window. The switch has 64
 > doorbells which are shared between the two partitions and a
 > configurable set of memory windows. While the hardware supports more
 > than 2 partitions, this driver only supports the first two seeing
 > the current NTB API only supports two hosts.
->=20
+> 
 > The driver has been tested with ntb_netdev and fully passes the
 > ntb_test script.
->=20
+> 
 > This patchset is based off of ntb-next and can be found in this
 > git repo:
->=20
+> 
 > https://github.com/sbates130272/linux-p2pmem.git switchtec_ntb_v2
->=20
+> 
 > Logan Gunthorpe (16):
 >   switchtec: move structure definitions into a common header
 >   switchtec: export class symbol for use in upper layer driver
@@ -95,15 +83,14 @@ messages.
 >   switchtec_ntb: implement scratchpad registers
 >   switchtec_ntb: add memory window support
 >   switchtec_ntb: update switchtec documentation with notes for NTB
->=20
+> 
 >  Documentation/switchtec.txt             |   12 +
 >  MAINTAINERS                             |    2 +
 >  drivers/ntb/hw/Kconfig                  |    1 +
 >  drivers/ntb/hw/Makefile                 |    1 +
 >  drivers/ntb/hw/mscc/Kconfig             |    9 +
 >  drivers/ntb/hw/mscc/Makefile            |    1 +
->  drivers/ntb/hw/mscc/switchtec_ntb.c     | 1213 =
-+++++++++++++++++++++++++++++++
+>  drivers/ntb/hw/mscc/switchtec_ntb.c     | 1213 +++++++++++++++++++++++++++++++
 >  drivers/ntb/ntb_transport.c             |   20 +-
 >  drivers/ntb/test/ntb_perf.c             |   18 +-
 >  drivers/ntb/test/ntb_tool.c             |    6 +-
@@ -116,6 +103,6 @@ messages.
 >  create mode 100644 drivers/ntb/hw/mscc/Makefile
 >  create mode 100644 drivers/ntb/hw/mscc/switchtec_ntb.c
 >  create mode 100644 include/linux/switchtec.h
->=20
+> 
 > --
 > 2.11.0
diff --git a/a/content_digest b/N1/content_digest
index 59e7f22..573c04c 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -3,9 +3,9 @@
  "Subject\0RE: [PATCH v2 00/16] Switchtec NTB Support\0"
  "Date\0Tue, 18 Jul 2017 13:51:02 -0400\0"
  "To\0'Logan Gunthorpe' <logang@deltatee.com>"
-  <linux-ntb@googlegroups.com>
-  <linux-pci@vger.kernel.org>
- " <linux-kernel@vger.kernel.org>\0"
+  linux-ntb@googlegroups.com
+  linux-pci@vger.kernel.org
+ " linux-kernel@vger.kernel.org\0"
  "Cc\0'Jon Mason' <jdmason@kudzu.us>"
   'Dave Jiang' <dave.jiang@intel.com>
   'Bjorn Helgaas' <bhelgaas@google.com>
@@ -17,13 +17,12 @@
  "b\0"
  "From: Logan Gunthorpe\n"
  "> Changes since v1:\n"
- ">=20\n"
+ "> \n"
  "> - Rebased onto latest ntb-next branch (with v4.13-rc1)\n"
  "> - Reworked ntb_mw_count() function so that it can be called all the\n"
  ">   time (per discussion with Allen)\n"
  "> - Various spelling and formatting cleanups from Bjorn\n"
- "> - Added request_module() call such that the NTB module is =\n"
- "automatically\n"
+ "> - Added request_module() call such that the NTB module is automatically\n"
  ">   loaded when appropriate hardware exists.\n"
  "\n"
  "Patches 5..16:\n"
@@ -34,27 +33,17 @@
  "\n"
  "\n"
  "\n"
- "While I still have some objections to this series, we have already been =\n"
- "over them, and I won't let these stand in the way:\n"
+ "While I still have some objections to this series, we have already been over them, and I won't let these stand in the way:\n"
  "\n"
- "6 - I think just the comment is best.  Rather than prohibit the use of =\n"
- "functionality for hardware that does support the calls, in my opinion it =\n"
- "should be left to specific hardware drivers to return an error.\n"
+ "6 - I think just the comment is best.  Rather than prohibit the use of functionality for hardware that does support the calls, in my opinion it should be left to specific hardware drivers to return an error.\n"
  "\n"
- "14 - I would prefer that a non-hardware-supported implementation of =\n"
- "spads via a memory window should be common code, not reinvented in each =\n"
- "specific hardware driver that lacks hardware spads.  You pointed out =\n"
- "that the spads implemented here use the shared_mw construct, which is =\n"
- "specific to this driver.  I am concerned that spads in the shared_mw =\n"
- "(really anything in shared_mw, including this driver's indication of the =\n"
- "peer link state) limits the applicability of this driver to just =\n"
- "configurations of two ntb ports.  You stated this limitation upfront.\n"
+ "14 - I would prefer that a non-hardware-supported implementation of spads via a memory window should be common code, not reinvented in each specific hardware driver that lacks hardware spads.  You pointed out that the spads implemented here use the shared_mw construct, which is specific to this driver.  I am concerned that spads in the shared_mw (really anything in shared_mw, including this driver's indication of the peer link state) limits the applicability of this driver to just configurations of two ntb ports.  You stated this limitation upfront.\n"
  "\n"
- ">=20\n"
+ "> \n"
  "> --\n"
- ">=20\n"
+ "> \n"
  "> Changes since the rfc:\n"
- ">=20\n"
+ "> \n"
  "> - Rebased on ntb-next\n"
  "> - Switched ntb_part_op to use sleep instead of delay\n"
  "> - Dropped a number of useless dbg __func__ prints\n"
@@ -62,37 +51,36 @@
  "> - Swapped the notifier block for a simple callback\n"
  "> - Modified the new ntb api so that a couple functions with pidx\n"
  ">   now must be called after link up. Per our discussion on the list.\n"
- ">=20\n"
+ "> \n"
  "> --\n"
- ">=20\n"
+ "> \n"
  "> This patchset implements Non-Transparent Bridge (NTB) support for the\n"
  "> Microsemi Switchtec series of switches. We're looking for some\n"
  "> review from the community at this point but hope to get it upstreamed\n"
  "> for v4.14.\n"
- ">=20\n"
+ "> \n"
  "> Switchtec NTB support is configured over the same function and bar\n"
  "> as the management endpoint. Thus, the new driver hooks into the\n"
  "> management driver which we had merged in v4.12. We use the class\n"
  "> interface API to register an NTB device for every switchtec device\n"
  "> which supports NTB (not all do).\n"
- ">=20\n"
- "> The Switchtec hardware supports doorbells, memory windows and =\n"
- "messages.\n"
+ "> \n"
+ "> The Switchtec hardware supports doorbells, memory windows and messages.\n"
  "> Seeing there is no native scratchpad support, 128 spads are emulated\n"
  "> through the use of a pre-setup memory window. The switch has 64\n"
  "> doorbells which are shared between the two partitions and a\n"
  "> configurable set of memory windows. While the hardware supports more\n"
  "> than 2 partitions, this driver only supports the first two seeing\n"
  "> the current NTB API only supports two hosts.\n"
- ">=20\n"
+ "> \n"
  "> The driver has been tested with ntb_netdev and fully passes the\n"
  "> ntb_test script.\n"
- ">=20\n"
+ "> \n"
  "> This patchset is based off of ntb-next and can be found in this\n"
  "> git repo:\n"
- ">=20\n"
+ "> \n"
  "> https://github.com/sbates130272/linux-p2pmem.git switchtec_ntb_v2\n"
- ">=20\n"
+ "> \n"
  "> Logan Gunthorpe (16):\n"
  ">   switchtec: move structure definitions into a common header\n"
  ">   switchtec: export class symbol for use in upper layer driver\n"
@@ -112,15 +100,14 @@
  ">   switchtec_ntb: implement scratchpad registers\n"
  ">   switchtec_ntb: add memory window support\n"
  ">   switchtec_ntb: update switchtec documentation with notes for NTB\n"
- ">=20\n"
+ "> \n"
  ">  Documentation/switchtec.txt             |   12 +\n"
  ">  MAINTAINERS                             |    2 +\n"
  ">  drivers/ntb/hw/Kconfig                  |    1 +\n"
  ">  drivers/ntb/hw/Makefile                 |    1 +\n"
  ">  drivers/ntb/hw/mscc/Kconfig             |    9 +\n"
  ">  drivers/ntb/hw/mscc/Makefile            |    1 +\n"
- ">  drivers/ntb/hw/mscc/switchtec_ntb.c     | 1213 =\n"
- "+++++++++++++++++++++++++++++++\n"
+ ">  drivers/ntb/hw/mscc/switchtec_ntb.c     | 1213 +++++++++++++++++++++++++++++++\n"
  ">  drivers/ntb/ntb_transport.c             |   20 +-\n"
  ">  drivers/ntb/test/ntb_perf.c             |   18 +-\n"
  ">  drivers/ntb/test/ntb_tool.c             |    6 +-\n"
@@ -133,8 +120,8 @@
  ">  create mode 100644 drivers/ntb/hw/mscc/Makefile\n"
  ">  create mode 100644 drivers/ntb/hw/mscc/switchtec_ntb.c\n"
  ">  create mode 100644 include/linux/switchtec.h\n"
- ">=20\n"
+ "> \n"
  "> --\n"
  > 2.11.0
 
-013c15d9864cef6ff9da078df121c405a238287df72cdd53fa304b79c1695b20
+00fd297bc06801e27f4d5b272915d6f7ff150a6ae9e49dc3fdcdab9e93882daa

diff --git a/a/1.txt b/N2/1.txt
index 220ced7..077bc2e 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -1,12 +1,11 @@
 From: Logan Gunthorpe
 > Changes since v1:
->=20
+> 
 > - Rebased onto latest ntb-next branch (with v4.13-rc1)
 > - Reworked ntb_mw_count() function so that it can be called all the
 >   time (per discussion with Allen)
 > - Various spelling and formatting cleanups from Bjorn
-> - Added request_module() call such that the NTB module is =
-automatically
+> - Added request_module() call such that the NTB module is automatically
 >   loaded when appropriate hardware exists.
 
 Patches 5..16:
@@ -17,27 +16,17 @@ Should the order of 6 and 7 be swapped?
 
 
 
-While I still have some objections to this series, we have already been =
-over them, and I won't let these stand in the way:
+While I still have some objections to this series, we have already been over them, and I won't let these stand in the way:
 
-6 - I think just the comment is best.  Rather than prohibit the use of =
-functionality for hardware that does support the calls, in my opinion it =
-should be left to specific hardware drivers to return an error.
+6 - I think just the comment is best.  Rather than prohibit the use of functionality for hardware that does support the calls, in my opinion it should be left to specific hardware drivers to return an error.
 
-14 - I would prefer that a non-hardware-supported implementation of =
-spads via a memory window should be common code, not reinvented in each =
-specific hardware driver that lacks hardware spads.  You pointed out =
-that the spads implemented here use the shared_mw construct, which is =
-specific to this driver.  I am concerned that spads in the shared_mw =
-(really anything in shared_mw, including this driver's indication of the =
-peer link state) limits the applicability of this driver to just =
-configurations of two ntb ports.  You stated this limitation upfront.
+14 - I would prefer that a non-hardware-supported implementation of spads via a memory window should be common code, not reinvented in each specific hardware driver that lacks hardware spads.  You pointed out that the spads implemented here use the shared_mw construct, which is specific to this driver.  I am concerned that spads in the shared_mw (really anything in shared_mw, including this driver's indication of the peer link state) limits the applicability of this driver to just configurations of two ntb ports.  You stated this limitation upfront.
 
->=20
+> 
 > --
->=20
+> 
 > Changes since the rfc:
->=20
+> 
 > - Rebased on ntb-next
 > - Switched ntb_part_op to use sleep instead of delay
 > - Dropped a number of useless dbg __func__ prints
@@ -45,37 +34,36 @@ configurations of two ntb ports.  You stated this limitation upfront.
 > - Swapped the notifier block for a simple callback
 > - Modified the new ntb api so that a couple functions with pidx
 >   now must be called after link up. Per our discussion on the list.
->=20
+> 
 > --
->=20
+> 
 > This patchset implements Non-Transparent Bridge (NTB) support for the
 > Microsemi Switchtec series of switches. We're looking for some
 > review from the community at this point but hope to get it upstreamed
 > for v4.14.
->=20
+> 
 > Switchtec NTB support is configured over the same function and bar
 > as the management endpoint. Thus, the new driver hooks into the
 > management driver which we had merged in v4.12. We use the class
 > interface API to register an NTB device for every switchtec device
 > which supports NTB (not all do).
->=20
-> The Switchtec hardware supports doorbells, memory windows and =
-messages.
+> 
+> The Switchtec hardware supports doorbells, memory windows and messages.
 > Seeing there is no native scratchpad support, 128 spads are emulated
 > through the use of a pre-setup memory window. The switch has 64
 > doorbells which are shared between the two partitions and a
 > configurable set of memory windows. While the hardware supports more
 > than 2 partitions, this driver only supports the first two seeing
 > the current NTB API only supports two hosts.
->=20
+> 
 > The driver has been tested with ntb_netdev and fully passes the
 > ntb_test script.
->=20
+> 
 > This patchset is based off of ntb-next and can be found in this
 > git repo:
->=20
+> 
 > https://github.com/sbates130272/linux-p2pmem.git switchtec_ntb_v2
->=20
+> 
 > Logan Gunthorpe (16):
 >   switchtec: move structure definitions into a common header
 >   switchtec: export class symbol for use in upper layer driver
@@ -95,15 +83,14 @@ messages.
 >   switchtec_ntb: implement scratchpad registers
 >   switchtec_ntb: add memory window support
 >   switchtec_ntb: update switchtec documentation with notes for NTB
->=20
+> 
 >  Documentation/switchtec.txt             |   12 +
 >  MAINTAINERS                             |    2 +
 >  drivers/ntb/hw/Kconfig                  |    1 +
 >  drivers/ntb/hw/Makefile                 |    1 +
 >  drivers/ntb/hw/mscc/Kconfig             |    9 +
 >  drivers/ntb/hw/mscc/Makefile            |    1 +
->  drivers/ntb/hw/mscc/switchtec_ntb.c     | 1213 =
-+++++++++++++++++++++++++++++++
+>  drivers/ntb/hw/mscc/switchtec_ntb.c     | 1213 +++++++++++++++++++++++++++++++
 >  drivers/ntb/ntb_transport.c             |   20 +-
 >  drivers/ntb/test/ntb_perf.c             |   18 +-
 >  drivers/ntb/test/ntb_tool.c             |    6 +-
@@ -116,6 +103,6 @@ messages.
 >  create mode 100644 drivers/ntb/hw/mscc/Makefile
 >  create mode 100644 drivers/ntb/hw/mscc/switchtec_ntb.c
 >  create mode 100644 include/linux/switchtec.h
->=20
+> 
 > --
 > 2.11.0
diff --git a/a/content_digest b/N2/content_digest
index 59e7f22..c74dc44 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -17,13 +17,12 @@
  "b\0"
  "From: Logan Gunthorpe\n"
  "> Changes since v1:\n"
- ">=20\n"
+ "> \n"
  "> - Rebased onto latest ntb-next branch (with v4.13-rc1)\n"
  "> - Reworked ntb_mw_count() function so that it can be called all the\n"
  ">   time (per discussion with Allen)\n"
  "> - Various spelling and formatting cleanups from Bjorn\n"
- "> - Added request_module() call such that the NTB module is =\n"
- "automatically\n"
+ "> - Added request_module() call such that the NTB module is automatically\n"
  ">   loaded when appropriate hardware exists.\n"
  "\n"
  "Patches 5..16:\n"
@@ -34,27 +33,17 @@
  "\n"
  "\n"
  "\n"
- "While I still have some objections to this series, we have already been =\n"
- "over them, and I won't let these stand in the way:\n"
+ "While I still have some objections to this series, we have already been over them, and I won't let these stand in the way:\n"
  "\n"
- "6 - I think just the comment is best.  Rather than prohibit the use of =\n"
- "functionality for hardware that does support the calls, in my opinion it =\n"
- "should be left to specific hardware drivers to return an error.\n"
+ "6 - I think just the comment is best.  Rather than prohibit the use of functionality for hardware that does support the calls, in my opinion it should be left to specific hardware drivers to return an error.\n"
  "\n"
- "14 - I would prefer that a non-hardware-supported implementation of =\n"
- "spads via a memory window should be common code, not reinvented in each =\n"
- "specific hardware driver that lacks hardware spads.  You pointed out =\n"
- "that the spads implemented here use the shared_mw construct, which is =\n"
- "specific to this driver.  I am concerned that spads in the shared_mw =\n"
- "(really anything in shared_mw, including this driver's indication of the =\n"
- "peer link state) limits the applicability of this driver to just =\n"
- "configurations of two ntb ports.  You stated this limitation upfront.\n"
+ "14 - I would prefer that a non-hardware-supported implementation of spads via a memory window should be common code, not reinvented in each specific hardware driver that lacks hardware spads.  You pointed out that the spads implemented here use the shared_mw construct, which is specific to this driver.  I am concerned that spads in the shared_mw (really anything in shared_mw, including this driver's indication of the peer link state) limits the applicability of this driver to just configurations of two ntb ports.  You stated this limitation upfront.\n"
  "\n"
- ">=20\n"
+ "> \n"
  "> --\n"
- ">=20\n"
+ "> \n"
  "> Changes since the rfc:\n"
- ">=20\n"
+ "> \n"
  "> - Rebased on ntb-next\n"
  "> - Switched ntb_part_op to use sleep instead of delay\n"
  "> - Dropped a number of useless dbg __func__ prints\n"
@@ -62,37 +51,36 @@
  "> - Swapped the notifier block for a simple callback\n"
  "> - Modified the new ntb api so that a couple functions with pidx\n"
  ">   now must be called after link up. Per our discussion on the list.\n"
- ">=20\n"
+ "> \n"
  "> --\n"
- ">=20\n"
+ "> \n"
  "> This patchset implements Non-Transparent Bridge (NTB) support for the\n"
  "> Microsemi Switchtec series of switches. We're looking for some\n"
  "> review from the community at this point but hope to get it upstreamed\n"
  "> for v4.14.\n"
- ">=20\n"
+ "> \n"
  "> Switchtec NTB support is configured over the same function and bar\n"
  "> as the management endpoint. Thus, the new driver hooks into the\n"
  "> management driver which we had merged in v4.12. We use the class\n"
  "> interface API to register an NTB device for every switchtec device\n"
  "> which supports NTB (not all do).\n"
- ">=20\n"
- "> The Switchtec hardware supports doorbells, memory windows and =\n"
- "messages.\n"
+ "> \n"
+ "> The Switchtec hardware supports doorbells, memory windows and messages.\n"
  "> Seeing there is no native scratchpad support, 128 spads are emulated\n"
  "> through the use of a pre-setup memory window. The switch has 64\n"
  "> doorbells which are shared between the two partitions and a\n"
  "> configurable set of memory windows. While the hardware supports more\n"
  "> than 2 partitions, this driver only supports the first two seeing\n"
  "> the current NTB API only supports two hosts.\n"
- ">=20\n"
+ "> \n"
  "> The driver has been tested with ntb_netdev and fully passes the\n"
  "> ntb_test script.\n"
- ">=20\n"
+ "> \n"
  "> This patchset is based off of ntb-next and can be found in this\n"
  "> git repo:\n"
- ">=20\n"
+ "> \n"
  "> https://github.com/sbates130272/linux-p2pmem.git switchtec_ntb_v2\n"
- ">=20\n"
+ "> \n"
  "> Logan Gunthorpe (16):\n"
  ">   switchtec: move structure definitions into a common header\n"
  ">   switchtec: export class symbol for use in upper layer driver\n"
@@ -112,15 +100,14 @@
  ">   switchtec_ntb: implement scratchpad registers\n"
  ">   switchtec_ntb: add memory window support\n"
  ">   switchtec_ntb: update switchtec documentation with notes for NTB\n"
- ">=20\n"
+ "> \n"
  ">  Documentation/switchtec.txt             |   12 +\n"
  ">  MAINTAINERS                             |    2 +\n"
  ">  drivers/ntb/hw/Kconfig                  |    1 +\n"
  ">  drivers/ntb/hw/Makefile                 |    1 +\n"
  ">  drivers/ntb/hw/mscc/Kconfig             |    9 +\n"
  ">  drivers/ntb/hw/mscc/Makefile            |    1 +\n"
- ">  drivers/ntb/hw/mscc/switchtec_ntb.c     | 1213 =\n"
- "+++++++++++++++++++++++++++++++\n"
+ ">  drivers/ntb/hw/mscc/switchtec_ntb.c     | 1213 +++++++++++++++++++++++++++++++\n"
  ">  drivers/ntb/ntb_transport.c             |   20 +-\n"
  ">  drivers/ntb/test/ntb_perf.c             |   18 +-\n"
  ">  drivers/ntb/test/ntb_tool.c             |    6 +-\n"
@@ -133,8 +120,8 @@
  ">  create mode 100644 drivers/ntb/hw/mscc/Makefile\n"
  ">  create mode 100644 drivers/ntb/hw/mscc/switchtec_ntb.c\n"
  ">  create mode 100644 include/linux/switchtec.h\n"
- ">=20\n"
+ "> \n"
  "> --\n"
  > 2.11.0
 
-013c15d9864cef6ff9da078df121c405a238287df72cdd53fa304b79c1695b20
+a327115743e52e3978171933ff538832214ed5d12a2998b7e7ffc2451fe1b371

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.