Linux-Media Archive mirror
 help / color / mirror / Atom feed
From: YongSu Yoo <yongsuyoo0215@gmail.com>
To: mchehab@kernel.org, yongsuyoo0215@gmail.com, v4bel@theori.io,
	 linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET
Date: Wed, 1 May 2024 16:54:37 +0900	[thread overview]
Message-ID: <CANXPkT7Sv3TSNaPuPMVdpST4vGYZrvh+cfuEX7WjO+i0SP__PA@mail.gmail.com> (raw)
In-Reply-To: <CANXPkT6Bcj0Xbn308jNGp-vqTEcB9LKtUjZ1_zS-tc7KuBEMwA@mail.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
> >

      reply	other threads:[~2024-05-01  7:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-08 12:13 [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET yongsuyoo0215
2024-04-11 12:02 ` YongSu Yoo
2024-05-01  7:54   ` YongSu Yoo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANXPkT7Sv3TSNaPuPMVdpST4vGYZrvh+cfuEX7WjO+i0SP__PA@mail.gmail.com \
    --to=yongsuyoo0215@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=v4bel@theori.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).