diff for duplicates of <87376imabh.fsf@kamboji.qca.qualcomm.com>

diff --git a/a/1.txt b/N1/1.txt
index aa2599c..f586efe 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -19,23 +19,26 @@ Ben Greear <greearb@candelatech.com> writes:
 >>>> +static int __ath10k_pci_probe(struct pci_dev *pdev,
 >>>> +                           const struct pci_device_id *pci_dev)
 >>>>   {
->>>>        int ret = 0;
+>>>>        int ret =3D 0;
 >>>>        struct ath10k *ar;
->>>> @@ -3672,6 +3672,22 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
+>>>> @@ -3672,6 +3672,22 @@ static int ath10k_pci_probe(struct pci_dev *pde=
+v,
 >>>>        return ret;
 >>>>   }
 >>>>
 >>>> +static int ath10k_pci_probe(struct pci_dev *pdev,
 >>>> +                         const struct pci_device_id *pci_dev)
 >>>> +{
->>>> +     int cnt = 0;
+>>>> +     int cnt =3D 0;
 >>>> +     int rv;
 >>>> +     do {
->>>> +             rv = __ath10k_pci_probe(pdev, pci_dev);
->>>> +             if (rv == 0)
+>>>> +             rv =3D __ath10k_pci_probe(pdev, pci_dev);
+>>>> +             if (rv =3D=3D 0)
 >>>> +                     return rv;
->>>> +             pr_err("ath10k: failed to probe PCI : %d, retry-count: %d\n", rv, cnt);
->>>> +             mdelay(10); /* let the ath10k firmware gerbil take a small break */
+>>>> +             pr_err("ath10k: failed to probe PCI : %d, retry-count: %=
+d\n", rv, cnt);
+>>>> +             mdelay(10); /* let the ath10k firmware gerbil take a sma=
+ll break */
 >>>> +     } while (cnt++ < 10);
 >>>> +     return rv;
 >>>> +}
@@ -44,7 +47,8 @@ Ben Greear <greearb@candelatech.com> writes:
 >>> cases, like when hardware is broken or memory allocation is failing.
 >>>
 >>> When the problem happens does it always fail at the the same place? Is
->>> it hw reset or something else? It's better to retry the invidiual action
+>>> it hw reset or something else? It's better to retry the invidiual actio=
+n
 >>> than to do this hack. Or is it just some more delay needed somewhere?
 >>
 >> I am seeing WMI timeouts during initial firmware load and wait on
@@ -55,15 +59,19 @@ Ben Greear <greearb@candelatech.com> writes:
 >> But then, I have played a lot of whackamole with WMI timeouts during
 >> my loooong porting effort..
 >
-> The failure I saw was a failure to wake pci, and from comments, it seems that
-> the current wait is longer than what should be required, and it warns on slow
-> wakes, and I never saw that warning.  So I assume that waiting longer would not help.
+> The failure I saw was a failure to wake pci, and from comments, it seems =
+that
+> the current wait is longer than what should be required, and it warns on =
+slow
+> wakes, and I never saw that warning.  So I assume that waiting longer wou=
+ld not help.
 >
 > I saw it fail twice in a row to wake pci and then succeed on the third
 > try, for instance,
 > when testing my patch.
 >
-> As for a big hammer, I guess we could check for certain return codes if you think
+> As for a big hammer, I guess we could check for certain return codes if y=
+ou think
 > that is better than just retrying all failures?
 
 ath10k_pci_probe() has a lots of stuff which should not affect your
@@ -74,9 +82,5 @@ more preferred.
 
 Do you have debug logs of failing cases?
 
--- 
-Kalle Valo
-_______________________________________________
-ath10k mailing list
-ath10k@lists.infradead.org
-http://lists.infradead.org/mailman/listinfo/ath10k
+--=20
+Kalle Valo=
diff --git a/a/content_digest b/N1/content_digest
index 9254b15..f885771 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -32,23 +32,26 @@
  ">>>> +static int __ath10k_pci_probe(struct pci_dev *pdev,\n"
  ">>>> +                           const struct pci_device_id *pci_dev)\n"
  ">>>>   {\n"
- ">>>>        int ret = 0;\n"
+ ">>>>        int ret =3D 0;\n"
  ">>>>        struct ath10k *ar;\n"
- ">>>> @@ -3672,6 +3672,22 @@ static int ath10k_pci_probe(struct pci_dev *pdev,\n"
+ ">>>> @@ -3672,6 +3672,22 @@ static int ath10k_pci_probe(struct pci_dev *pde=\n"
+ "v,\n"
  ">>>>        return ret;\n"
  ">>>>   }\n"
  ">>>>\n"
  ">>>> +static int ath10k_pci_probe(struct pci_dev *pdev,\n"
  ">>>> +                         const struct pci_device_id *pci_dev)\n"
  ">>>> +{\n"
- ">>>> +     int cnt = 0;\n"
+ ">>>> +     int cnt =3D 0;\n"
  ">>>> +     int rv;\n"
  ">>>> +     do {\n"
- ">>>> +             rv = __ath10k_pci_probe(pdev, pci_dev);\n"
- ">>>> +             if (rv == 0)\n"
+ ">>>> +             rv =3D __ath10k_pci_probe(pdev, pci_dev);\n"
+ ">>>> +             if (rv =3D=3D 0)\n"
  ">>>> +                     return rv;\n"
- ">>>> +             pr_err(\"ath10k: failed to probe PCI : %d, retry-count: %d\\n\", rv, cnt);\n"
- ">>>> +             mdelay(10); /* let the ath10k firmware gerbil take a small break */\n"
+ ">>>> +             pr_err(\"ath10k: failed to probe PCI : %d, retry-count: %=\n"
+ "d\\n\", rv, cnt);\n"
+ ">>>> +             mdelay(10); /* let the ath10k firmware gerbil take a sma=\n"
+ "ll break */\n"
  ">>>> +     } while (cnt++ < 10);\n"
  ">>>> +     return rv;\n"
  ">>>> +}\n"
@@ -57,7 +60,8 @@
  ">>> cases, like when hardware is broken or memory allocation is failing.\n"
  ">>>\n"
  ">>> When the problem happens does it always fail at the the same place? Is\n"
- ">>> it hw reset or something else? It's better to retry the invidiual action\n"
+ ">>> it hw reset or something else? It's better to retry the invidiual actio=\n"
+ "n\n"
  ">>> than to do this hack. Or is it just some more delay needed somewhere?\n"
  ">>\n"
  ">> I am seeing WMI timeouts during initial firmware load and wait on\n"
@@ -68,15 +72,19 @@
  ">> But then, I have played a lot of whackamole with WMI timeouts during\n"
  ">> my loooong porting effort..\n"
  ">\n"
- "> The failure I saw was a failure to wake pci, and from comments, it seems that\n"
- "> the current wait is longer than what should be required, and it warns on slow\n"
- "> wakes, and I never saw that warning.  So I assume that waiting longer would not help.\n"
+ "> The failure I saw was a failure to wake pci, and from comments, it seems =\n"
+ "that\n"
+ "> the current wait is longer than what should be required, and it warns on =\n"
+ "slow\n"
+ "> wakes, and I never saw that warning.  So I assume that waiting longer wou=\n"
+ "ld not help.\n"
  ">\n"
  "> I saw it fail twice in a row to wake pci and then succeed on the third\n"
  "> try, for instance,\n"
  "> when testing my patch.\n"
  ">\n"
- "> As for a big hammer, I guess we could check for certain return codes if you think\n"
+ "> As for a big hammer, I guess we could check for certain return codes if y=\n"
+ "ou think\n"
  "> that is better than just retrying all failures?\n"
  "\n"
  "ath10k_pci_probe() has a lots of stuff which should not affect your\n"
@@ -87,11 +95,7 @@
  "\n"
  "Do you have debug logs of failing cases?\n"
  "\n"
- "-- \n"
- "Kalle Valo\n"
- "_______________________________________________\n"
- "ath10k mailing list\n"
- "ath10k@lists.infradead.org\n"
- http://lists.infradead.org/mailman/listinfo/ath10k
+ "--=20\n"
+ Kalle Valo=
 
-45618d8c2b4efcc7b7a122e36b56e4f81aaba339b692d6e9581e78fbe2ea22aa
+4785c0a0d91b635f19eba4d03cd3062944f22ff89b14a6fa8840adbdc7fdd562
