diff for duplicates of <20210817125949.5bde9715@xps13>

diff --git a/a/1.txt b/N1/1.txt
index 7d19313..01943e3 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -89,7 +89,8 @@ also have an answer or perhaps knows who to include in the discussion
 > > > 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 
+ checked. 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
@@ -107,7 +108,3 @@ also have an answer or perhaps knows who to include in the discussion
 > 
 > 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 187044f..fc725d2 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -108,7 +108,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 \n"
+ " checked. 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"
@@ -125,10 +126,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"
 
-8370372a0f7e1856a3fa0434198f9282b9b4629aff209d8c5874691d2d0c28e5
+eba01975aba60b55c9e9ffab6dd2dc57a79f44a2845f7cd5fcdf9a8718b9e049
