Received-SPF: pass (google.com: domain of linux-kernel+bounces-190722-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240308121338.1983-1-yongsuyoo0215@gmail.com> <e5e1b2cc-6e21-41d5-bfb7-f0f7cf8c6ed4@moroto.mountain>
In-Reply-To: <e5e1b2cc-6e21-41d5-bfb7-f0f7cf8c6ed4@moroto.mountain>
From: YongSu Yoo <yongsuyoo0215@gmail.com>
Date: Mon, 27 May 2024 22:32:56 +0900
Message-ID: <CANXPkT5EndLDXLqR070KtiPQX-dmkZcFtBUFHiEtFPRODXvY2g@mail.gmail.com>
Subject: Re: [PATCH] media: dvb_ca_en50221: Add a returing EBUSY logic into CA_RESET
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: mchehab@kernel.org, v4bel@theori.io, linux-media@vger.kernel.org, 
	linux-kernel@vger.kernel.org, yongsu.yoo@lge.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=EB=85=84 5=EC=9B=94 27=EC=9D=BC (=EC=9B=94) =EC=98=A4=ED=9B=84 7:56, D=
an Carpenter <dan.carpenter@linaro.org>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=
=B1:
>
> 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 ioct=
l
> > 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_INVAL=
ID.
> > 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
>
>