[PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[yongsuyoo0215]

From: Yongsu yoo <yongsuyoo0215@gmail.com>

Signed-off-by:Yongsu Yoo <yongsuyoo0215@gmail.com>

In source/drivers/media/dvb-core/dvb_ca_en50221.c, if the CA_RESET ioctl
is called, in a normal case, the state of the thread of the
dvb_ca_en50221_thread_state_machine will transit like below order.
DVB_CA_SLOTSTATE_NONE -> DVB_CA_SLOTSTATE_UNINITIALISED ->
DVB_CA_SLOTSTATE_WAITREADY -> DVB_CA_SLOTSTATE_VALIDATE ->
DVB_CA_SLOTSTATE_WAITFR -> DVB_CA_SLOTSTATE_LINKINIT ->
DVB_CA_SLOTSTATE_RUNNING
But in some problem cases, the state will become DVB_CA_SLOTSTATE_INVALID.
Among the above mentioned states, the DVB_CA_SLOTSTATE_NONE and
the DVB_CA_SLOTSTATE_INVALID are "already stablized" states,
whereas other states are "transiting" states.
The "already stablized" states mean no matter how long time we wait,
the state will not be changed.
The "transiting" states mean the states whose final state is not yet
determined. The state keeps to be changed. Only after some time passes,
we get to know whether the final state will be DVB_CA_SLOTSTATE_RUNNING
or DVB_CA_SLOTSTATE_INVALID.
During the "transiting" states, we do not yet know whether the
CA_RESET operation, which triggered the "transiting" states, will
succeed or fail. For this reason, during the "transiting" states, if
another CA_RESET ioctl is called and if this new CA_RESET ioctl
operation begins again, it will be meaningless and waste time.
For preventing this problem from happening, we make CA_RESET ioctl do
nothing and only return EBUSY if the ioctl is called during the
"transiting" states.
---
 drivers/media/dvb-core/dvb_ca_en50221.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c b/drivers/media/dvb-core/dvb_ca_en50221.c
index baf64540dc00..2e8aec354b7c 100644
--- a/drivers/media/dvb-core/dvb_ca_en50221.c
+++ b/drivers/media/dvb-core/dvb_ca_en50221.c
@@ -1362,13 +1362,19 @@ static int dvb_ca_en50221_io_do_ioctl(struct file *file,
 			struct dvb_ca_slot *sl = &ca->slot_info[slot];
 
 			mutex_lock(&sl->slot_lock);
-			if (sl->slot_state != DVB_CA_SLOTSTATE_NONE) {
+			if ((sl->slot_state == DVB_CA_SLOTSTATE_RUNNING) ||      
+			    (sl->slot_state == DVB_CA_SLOTSTATE_INVALID)) { 
 				dvb_ca_en50221_slot_shutdown(ca, slot);
 				if (ca->flags & DVB_CA_EN50221_FLAG_IRQ_CAMCHANGE)
 					dvb_ca_en50221_camchange_irq(ca->pub,
 								     slot,
 								     DVB_CA_EN50221_CAMCHANGE_INSERTED);
 			}
+			else {
+				if (sl->slot_state != DVB_CA_SLOTSTATE_NONE) {
+					err = -EBUSY;
+				}
+			}
 			mutex_unlock(&sl->slot_lock);
 		}
 		ca->next_read_slot = 0;
-- 
2.17.1

Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[YongSu Yoo]

Dear All

Can you review this patch ?
Can you share how this modification is going ?

2024년 3월 8일 (금) 오후 9:13, <yongsuyoo0215@gmail.com>님이 작성:
>
> From: Yongsu yoo <yongsuyoo0215@gmail.com>
>
> Signed-off-by:Yongsu Yoo <yongsuyoo0215@gmail.com>
>
> In source/drivers/media/dvb-core/dvb_ca_en50221.c, if the CA_RESET ioctl
> is called, in a normal case, the state of the thread of the
> dvb_ca_en50221_thread_state_machine will transit like below order.
> DVB_CA_SLOTSTATE_NONE -> DVB_CA_SLOTSTATE_UNINITIALISED ->
> DVB_CA_SLOTSTATE_WAITREADY -> DVB_CA_SLOTSTATE_VALIDATE ->
> DVB_CA_SLOTSTATE_WAITFR -> DVB_CA_SLOTSTATE_LINKINIT ->
> DVB_CA_SLOTSTATE_RUNNING
> But in some problem cases, the state will become DVB_CA_SLOTSTATE_INVALID.
> Among the above mentioned states, the DVB_CA_SLOTSTATE_NONE and
> the DVB_CA_SLOTSTATE_INVALID are "already stablized" states,
> whereas other states are "transiting" states.
> The "already stablized" states mean no matter how long time we wait,
> the state will not be changed.
> The "transiting" states mean the states whose final state is not yet
> determined. The state keeps to be changed. Only after some time passes,
> we get to know whether the final state will be DVB_CA_SLOTSTATE_RUNNING
> or DVB_CA_SLOTSTATE_INVALID.
> During the "transiting" states, we do not yet know whether the
> CA_RESET operation, which triggered the "transiting" states, will
> succeed or fail. For this reason, during the "transiting" states, if
> another CA_RESET ioctl is called and if this new CA_RESET ioctl
> operation begins again, it will be meaningless and waste time.
> For preventing this problem from happening, we make CA_RESET ioctl do
> nothing and only return EBUSY if the ioctl is called during the
> "transiting" states.
> ---
>  drivers/media/dvb-core/dvb_ca_en50221.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c b/drivers/media/dvb-core/dvb_ca_en50221.c
> index baf64540dc00..2e8aec354b7c 100644
> --- a/drivers/media/dvb-core/dvb_ca_en50221.c
> +++ b/drivers/media/dvb-core/dvb_ca_en50221.c
> @@ -1362,13 +1362,19 @@ static int dvb_ca_en50221_io_do_ioctl(struct file *file,
>                         struct dvb_ca_slot *sl = &ca->slot_info[slot];
>
>                         mutex_lock(&sl->slot_lock);
> -                       if (sl->slot_state != DVB_CA_SLOTSTATE_NONE) {
> +                       if ((sl->slot_state == DVB_CA_SLOTSTATE_RUNNING) ||
> +                           (sl->slot_state == DVB_CA_SLOTSTATE_INVALID)) {
>                                 dvb_ca_en50221_slot_shutdown(ca, slot);
>                                 if (ca->flags & DVB_CA_EN50221_FLAG_IRQ_CAMCHANGE)
>                                         dvb_ca_en50221_camchange_irq(ca->pub,
>                                                                      slot,
>                                                                      DVB_CA_EN50221_CAMCHANGE_INSERTED);
>                         }
> +                       else {
> +                               if (sl->slot_state != DVB_CA_SLOTSTATE_NONE) {
> +                                       err = -EBUSY;
> +                               }
> +                       }
>                         mutex_unlock(&sl->slot_lock);
>                 }
>                 ca->next_read_slot = 0;
> --
> 2.17.1
>

Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[YongSu Yoo]

Dear All

Can you review this patch ?
Can you share how this modification is going ?

2024년 4월 11일 (목) 오후 9:02, YongSu Yoo <yongsuyoo0215@gmail.com>님이 작성:
>
> Dear All
>
> Can you review this patch ?
> Can you share how this modification is going ?
>
> 2024년 3월 8일 (금) 오후 9:13, <yongsuyoo0215@gmail.com>님이 작성:
> >
> > From: Yongsu yoo <yongsuyoo0215@gmail.com>
> >
> > Signed-off-by:Yongsu Yoo <yongsuyoo0215@gmail.com>
> >
> > In source/drivers/media/dvb-core/dvb_ca_en50221.c, if the CA_RESET ioctl
> > is called, in a normal case, the state of the thread of the
> > dvb_ca_en50221_thread_state_machine will transit like below order.
> > DVB_CA_SLOTSTATE_NONE -> DVB_CA_SLOTSTATE_UNINITIALISED ->
> > DVB_CA_SLOTSTATE_WAITREADY -> DVB_CA_SLOTSTATE_VALIDATE ->
> > DVB_CA_SLOTSTATE_WAITFR -> DVB_CA_SLOTSTATE_LINKINIT ->
> > DVB_CA_SLOTSTATE_RUNNING
> > But in some problem cases, the state will become DVB_CA_SLOTSTATE_INVALID.
> > Among the above mentioned states, the DVB_CA_SLOTSTATE_NONE and
> > the DVB_CA_SLOTSTATE_INVALID are "already stablized" states,
> > whereas other states are "transiting" states.
> > The "already stablized" states mean no matter how long time we wait,
> > the state will not be changed.
> > The "transiting" states mean the states whose final state is not yet
> > determined. The state keeps to be changed. Only after some time passes,
> > we get to know whether the final state will be DVB_CA_SLOTSTATE_RUNNING
> > or DVB_CA_SLOTSTATE_INVALID.
> > During the "transiting" states, we do not yet know whether the
> > CA_RESET operation, which triggered the "transiting" states, will
> > succeed or fail. For this reason, during the "transiting" states, if
> > another CA_RESET ioctl is called and if this new CA_RESET ioctl
> > operation begins again, it will be meaningless and waste time.
> > For preventing this problem from happening, we make CA_RESET ioctl do
> > nothing and only return EBUSY if the ioctl is called during the
> > "transiting" states.
> > ---
> >  drivers/media/dvb-core/dvb_ca_en50221.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c b/drivers/media/dvb-core/dvb_ca_en50221.c
> > index baf64540dc00..2e8aec354b7c 100644
> > --- a/drivers/media/dvb-core/dvb_ca_en50221.c
> > +++ b/drivers/media/dvb-core/dvb_ca_en50221.c
> > @@ -1362,13 +1362,19 @@ static int dvb_ca_en50221_io_do_ioctl(struct file *file,
> >                         struct dvb_ca_slot *sl = &ca->slot_info[slot];
> >
> >                         mutex_lock(&sl->slot_lock);
> > -                       if (sl->slot_state != DVB_CA_SLOTSTATE_NONE) {
> > +                       if ((sl->slot_state == DVB_CA_SLOTSTATE_RUNNING) ||
> > +                           (sl->slot_state == DVB_CA_SLOTSTATE_INVALID)) {
> >                                 dvb_ca_en50221_slot_shutdown(ca, slot);
> >                                 if (ca->flags & DVB_CA_EN50221_FLAG_IRQ_CAMCHANGE)
> >                                         dvb_ca_en50221_camchange_irq(ca->pub,
> >                                                                      slot,
> >                                                                      DVB_CA_EN50221_CAMCHANGE_INSERTED);
> >                         }
> > +                       else {
> > +                               if (sl->slot_state != DVB_CA_SLOTSTATE_NONE) {
> > +                                       err = -EBUSY;
> > +                               }
> > +                       }
> >                         mutex_unlock(&sl->slot_lock);
> >                 }
> >                 ca->next_read_slot = 0;
> > --
> > 2.17.1
> >

Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[YongSu Yoo]

Dear All

Can you review this patch ?
Can you share how this modification is going ?

2024년 5월 1일 (수) 오후 4:54, YongSu Yoo <yongsuyoo0215@gmail.com>님이 작성:
>
> Dear All
>
> Can you review this patch ?
> Can you share how this modification is going ?
>
> 2024년 4월 11일 (목) 오후 9:02, YongSu Yoo <yongsuyoo0215@gmail.com>님이 작성:
> >
> > Dear All
> >
> > Can you review this patch ?
> > Can you share how this modification is going ?
> >
> > 2024년 3월 8일 (금) 오후 9:13, <yongsuyoo0215@gmail.com>님이 작성:
> > >
> > > From: Yongsu yoo <yongsuyoo0215@gmail.com>
> > >
> > > Signed-off-by:Yongsu Yoo <yongsuyoo0215@gmail.com>
> > >
> > > In source/drivers/media/dvb-core/dvb_ca_en50221.c, if the CA_RESET ioctl
> > > is called, in a normal case, the state of the thread of the
> > > dvb_ca_en50221_thread_state_machine will transit like below order.
> > > DVB_CA_SLOTSTATE_NONE -> DVB_CA_SLOTSTATE_UNINITIALISED ->
> > > DVB_CA_SLOTSTATE_WAITREADY -> DVB_CA_SLOTSTATE_VALIDATE ->
> > > DVB_CA_SLOTSTATE_WAITFR -> DVB_CA_SLOTSTATE_LINKINIT ->
> > > DVB_CA_SLOTSTATE_RUNNING
> > > But in some problem cases, the state will become DVB_CA_SLOTSTATE_INVALID.
> > > Among the above mentioned states, the DVB_CA_SLOTSTATE_NONE and
> > > the DVB_CA_SLOTSTATE_INVALID are "already stablized" states,
> > > whereas other states are "transiting" states.
> > > The "already stablized" states mean no matter how long time we wait,
> > > the state will not be changed.
> > > The "transiting" states mean the states whose final state is not yet
> > > determined. The state keeps to be changed. Only after some time passes,
> > > we get to know whether the final state will be DVB_CA_SLOTSTATE_RUNNING
> > > or DVB_CA_SLOTSTATE_INVALID.
> > > During the "transiting" states, we do not yet know whether the
> > > CA_RESET operation, which triggered the "transiting" states, will
> > > succeed or fail. For this reason, during the "transiting" states, if
> > > another CA_RESET ioctl is called and if this new CA_RESET ioctl
> > > operation begins again, it will be meaningless and waste time.
> > > For preventing this problem from happening, we make CA_RESET ioctl do
> > > nothing and only return EBUSY if the ioctl is called during the
> > > "transiting" states.
> > > ---
> > >  drivers/media/dvb-core/dvb_ca_en50221.c | 8 +++++++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c b/drivers/media/dvb-core/dvb_ca_en50221.c
> > > index baf64540dc00..2e8aec354b7c 100644
> > > --- a/drivers/media/dvb-core/dvb_ca_en50221.c
> > > +++ b/drivers/media/dvb-core/dvb_ca_en50221.c
> > > @@ -1362,13 +1362,19 @@ static int dvb_ca_en50221_io_do_ioctl(struct file *file,
> > >                         struct dvb_ca_slot *sl = &ca->slot_info[slot];
> > >
> > >                         mutex_lock(&sl->slot_lock);
> > > -                       if (sl->slot_state != DVB_CA_SLOTSTATE_NONE) {
> > > +                       if ((sl->slot_state == DVB_CA_SLOTSTATE_RUNNING) ||
> > > +                           (sl->slot_state == DVB_CA_SLOTSTATE_INVALID)) {
> > >                                 dvb_ca_en50221_slot_shutdown(ca, slot);
> > >                                 if (ca->flags & DVB_CA_EN50221_FLAG_IRQ_CAMCHANGE)
> > >                                         dvb_ca_en50221_camchange_irq(ca->pub,
> > >                                                                      slot,
> > >                                                                      DVB_CA_EN50221_CAMCHANGE_INSERTED);
> > >                         }
> > > +                       else {
> > > +                               if (sl->slot_state != DVB_CA_SLOTSTATE_NONE) {
> > > +                                       err = -EBUSY;
> > > +                               }
> > > +                       }
> > >                         mutex_unlock(&sl->slot_lock);
> > >                 }
> > >                 ca->next_read_slot = 0;
> > > --
> > > 2.17.1
> > >

Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[Dan Carpenter]

On Fri, Mar 08, 2024 at 12:13:38PM +0000, yongsuyoo0215@gmail.com wrote:
> From: Yongsu yoo <yongsuyoo0215@gmail.com>
> 
> Signed-off-by:Yongsu Yoo <yongsuyoo0215@gmail.com>

You've sent several patches that have not recieved any feedback.  Resend
them all as a patchset.

The Signed-off should go at the bottom.  Run your patches through
scripts/checkpatch.pl.

> 
> In source/drivers/media/dvb-core/dvb_ca_en50221.c, if the CA_RESET ioctl
> is called, in a normal case, the state of the thread of the
> dvb_ca_en50221_thread_state_machine will transit like below order.
> DVB_CA_SLOTSTATE_NONE -> DVB_CA_SLOTSTATE_UNINITIALISED ->
> DVB_CA_SLOTSTATE_WAITREADY -> DVB_CA_SLOTSTATE_VALIDATE ->
> DVB_CA_SLOTSTATE_WAITFR -> DVB_CA_SLOTSTATE_LINKINIT ->
> DVB_CA_SLOTSTATE_RUNNING
> But in some problem cases, the state will become DVB_CA_SLOTSTATE_INVALID.
> Among the above mentioned states, the DVB_CA_SLOTSTATE_NONE and
> the DVB_CA_SLOTSTATE_INVALID are "already stablized" states,
> whereas other states are "transiting" states.
> The "already stablized" states mean no matter how long time we wait,
> the state will not be changed.
> The "transiting" states mean the states whose final state is not yet
> determined. The state keeps to be changed. Only after some time passes,
> we get to know whether the final state will be DVB_CA_SLOTSTATE_RUNNING
> or DVB_CA_SLOTSTATE_INVALID.
> During the "transiting" states, we do not yet know whether the
> CA_RESET operation, which triggered the "transiting" states, will
> succeed or fail. For this reason, during the "transiting" states, if
> another CA_RESET ioctl is called and if this new CA_RESET ioctl
> operation begins again, it will be meaningless and waste time.
> For preventing this problem from happening, we make CA_RESET ioctl do
> nothing and only return EBUSY if the ioctl is called during the
> "transiting" states.

A lot of the commit messages are confusing.  It seems from looking at
the patches that you have been testing CA_RESET and fixing the bugs.
Please talk more about how you are finding these bugs?

In this case the bug is that if you call CA_RESET twice before the
first reset has completed then it is a waste of time?  How serious is
this bug for normal users?  How much time are we talking about?

regards,
dan carpenter

Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[YongSu Yoo]

Dear Dan Carpenter

CA_RESET is a very long process.
CA_RESET usually takes around 1 ~ 2 seconds (It depends on the CICAM
brand, some CICAMs take a long time whereas other CICAMs take less
time.
No matter if it takes a long time or less time, if it occurs two
times, its time will become double.
Imagine how bad it is, if your TV's channel changes time and DC-on
time increases more than 2 ~ 4 seconds.
Most of all, it can cause video blinking or video momentarily garbage.
The Kernel controls CA_RESET operation and CA mw also control the CA_RESET.
If the two operations are overlapped (duplicated), this kind of
problem can occur.
I found these bugs while I developed a DVB TV using Linux Kernel.
By adding this solution, I fixed this bug.

2024년 5월 27일 (월) 오후 7:56, Dan Carpenter <dan.carpenter@linaro.org>님이 작성:
>
> On Fri, Mar 08, 2024 at 12:13:38PM +0000, yongsuyoo0215@gmail.com wrote:
> > From: Yongsu yoo <yongsuyoo0215@gmail.com>
> >
> > Signed-off-by:Yongsu Yoo <yongsuyoo0215@gmail.com>
>
> You've sent several patches that have not recieved any feedback.  Resend
> them all as a patchset.
>
> The Signed-off should go at the bottom.  Run your patches through
> scripts/checkpatch.pl.
>
> >
> > In source/drivers/media/dvb-core/dvb_ca_en50221.c, if the CA_RESET ioctl
> > is called, in a normal case, the state of the thread of the
> > dvb_ca_en50221_thread_state_machine will transit like below order.
> > DVB_CA_SLOTSTATE_NONE -> DVB_CA_SLOTSTATE_UNINITIALISED ->
> > DVB_CA_SLOTSTATE_WAITREADY -> DVB_CA_SLOTSTATE_VALIDATE ->
> > DVB_CA_SLOTSTATE_WAITFR -> DVB_CA_SLOTSTATE_LINKINIT ->
> > DVB_CA_SLOTSTATE_RUNNING
> > But in some problem cases, the state will become DVB_CA_SLOTSTATE_INVALID.
> > Among the above mentioned states, the DVB_CA_SLOTSTATE_NONE and
> > the DVB_CA_SLOTSTATE_INVALID are "already stablized" states,
> > whereas other states are "transiting" states.
> > The "already stablized" states mean no matter how long time we wait,
> > the state will not be changed.
> > The "transiting" states mean the states whose final state is not yet
> > determined. The state keeps to be changed. Only after some time passes,
> > we get to know whether the final state will be DVB_CA_SLOTSTATE_RUNNING
> > or DVB_CA_SLOTSTATE_INVALID.
> > During the "transiting" states, we do not yet know whether the
> > CA_RESET operation, which triggered the "transiting" states, will
> > succeed or fail. For this reason, during the "transiting" states, if
> > another CA_RESET ioctl is called and if this new CA_RESET ioctl
> > operation begins again, it will be meaningless and waste time.
> > For preventing this problem from happening, we make CA_RESET ioctl do
> > nothing and only return EBUSY if the ioctl is called during the
> > "transiting" states.
>
> A lot of the commit messages are confusing.  It seems from looking at
> the patches that you have been testing CA_RESET and fixing the bugs.
> Please talk more about how you are finding these bugs?
>
> In this case the bug is that if you call CA_RESET twice before the
> first reset has completed then it is a waste of time?  How serious is
> this bug for normal users?  How much time are we talking about?
>
> regards,
> dan carpenter
>
>

Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[Markus Elfring]

…
> For preventing this problem from happening, we make CA_RESET ioctl do
> nothing and only return EBUSY if the ioctl is called during the
> "transiting" states.

Would you like to avoid any typos (in the summary phrase)?

Regards,
Markus

Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[YongSu Yoo]

Dear Markus Elfring

Initially, I sent this E-mail using the below command
"....git send-email --to  mchehab@kernel.org,
linux-media@vger.kernel.org, xxxxxxxxxxx.patch. ..."

In response to what you suggested, is it OK if I use Gmail and attach
a new patch ?


2024년 5월 28일 (화) 오후 2:38, Markus Elfring <Markus.Elfring@web.de>님이 작성:

>
> …
> > For preventing this problem from happening, we make CA_RESET ioctl do
> > nothing and only return EBUSY if the ioctl is called during the
> > "transiting" states.
>
> Would you like to avoid any typos (in the summary phrase)?
>
> Regards,
> Markus

Re: media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[Markus Elfring]

> In response to what you suggested, is it OK if I use Gmail

It depends on a proper configuration of preferred message tools.

See also:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/email-clients.rst?h=v6.10-rc1#n341


> and attach a new patch ?

Unlikely.

You may respond with subsequent patch versions which contain hopefully
a more appropriate summary phrase and improved change descriptions.

Regards,
Markus

Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[Mauro Carvalho Chehab]

Em Tue, 28 May 2024 21:14:37 +0900
YongSu Yoo <yongsuyoo0215@gmail.com> escreveu:

> Dear Markus Elfring

Please don't top-post. Makes hard to follow the comments.
> 
> 
> 2024년 5월 28일 (화) 오후 2:38, Markus Elfring <Markus.Elfring@web.de>님이 작성:
> 
> >
> > …  
> > > For preventing this problem from happening, we make CA_RESET ioctl do
> > > nothing and only return EBUSY if the ioctl is called during the
> > > "transiting" states.  
> >
> > Would you like to avoid any typos (in the summary phrase)?

> Initially, I sent this E-mail using the below command
> "....git send-email --to  mchehab@kernel.org,
> linux-media@vger.kernel.org, xxxxxxxxxxx.patch. ..."

Git send-email is a good way to send patches. You may also use
a decent e-mail client that won't mangle with whitespaces. I use
myself claws-mail; other develpers use emacs. Feel free to pick your
poison, but if the email doesn't handle whitespaces well and/or
don't allow writing the answers below the original comments (instead
of top-posting), it shouldn't be used.

> In response to what you suggested, is it OK if I use Gmail and attach
> a new patch ?

No. Never attach a patch as the mailing list will reject, and if not,
patchwork.linuxtv.org won't pick it.

You may use gmail, if you setup your e-mail client to use it as a
SMTP server. Using webmail solutions typically won't work open source
discussions, as it does lots of wrong things, like top-posting, not
honoring 80 columns on emails and/or mangling tabs and white spaces.

Thanks,
Mauro

Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[Mauro Carvalho Chehab]

Em Sat, 1 Feb 2025 09:44:18 +0900
YongSu Yoo <yongsuyoo0215@gmail.com> escreveu:

> Dear Mauro Carvalho Chehab
> 
> I know how to send an E-mail using "....git send-email --to .."
> But,
> I do not know how to reply to this E-mail loop using "....git send-email
> --to .."
> Can you kindly guide me ?

Never used git send-email to reply, as it is mainly focused on sending
e-mails, not being a true emailer: it just sends e-mail: it doesn't
receive. In thesis, you could download the original e-mail using b4 or lei, 
then manually write a reply text on it and use git send-email. This is
easier said than done, as you'll need to take care of SMTP headers yourself.
This would require some knowledge about SMTP RFCs.

If I were you, I would seek for some other alternatives.

Most people use mutt for Kernel work, as it is CLI. There is also alpine
I haven't used alpine for ages, but it is a decent CLI e-mail client, using
a very simple interface, although it has less features than mutt.

I prefer instead to use claws-mail as it has a reasonable GUI, it is fast
and it is not overbloated with features I won't use.

Neither mutt, alpine or claws-mail mangle whitespaces and line breaks on
e-mails, and they can be setup to not do top-postings.

If you want something simpler, perhaps you could try notmuch[1]. I never
tried myself, but I heard it can be used to reply to e-mails without even
needing to subscribe to a ML.

[1] https://notmuchmail.org/

You may also find useful to have a SMTP relay server. Probably one of the
simplest ones to setup is msmtp: https://marlam.de/msmtp/.

I hope that helps.

Regards,
Mauro


> 
> 2024년 5월 31일 (금) 오전 3:31, Mauro Carvalho Chehab <mchehab@kernel.org>님이 작성:
> 
> > Em Tue, 28 May 2024 21:14:37 +0900
> > YongSu Yoo <yongsuyoo0215@gmail.com> escreveu:
> >  
> > > Dear Markus Elfring  
> >
> > Please don't top-post. Makes hard to follow the comments.  
> > >
> > >
> > > 2024년 5월 28일 (화) 오후 2:38, Markus Elfring <Markus.Elfring@web.de>님이 작성:
> > >  
> > > >
> > > > …  
> > > > > For preventing this problem from happening, we make CA_RESET ioctl do
> > > > > nothing and only return EBUSY if the ioctl is called during the
> > > > > "transiting" states.  
> > > >
> > > > Would you like to avoid any typos (in the summary phrase)?  
> >  
> > > Initially, I sent this E-mail using the below command
> > > "....git send-email --to  mchehab@kernel.org,
> > > linux-media@vger.kernel.org, xxxxxxxxxxx.patch. ..."  
> >
> > Git send-email is a good way to send patches. You may also use
> > a decent e-mail client that won't mangle with whitespaces. I use
> > myself claws-mail; other develpers use emacs. Feel free to pick your
> > poison, but if the email doesn't handle whitespaces well and/or
> > don't allow writing the answers below the original comments (instead
> > of top-posting), it shouldn't be used.
> >  
> > > In response to what you suggested, is it OK if I use Gmail and attach
> > > a new patch ?  
> >
> > No. Never attach a patch as the mailing list will reject, and if not,
> > patchwork.linuxtv.org won't pick it.
> >
> > You may use gmail, if you setup your e-mail client to use it as a
> > SMTP server. Using webmail solutions typically won't work open source
> > discussions, as it does lots of wrong things, like top-posting, not
> > honoring 80 columns on emails and/or mangling tabs and white spaces.
> >
> > Thanks,
> > Mauro
> >  



Thanks,
Mauro

Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

[Mauro Carvalho Chehab]

Em Sat, 1 Feb 2025 09:24:27 +0100
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:

> Em Sat, 1 Feb 2025 09:44:18 +0900
> YongSu Yoo <yongsuyoo0215@gmail.com> escreveu:
> 
> > Dear Mauro Carvalho Chehab
> > 
> > I know how to send an E-mail using "....git send-email --to .."
> > But,
> > I do not know how to reply to this E-mail loop using "....git send-email
> > --to .."
> > Can you kindly guide me ?  
> 
> Never used git send-email to reply, as it is mainly focused on sending
> e-mails, not being a true emailer: it just sends e-mail: it doesn't
> receive. In thesis, you could download the original e-mail using b4 or lei, 
> then manually write a reply text on it and use git send-email. This is
> easier said than done, as you'll need to take care of SMTP headers yourself.
> This would require some knowledge about SMTP RFCs.
> 
> If I were you, I would seek for some other alternatives.
> 
> Most people use mutt for Kernel work, as it is CLI. There is also alpine
> I haven't used alpine for ages, but it is a decent CLI e-mail client, using
> a very simple interface, although it has less features than mutt.
> 
> I prefer instead to use claws-mail as it has a reasonable GUI, it is fast
> and it is not overbloated with features I won't use.
> 
> Neither mutt, alpine or claws-mail mangle whitespaces and line breaks on
> e-mails, and they can be setup to not do top-postings.
> 
> If you want something simpler, perhaps you could try notmuch[1]. I never
> tried myself, but I heard it can be used to reply to e-mails without even
> needing to subscribe to a ML.
> 
> [1] https://notmuchmail.org/
> 
> You may also find useful to have a SMTP relay server. Probably one of the
> simplest ones to setup is msmtp: https://marlam.de/msmtp/.
> 
> I hope that helps.

Btw, there's a chapter at Kernel documentation related to e-mail
clients:

https://www.kernel.org/doc/html/latest/process/email-clients.html

> 
> Regards,
> Mauro
> 
> 
> > 
> > 2024년 5월 31일 (금) 오전 3:31, Mauro Carvalho Chehab <mchehab@kernel.org>님이 작성:
> >   
> > > Em Tue, 28 May 2024 21:14:37 +0900
> > > YongSu Yoo <yongsuyoo0215@gmail.com> escreveu:
> > >    
> > > > Dear Markus Elfring    
> > >
> > > Please don't top-post. Makes hard to follow the comments.    
> > > >
> > > >
> > > > 2024년 5월 28일 (화) 오후 2:38, Markus Elfring <Markus.Elfring@web.de>님이 작성:
> > > >    
> > > > >
> > > > > …    
> > > > > > For preventing this problem from happening, we make CA_RESET ioctl do
> > > > > > nothing and only return EBUSY if the ioctl is called during the
> > > > > > "transiting" states.    
> > > > >
> > > > > Would you like to avoid any typos (in the summary phrase)?    
> > >    
> > > > Initially, I sent this E-mail using the below command
> > > > "....git send-email --to  mchehab@kernel.org,
> > > > linux-media@vger.kernel.org, xxxxxxxxxxx.patch. ..."    
> > >
> > > Git send-email is a good way to send patches. You may also use
> > > a decent e-mail client that won't mangle with whitespaces. I use
> > > myself claws-mail; other develpers use emacs. Feel free to pick your
> > > poison, but if the email doesn't handle whitespaces well and/or
> > > don't allow writing the answers below the original comments (instead
> > > of top-posting), it shouldn't be used.
> > >    
> > > > In response to what you suggested, is it OK if I use Gmail and attach
> > > > a new patch ?    
> > >
> > > No. Never attach a patch as the mailing list will reject, and if not,
> > > patchwork.linuxtv.org won't pick it.
> > >
> > > You may use gmail, if you setup your e-mail client to use it as a
> > > SMTP server. Using webmail solutions typically won't work open source
> > > discussions, as it does lots of wrong things, like top-posting, not
> > > honoring 80 columns on emails and/or mangling tabs and white spaces.
> > >
> > > Thanks,
> > > Mauro
> > >    
> 
> 
> 
> Thanks,
> Mauro



Thanks,
Mauro