diff for duplicates of <65e6e58d.050a0220.6580e.7a57@mx.google.com>

diff --git a/a/1.txt b/N1/1.txt
index c92582e..062e3e3 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,50 +1,54 @@
-Hello Francesco,\r
-\r
-Sorry for the abysmal delay.\r
-Thanks for your review and suggestions.\r
-\r
->Hello Pratik,\r
->\r
->On Wed, Jan 03, 2024 at 04:32:00PM +0530, pratikmanvar09@gmail.com wrote:\r
->> From: Clark Wang <xiaoning.wang@nxp.com>\r
->> \r
->> This fixes the pwm output bug when decrease the duty cycle.\r
->> This is a limited workaround for the PWM IP issue TKT0577206.\r
->> \r
->> Root cause:\r
->> When the SAR FIFO is empty, the new write value will be directly applied\r
->> to SAR even the current period is not over.\r
->> If the new SAR value is less than the old one, and the counter is\r
->> greater than the new SAR value, the current period will not filp the\r
->> level. This will result in a pulse with a duty cycle of 100%.\r
->> \r
->> Workaround:\r
->> Add an old value SAR write before updating the new duty cycle to SAR.\r
->> This will keep the new value is always in a not empty fifo, and can be\r
->> wait to update after a period finished.\r
->> \r
->> Limitation:\r
->> This workaround can only solve this issue when the PWM period is longer\r
->> than 2us(or <500KHz).\r
->> \r
->> Reviewed-by: Jun Li <jun.li@nxp.com>\r
->> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>\r
->> Link: https://github.com/nxp-imx/linux-imx/commit/16181cc4eee61d87cbaba0e5a479990507816317\r
->> Tested-by: Pratik Manvar <pratik.manvar@ifm.com>\r
->> Signed-off-by: Pratik Manvar <pratik.manvar@ifm.com>\r
->\r
->A very similar patch was already send in 2021 [1], did it had review\r
->comments not addressed? Please have a look.\r
->\r
->In general please refrain from sending a new patch version every other\r
->day, while every Linux kernel subsystem has different rules and a\r
->difference pace of development, in this specific case sending a v3 just\r
->adding your signed-off-by without allowing a little bit of time to wait\r
->for more feedback is just not sane.\r
-Ok, I will keep this in mind. Thanks!\r
->\r
->[1] https://lore.kernel.org/all/?q=dfn%3Adrivers%2Fpwm%2Fpwm-imx27.c+AND+b%3A%22Clark+Wang%22\r
-Ok, I did not check this. I will look into this. Thanks!\r
-\r
-Thanks & Regards,\r
+Hello Francesco,
+
+Sorry for the abysmal delay.
+Thanks for your review and suggestions.
+
+>Hello Pratik,
+>
+>On Wed, Jan 03, 2024 at 04:32:00PM +0530, pratikmanvar09@gmail.com wrote:
+>> From: Clark Wang <xiaoning.wang@nxp.com>
+>> 
+>> This fixes the pwm output bug when decrease the duty cycle.
+>> This is a limited workaround for the PWM IP issue TKT0577206.
+>> 
+>> Root cause:
+>> When the SAR FIFO is empty, the new write value will be directly applied
+>> to SAR even the current period is not over.
+>> If the new SAR value is less than the old one, and the counter is
+>> greater than the new SAR value, the current period will not filp the
+>> level. This will result in a pulse with a duty cycle of 100%.
+>> 
+>> Workaround:
+>> Add an old value SAR write before updating the new duty cycle to SAR.
+>> This will keep the new value is always in a not empty fifo, and can be
+>> wait to update after a period finished.
+>> 
+>> Limitation:
+>> This workaround can only solve this issue when the PWM period is longer
+>> than 2us(or <500KHz).
+>> 
+>> Reviewed-by: Jun Li <jun.li@nxp.com>
+>> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>
+>> Link: https://github.com/nxp-imx/linux-imx/commit/16181cc4eee61d87cbaba0e5a479990507816317
+>> Tested-by: Pratik Manvar <pratik.manvar@ifm.com>
+>> Signed-off-by: Pratik Manvar <pratik.manvar@ifm.com>
+>
+>A very similar patch was already send in 2021 [1], did it had review
+>comments not addressed? Please have a look.
+>
+>In general please refrain from sending a new patch version every other
+>day, while every Linux kernel subsystem has different rules and a
+>difference pace of development, in this specific case sending a v3 just
+>adding your signed-off-by without allowing a little bit of time to wait
+>for more feedback is just not sane.
+Ok, I will keep this in mind. Thanks!
+>
+>[1] https://lore.kernel.org/all/?q=dfn%3Adrivers%2Fpwm%2Fpwm-imx27.c+AND+b%3A%22Clark+Wang%22
+Ok, I did not check this. I will look into this. Thanks!
+
+Thanks & Regards,
 Pratik Manvar
+_______________________________________________
+linux-arm-kernel mailing list
+linux-arm-kernel@lists.infradead.org
+http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff --git a/a/content_digest b/N1/content_digest
index a2afe32..29aace9 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -21,55 +21,59 @@
  " xiaoning.wang@nxp.com\0"
  "\00:1\0"
  "b\0"
