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
