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@xxxxxxxxxx>님이 작성: > > On Fri, Mar 08, 2024 at 12:13:38PM +0000, yongsuyoo0215@xxxxxxxxx wrote: > > From: Yongsu yoo <yongsuyoo0215@xxxxxxxxx> > > > > Signed-off-by:Yongsu Yoo <yongsuyoo0215@xxxxxxxxx> > > 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 > >
