diff mbox series

media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET

Message ID 20240308121338.1983-1-yongsuyoo0215@gmail.com (mailing list archive)
State New
Headers
Series media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET |

Commit Message

YongSu Yoo March 8, 2024, 12:13 p.m. UTC 
  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(-)

Comments

YongSu Yoo April 11, 2024, 12:02 p.m. UTC | #1 
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
>
YongSu Yoo May 1, 2024, 7:54 a.m. UTC | #2 
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
> >
YongSu Yoo May 23, 2024, 1:16 p.m. UTC | #3 
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
> > >
Dan Carpenter May 27, 2024, 10:56 a.m. UTC | #4 
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
YongSu Yoo May 27, 2024, 1:32 p.m. UTC | #5 
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
>
>
Markus Elfring May 28, 2024, 5:37 a.m. UTC | #6 
…
> 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
YongSu Yoo May 28, 2024, 12:14 p.m. UTC | #7 
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
Markus Elfring May 28, 2024, 12:35 p.m. UTC | #8 
> 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
Mauro Carvalho Chehab May 30, 2024, 6:31 p.m. UTC | #9 
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
diff mbox series

Patch

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;