- "Hello Francesco,\r\n"
- "\r\n"
- "Sorry for the abysmal delay.\r\n"
- "Thanks for your review and suggestions.\r\n"
- "\r\n"
- ">Hello Pratik,\r\n"
- ">\r\n"
- ">On Wed, Jan 03, 2024 at 04:32:00PM +0530, pratikmanvar09@gmail.com wrote:\r\n"
- ">> From: Clark Wang <xiaoning.wang@nxp.com>\r\n"
- ">> \r\n"
- ">> This fixes the pwm output bug when decrease the duty cycle.\r\n"
- ">> This is a limited workaround for the PWM IP issue TKT0577206.\r\n"
- ">> \r\n"
- ">> Root cause:\r\n"
- ">> When the SAR FIFO is empty, the new write value will be directly applied\r\n"
- ">> to SAR even the current period is not over.\r\n"
- ">> If the new SAR value is less than the old one, and the counter is\r\n"
- ">> greater than the new SAR value, the current period will not filp the\r\n"
- ">> level. This will result in a pulse with a duty cycle of 100%.\r\n"
- ">> \r\n"
- ">> Workaround:\r\n"
- ">> Add an old value SAR write before updating the new duty cycle to SAR.\r\n"
- ">> This will keep the new value is always in a not empty fifo, and can be\r\n"
- ">> wait to update after a period finished.\r\n"
- ">> \r\n"
- ">> Limitation:\r\n"
- ">> This workaround can only solve this issue when the PWM period is longer\r\n"
- ">> than 2us(or <500KHz).\r\n"
- ">> \r\n"
- ">> Reviewed-by: Jun Li <jun.li@nxp.com>\r\n"
- ">> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>\r\n"
- ">> Link: https://github.com/nxp-imx/linux-imx/commit/16181cc4eee61d87cbaba0e5a479990507816317\r\n"
- ">> Tested-by: Pratik Manvar <pratik.manvar@ifm.com>\r\n"
- ">> Signed-off-by: Pratik Manvar <pratik.manvar@ifm.com>\r\n"
- ">\r\n"
- ">A very similar patch was already send in 2021 [1], did it had review\r\n"
- ">comments not addressed? Please have a look.\r\n"
- ">\r\n"
- ">In general please refrain from sending a new patch version every other\r\n"
- ">day, while every Linux kernel subsystem has different rules and a\r\n"
- ">difference pace of development, in this specific case sending a v3 just\r\n"
- ">adding your signed-off-by without allowing a little bit of time to wait\r\n"
- ">for more feedback is just not sane.\r\n"
- "Ok, I will keep this in mind. Thanks!\r\n"
- ">\r\n"
- ">[1] https://lore.kernel.org/all/?q=dfn%3Adrivers%2Fpwm%2Fpwm-imx27.c+AND+b%3A%22Clark+Wang%22\r\n"
- "Ok, I did not check this. I will look into this. Thanks!\r\n"
- "\r\n"
- "Thanks & Regards,\r\n"
- Pratik Manvar
+ "Hello Francesco,\n"
+ "\n"
+ "Sorry for the abysmal delay.\n"
+ "Thanks for your review and suggestions.\n"
+ "\n"
+ ">Hello Pratik,\n"
+ ">\n"
+ ">On Wed, Jan 03, 2024 at 04:32:00PM +0530, pratikmanvar09@gmail.com wrote:\n"
+ ">> From: Clark Wang <xiaoning.wang@nxp.com>\n"
+ ">> \n"
+ ">> This fixes the pwm output bug when decrease the duty cycle.\n"
+ ">> This is a limited workaround for the PWM IP issue TKT0577206.\n"
+ ">> \n"
+ ">> Root cause:\n"
+ ">> When the SAR FIFO is empty, the new write value will be directly applied\n"
+ ">> to SAR even the current period is not over.\n"
+ ">> If the new SAR value is less than the old one, and the counter is\n"
+ ">> greater than the new SAR value, the current period will not filp the\n"
+ ">> level. This will result in a pulse with a duty cycle of 100%.\n"
+ ">> \n"
+ ">> Workaround:\n"
+ ">> Add an old value SAR write before updating the new duty cycle to SAR.\n"
+ ">> This will keep the new value is always in a not empty fifo, and can be\n"
+ ">> wait to update after a period finished.\n"
+ ">> \n"
+ ">> Limitation:\n"
+ ">> This workaround can only solve this issue when the PWM period is longer\n"
+ ">> than 2us(or <500KHz).\n"
+ ">> \n"
+ ">> Reviewed-by: Jun Li <jun.li@nxp.com>\n"
+ ">> Signed-off-by: Clark Wang <xiaoning.wang@nxp.com>\n"
+ ">> Link: https://github.com/nxp-imx/linux-imx/commit/16181cc4eee61d87cbaba0e5a479990507816317\n"
+ ">> Tested-by: Pratik Manvar <pratik.manvar@ifm.com>\n"
+ ">> Signed-off-by: Pratik Manvar <pratik.manvar@ifm.com>\n"
+ ">\n"
+ ">A very similar patch was already send in 2021 [1], did it had review\n"
+ ">comments not addressed? Please have a look.\n"
+ ">\n"
+ ">In general please refrain from sending a new patch version every other\n"
+ ">day, while every Linux kernel subsystem has different rules and a\n"
+ ">difference pace of development, in this specific case sending a v3 just\n"
+ ">adding your signed-off-by without allowing a little bit of time to wait\n"
+ ">for more feedback is just not sane.\n"
+ "Ok, I will keep this in mind. Thanks!\n"
+ ">\n"
+ ">[1] https://lore.kernel.org/all/?q=dfn%3Adrivers%2Fpwm%2Fpwm-imx27.c+AND+b%3A%22Clark+Wang%22\n"
+ "Ok, I did not check this. I will look into this. Thanks!\n"
+ "\n"
+ "Thanks & Regards,\n"
+ "Pratik Manvar\n"
+ "_______________________________________________\n"
+ "linux-arm-kernel mailing list\n"
+ "linux-arm-kernel@lists.infradead.org\n"
+ http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 
-0bc1d0e6795b9781528a21ac50a4dfe798d26780040b56e3377d7938e306efd0
+3d0cac2f10d8937b3671a78a7073f9a784f70b3015467118ff9c088a022beba3
