diff for duplicates of <20210817125521.487979b9@xps13>

diff --git a/a/1.txt b/N1/1.txt
index b0f51a3..b34b108 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -80,7 +80,8 @@ Evgeny Novikov <novikov@ispras.ru> wrote on Tue, 17 Aug 2021 13:36:03
 > > jump to it.
 > >  
 > 
-> We still need some help and clarification from those who are very familiar with this sort of drivers or/and can test this particular driver. mxic_nfc_clk_enable() is the complementary function for mxic_nfc_clk_disable(). No other functions invoke clk_prepare_enable()/clk_disable_unprepare() in the driver. Unlikely somebody in its environment does that since driver specific clocks are dealt with. At the moment the driver invokes mxic_nfc_clk_disable() on error handling paths in probe, in remove and in mxic_nfc_set_freq(). mxic_nfc_clk_enable() is called just by mxic_nfc_set_freq() that moreover does this after calling mxic_nfc_clk_disable() first. So, we did not find any place in the driver that invokes mxic_nfc_clk_enable() prior to mxic_nfc_clk_disable(). Basing on this we added mxic_nfc_clk_enable() just after getting clocks. As I explained in the previous large e-mail, we may be wrong in our understanding of the driver environment or/and at specification of requirements being checked. It would be great if you will point out on our mistakes.
+> We still need some help and clarification from those who are very familiar with this sort of drivers or/and can test this particular driver. mxic_nfc_clk_enable() is the complementary function for mxic_nfc_clk_disable(). No other functions invoke clk_prepare_enable()/clk_disable_unprepare() in the driver. Unlikely somebody in its environment does that since driver specific clocks are dealt with. At the moment the driver invokes mxic_nfc_clk_disable() on error handling paths in probe, in remove and in mxic_nfc_set_freq(). mxic_nfc_clk_enable() is called just by mxic_nfc_set_freq() that moreover does this after calling mxic_nfc_clk_disable() first. So, we did not find any place in the driver that invokes mxic_nfc_clk_enable() prior to mxic_nfc_clk_disable(). Basing on this we added mxic_nfc_clk_enable() just after getting clocks. As I explained in the previous large e-mail, we may be wrong in our understanding of the driver environment or/and at specification of requirements being ch
+ ecked. It would be great if you will point out on our mistakes.
 
 Enabling the clocks seems to only be needed to access the NAND device
 and not the registers of the controller. Mason, is this statement
@@ -98,7 +99,3 @@ In all cases, the error path is wrong.
 
 Thanks,
 Miquèl
-
-______________________________________________________
-Linux MTD discussion mailing list
-http://lists.infradead.org/mailman/listinfo/linux-mtd/
diff --git a/a/content_digest b/N1/content_digest
index 405839f..91790a8 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -98,7 +98,8 @@
  "> > jump to it.\n"
  "> >  \n"
  "> \n"
- "> We still need some help and clarification from those who are very familiar with this sort of drivers or/and can test this particular driver. mxic_nfc_clk_enable() is the complementary function for mxic_nfc_clk_disable(). No other functions invoke clk_prepare_enable()/clk_disable_unprepare() in the driver. Unlikely somebody in its environment does that since driver specific clocks are dealt with. At the moment the driver invokes mxic_nfc_clk_disable() on error handling paths in probe, in remove and in mxic_nfc_set_freq(). mxic_nfc_clk_enable() is called just by mxic_nfc_set_freq() that moreover does this after calling mxic_nfc_clk_disable() first. So, we did not find any place in the driver that invokes mxic_nfc_clk_enable() prior to mxic_nfc_clk_disable(). Basing on this we added mxic_nfc_clk_enable() just after getting clocks. As I explained in the previous large e-mail, we may be wrong in our understanding of the driver environment or/and at specification of requirements being checked. It would be great if you will point out on our mistakes.\n"
+ "> We still need some help and clarification from those who are very familiar with this sort of drivers or/and can test this particular driver. mxic_nfc_clk_enable() is the complementary function for mxic_nfc_clk_disable(). No other functions invoke clk_prepare_enable()/clk_disable_unprepare() in the driver. Unlikely somebody in its environment does that since driver specific clocks are dealt with. At the moment the driver invokes mxic_nfc_clk_disable() on error handling paths in probe, in remove and in mxic_nfc_set_freq(). mxic_nfc_clk_enable() is called just by mxic_nfc_set_freq() that moreover does this after calling mxic_nfc_clk_disable() first. So, we did not find any place in the driver that invokes mxic_nfc_clk_enable() prior to mxic_nfc_clk_disable(). Basing on this we added mxic_nfc_clk_enable() just after getting clocks. As I explained in the previous large e-mail, we may be wrong in our understanding of the driver environment or/and at specification of requirements being ch\n"
+ " ecked. It would be great if you will point out on our mistakes.\n"
  "\n"
  "Enabling the clocks seems to only be needed to access the NAND device\n"
  "and not the registers of the controller. Mason, is this statement\n"
@@ -115,10 +116,6 @@
  "In all cases, the error path is wrong.\n"
  "\n"
  "Thanks,\n"
- "Miqu\303\250l\n"
- "\n"
- "______________________________________________________\n"
- "Linux MTD discussion mailing list\n"
- http://lists.infradead.org/mailman/listinfo/linux-mtd/
+ "Miqu\303\250l"
 
-7cbd75eb86c75ee4394a6e65b700164e2bba6b913ebc72a95ba349daf8be366c
+e08f19faa67acc7f022bda1e23ecd390b7fafeb56594de28baa818cbe53cc722
